Usage Limit Reached Is No Longer a Limit

A developer's Claude session hit a usage limit at 80% completion, but a second agent from a different vendor, Codex, finished the work in 15 minutes for $0.16 by reading only 0.4% of Claude's 17.8M-token session via Capacitor's event log, which stores sessions as immutable, vendor-neutral streams. The handoff required no re-explanation, and the PR merged on schedule, demonstrating that session state outlives the original agent harness.

My Claude session died at 80% done - usage limit reached, mid-fix, no warning. A different agent, from a different vendor, finished the work fifteen minutes later, having read 0.4% of what Claude wrote, and I re-explained nothing. It cost me sixteen cents. Here's how Tuesday afternoon. Claude and I are deep in a session hardening the test suite for a feature that needs to ship today, and Claude is mid-sentence reading code to fix a bug. Then the dreaded " Usage limit reached " No warning, no graceful wind-down. One moment the agent is reasoning about constructor injection, the next it's telling me to go ask my admin for more credits. The work was roughly 80% done, the remaining 20% was fully specified in the agent's own reasoning, and all of it was now trapped inside a session I could no longer continue What this used to cost A year ago this was a genuinely bad afternoon. The context — every hypothesis tried, every test that failed and why, the exact continuation point — lived in one vendor's session state. My options were to wait for the limit to reset, beg an admin, or open a different agent and spend an hour re-explaining everything from memory, inevitably worse than the original. Agents don't just hold code changes; they hold ruled-out approaches . Lose those and the new agent cheerfully re-tries everything the old one already disproved What it actually cost Every session my agents run is recorded by Capacitor https://capacitor.kurrent.io — full transcript, tool calls, diffs, turn by turn — as an event stream. The Claude session that just died wasn't gone. It was sitting in my dashboard with everything intact: 17.8M cumulative tokens, +53,496/−15,567 lines changed, 11,834 tool calls, all turns traceable down to individual tool invocations So I opened Codex, pasted the session URL from Capacitor, and typed: " Recap session … and continue " Codex read the Kcap Recap skill and got to work. And this is the part worth slowing down for, because it didn't slurp 17.8 million tokens of transcript into its context window. It asked Capacitor for just the tail of the final turn — the concluding state and next steps — then verified the actual workspace against git before trusting anything: Two recap calls, about six seconds each, roughly $0.16. From those it concluded: "The continuation point is clear…" That is an agent from a different vendor, running a different model, correctly identifying where another agent left off — including which commit to diff against — without me explaining anything. The entire resume session ran on 67.4k cumulative tokens. The original burned 17.8M. The handoff needed 0.4% of the context to recover 100% of the work Two agents, one PR The Capacitor sidebar afterward tells the whole story in two cards: Same repo, same PR, two harnesses, two vendors. Claude did the heavy lifting; Codex ran the anchor leg. The PR merged, the feature shipped, and my afternoon stayed on schedule despite my org's finance settings having other plans Why this works at all The unglamorous answer is that Capacitor doesn't store "memory" as a pile of markdown files or a vendor-specific context blob. Every session is in an immutable, append-only event log. That's what makes the recap skill possible: an agent can query exactly the slice it needs — one turn, one tail, one decision — instead of replaying everything or trusting a summary someone wrote before knowing what would matter. And because the log is vendor-neutral, the agent asking doesn't have to be the agent that wrote it Usage limits, outages, a colleague going on holiday mid-feature — the interruption doesn't matter. The session outlives the harness that ran it One more thing The feature that shipped in that PR? It's the work that lets GitHub Copilot participate as a code reviewer in Capacitor. So yes: the work that got interrupted, handed off, and finished by a second agent was the work that adds a third agent to the review flows. There's probably a lesson in there about delegation And by the way, Copilot can now act as a code reviewer using Review Flows. If you don't know what that means, check out the Flows docs https://capacitor.kurrent.io/docs/using/review-flows/ and get started with Capacitor today