Proof — reproducible continuity tests
Reproducible, not rhetorical.
Renitor's claim is that a coding task survives when one agent stops — and that you can see what carried over. That's testable. Below is a deterministic benchmark you can run yourself, exactly what it checks, and — honestly — what it does and doesn't prove.
Measured locally on v1.73.7. Reproduce every number below with two commands — no account, no quota.
The continuity benchmark
Ten "the agent stopped here" situations run through the same code path the product uses to build a handoff. For each, we measure how completely the task state was captured — and assert that no secret ever leaks into the handoff. Deterministic: same input, same result, every time.
| Scenario | Readiness | Changed files captured | Secrets exposed |
|---|---|---|---|
| Quota hit before any edit | 88/100 | 0 | 0 |
| Quota hit after one edit | 88/100 | 1 | 0 |
| Quota hit after a failing test | 93/100 | 2 · test state captured | 0 |
| Multi-file refactor interrupted | 95/100 | 4 · decisions captured | 0 |
| Stopped with uncommitted changes | 88/100 | 2 | 0 |
| Model's summary contradicts the diff | 88/100 | 1 · observed file list wins | 0 |
| Session trace unavailable | 69/100 | 1 · goal flagged as missing | 0 |
| .env contains secrets | 90/100 | 1 · secret redacted | 0 |
| Unrelated dirty files present | 88/100 | 2 | 0 |
| Destination has a smaller context window | 88/100 | 30 · diff bounded to budget | 0 |
Every readiness score is evidence-linked: it counts what was actually captured — goal, branch, HEAD commit, changed files, failing commands, test state, decisions, redactions — and an inferred goal is always labelled inferred, never presented as stated fact.
npm ci npm run bench:continuity # 10 scenarios · asserts 0 secret exposures · exits non-zero on any leak
The benchmark ships inside the extension source (benchmarks/continuity/) and runs as part of the test suite. The public reproduction repository — with the recorded Claude → Codex → Claude run, the CI badge, and a clickable methodology file — opens when the extension is published. Until then, these are Renitor's own locally-measured results, reproducible the moment the source is in your hands.
Context survives the conversation — not just the handoff.
The benchmark above proves a task transfers between agents. This one proves a task keeps its whole memory inside one chat: a constraint you state at turn 1 still reaches the model deep into a long conversation. It drives the same code path the chat uses to build every request over threads of 40, 60, 100 and 200 turns.
| Conversation | Messages sent to the model | Older turns folded to a summary | Turn-1 constraint |
|---|---|---|---|
| 40 turns · full window | 82 | 0 | kept |
| 60 turns · full window | 122 | 0 | kept |
| 100 turns · full window | 202 | 0 | kept |
| 200 turns · full window | 402 | 0 | kept |
| 200 turns · tight window (forced overflow) | 106 | 296 · folded to a durable summary | kept |
The whole conversation is sent, compacted only when it genuinely won't fit — and when older turns are folded they become a durable summary, never a silent drop. A fixed "last-N-messages" cap would have lost the turn-1 constraint on every row past ~20 turns.
npm ci npm run bench:context # 5 conversations up to 200 turns · exits non-zero if any early constraint is lost
Ships in the extension source (benchmarks/context-window/) and is guarded at the wire by a flight-simulator scenario that drives a real chat past 40 turns and checks the request each model actually receives.
What this proves — and what it doesn't.
That the handoff captures the task state with high fidelity — goal, changed files, branch/commit, failures, decisions — across the failure modes that actually happen, and that secret redaction holds (0 exposures across every scenario). Deterministic and reproducible on your machine.
It measures capture fidelity, not task success. It does not claim a destination model will always finish the job — that depends on the model. It's an honest readiness estimate, not a guarantee, and it doesn't bypass any provider's limits.
The benchmark runs the real `renderHandoff` + record builder — not a mock. It's part of the test suite (247 automated checks), and it fails the build if a secret ever leaks. The methodology is open in docs/continuity-benchmark.md.
The round-trip, on a real repo.
Beyond the benchmark, the flagship handoff is demonstrated end-to-end: a task starts on Claude, a limit hits, work detours through Codex, and Claude resumes — carrying the goal, diff, failures and decisions across. The full transcript, with the exact prompts to reproduce it, lives in the docs.
Verified on this repo: running the handoff against Renitor's own codebase produced a 88/100 continuation record that correctly counted 22 changed files, pinned the branch and HEAD commit, and flagged the recovered goal as inferred — confirm before continuing rather than asserting it as fact. That's the same record every handoff writes to .renitor/continuity/.
A public, fully-recorded end-to-end run — starting commit, prompts, generated record, resulting diff and test output — is being prepared as a standalone reproducible case. Until it's published here, the benchmark above is the systematic evidence, and the docs carry the step-by-step reproduction.
Your machine keeps the receipt.
Separate from the benchmark: Renitor counts — locally, on your machine — every provider limit it survived and every token it ran on a free model, priced at paid rates. These are your measured numbers, not ours, and they never leave your machine. Treat them as a local estimate, not a marketing figure.
Run it yourself.
The strongest proof is the one you reproduce. Get the free beta, generate a handoff, and read the readiness section it writes for your own repo.