Comparing changes

… spike Companion to the thin.ly gateway change (serve moonshotai/kimi-k3 as a selectable Pro model). That ships without an editor release; these are the editor-side pieces. - providers/catalog.js — a CAPS row for moonshotai/kimi-k3 (1M context). The roster feeds the PICKER's context, but the in-run meter reads local CAPS and would otherwise default to 200K and warn "full" 5× too early. No `fast` (a 2.8T reasoning model is a poor ghost-text completer). tools:true matches K3's agentic intent — flip to false ONLY if the spike (below) shows it breaks the tool loop. - test/catalog.test.js — pins the 1M resolution. - scripts/kimi-k3-spike.js — the reasoning-loop validation (docs/KIMI-K3.md §3). K3 is always-on reasoning and the OpenAI-compat agent path drops the separate reasoning field; deepseek-reasoner is tools:false for exactly this, and K3 has no non-reasoning fallback. The spike drives the REAL streamOpenAIAgentTurn twice, building turn 2 as agent.js does (assistant tool_use, reasoning dropped, then tool_result), and prints PASS/FAIL. Defaults to the Path-B route (OpenRouter) so it validates production; needs the gateway's OPENROUTER_API_KEY, no user key. - docs/KIMI-K3.md — the full scope + implementation plan: both integration paths, the OpenRouter routing reality, the 4× cost, the capacity caveat, the spike, tests. Verified: client suites green; node --check + a standalone load of the spike (no vscode dependency); the spike's no-key path exits 2 with guidance. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

… ctx = 2^20 Addresses the PR #26 review (Copilot). - Stage 1's 60s timeout timer wasn't cleared if the initial fetch threw (DNS/auth) — the empty `finally` only "kept the timer for the stream". Wrapped fetch + the !ok return + the stream in a single try/finally that always calls `to.done()`, so the timer is cleared on a throw, an early return, or a normal end, and its abort can't fire spuriously. - The verdict used `/42/`, which false-positives on "142", "420", or prose like "…in 42 steps". Since the prompt asks for ONLY the number, tightened to `^\D*42\D*$` — 42 must be the sole number in the answer. Verified: accepts "42" / "42." / "= **42**"; rejects "142" / "420" / "1420" / mixed-digit prose. - docs/KIMI-K3.md said the context is "1,000,000 tokens" while the shipped caps (and their test) use 1,048,576 (2^20, what OpenRouter serves). Aligned the §2 table and the Path A caps example to 1,048,576 so a future edit can't "fix" the doc into breaking the meter alignment. Verified: node --check passes; the no-key path still exits 2 with guidance. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

feat(ai): Kimi K3 editor support — context meter, plan doc, reasoning spike

Addresses the PR #27 review (Copilot). The guard is named/documented as a byte cap (MAX_BYTES / maxBytes) but checked `trimmed.length` — UTF-16 code units. For non-ASCII pastes that undercounts the real size (a CJK char is 1 code unit but 3 UTF-8 bytes), so a payload up to ~3× the intended cap could slip past and get parsed/stringified on paste, defeating the ext-host-stall protection. Switched the check to Buffer.byteLength(trimmed, 'utf8') so the cap means what its name says, and added a regression test: a JSON blob whose .length is under the cap but whose byte size is over it is now blocked (and still beautifies when the cap is raised above its byte size). Verified: 13 tests pass; a 58-code-unit / 158-byte payload is now too-large at maxBytes=100, where a .length guard would have parsed it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

JSON beautify on paste

Navigation Menu

Uh oh!

Comparing changes

Open a pull request

Commits on Jul 21, 2026

This comparison is taking too long to generate.

Uh oh!