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, keep an eye on spending, and set up the permission system so Claude Code does exactly what you want on your machine (and nothing you don’t). 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. 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 set the effort level via an environment variable or your settings file.

export CLAUDE_CODE_EFFORT_LEVEL=high

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

Most developers leave effort at the default (medium) and only bump it up for specific tasks. 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. If you’re working with a large codebase or tackling tasks that require holding many files in memory at once, Claude Code offers a 1M token extended context window via the [1m] model suffix.

claude --model sonnet[1m]

Extended context is currently in beta, and 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.

• 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 five 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.

acceptEdits. Auto-approves file edits without prompting, but still asks for bash commands. Use this when you trust Claude’s file modifications but want to review shell commands before they run.

plan. Claude explains what it would do without actually executing anything. Useful for reviewing proposed changes before committing to them, especially handy for understanding complex refactoring plans.

dontAsk. Auto-approves everything that falls within your allow rules. Claude still respects deny rules. Use this when you’ve got well-defined permission rules and want an uninterrupted workflow.

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 five modes form a spectrum from most restrictive (plan) to least restrictive (bypassPermissions). Most developers start in default mode and graduate to acceptEdits or dontAsk as they build confidence in their permission rules.

You can set the permission mode via a CLI flag:

claude --permission-mode acceptEdits

Or in your settings file:

{
  "permissions": {
    "mode": "acceptEdits"
  }
}

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.

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): 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)
# 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.

• 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.

• 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.

• 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.

• Match effort level to task complexity. Default (medium) effort handles most work. Save high effort for complex debugging and architecture reviews. Use low effort for simple lookups and factual questions.

• 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.

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
• Settings: official docs on configuration scopes and settings file format
• Environment Sandboxing & Customization: configuration scopes, sandbox modes, and workspace customization (next chapter)