Back to all posts

Usage Limit Reached Is No Longer a Limit

Tony Young avatar Tony Young
Usage Limit Reached Is No Longer a Limit

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"

A Claude Code session reasoning about a test fix, then hitting a red "Usage limit reached — you've hit your org's monthly spend limit" banner.
Usage limit reached. You've hit your org's monthly spend limit

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

Waiting-skeleton meme captioned "Waiting for my org's monthly spend limit to reset so I can finish the last 20%."

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 — 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

The Capacitor dashboard showing the interrupted Claude session "Build feature support matrix for coding agents": 17.8M cumulative tokens, +53,496/−15,567 lines changed, 11,834 tool calls, marked Active, with a seven-turn trace.
The interrupted Claude session, fully recorded in Capacitor

So I opened Codex, pasted the session URL from Capacitor, and typed: "Recap session … and continue"

Codex prompted with "Recap session <Capacitor URL> and continue", replying that it will use the kcap recap skill to retrieve the session and continue its unfinished work.
Codex picks up the session via the kcap recap skill

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:

Codex running two kcap recap tool calls, about $0.16 total, and concluding the continuation point: finish the July 15 matrix refresh against origin/main, diffing from commit 1cdfcdd1.
Codex retrieves the continuation point and verifies workspace state

Two recap calls, about six seconds each, roughly $0.16. From those it concluded: "The continuation point is clear…"

Sleeping-Shaq meme: "17.8M tokens to do the work" (asleep) versus "67.4K tokens to recover all of it" (wide awake).

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

Epic-handshake meme with two clasped arms labeled "Claude" and "Codex" and the handshake itself labeled "Capacitor."

The Capacitor sidebar afterward tells the whole story in two cards:

The Capacitor sidebar with two session cards for the same PR #1103: a Codex / gpt-5.6 resume session at 67.4K tokens above the original Claude / opus session at 17.8M tokens.
Claude and Codex sessions, side by side, same PR

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

Three-Spider-Men-pointing meme with the three identical figures labeled "Claude", "Codex", and "Copilot."

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 and get started with Capacitor today