Models, usage, limits in Claude Code

This guide explains which model you are using, how usage is metered, and how to keep long sessions within their context and usage limits.

How you signed in determines how usage is metered. Everything else about Claude Code behaves the same way regardless.

If you signed in with an Enterprise seat, you generally do not need to think about tokens until you reach a limit. If you are using an API key, the /cost command shows your running spend for the current session.

Run /model at any time to see which models are available to your account and to switch between them. As a rough guide:

You can change models mid-session without losing your conversation. A common pattern is to plan with Opus and execute with Sonnet.

Every turn sends three things to the model:

Of these, the first item grows the fastest. A long debugging session in which Claude has read twenty files and produced fifteen diffs is carrying all of that on every subsequent message. This is where both cost and context limits originate.

The context window is the maximum amount of text the model can consider at once. Claude Code shows a live indicator of how full it is. When it fills up, Claude can no longer see the oldest parts of the conversation clearly and quality drops.

Two commands keep it under control:

Rule of thumb: use /clear when starting a new task, and /compact when continuing a long one.

Almost every "I burned through my limit by lunchtime" report traces back to one of these five.

Every previous message is resent on every turn, so a session that has wandered through three unrelated problems pays for all three on each new message. In practice: you just finished debugging a login redirect and now want to write a database migration. Run /clear first. A simple test: if your next prompt would make perfect sense in a brand-new terminal, clear before sending it. Your CLAUDE.md and project files stay put; only the chat history goes. One warning: /clear cannot be undone. If you might still need something from the history, copy it out first or run /compact instead, which preserves a summary rather than wiping everything.

Opus costs several times more per turn than Sonnet, and Sonnet more than Haiku. Spending Opus on routine work is the fastest way to drain a daily limit. Reasonable defaults: Sonnet for most coding (features, tests, known bugs, refactors); Opus when you're genuinely stuck or the change is wide (hard debugging, cross-cutting refactors, architecture calls); Haiku for quick mechanical work (renames, log lines, regex explanations, boilerplate).

Anything you paste sits in context, in full, for the rest of the session. Referencing a file by path lets Claude read selectively and focus on the part you care about. In practice: instead of pasting auth.ts, write look at the validateToken function in @src/auth.ts. For logs and stack traces, trim to the relevant 20 or 30 lines before pasting. For anything large (lockfiles, build logs, data dumps), put it on disk and reference the path.

This file is prepended to every turn, so its cost is multiplied by the number of messages you send. A 300-line CLAUDE.md across a 40-turn session is 12,000 lines of input you paid for before doing any work. The rule: two strikes, one screen. Only add a note the second time you have to correct Claude on the same thing (first-time issues are usually one-offs). And never let the file grow past a single screen of roughly 80 to 100 lines; if something new needs to go in and there's no room, something old has to come out. When to update it: right after a session where you had to correct Claude twice on the same thing. That's when the fix is fresh and takes a minute to write down. Every few weeks, read the whole file and delete anything that is no longer true or whose purpose you can't remember. Stale notes are worse than missing notes because they actively misdirect Claude.

A plan costs a few hundred tokens. A wrong 400-line diff that you revert and regenerate costs thousands, twice, plus the turns spent explaining what went wrong. In practice: for anything touching more than two or three files, switch to Plan Mode or just ask: "Before changing anything, list the files you'll touch and what you'll do in each." Read the list, correct it in plain English ("skip legacy/, and don't touch the tests yet"), then let it execute.

Pro tip: plan with Opus, execute with Sonnet. The highest-value use of Opus is writing the plan itself, where deeper reasoning actually pays off. Once a good plan exists, execution is mostly mechanical and Sonnet handles it at a fraction of the cost. Workflow: /model opus, ask for the plan, review and correct it, then /model sonnet and "execute the plan above." Switching models doesn't clear the conversation, so Sonnet still sees everything Opus produced.