Models, Cost Economics & Permissions

What You’ll Learn

Every time you fire up Claude Code, you’re making decisions about models, costs, and permissions, whether you realize it or not. This chapter walks you through all three. You’ll learn how to pick the right model for each task, dial reasoning depth up or down with effort levels (including the /effort command for quick mid-session adjustments), keep an eye on spending, and set up the permission system so Claude Code does exactly what you want on your machine. You’ll also learn about Auto Mode, which uses a background classifier to intelligently automate permission decisions so you can work with fewer interruptions while maintaining safety guardrails. By the end, you’ll be making confident tradeoffs between speed, quality, cost, and safety.

Available Models

Claude Code gives you several model aliases, each mapping to a member of the Claude model family. They sit at different points on the speed-quality-cost spectrum, and picking the right one is honestly the single most impactful decision you’ll make for both productivity and your wallet.

Sonnet is the default, and for good reason. It strikes a great balance of speed, quality, and cost, making it the workhorse for everyday coding. Most developers live here: writing features, debugging, refactoring, navigating codebases.

Opus is the heavy hitter. It reasons more deeply and produces more thorough analysis, but it’s slower and pricier. Opus comes with a 1M token context window, making it the go-to choice for tasks that require holding many files in memory at once. Reach for Opus when you need careful architectural decisions, complex multi-file refactoring, or nuanced code review where depth matters more than speed.

Haiku is the fastest and cheapest option. It shines on simple queries, quick lookups, and straightforward tasks that don’t need deep reasoning. Want a fast answer to a factual question or just need to check something real quick? Haiku’s your model.

Opusplan is a hybrid: Opus generates the plan, Sonnet executes it. You get Opus-level strategic thinking paired with Sonnet-level execution speed for the bulk of the work.

The alias default maps to Sonnet. You can also tack on model suffixes like sonnet[1m] to access extended context windows (see the Extended Context section below).

Choosing the Right Model

The right model depends on what you’re doing, not personal preference. Here’s a quick decision framework:

In practice, Sonnet covers 80-90% of most developers’ work. The trick is recognizing that 10-20% of tasks where switching models saves you either time or money.

Selecting a Model

There are four ways to select a model, listed here from most temporary to most persistent.

In-session command: Use /model to switch models mid-conversation. This only affects the current session.

CLI flag: Pass --model when starting Claude Code.

claude --model opus

Environment variable: Set ANTHROPIC_MODEL in your shell profile to change the default for all sessions.

export ANTHROPIC_MODEL=opus

Settings file: Set the model in your settings file for persistent configuration. This is your best bet for team-wide defaults.

{
  "model": "sonnet"
}

Effort Levels

Effort levels let you control how much reasoning Claude Code puts into each response. Higher effort means deeper thinking, but also slower responses and higher cost. The three levels give you fine-grained control over the speed-quality tradeoff within any model.

Low. Minimal reasoning, fast responses, lowest cost. Claude gives you concise answers without extended analysis. Great for simple questions, file lookups, and quick factual queries where you already know roughly what you need.

Medium. Balanced reasoning that handles most tasks well. This is the default, and it covers the majority of daily coding work.

High. Maximum reasoning depth for the most thorough analysis. Claude takes more time to think through complex problems, consider edge cases, and produce comprehensive solutions. Reach for this during complex debugging, architecture decisions, security reviews, or anytime you want Claude to be especially careful.

Setting Effort Level

You can change the effort level in three ways: the /effort slash command for quick mid-session changes, an environment variable, or your settings file.

In-session command: Use /effort to change the effort level without leaving your current conversation. This is the fastest way to bump effort up for a tricky problem or dial it down for a quick lookup.

> /effort high
Effort level set to high for this session

Environment variable: Set CLAUDE_CODE_EFFORT in your shell profile to change the default for all sessions.

export CLAUDE_CODE_EFFORT=high

Settings file: Set the effort level in your settings file for persistent configuration.

{
  "preferences": {
    "effort": "high"
  }
}

Most developers leave effort at the default (medium) and only bump it up for specific tasks. The /effort command makes this easy: set it to high before a complex debugging session, then drop it back to medium when you’re done. If you find yourself repeatedly cranking effort to high, that’s probably a sign you should switch to Opus instead.

When Effort Level Matters

Effort levels interact with model selection in an important way. Setting high effort on Haiku won’t produce the same quality as medium effort on Opus. The model’s ceiling determines maximum quality, while effort controls how close Claude gets to that ceiling.

Think of it as a two-dimensional choice: the model sets the quality ceiling, and effort determines how thoroughly Claude explores the problem space. For cost-sensitive workflows, you can sometimes get “good enough” results by using a higher quality model at low effort rather than a lower quality model at high effort.

Extended Context

The standard context window is 200K tokens. For tasks that require holding many files in memory at once, Claude Code offers extended context windows via the [1m] model suffix.

Opus comes with a 1M token context window by default. When you select Opus as your model, you get the full 1M context without any special configuration. This makes Opus the natural choice for large-scale codebase analysis, comprehensive security audits, and complex migrations where Claude needs to hold the full picture of a system in memory.

Sonnet can also access a 1M context window via the sonnet[1m] variant. This gives you Sonnet’s speed and cost profile with a much larger context window.

claude --model sonnet[1m]

Extended context pricing differs from the standard context window. Check the official model configuration docs for current pricing details.

You’ll want extended context when you need to analyze a large chunk of a codebase all at once, such as tracing a data flow across dozens of files or untangling a complex dependency graph. For most daily tasks, the standard 200K window is more than enough.

Where extended context really shines is large-scale migrations, comprehensive security audits, and situations where Claude needs to hold the full picture of a system in memory. The tradeoff is higher cost per session, so use it deliberately rather than as a default.

Cost Tracking

Claude Code has built-in cost visibility so you can keep tabs on spending in real time.

The /cost command shows your current session cost along with a running daily total. Run it anytime to see how much the current conversation has cost and what you’ve spent so far today.

> /cost

Session cost:  $0.42
Total today:   $4.87

If you’re a Max subscriber, the /stats command gives you additional usage analytics including message counts and usage patterns.

The official average cost for Claude Code with Sonnet is approximately ~$6 per developer per day, which works out to roughly ~$100 to $200 per developer per month depending on usage patterns. These are typical numbers, and your actual costs will vary based on model choice, effort level, context size, and how many sessions you run.

If you’re evaluating Claude Code for a team, these averages give you a solid baseline for budgeting. A team of 10 developers can expect roughly $60/day or $1,200 to $2,000/month in aggregate. Heavy Opus usage will push costs higher, while disciplined Haiku usage for simple tasks will bring them down.

Cost Reduction Strategies

Cost management isn’t about restricting usage; it’s about using the right tool for each task. The most expensive sessions aren’t the ones that use Opus; they’re the ones that use the wrong model for the job. Here are practical strategies that cut costs without sacrificing productivity.

• Match the model to the task. Haiku for simple questions and quick lookups. Sonnet for daily coding work. Opus reserved for complex architecture decisions and deep debugging sessions where quality justifies the cost.

• Clear context between unrelated tasks. Hit /clear when you’re switching to something completely different. Carrying irrelevant context between tasks burns tokens without adding value.

• Compact when context grows large. Use /compact to compress the conversation history when it gets long. You can pass a focus instruction to tell Claude what to preserve: /compact focus on the authentication changes.

• Delegate subtasks to subagents. When Claude spawns a subagent for a specific subtask, the subagent gets its own smaller context window. That’s more token efficient than having the main agent hold everything.

• Use low effort for quick lookups. If you just need to find a file, check a type signature, or answer a simple factual question, low effort gets you a fast answer at minimal cost. Use /effort low before quick queries and /effort medium when you’re done.

• Review costs periodically. Run /cost at natural breakpoints in your workflow. If costs are climbing faster than expected, check whether you’re using the right model and effort level for what you’re doing.

The Permission System

Claude Code runs on your machine with real access to your filesystem, terminal, and network. The permission system is how you stay in control of what it can actually do.

Tools are organized into three tiers based on their potential impact:

Read-only tools are always allowed without prompting. These include reading files, searching code, listing directories, and other operations that can’t modify your system.

Bash commands require permission by default. Claude will show you the exact command it wants to run and wait for your approval before executing it. This covers package installations, build scripts, test runners, and any other shell command.

File modifications also require permission by default. Claude shows you the proposed changes as a diff and waits for your go-ahead before writing to disk. This applies to creating new files, editing existing ones, and deleting files.

The diagram below shows how Claude Code evaluates permission rules when a tool is invoked. Rules are checked in strict order: deny rules first, then ask rules, then allow rules.

The diagram illustrates the deny, ask, and allow evaluation chain. When Claude Code wants to execute an action, it walks through three rule lists in order:

1. Deny rules are checked first. If any deny rule matches, the action is blocked immediately. No further rules are evaluated.
2. Ask rules come next. If an ask rule matches, Claude prompts you for approval before proceeding.
3. Allow rules are checked last. If an allow rule matches, the action proceeds silently without prompting.
4. Default fallback: if no rule matches at all, Claude asks for permission (the safe default).

Permission Evaluation Order

The evaluation order is deny, then ask, then allow. Deny rules always win, no matter what allow or ask rules exist. This is intentional: you can grant broad permissions with allow rules while still maintaining hard guardrails through deny rules.

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf /)*"
    ],
    "ask": [
      "Bash(docker *)",
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Read(*)",
      "Write(src/**)"
    ]
  }
}

In this example, curl and wget are always blocked (deny). Docker and git push commands always prompt for approval (ask). npm scripts, git staging, git commits, file reads, and writes to src/ are all auto-approved (allow). Anything not matching these rules falls through to the default behavior, which is to ask.

Permission rules use glob-style pattern matching. Bash(npm run *) matches any npm run command, and Write(src/**) matches writes to any file under the src/ directory tree.

Rule Specificity

Within the same tier, more specific rules take precedence. If you have Bash(git *) in allow and Bash(git push --force *) in deny, the deny rule blocks force pushes while all other git commands sail through.

A common pattern is to allow a broad category of commands and then deny the specific dangerous variants:

{
  "permissions": {
    "deny": [
      "Bash(git push --force *)",
      "Bash(git reset --hard *)"
    ],
    "allow": [
      "Bash(git *)"
    ]
  }
}

Permission Modes

Claude Code supports six permission modes that control the overall permission behavior. These set the baseline, and your deny, ask, and allow rules still apply on top of whichever mode you choose.

default. The standard mode. Claude asks for permission before potentially dangerous actions (bash commands and file modifications). This is the safest starting point for any project.

plan. Claude explains what it would do without actually executing anything. When the plan is ready, Claude presents five options: approve and switch to auto mode, approve and switch to acceptEdits mode, approve and continue with manual review, keep planning for more detail, or refine the plan with deeper analysis. This makes plan mode a natural starting point for complex tasks where you want to review the approach before committing to execution.

acceptEdits. Auto-approves file edits and common filesystem commands (mkdir, touch, rm, mv, cp, sed within the working directory) without prompting, but still asks for other bash commands. Use this when you trust Claude’s file modifications but want to review shell commands before they run.

auto. A classifier-based permission mode that intelligently decides which actions are safe to proceed and which need review. Auto mode uses a background classifier model to evaluate each tool call before execution. Safe actions like editing local files, installing declared dependencies, and running tests proceed without interruption. Destructive or suspicious actions like production deploys, mass deletions, and data exfiltration attempts are blocked. This gives you a productive uninterrupted workflow while maintaining meaningful safety guardrails. See the dedicated Auto Mode section below for full details on how the classifier works, what it blocks and allows, and how to configure it.

dontAsk. Auto-approves everything that falls within your allow rules and auto-denies everything else. Claude never prompts for permission. This mode is designed for CI/CD pipelines and automated workflows where there’s no human to answer prompts. If an action isn’t explicitly allowed, it’s denied rather than queued for approval.

bypassPermissions. Skips all permission checks entirely. This is dangerous and not recommended for general use. It removes all safety guardrails and should only be used in fully isolated environments (like ephemeral CI containers) where you accept all risk.

These six modes form a spectrum from most restrictive (plan) to least restrictive (bypassPermissions). Most developers start in default mode and graduate to acceptEdits or auto as they build confidence in their permission rules and Claude’s judgment.

You can cycle through permission modes during a session by pressing Shift+Tab, set one via a CLI flag, or configure it in your settings file:

claude --permission-mode auto

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Auto Mode

Auto mode is the most significant addition to the permission system. Instead of requiring you to approve every bash command and file edit, a background classifier model evaluates each tool call and makes an intelligent allow-or-block decision. The result is a workflow where safe, routine actions proceed without interruption while genuinely risky operations get flagged.

How the Classifier Works

The classifier runs on Sonnet 4.6, regardless of which model you’re using for your main session. It sees your messages, the proposed tool call, and your CLAUDE.md project context, but it does not see tool results. A separate server-side probe scans tool results for hostile content independently.

For subagents, the classifier evaluates actions at three points: when the subagent spawns (checking the task description), during execution (each tool call), and when the subagent returns (reviewing the full action history).

What Auto Mode Blocks

The classifier blocks actions that are destructive, suspicious, or outside the expected scope of development work:

• Piping downloads to execution (curl | bash)
• Sending sensitive data to external endpoints
• Production deploys and database migrations
• Mass cloud storage deletion
• IAM permission grants and repository access changes
• Force-pushing or pushing to main/master
• Destroying pre-existing files outside the working directory

What Auto Mode Allows

Routine development actions proceed without interruption:

• Local file operations within the working directory
• Installing declared dependencies
• Reading .env and sending credentials to their matching API endpoints
• Read-only HTTP requests
• Pushing to the current branch or a branch Claude created
• Sandbox network access
• Running tests, builds, and linters

Fallback Behavior

Auto mode has a built-in safety valve. If the classifier blocks 3 consecutive actions or 20 total actions in a session, auto mode pauses and falls back to standard prompting. Approving the next prompted action resumes auto mode. In non-interactive mode (-p), repeated blocks abort the session instead of prompting.

Availability

Auto mode requires all of the following:

• A Team, Enterprise, or API plan (not available on Pro or Max plans)
• Sonnet 4.6 or Opus 4.6 as the session model
• Anthropic API as the provider (not available through Bedrock or Vertex)
• Admin enablement on Team and Enterprise plans

Configuring Auto Mode

Enterprise administrators can disable auto mode via managed settings:

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

You can also configure trusted environments for the classifier:

{
  "autoMode": {
    "environment": {
      "trustedRepos": ["github.com/myorg/*"],
      "trustedServices": ["api.mycompany.com"]
    }
  }
}

For the full list of classifier rules, run claude auto-mode defaults in your terminal.

For more on how auto mode interacts with enterprise security governance, see Security & Enterprise Governance. For details on the PermissionDenied hook event that fires when auto mode blocks an action, see Hooks & Lifecycle Automation.

Interactive Permission Explorer

Want to see the permission evaluation logic in action? Explore the decision tree interactively below. Click any node to see its evaluation context, example configurations, and how different rule combinations affect the outcome.

The explorer shows the full decision tree that Claude Code follows when evaluating a tool call. Click on any decision node to see what happens at that step, review example configurations, and understand how different rule combinations affect the final outcome. It’s the same evaluation logic described in the Permission Evaluation Order section above, just presented as a navigable tree. Note that this tree applies to all permission modes: auto mode uses the classifier to decide which tool calls reach this evaluation chain, but once a tool call enters evaluation, the deny/ask/allow rules are applied identically.

Settings Precedence

Permission rules and all other settings follow a strict precedence hierarchy. When the same setting is defined at multiple levels, the higher priority level wins.

1. Managed (~/.claude/managed-settings.json and managed-settings.d/): set by enterprise administrators. Highest priority. Nothing can override these.
2. CLI arguments: flags passed when starting Claude Code (e.g., --model, --permission-mode).
3. Local (.claude/settings.local.json): personal overrides for the current project. Not committed to git.
4. Project (.claude/settings.json): shared team settings committed to the repository.
5. User (~/.claude/settings.json): personal preferences that apply across all projects. Lowest priority.

What this means in practice: a project-level deny rule can’t be overridden by a user-level allow rule. If your team’s .claude/settings.json denies Bash(curl *), your personal ~/.claude/settings.json can’t undo that. Deny rules from higher precedence levels are absolute.

This is especially important for teams. Your project-level settings file (.claude/settings.json) should define the team’s security baseline: the deny rules everyone must follow and the allow rules for standard development commands. Individual developers can add personal overrides in .claude/settings.local.json (not committed to git) for their own workflow preferences, but they can’t weaken the team’s security rules.

# Precedence order (highest to lowest):
# 1. managed-settings.json    (enterprise admin)
#    managed-settings.d/       (layered policy fragments)
# 2. CLI flags                (--model, --permission-mode)
# 3. settings.local.json      (personal project overrides)
# 4. settings.json             (team project settings)
# 5. ~/.claude/settings.json  (personal global defaults)

Best Practices

• Start with the default permission mode. It gives you a good balance of safety and productivity. Only relax permissions after you understand what Claude needs for your specific workflow.

• Graduate to auto mode when you’re comfortable. Once you trust your deny rules and understand Claude’s behavior in your codebase, auto mode dramatically reduces interruptions without sacrificing safety. The classifier is conservative by default, so the risk is low.

• Add allow rules incrementally. When you catch yourself approving the same command over and over, add it to your allow rules. Build up trust gradually rather than starting with broad permissions.

• Use deny rules as hard guardrails. Block dangerous patterns like curl to untrusted URLs, rm -rf on paths outside your project, and any command that could exfiltrate data. Deny rules are your safety net, and they override everything else — including auto mode’s classifier.

• Commit project settings, gitignore local settings. Put .claude/settings.json in version control so your team shares the same permission baseline. Keep .claude/settings.local.json in .gitignore for personal overrides that shouldn’t affect teammates.

• Use /effort to match reasoning to task complexity. Default (medium) effort handles most work. Use /effort high before a complex debugging session and /effort low for quick lookups. Save high effort for complex debugging and architecture reviews.

• Review /cost at natural breakpoints. Check costs when switching tasks, before and after complex operations, and at the end of each day. This builds awareness of which workflows are expensive.

• Use Haiku for prototyping and exploration. When you’re exploring approaches, asking quick questions, or working through early iterations, Haiku gives you fast answers at a fraction of the cost.

• Separate cost-sensitive and quality-sensitive workflows. Prototyping? Use Haiku at low effort. Shipping to production? Sonnet or Opus at medium or high effort. The best cost management strategy is conscious model switching at workflow boundaries.

• Use dontAsk mode for CI/CD pipelines. In automated environments, dontAsk mode ensures Claude never stalls waiting for a human to approve an action. Combine it with well-defined allow rules so the pipeline can do its work, and everything else is safely denied.

Further Reading

• Model Configuration: official docs on model aliases, effort levels, and extended context
• Costs: official pricing information, cost tracking, and reduction strategies
• Permissions: official docs on permission modes, rule syntax, and evaluation order
• Permission Modes: official docs on all six permission modes including auto mode
• Settings: official docs on configuration scopes and settings file format
• Environment Sandboxing & Customization: configuration scopes, sandbox modes, and workspace customization (next chapter)