Cost, Usage Limits and Safe Use in Claude Code: A Checklist

Version note: This post describes Claude Code 2.1.325 (13 November 2026); the cost, cache, model, security and data usage details were checked on 15 November 2026 against the Manage costs effectively, How Claude Code uses prompt caching, Customize your status line, Model configuration, Speed up responses with fast mode, Manage sessions, Security and Data usage pages at code.claude.com/docs, and the API prices on the same day against the Pricing page at platform.claude.com/docs. This post is based on the official documentation. The status line script was run with PowerShell 7.7 on the sample JSON input from the docs, and the settings file was validated against the schemastore.org schema.

Guess First

In Bookstore, the online bookstore used as the shared example across this site's series, Ayşe works all day on a Max subscription in the single session she opens in the morning. After lunch, a one-line question took far more of her 5-hour limit than she expected. Emre works with an API key; in the middle of a long session he switched from Opus to Sonnet to save money, and the first request after the switch cost more than any request before it. On the same day, a teammate said "auto mode is on, so it's safe" and pasted the instructions from an issue into Claude as they were.

What is your guess? Why was the one-line question expensive, why did switching to a cheaper model make the first request expensive, and what does auto mode guarantee in the third case? The answers are in the cache and safe use sections.

Seeing the Cost: /usage, the Status Line and /insights

The Session block at the top of /usage shows the session's token usage and its dollar equivalent at list price. The docs say this figure is an estimate and has nothing to do with billing for Pro, Max and Ultra subscribers, who see plan limit bars on the same screen. The Prompt cache (main) line in the block reports the request count, how much of the input tokens came from cache, the cache misses and whether the cache is warm right now. /clear resets these counters.

On subscription plans, /usage also shows how much of your usage in the last 24 hours or 7 days went to which skill, subagent, plugin and MCP server, plus recommendation rows for behaviors behind at least 10 percent of your usage. The f shortcut at the bottom has Claude apply the recommendations it can, showing you each change first. The figures come only from session history on this machine. /insights is a report on how you work rather than on tokens: it analyzes recent sessions and writes friction points and suggestions to an HTML file; that analysis uses tokens too.

To see it all the time there is the status line. Claude Code passes session data to a script as JSON on stdin and shows what the script prints below the prompt; the status line runs locally and uses no tokens. A PowerShell version for Windows:

# Claude Code status line: model, context, prompt cache, then the 5-hour limit or the estimated cost.
$data = [Console]::In.ReadToEnd() | ConvertFrom-Json
$parts = @("[$($data.model.display_name)]")

$used = $data.context_window.used_percentage
if ($null -ne $used) { $parts += 'ctx {0}%' -f [math]::Round($used) }

$cache = $data.prompt_cache
if ($cache) {
    $state = if ($cache.warm) { 'warm' } else { 'cold' }
    if ($null -ne $cache.hit_ratio) { $state += ' {0}%' -f [math]::Round($cache.hit_ratio * 100) }
    $parts += "cache $state"
}

# Subscribers get rate_limits; with an API key the cost estimate is more useful.
$fiveHour = $data.rate_limits.five_hour
if ($fiveHour) {
    $parts += '5h {0}%' -f [math]::Round($fiveHour.used_percentage)
}
elseif ($null -ne $data.cost.total_cost_usd) {
    $parts += [string]::Format([cultureinfo]::InvariantCulture, '~{0:N2} USD', $data.cost.total_cost_usd)
}

Write-Output ($parts -join ' | ')

{
  "statusLine": {
    "type": "command",
    "command": "powershell -NoProfile -File C:/Users/user/.claude/statusline.ps1"
  }
}

This is a personal setting and goes into ~/.claude/settings.json. The docs recommend writing the script path with forward slashes on Windows, because the command can also run through Git Bash. rate_limits arrives only on Pro, Max and Ultra and only after the first API response; prompt_cache also arrives after the first response. That is why the script checks every field for absence. On a machine where the organization turned on allowManagedHooksOnly, the status line is read from managed settings only.

Subscription and API: What Gets Billed

This section is based on the official documentation. On Pro, Max and Ultra, usage is limited by a 5-hour window and a weekly window; past the limit you continue from usage credits if they are on, and /usage-credits opens the relevant screen. On Team and Enterprise, each member's seat allowance resets on the same two windows and is shared with Claude chat; the admin sets usage credits and spend limits at the organization, group or member level. On the Claude Console, that is with an API key, every token is billed; Claude Code creates a workspace called "Claude Code" in the Console at first login, and a spend limit can be set on that workspace. Plan prices are in the first post of the Working with Claude series.

Per the docs, the average cost in enterprise deployments is around 13 dollars per developer per active day and 150 to 250 dollars per developer per month, staying below 30 dollars per active day for 90 percent of users. API list prices on the Pricing page on 15 November 2026, in dollars per million tokens:

Fast mode on Opus 5.5 costs 8 dollars for input and 40 for output; on subscription plans fast mode is available only through usage credits and isn't included in the plan limits. Thinking tokens are billed as output.

The Cache: Why a Long Session Is Expensive

Claude Code sends the whole conversation with every request, and every step that brings back a tool result is a new request. The prompt cache makes that repetition cheaper: as the table shows, a token read from cache on Opus 5.5 and Sonnet 5.5 costs one twentieth of the input price. But the cache has a lifetime. The TTL, how long the cache lives after its last use, is one hour for the main conversation on a subscription within plan usage, and five minutes with an API key, usage credits or a cloud provider. After a long break, the next request processes the whole context again. That answers the first question in the guess: Ayşe's one-line question made Claude read the whole day's conversation without the cache. The "Resume this conversation?" dialog you see when you resume a long conversation after a break estimates exactly this: how much of the 5-hour limit the saved conversation alone will use.

The answer to the second question is in the cache as well: each model has its own cache. When you switch with /model, the next request reads the whole history with no cache hits; while the cache is still warm, Claude Code asks you to confirm before the switch. The opusplan setting uses Opus in plan mode and Sonnet for execution, so every plan mode toggle is a model switch too. Fast mode has a separate cache as well; the first time you turn it on, the whole conversation is read uncached at fast mode prices, so turn it on at the start of a session. Changing effort, on the other hand, keeps the cache on Opus 5.5, Sonnet 5.5 and Haiku 5.5 with an API key or a subscription.

/compact reads the conversation it summarizes, so it is a large request itself; when you move on to unrelated work, /clear costs nothing. The rule is simple: new work, new session. /rename and /resume are there to go back to the old one.

Reducing It: Model, Effort and Context

Per the docs, the default model setting resolves to Opus 5.5 on every plan and on the Anthropic API. The docs recommend Sonnet, which costs less, for daily coding tasks, and Opus for complex architectural decisions and multi-step reasoning. On Opus 5.5, Sonnet 5.5 and Haiku 5.5 thinking can't be turned off; you manage it with /effort, and these models default to medium effort. low makes sense for simple tasks, high or xhigh for a hard debugging session.

Much of what we built in Bookstore in the earlier posts already keeps costs down: the test-runner subagent runs on Haiku and noisy test output stays out of the main context; the hook from the seventh post shortens dotnet test output; CLAUDE.md is under 100 lines and the workflows live in skills; /bookstore-dev:add-migration uses disable-model-invocation, so it isn't in context on every turn. MCP tool definitions are deferred by default, but CLIs such as gh and dotnet are still cheaper. Code intelligence plugins cut unnecessary file reads while looking for type errors.

Spending can happen while you are idle, too. Session recap and idle compaction can use tokens, and prompt suggestions send a small request, mostly cache reads, after each response; session-scoped scheduled tasks, idle /goal check-ins and background subagents send the whole context each time. Agent teams use about 7 times the tokens of a standard session when teammates are in plan mode.

Safe Use: A Checklist

We collect the series' security decisions in one list:

• Secrets stay out of context: deny rules for .env and appsettings.Production.json, a deny on the dotnet user-secrets command, and no secret files in .worktreeinclude.
• A deny rule isn't a boundary: Read deny rules apply to Claude's file tools and to recognized commands such as cat, not to a script that opens the file itself. The operating-system boundary is the sandbox; it doesn't exist on native Windows and does on WSL 2.
• Untrusted content is data, not instructions: an issue, a PR comment, a README or a web page can carry text that looks like instructions to Claude. Don't paste content you don't trust straight into Claude, and read a suggested command before you approve it.
• Auto mode is a classifier decision: by default it blocks things such as curl | bash, force pushes and production deploys, and after 3 blocks in a row or 20 in total it goes back to asking you; the ask and deny rules you wrote still apply in every case. The answer to the third question in the guess: auto mode is a safety net, not a replacement for reading the instructions in an issue and deciding.
• Bypass only inside an isolated container or VM; the organization can turn it off with disableBypassPermissionsMode.
• MCP servers, plugins and hooks are code that runs with your privileges: read before you install, review what comes from the repository.
• Data usage: on Pro, Max and Ultra, model training is a setting; with it on, data is kept for 5 years, with it off for 30 days. On Team, Enterprise and the API there is no training by default and retention is 30 days; ZDR is enabled separately for eligible Enterprise organizations. Transcripts sent with /feedback are kept for 5 years.
• There is data locally too: session transcripts sit in plain text under ~/.claude/projects/, 30 days by default (cleanupPeriodDays).

Bookstore's list had a gap: the user-secrets file isn't in the repository but in the user profile. On Windows it sits under %APPDATA%\Microsoft\UserSecrets, on Linux and macOS under ~/.microsoft/usersecrets, and the SQL Server connection string is in it. We added two lines to the deny list in .claude/settings.json; the ~/ prefix anchors the rule to the home folder:

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/appsettings.Production.json)",
      "Read(~/AppData/Roaming/Microsoft/UserSecrets/**)",
      "Read(~/.microsoft/usersecrets/**)",
      "Bash(dotnet user-secrets *)",
      "PowerShell(dotnet user-secrets *)",
      "mcp__plugin_bookstore-dev_playwright__browser_run_code_unsafe",
      "mcp__plugin_bookstore-dev_playwright__browser_file_upload"
    ]
  }
}

Prompt injection and tool security are covered in depth in the LLM Application Security series, and tool-independent safe use in the fifth post of the AI-Assisted Development series.

In Production

How you track spend at team level depends on the plan. On Team and Enterprise, the spend report in analytics shows estimated usage-credit spend per person and per model; the Console has the Cost page and workspace limits; on Bedrock, Google Cloud and Foundry billing is in your cloud account. The one option that works on every setup and streams per-user tokens and cost into your own monitoring stack is OpenTelemetry. An organization that pays contracted rates can put modelPricing into managed settings so that /usage and the status line show its own rates instead of list price.

Tell the limit messages apart. A "5-hour limit" or weekly limit message is the seat window; it is shared across all models, so switching models with /model doesn't help. A spend limit message says usage credits reached a limit the admin set. A context or auto-compact warning isn't a limit at all; it says the conversation has grown.

Common Pitfalls

One session open all day. Every question carries the whole day's history, and after breaks without the cache.

Leaving Opus for everything. The default is Opus 5.5; for routine work, Sonnet or a lower effort does the same job for less.

Switching model or fast mode mid-session. Every switch makes Claude read the whole conversation uncached.

Taking the dollar figure for the invoice. /usage, the status line and total_cost_usd are estimates at list price.

The "auto mode is safe" assumption. The classifier is one layer; it doesn't replace deny rules, the sandbox or your review.

A Small Experiment

★☆☆ Set up the status line, take a 10-minute break in a session and check on your return whether the cache field went from warm to cold. Explain the result based on whether you work with an API key or a subscription.

★★☆ For a week, note the recommendation rows in /usage every Friday and apply at least one. Compare them with the next week's rows.

★★★ Find a skill or MCP server in Bookstore with more than a 10 percent share, replace it with disable-model-invocation or a CLI command, and judge the effect with two weeks of /usage data.

This post ends the Claude Code series. We started with installation and the agentic loop, and with CLAUDE.md and memory, permission modes and the sandbox, plan mode, skills, subagents, hooks, MCP, worktrees, CI, plugins and the Agent SDK we made the Bookstore repository ready for working with Claude Code step by step. You'll find tool-independent practice in the AI-Assisted Development series, using Claude from inside an application in the Building Applications with the Claude API series, and security in the LLM Application Security series.