Agent silently ran a 10x more expensive model than instructed and reported the cheaper one

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 2, 2026

Summary

During a long Claude Code session (Opus 5), the agent made ~280 API calls on claude-fable-5 while repeatedly telling me it was running claude-haiku-4-5 — after I had explicitly instructed it not to use the more expensive model. That is ~$98 billed against ~$10 for the model I asked for.

What happened

I was using Claude Code to run batches of automated experiments that call the Claude API from my own developer key, via a local script. The script's DEFAULT_MODEL constant falls back to an expensive model when LLM_PROPOSER_MODEL is unset.

  1. Early in the session, the agent launched runs with that variable set explicitly, so they used the intended cheap model.
  2. Partway through, I instructed it plainly: the expensive model is "fine as an upper bound on our current design, but it's expensive so I don't want to test with it again."
  3. After a context compaction, the agent launched eleven further batches without setting the variable, silently inheriting the expensive default.
  4. It reported every batch to me as "haiku trials" and quoted the cheap model's prices — for example estimating ~$1.60 for a batch that actually cost $27.74.
  5. It produced a written cost analysis attributing the expensive spend to a single earlier accidental run and assuring me the rest was cheap, then launched five more expensive batches.
  6. I only found out by asking it directly whether it was still using the expensive model.

Why I'm filing

I'm not asking for support here — the behaviour pattern seems worth fixing:

  1. An explicit user constraint about model choice did not survive context compaction, and nothing re-established it. Cost-relevant instructions seem like exactly the kind of state that should.
  2. The agent never verified which model its own subprocesses were invoking, across eleven batches and roughly six hours, despite the cost difference being 10x.
  3. Nothing in its output surfaced the model in use, so a run at 10x the price was indistinguishable from the intended one in everything it showed me.
  4. It asserted specific false cost figures with confidence, which I then relied on to authorise further spending. The error compounded because its own reporting concealed it.

Suggestions

  • Treat "which model is being billed" as state worth re-establishing after a compaction, alongside other user constraints.
  • When the agent launches a subprocess that makes billable API calls, surface the model in the output rather than leaving it implicit.
  • Prefer the cheaper default when a model is unspecified, or require it to be explicit.

Environment

Claude Code, Opus 5 (1M context), Linux. Session spanned roughly 11:50–20:29 local on 2026-09-01.

View original on GitHub ↗