"LLM Reasoning Modes (3/6) — Claude effort in Full: low·medium·high·xhigh·max"

Part 2 covered Claude's Thinking (whether to think, and when). Part 3 takes the dial that controls the depth of that thinking and the whole response head-on — effort. We dissect what low / medium / high / xhigh / max each change, not only in thinking but in tool calls and preamble.

Claude's reasoning control has two layers — Thinking (whether and when to think) and effort (how deep, and how many tokens across the whole response). Part 2 looked at the first; Part 3 decomposes effort to the end. What makes effort unusual is that a single dial controls not just thinking depth but every token in the response.

In One Paragraph

Claude's effort is a GA parameter set via output_config: {effort: "low"|"medium"|"high"|"xhigh"|"max"} (no beta header). It first appeared on Opus 4.5 (then behind the beta header effort-2025-11-24) and went GA from 4.6. The default is high — and setting high is identical to omitting the parameter — on both the API and Claude Code. effort's defining trait: it controls all tokens in the response (text and explanations, tool calls and function arguments, thinking depth), not just thinking. It is a behavioral signal, not a strict token cap — at low effort Claude still thinks on hard problems, just less than it would at higher effort for the same problem.

1. The Parameter: What and How

effort lives inside output_config on the message request.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "..."}],
)

The facts, pinned down:

  • Parameter: output_config: {effort: "low"|"medium"|"high"|"xhigh"|"max"}. GA, no beta header required.
  • First introduced on Opus 4.5 (originally behind the beta header effort-2025-11-24). GA from 4.6 onward.
  • Default = high. Setting high is exactly the same as omitting the parameter. This default applies on both the API and Claude Code.

2. What effort Controls — Every Token in the Response

This is why effort is more than a "thinking knob." effort controls all tokens in the response together.

  • (a) text and explanations: how detailed the answer body is, how much it spells out.
  • (b) tool calls and function arguments: how often and how it invokes tools.
  • (c) extended/adaptive thinking depth: how deeply it thinks.

Bundling these three under a single dial is what separates effort from a pure thinking control. It doesn't only change thinking depth — the same knob also moves the verbosity of explanations and the tool-use pattern at the same time.

And effort is a behavioral signal, not a strict token budget. Setting low doesn't forbid thinking on hard problems — Claude still thinks on them, just less than it would at higher effort for the same problem. effort tells the model "what posture of effort to bring to this work"; it is not a hard ceiling that cuts the token counter off.

3. effort and Tool Use — The Same Dial Shifts Agent Behavior

That effort also governs tool calls is felt most in agentic workflows. Low and high effort diverge in behavior even on the same task.

Lower effort Higher effort
Tool calls Combine ops into fewer calls, fewer calls total More calls, more granular
How it starts Acts without preamble Explains the plan before acting
Completion report Terse confirmation Detailed change summary
Code comments Minimal More comments

So lower effort is "say less, batch it, move fast," and higher effort is "lay out the plan, be thorough." Because the same effort dial pulls thinking depth and tool behavior together, lowering effort makes the response shorter while also consolidating and reducing tool calls.

4. Per-Level Guidance — Anthropic's effort Doc

The recommended use for each level, taken straight from Anthropic's effort documentation:

Level Description Use case
max Absolute maximum capability, no constraint on token spend, deepest reasoning Reserve for genuinely frontier problems. On most workloads it adds significant cost for small gains, and on structured-output / less-intelligence-sensitive tasks it can lead to overthinking
xhigh Extended capability for long-horizon work Agentic/coding runs over ~30 min, token budgets in the millions. The recommended starting point for coding/agentic on Opus 4.7/4.8
high High capability (= the default) Complex reasoning, hard coding, agentic. Often the sweet spot for quality vs token efficiency
medium Balanced, moderate token savings The drop-in for average workflows
low Most efficient, significant savings, some capability loss Simple tasks, subagents, high-volume, latency-sensitive work

The principle is the one repeated since Part 1 — not "always maximum" but match the dial to task difficulty. Even max is not a universal win; on a narrow output space it can actually reduce quality.

5. 4.7/4.8 Respect effort More Strictly

Across generations, the interpretation of effort changed too. Opus 4.7/4.8 respect effort more strictly than 4.6 — especially at low/medium, they scope work to exactly what's asked. They don't expand into work you didn't request.

Two practical rules follow.

  • If reasoning is shallow on a hard task, raise effort rather than prompting around it. Bumping effort a level is more direct and behaves as intended, versus contorting the prompt with "think harder."
  • At xhigh/max, set a large max_tokens (start ~64k). The model needs room to think and then act across tool calls and subagents. Dial effort up but leave max_tokens tight, and the response gets cut off before the model can fully unfold.

6. effort × thinking Interaction — Per Model

effort and Thinking (Part 2) are separate knobs, but how they mesh differs per model.

Model Thinking mode Relation to effort
Fable 5 / Mythos 5 adaptive, always on effort controls depth; {type:"disabled"} returns 400
Opus 4.8 / 4.7 adaptive thinking effort is the recommended depth control; manual budget_tokens returns 400
Opus 4.6 adaptive thinking effort recommended; budget_tokens deprecated but still accepted
Sonnet 4.6 adaptive thinking effort controls thinking depth
Opus 4.5 manual thinking (budget_tokens) effort works alongside the thinking budget

The read is simple. On current models (4.6-4.8, Fable 5), the official knob to raise or lower thinking depth is effort. Pinning thinking volume directly with budget_tokens survives only on Opus 4.5; the newer generations removed it (see Part 2).

7. Model Support Matrix

effort levels have different support per model. Here's the table to check before sending.

effort level Supported models
low / medium / high Opus 4.5, Opus 4.6, Opus 4.7, Opus 4.8, Sonnet 4.6, Fable 5
max Opus 4.6 and later, Sonnet 4.6, Fable 5 — not Opus 4.5, not Haiku, not older Sonnets
xhigh Added on Opus 4.7, also Opus 4.8, Fable 5 (sits between high and max)

Additional notes:

  • Sending effort to Sonnet 4.5 / Haiku 4.5 returns an error.
  • xhigh is the intermediate step — deeper than high, lighter than max — introduced on Opus 4.7.
  • max is not available on Opus 4.5 (from 4.6 onward).

8. Task Budgets — A Separate, Complementary Control

If effort controls per-turn depth, there's a separate knob for the cumulative token spend across a whole loop — Task Budgets.

  • Parameter: output_config: {task_budget: {type: "tokens", total: N}}. Beta header task-budgets-2026-03-13, minimum 20,000.
  • Behavior: tells the model how many tokens it has for a full agentic loop. The model sees a running countdown and self-moderates against it.
  • Difference from max_tokens: max_tokens is an enforced per-response ceiling the model is not aware of. A Task Budget is a loop-level budget the model is aware of and self-moderates against.

In short — effort = per-turn depth, Task Budget = cumulative loop spend. The two don't compete; they complement. Set depth with effort, and cap the total of a long agentic run by letting the model self-moderate against a Task Budget.

What Comes Next

That's effort as seen from the API surface. Part 4 looks at the same effort in Claude Code in practice — the five CLI levels, /effort and the CLAUDE_CODE_EFFORT_LEVEL env var, session persistence, and what ultracode actually is (it shows up in the menu but is not an API-level effort).

This article's parameter values, defaults, and per-model support are grounded in Anthropic's primary effort documentation and the model migration guide.

Series overview: Series index

댓글

댓글 쓰기

이 블로그의 인기 게시물

"ML Foundations (9/9) — PyTorch vs TensorFlow, and the Road to Local LLMs"

이미지
← 8/9 Deep Learning Architec… 📚 Series Index (series end) The final part. So far we've focused on models. Now we focus on the tools that actually run them . We'll lay out the philosophical difference between PyTorch and TensorFlow, and trace how Hugging Face transformers , llama.cpp , MLX , and Ollama built the bridge to running large language models on your own machine. By the end you should have the full mental model of "download a pretrained LLM and serve it locally." 0. Learning Objectives Explain the eager-vs-graph difference between PyTorch and TensorFlow. Explain, in graph terms, how autograd automates the backward pass. Use Hugging Face transformers ' AutoModel , AutoTokenizer , and pipeline abstractions. Describe llama.cpp's GGUF quantization, INT4 inference, and CPU-first flow. Describe Apple MLX's use of unified memory and how it differs from PyTorch. Run a local LLM with Ollama and call it through an OpenAI-compatible API. ...
Read more »

Agent Memory Engine (2/10) — Building an AI Agent Memory System with SQLite Alone

← 1/10 SQLite Memory Engine f… 📚 Series Index 3/10 memcore Completed → A memory engine that runs without daemons, without dependencies, anywhere 핵심 요약 This post covers how to design an AI agent memory engine (memcore) on a single-file SQLite backend. - Structure: 25 modules, ~6,464 lines, 22 DB tables - Principles: no daemon, single-file portability, no required external dependencies, host-agnostic - Core techniques: 4-layer hybrid search (topic · vector · FTS5 · LIKE), U-tag dialectic-based confidence evolution, ingestion-layer bias rejection rules What This Post Covers One approach to building AI agent memory without a server or cloud vector DB. Specifically: (1) the limitations of text-file-based memory, (2) vector DB alternatives compared and selection criteria, (3) how to layer search tiers, (4) how to evolve confidence scores over time, and (5) how to block biased memory accumulation at the ingestion stage. Design Principles: Why Single-File SQLite Text-file-based ...
Read more »

"ML Foundations (8/9) — Deep Learning Architectures: CNN, RNN, Attention"

이미지
← 7/9 Deep Learning Training 📚 Series Index 9/9 PyTorch vs TensorFlow → What did we keep adding on top of an MLP? Vision went CNN, sequences went RNN/LSTM, and eventually both converged on Attention and the Transformer. Each architecture is easier to remember if you read it as what it gave up to gain something else . This part is the one-line summary of the decisive inflection points: LeNet → AlexNet → ResNet → LSTM → Attention → Transformer. 0. Learning Objectives Explain why CNN's convolution, pooling, and weight sharing match images so well. Trace what got unblocked from LeNet → AlexNet → VGG → ResNet as depth grew. State BPTT for RNNs and the vanishing/exploding gradient problem. Write the LSTM gate equations (forget, input, output) with intuition. Write the attention formula in query/key/value form and the scaled dot-product variant. State the precise reasons Transformers replaced RNNs (parallelism + long-range dependencies). 1. 핵심 요약 CNN : weight sharin...
Read more »

"RAG Core Study (14/26) — Evaluation Sets with RAGAS & DeepEval"

이미지
Series overview: Series index 📚 Series Index Without an evaluation set, every RAG improvement is a story, not evidence. RAG systems fail in more than one place: retrieval, context selection, answer generation, and grounding. That means "looks better" is not a metric. Part 14 explains how to build a golden dataset , how RAGAS and DeepEval fit into the workflow, and why teams must separate retrieval quality from answer quality if they want tuning decisions to hold up. 0. Prerequisites Part 13 reranking — system quality now depends on multi-stage ranking. Part 1 grounding — a correct-looking answer is not enough. Part 12 Hybrid — multiple retrieval settings need comparison on fixed data. 1. Learning Objectives Build a small but useful golden dataset for RAG. Distinguish retrieval metrics from answer metrics . Use RAGAS and DeepEval in the right roles. Avoid the common traps in judge-model-based evaluation. 2. 핵심 요약 An evaluation set for RAG is ...
Read more »

"ML Foundations (7/9) — Deep Learning Training: Optimizers, Regularization, Initialization"

← 6/9 Neural Networks 📚 Series Index 8/9 Deep Learning Architec… → Building an MLP, as we did in Part 6, is not the same as getting it to train well . The right optimizer, regularization, initialization, and learning rate — when these line up, deep networks converge. When they don't, the network refuses to learn at all. This part is the catalog of those crafts, with formulas, paper citations, and code in one place. 0. Learning Objectives Compare and write the update rules for SGD, Momentum, Nesterov, and Adam. Explain how Dropout, BatchNorm, and LayerNorm work and where they belong in a model. Derive the variance formulas for Xavier and He initialization and match them to activations. Implement step, cosine, and warmup learning-rate schedules in PyTorch. Explain why gradient clipping is effectively required for RNNs and Transformers. Diagnose the most common training failures (NaN, plateau, overfitting) and apply first-line fixes. 1. 핵심 요약 SGD : \(w \leftarro...
Read more »

AI Agents I Built (5/7) — Building an Automated Blogger API Publishing System

← 4/7 My Life Organizer Agent 📚 Series Index 6/7 Dual → Designing a Markdown-Based Auto-Publish Pipeline with Blogger API v3 + OAuth 2.0 Key Summary Blogger API v3 + OAuth 2.0 enables a pipeline that converts Markdown files into publishable HTML posts blogger_publish.py handles the full flow — frontmatter parsing → body cleanup → HTML conversion → CSS injection → API post — in a single script For bulk publishing, quota management (delay, retry, TOC suppression) is the critical design concern Platform Selection Criteria API access is mandatory for AI agent-driven content publishing. A comparison of platforms: Platform API Cost AdSense Decision WordPress.com REST API Paid plan required Paid only Cost overhead Ghost REST API Self-hosted or paid Manual setup Ops overhead Blogger v3 API Free Native integration Adopted Blogger is free, exposes a REST API, and integrates natively with AdSense. For personal blog automation, this combination i...
Read more »

"ML Foundations (6/9) — Neural Networks: From Perceptron to MLP"

이미지
← 5/9 Regularization & Model… 📚 Series Index 7/9 Deep Learning Training → A neural network is logistic regression from Part 4 stacked into layers. Each layer passes through a new nonlinear activation, expanding the family of functions the network can represent. In this part we put how a neural network learns onto one page. Perceptrons, XOR, MLPs, backpropagation, activation functions, and the universal approximation theorem all meet here. 0. Learning Objectives Write the perceptron's learning rule and explain why it cannot solve XOR. Express an MLP's forward pass as one line of matrix products. Derive backpropagation by hand on a two-layer MLP. Compare the definitions, derivatives, and trade-offs of sigmoid, tanh, ReLU, and GELU. State the universal approximation theorem (Cybenko 1989 / Hornik 1991) precisely. Train an MLP end-to-end in PyTorch. 1. 핵심 요약 Perceptron (1958): \(\hat{y} = \mathrm{step}(w^\top x + b)\). Converges only on linearly separabl...
Read more »