Cognition's Devin Fusion describes a two-agent harness. One is an expensive frontier model (the lead) which plans, decides, and reviews, while the second, a cheaper model (the sidekick) does the mechanical work. Their post ends with an open invitation. Provider prompt caches mostly expire after 5 minutes of inactivity, and whenever one agent works the other idles, so the reader is encouraged to think about how to engineer around this.
The stakes are easy to state. A lead agent carries a context that grows into the hundreds of thousands of tokens. While the sidekick works, that context sits in a cache with a 5-minute fuse. If it expires, the next lead turn re-writes the whole thing at full price, which on Anthropic API costs 12.5 times more than a cached read of the same tokens. A single expiry can wipe out what the delegation saved.
I spent a quite some time building a solution and an answer. It splits into two separate questions: how to keep or cheaply rebuild the cache (an economics problem), and what the lead should do with the idle time so the spend buys more than warmth (a harness design problem).
Everything the harness can do about an idle context of C tokens comes down to four actions, and every one of them has a documented price:
| Action | Cost on Anthropic | Wins when |
|---|---|---|
| Let the cache die | 1.25C re-write at next use | Very long idles |
| Heartbeat pings | 0.1C per ping, one per ~4.5 min | Idles up to ~55 min |
| Pay for the 1-hour TTL at write time | 2C once | Long idles known in advance |
| Let it die, compact on resume | C read + summary + 1.25C' write | Compaction was due anyway |
The break-evens fall straight out of the multipliers. Heartbeats beat re-writing while n pings x 0.1C stays under 1.25C, so under 12.5 ping intervals, roughly 55 minutes of idle. The 1-hour tier costs 0.75C more than a normal write, which is about 8 ping intervals, so it wins when a 35-minute-plus idle is predictable at write time. The last action never triggers compaction early just to save cache cost; it only applies when the harness was going to compact anyway, in which case the unavoidable cache miss is the free moment to do it.
A scheduler that picks the cheapest expected action needs one input: an estimate of how long the idle will last. That estimate turned out to be the whole game.
The code repository contains a trace-driven simulator that replays synthetic delegation traces (loosely calibrated to Cognition's published Fable-vs-Opus aggregates) and compares five policies, from naive (always let the cache die) to an oracle that knows the true idle duration. Three results stood out.
Simulators are only as good as their constants, so I verified the mechanism against the real Anthropic API on the cheapest model, with a 6,457-token cached prefix:
| Step | Wall time | cache_creation | cache_read |
|---|---|---|---|
First request (explicit cache_control breakpoint) |
0:00 | 6,457 | 0 |
| Immediate follow-up | 0:06 | 0 | 6,457 |
Pre-warm ping 1 (max_tokens: 0) |
4:09 | 0 | 6,457 |
Pre-warm ping 2 (max_tokens: 0) |
8:11 | 0 | 6,457 |
| Real request, past the original 5-min TTL | 9:14 | 0 | 6,457 |
| Control request after 5.5 min with no pings | 14:48 | 6,457 | 0 |
The pings billed zero output tokens and refreshed the TTL, exactly as documented. Without them, the cache expired and the same request paid a full re-write. The whole run cost $0.019, and the script is in the repository so anyone can re-run it with their own key.
One implementation detail bit harder than expected: the pre-warm must place an explicit
cache_control breakpoint on the shared prefix. Rely on automatic caching and the entry gets keyed
to the ping's placeholder message, so real traffic never hits it. You pay for a cache nobody reads.
Keeping the cache warm is bookkeeping. The sharper question is whether the lead's idle turns can do useful work, because a heartbeat ping and a productive turn cost nearly the same infrastructure: both touch the warm prefix.
The bar I set: an idle turn is only worth its tokens if it removes work from the critical path after the sidekick returns. Compacting, summarizing, and re-planning fail that bar; they are maintenance, and nothing downstream gets faster.
The candidate I would bet on is pre-writing the verification plan. At delegation time the lead already knows the acceptance criteria. While the sidekick works, the lead spends one turn drafting the concrete review checklist for the in-flight change: what to check, which commands to run, what the tests should show. When the sidekick returns, review starts immediately instead of burning a turn or two on re-orientation. And that turn doubles as a heartbeat, so the keep-warm cost and the useful work are the same spend.
The obvious failure mode is staleness. If the sidekick's approach diverges from what the lead assumed, a stale plan is worse than none. So the plan splits into invariant acceptance criteria, which survive any implementation, and approach-conditional checks, which get validated against the sidekick's actual change summary on return and regenerated on mismatch. The worst case then reduces to the no-plan world, since the regeneration turn was going to be spent anyway.
The accounting makes this falsifiable rather than hand-wavy. The plan costs about 7,500 input-token equivalents per delegation. A valid plan saves around 1.5 post-return turns at roughly 8,000 tokens each. At an assumed 30% staleness rate, that nets +900 tokens per delegation, and the idea flips negative once more than 37.5% of plans go stale. That staleness rate is directly measurable from replayed delegation traces, so the hypothesis has a clean pass/fail condition.
The verification-plan result is accounting on top of simulation, not a live harness experiment; the real test needs a lead-plus-sidekick setup and replayed delegations, measured against that 37.5% threshold. I also considered mid-flight checkpoint review of the sidekick's work and decided against leading with it: Cognition's own Fable-vs-Opus data shows the expensive failure pattern was precisely a lead that keeps pulling sidekick work back into context. If tested at all, it should be one checkpoint, only on high-judgment handoffs, scored against a no-checkpoint baseline. And the live verification covers Anthropic so far; the OpenAI script is written but not yet run due to budget constraints.
The 5-minute cache expiry looks like an infrastructure nuisance, but it decomposes into a small, fully-priced decision problem with break-evens you can compute on paper and verify for two cents. The simulation's most useful output was negative: the clever scheduler mostly ties a one-line static rule, and only earns its complexity where a provider offers something the rule cannot reach. And the idle time itself is the more interesting frontier. If the lead can reliably pre-write the review of work that has not landed yet, the cache heartbeat stops being overhead and becomes the delivery vehicle for genuinely useful turns.
Everything here can be reproduced from the repository: 22 unit tests against hand-computed break-evens, the simulator with all its knobs exposed, and the live experiment script. If you work on agent harnesses and see something that contradicts your production numbers, I would genuinely like to hear about it. Please reach out to me at taneemishere@gmail.com.