feat(pair): pair_reset gives the executor a fresh context

[rynfar]

What

A new pair tool, pair_reset, starts the executor over with an empty context: same model, same runtime mode, the lead's current branch and worktree, and the pair stays on. The executor's transcript is deleted; the files it changed are untouched.

Why

One executor serves every brief of a pair, so its context only grows. The first executor used for real work ended a day at 126k of 128k tokens. Until now the only way out was to turn the pair off and on again from the UI.

How

• There is no command that starts a thread's provider session afresh, and adding one would mean contract and decider changes. The reset deletes the executor thread and creates it again under the same id, which the composer's off-then-on toggle already proved works.
• Refused while the executor is running (PairExecutorBusyError); PairNotActiveError without an active pair; a no-op returning reset: false for an executor that never ran.
• Both commands use unique ids. The first create of a pair has the fixed id server:mcp-pair-create:<executor>, and reusing it would replay that receipt as a success and create nothing.
• Between the delete and the create it waits on ThreadDeletionReactor.drainThrough. That reactor stops the old provider session after thread.deleted; the new thread has the same id, so without the wait a brief sent straight after a reset could have its new session stopped. This was a lead correction after review, with a test that records the order: delete, reactor drained, create.
• Accepts the pair or delegation capability, like the other tools that drive an existing pair. The protocol tells the lead when to use it and that the next brief must stand on its own. Work-log label added.

Verification

• vp test run on apps/server/src/mcp, apps/server/src/orchestration, RuntimeInstructions.test.ts and the work-log presentation tests: 1133 passed. Six tests were written first and seen failing.
• Typecheck t3 and @t3tools/client-runtime: 0 errors. Lint, format and vp run knip:check clean.
• Not run live: the running install predates the tool.

How it was built

Third change made through pair mode on a real install: Claude lead, Antigravity executor, one shared worktree, four files protected (checked 4, changed []). The executor's final message was a raw Antigravity task notification rather than the requested report, so the review was done from git diff alone.

Part of #622.

Model: Claude Fable 5.1 (lead) with an Antigravity executor, paired in Pylon via the Claude Code harness.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pylon-marketing	Ready	Preview	Sep 18, 2026 10:11pm UTC

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.9 KiB	14.0 KiB	+16 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.2 KiB	7.2 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.7 KiB	6.7 KiB	+12 B (+0.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	58.0 KiB	58.0 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.9 KiB	14.0 KiB	+28 B (+0.2%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.2 KiB	7.2 KiB	−2 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.7 KiB	6.7 KiB	+30 B (+0.4%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.8 KiB	58.9 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	8	9	+1 (+12.5%)	21	✅

Baseline: 1045c63 · PR result: 2f7ef67 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 115.6 KiB
• Claude decoded thread snapshot: 116.3 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[vercel]

Deployment failed for project pylon-marketing with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/pylon-code?upgradeToPro=build-rate-limit

[rynfar]

Merging with the Vercel preview check red: it failed with build-rate-limit (the account's build quota, tracked in #655), not because of this change, which touches no marketing or hosted-web code. Every code check is green: Check, Test, Test Server 1 to 3, Rust, release smoke and the packaged desktop smokes.