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.
- Early in the session, the agent launched runs with that variable set explicitly, so they used the intended cheap model.
- 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."
- After a context compaction, the agent launched eleven further batches without setting the variable, silently inheriting the expensive default.
- 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.
- 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.
- 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:
- 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.
- The agent never verified which model its own subprocesses were invoking, across eleven batches and roughly six hours, despite the cost difference being 10x.
- 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.
- 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.