Paths Subjects Questions Quizzes Pricing Search
Advanced Open Free

Explaining an Unexpected Bill

Your team's Claude Code spend for the month is far higher than expected. Looking at /usage across a few engineers' machines, you notice: one engineer runs a single session per day, left open for the entire workday, and asks a handful of questions spread hours apart. Another engineer defaults to Opus for everything, including small one-line fixes, and rarely uses subagents even for large log-reading tasks.

  1. For the first engineer, explain the specific mechanism (not just "long sessions cost more") driving their higher-than-expected spend, including what happens after a multi-hour gap between messages.
  2. For the second engineer, explain why defaulting to Opus for small tasks doesn't just cost more per token — connect it to the actual savings available.
  3. Propose one concrete change for each engineer, and one thing you'd check with /usage//context to confirm the fix worked.
Solution

1. The first engineer's mechanism:

Every request sends the full conversation history, and with prompt caching, that history is normally re-read at a cheaper cached rate. But a message sent after a long enough gap since the last one misses the cache and reprocesses the entire context at full, uncached rates. A handful of one-line questions spread across an 8-hour day, in the same long-lived session, means several of those questions each pay for reprocessing a full day's accumulated context from scratch — a single short question can draw usage for the whole conversation. The fix isn't "ask fewer questions," it's that the session itself should not have stayed open and growing across large idle gaps.

2. The second engineer's mechanism:

Sonnet handles most coding tasks well at lower cost; Opus is reserved for complex architectural or multi-step reasoning. Using Opus by default means every small fix pays a cost premium for reasoning capability the task doesn't need — model choice is a lever independent of, and in addition to, context size. Not using subagents for large-output tasks (log reading) compounds this: that verbose output sits in the main context at the more expensive model's rate on every subsequent turn, instead of being isolated in a subagent's own context and returned as a short summary.

3. Concrete fixes and what to check:

  • Engineer 1: /clear at natural task boundaries instead of leaving one session open all day; /rename before clearing if they'll want to return to it. Check /usage the next day — the session-block total cost should no longer show a disproportionate jump on the first message after a gap.
  • Engineer 2: switch the default to Sonnet via /model, reserving Opus for genuinely complex tasks; delegate log-reading to a subagent explicitly ("use a subagent to read this log and report only the errors"). Check /context during a log-reading task to confirm the raw log contents no longer appear in the main conversation's context, and compare /usage totals for similar tasks before and after the model change.

Share this question

← Back to Claude Code Best Practices: Reliable, Cheap, High-Leverage Sessions practice

We use cookies for product analytics to improve OmniAtlas. See our Privacy Policy.