Failover is sticky. The cache is not.

On 12 September 2026 a terminal coding agent called GoatCode went up on Hacker News. It ships as a single 85 MB binary, talks to 180+ providers, and its headline feature is that when your quota dies it does not stop:

"GoatCode retries the provider, then walks your fallback chain live — switches, says so, and finishes the answer."

And then the sentence that matters more than any of that:

"The switch is sticky: the next launch starts on the provider that worked."

The same README advertises prompt caching in the comparison table — sessions "up to 90% cheaper", "repeated context bills at 10% of input price", savings shown live in /cost. Both features are correct on their own. Together they contain the most expensive interaction in the tool, and the bill lands somewhere nobody is looking.

A prefix cache is state that one provider holds for you. Failover moves the session to a provider that has never seen it. The session survives the switch; the discount does not.

Why the cache cannot follow the session

Prompt caching is not a property of your prompt. It is a prefix hash held by a specific provider for a specific model, and it is only honoured by the endpoint that wrote it. Anthropic's published rates make this visible: a cache read bills at 0.1× base input and a cache write at 1.25×, and that asymmetry only makes sense as rent on state one party is holding.

So when the chain walks and the next provider takes over, the entire accumulated transcript arrives cold. GoatCode is right that nothing is lost — the context window travels fine. What does not travel is the fact that the previous provider had already been paid to remember it.

The tool's own example chain is ["openrouter/claude-sonnet","groq/llama-3.3-70b","deepseek/deepseek-chat"]. Walking from the first entry to the second is a change of provider and a change of model, and neither of those has your prefix.

The arithmetic

Take a session whose transcript grows 2,000 tokens per turn — a file read, a test run, a diff — emitting 300 tokens per turn, over 60 turns. At published Claude rates, checked 12 September 2026, with Sonnet 5 at $2/$10 per MTok, cache read $0.20, cache write $2.50:

No caching. The whole transcript is re-sent every turn:
  input  = 2,000 × (60×61/2) = 3,660,000 tok = 3.66 MTok
  output =            60×300 =    18,000 tok = 0.018 MTok

  3.66 × $2   = $7.32
  0.018 × $10 = $0.18
                -----
                $7.50

With the cache doing its job — the settled prefix read at 0.1×, only the new 2,000 tokens written at 1.25×:

  prefix reads  = 2,000 × (59×60/2) = 3,540,000 tok × $0.20 = $0.708
  new writes    =        60 × 2,000 =   120,000 tok × $2.50 = $0.300
  output        =        60 ×   300 =    18,000 tok × $10   = $0.180
                                                              ------
                                                              $1.188

That is the 84% the marketing is talking about, and it is real. $7.50 becomes $1.19, and caching has banked about $1.43 of saving by the time the session reaches turn 29.

Now the quota dies at turn 30. Turns 1–29 were cached and are behind you:

  prefix reads = 2,000 × (28×29/2) = 812,000 tok × $0.20 = $0.162
  new writes   =        29 × 2,000 =  58,000 tok × $2.50 = $0.145
  output       =        29 ×   300 =   8,700 tok × $10   = $0.087
                                                           ------
                                                           $0.394

Everything from turn 30 onward runs on a provider that has never seen the transcript. If it does not cache the same way, the rest of the session is billed the uncached way:

  turns 30–60  = 2,000 × 1,395 = 2,790,000 tok × $2 = $5.580
  output       =        31×300 =     9,300 tok × $10 = $0.093
                                                      ------
                                                      $5.673

  session total = $0.394 + $5.673 = $6.07

$6.07 instead of $1.19. One quota error, halfway through, multiplied the session by 5.1, and handed back $4.88 — about 3.4× everything the cache had managed to save before the switch. It lands 81% of the way back to the no-caching-at-all cost that caching was supposed to eliminate.

The honest range is wide, because it depends entirely on the fallback provider's own cache. If the provider you land on caches identically, only turn 30 is cold: the full transcript written once at 1.25× is $0.15, the remaining turns re-warm at $0.774, and the session ends at $1.32 — an 11% penalty, which is fine. So the cost of a failover is somewhere between +11% and +411%, decided by which entry in the fallback chain happened to be up at 2am. That is not a number in anyone's cost model, and it cannot be, because it is not a property of your code.

Two caveats. The 2,000-and-300 token figures are my scenario, not measurements taken from GoatCode — substitute your own and the spreadsheet changes shape, not direction. And I have used Claude rates on both sides of the switch so the arithmetic uses one rate table; a real chain across Groq and DeepSeek has a different constant. The ratio is the point, not the dollars.

The sticky switch is the part I would change

Failover on a 429 is right. A rate limit is transient by definition — that is what the status code means. But "the next launch starts on the provider that worked" converts a transient event into a durable configuration change, written by the tool, in response to an error that had already resolved.

Nothing announces it. There is no deploy, no config diff in review, no alert. One bad minute of quota at 2am permanently moves your production traffic, and the only artefact is that /cost starts pricing sessions against a different row of the rate table.

The consequence that would worry me most is not the money. It is that your eval set now describes a model you are not running. If your regression suite was scored against Sonnet 5 and production has been quietly served by Llama 3.3 70B since Tuesday, then your pass rate is a measurement of the wrong system, and it will keep reporting confidently. This is the sample-size problem in eval runs with an extra failure mode on top: the number is not noisy, it is aimed at the wrong target, and nothing in the report can tell you that.

The tool does make one routing decision properly, and the contrast is instructive: small_model sends compaction and explore-subagents to a cheap model while "your main turn stays on the frontier one." That is a deliberate cascade — chosen, priced, and stable. Failover is the same class of decision, made by an error handler.

What I would do with a chain like this

Pin it, and treat a switch as an incident. If the fallback exists so an overnight run finishes, that is a good reason to have one. It is not a reason for the choice to persist silently. Record which provider served every turn — the same column that makes retry spend visible makes provider drift visible — and alert on the provider mix changing, not just on the bill.

Re-run the eval when the provider changes. The eval set is the only thing that can tell you whether the fallback is actually a fallback or a quiet downgrade, and it only works if you know to run it. Owning that trigger in the contract is worth more than owning the eval itself.

Put a ceiling on the run, not the request. A per-run budget stops the $6.07 version of a session at the point a human would want to know, rather than at the end of the month.

Order the chain by cache compatibility before capability. If the second entry caches the way the first does, a switch costs about 11%. If it does not, the same switch costs 5×. That ordering decision is worth more than most of the model comparisons made on benchmark scores.

The general lesson outlives this tool. Failover and caching are both advertised as resilience and savings, and each is described in isolation because that is where the benefit is legible. The interaction is where the money goes, and it only shows up in a system that has already switched once.

This is the class of thing I look at in agent runtimes with approval gates, and it is squarely what a reliability audit is for when the runtime is already in production. More in the arithmetic of prompt caching, retries are a line item, and routing cheap first, on purpose. GoatCode's failover, stickiness and caching behaviour are quoted from its README and landing page, read 12 September 2026. Model rates from claude.com/pricing, checked 12 September 2026; the per-turn token figures are a stated scenario, not measurements.