# claude opus 4.7 has a shitty new adaptive thinking mode which has ruined my workflow, now it neve... ## Retrieval Notes - Session id: `315bb208-711a-4715-aaf9-346797a3d820` - Last activity: `2026-04-16T19:54:15.842Z` ## My Notes <!-- Add your notes here. This section is preserved across syncs. --> ## Conversation ### User claude opus 4.7 has a shitty new adaptive thinking mode which has ruined my workflow, now it never ever bothers to think hard about problems. how can i stop it? " Model capabilities Adaptive thinking Adaptive thinking Let Claude dynamically determine when and how much to use extended thinking with adaptive thinking mode. Copy page This feature is eligible for Zero Data Retention (ZDR). When your organization has a ZDR arrangement, data sent through this feature is not stored after the API response is returned. Adaptive thinking is the recommended way to use extended thinking with Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6, and is the default mode on Claude Mythos Preview (where it auto-applies whenever thinking is unset). Instead of manually setting a thinking token budget, adaptive thinking lets Claude dynamically determine when and how much to use extended thinking based on the complexity of each request. On Claude Opus 4.7, adaptive thinking is the only supported thinking mode; manual thinking: {type: "enabled", budget_tokens: N} is no longer accepted. Adaptive thinking can drive better performance than extended thinking with a fixed budget_tokens for many workloads, especially bimodal tasks and long-horizon agentic workflows. No beta header is required. If your workload requires predictable latency or precise control over thinking costs, extended thinking with budget_tokens is still functional on Claude Opus 4.6 and Claude Sonnet 4.6 but is deprecated and no longer recommended. See the warning below. Supported models Adaptive thinking is supported on the following models: Claude Mythos Preview (claude-mythos-preview), adaptive thinking is the default; thinking: {type: "disabled"} is not supported Claude Opus 4.7 (claude-opus-4-7), adaptive thinking is the only supported thinking mode. Thinking is off unless you explicitly set thinking: {type: "adaptive"} in your request; manual thinking: {type: "enabled"} is rejected with a 400 error. Claude Opus 4.6 (claude-opus-4-6) Claude Sonnet 4.6 (claude-sonnet-4-6) thinking.type: "enabled" and budget_tokens are deprecated on Opus 4.6 and Sonnet 4.6 and will be removed in a future model release. Use thinking.type: "adaptive" with the effort parameter instead. Existing budget_tokens configurations are still functional but no longer recommended; plan to migrate. Older models (Sonnet 4.5, Opus 4.5, etc.) do not support adaptive thinking and require thinking.type: "enabled" with budget_tokens. How adaptive thinking works In adaptive mode, thinking is optional for the model. Claude evaluates the complexity of each request and determines whether and how much to use extended thinking. At the default effort level (high), Claude almost always thinks. At lower effort levels, Claude may skip thinking for simpler problems. Adaptive thinking also automatically enables interleaved thinking. This means Claude can think between tool calls, making it especially effective for agentic workflows. How to use adaptive thinking Set thinking.type to "adaptive" in your API request: Shell CLI Python TypeScript C# Go Java PHP Ruby curl https://api.anthropic.com/v1/messages \ --header "x-api-key: $ANTHROPIC_API_KEY" \ --header "anthropic-version: 2023-06-01" \ --header "content-type: application/json" \ --data \ '{ "model": "claude-opus-4-7", "max_tokens": 16000, "thinking": { "type": "adaptive" }, "messages": [ { "role": "user", "content": "Explain why the sum of two even numbers is always even." } ] }' Adaptive thinking with the effort parameter You can combine adaptive thinking with the effort parameter to guide how much thinking Claude does. The effort level acts as soft guidance for Claude's thinking allocation: Effort level Thinking behavior max Claude always thinks with no constraints on thinking depth. Available on Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, and Claude Sonnet 4.6. xhigh Claude always thinks deeply with extended exploration. Available on Claude Opus 4.7. high (default) Claude always thinks. Provides deep reasoning on complex tasks. medium Claude uses moderate thinking. May skip thinking for very simple queries. low Claude minimizes thinking. Skips thinking for simple tasks where speed matters most. Shell CLI Python TypeScript C# Go Java PHP Ruby curl https://api.anthropic.com/v1/messages \ --header "x-api-key: $ANTHROPIC_API_KEY" \ --header "anthropic-version: 2023-06-01" \ --header "content-type: application/json" \ --data \ '{ "model": "claude-opus-4-7", "max_tokens": 16000, "thinking": { "type": "adaptive" }, "output_config": { "effort": "medium" }, "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }' Streaming with adaptive thinking Adaptive thinking works seamlessly with streaming. Thinking blocks are streamed via thinking_delta events just like manual thinking mode: CLI Python TypeScript C# Go Java PHP Ruby ant messages create --stream --format jsonl \ --model claude-opus-4-7 \ --max-tokens 16000 \ --thinking '{type: adaptive}' \ --message '{role: user, content: What is the greatest common divisor of 1071 and 462?}' Adaptive vs manual vs disabled thinking Mode Config Availability When to use Adaptive thinking: {type: "adaptive"} Claude Mythos Preview (default), Opus 4.7 (only mode), Opus 4.6, Sonnet 4.6 Claude determines when and how much to use extended thinking. Use effort to guide. Manual thinking: {type: "enabled", budget_tokens: N} All models except Claude Opus 4.7 (rejected). Deprecated on Opus 4.6 and Sonnet 4.6 (consider adaptive mode instead). When you need precise control over thinking token spend. Disabled Omit thinking parameter or pass {type: "disabled"} All models except Claude Mythos Preview When you don't need extended thinking and want the lowest latency. Adaptive thinking is available on Claude Mythos Preview, Claude Opus 4.7, Opus 4.6, and Sonnet 4.6. On Mythos Preview, adaptive thinking is the default and applies automatically whenever thinking is unset. On Claude Opus 4.7, adaptive thinking is the only supported mode and type: "enabled" with budget_tokens is rejected. Older models only support type: "enabled" with budget_tokens. On Opus 4.6 and Sonnet 4.6, type: "enabled" with budget_tokens is still functional but deprecated. Interleaved thinking availability by mode: Adaptive mode: Interleaved thinking is automatically enabled on Claude Mythos Preview, Claude Opus 4.7, Opus 4.6, and Sonnet 4.6. On Mythos Preview and Opus 4.7, inter-tool reasoning always lives inside thinking blocks. Manual mode on Sonnet 4.6: Interleaved thinking works via the interleaved-thinking-2025-05-14 beta header. Manual mode on Opus 4.6: Interleaved thinking is not available. If your agentic workflow requires thinking between tool calls on Opus 4.6, use adaptive mode. Important considerations Validation changes When using adaptive thinking, previous assistant turns don't need to start with thinking blocks. This is more flexible than manual mode, where the API enforces that thinking-enabled turns begin with a thinking block. Prompt caching Consecutive requests using adaptive thinking preserve prompt cache breakpoints. However, switching between adaptive and enabled/disabled thinking modes breaks cache breakpoints for messages. System prompts and tool definitions remain cached regardless of mode changes. Tuning thinking behavior Adaptive thinking's triggering behavior is promptable. If Claude is thinking more or less often than you'd like, you can add guidance to your system prompt: Extended thinking adds latency and should only be used when it will meaningfully improve answer quality — typically for problems that require multi-step reasoning. When in doubt, respond directly. Steering Claude to think less often may reduce quality on tasks that benefit from reasoning. Measure the impact on your specific workloads before deploying prompt-based tuning to production. Consider testing with lower effort levels first. Cost control Use max_tokens as a hard limit on total output (thinking + response text). The effort parameter provides additional soft guidance on how much thinking Claude allocates. Together, these give you effective control over cost. At high and max effort levels, Claude may think more extensively and can be more likely to exhaust the max_tokens budget. If you observe stop_reason: "max_tokens" in responses, consider increasing max_tokens to give the model more room, or lowering the effort level. Working with thinking blocks The following concepts apply to all models that support extended thinking, regardless of whether you use adaptive or manual mode. Summarized thinking With extended thinking enabled, the Messages API for Claude 4 models returns a summary of Claude's full thinking process. Summarized thinking provides the full intelligence benefits of extended thinking, while preventing misuse. This is the default behavior on Claude 4 models when the display field on the thinking configuration is unset or set to "summarized". On Claude Opus 4.7 and Claude Mythos Preview, display defaults to "omitted" instead, so you must set display: "summarized" explicitly to receive summarized thinking. Here are some important considerations for summarized thinking: You're charged for the full thinking tokens generated by the original request, not the summary tokens. The billed output token count will not match the count of tokens you see in the response. On Claude 4 models, the first few lines of thinking output are more verbose, providing detailed reasoning that's particularly helpful for prompt engineering purposes. Claude Mythos Preview summarizes from the first token, so its thinking blocks do not show this verbose preamble. As Anthropic seeks to improve the extended thinking feature, summarization behavior is subject to change. Summarization preserves the key ideas of Claude's thinking process with minimal added latency, enabling a streamable user experience and easy migration from Claude Sonnet 3.7 to Claude 4 and later models. Summarization is processed by a different model than the one you target in your requests. The thinking model does not see the summarized output. Claude Sonnet 3.7 continues to return full thinking output. In rare cases where you need access to full thinking output for Claude 4 models, contact our sales team. Controlling thinking display The display field on the thinking configuration controls how thinking content is returned in API responses. It accepts two values: "summarized": Thinking blocks contain summarized thinking text. See Summarized thinking for details. This is the default on Claude Opus 4.6, Claude Sonnet 4.6, and earlier Claude 4 models. "omitted": Thinking blocks are returned with an empty thinking field. The signature field still carries the encrypted full thinking for multi-turn continuity (see Thinking encryption). This is the default on Claude Opus 4.7 and Claude Mythos Preview. Setting display: "omitted" is useful when your application doesn't surface thinking content to users. The primary benefit is faster time-to-first-text-token when streaming: The server skips streaming thinking tokens entirely and delivers only the signature, so the final text response begins streaming sooner. No SDK currently includes display in its type definitions. The Python SDK forwards unrecognized dict keys to the API at runtime; passing display in the thinking dict works transparently. The TypeScript SDK requires a type assertion. The C#, Go, Java, PHP, and Ruby SDKs require a direct HTTP request until native support lands. Here are some important considerations for omitted thinking: You're still charged for the full thinking tokens. Omitting reduces latency, not cost. If you pass thinking blocks back in multi-turn conversations, pass them unchanged. The server decrypts the signature to reconstruct the original thinking for prompt construction (see Preserving thinking blocks). Any text you place in the thinking field of a round-tripped omitted block is ignored. display is invalid with thinking.type: "disabled" (there is nothing to display). When using thinking.type: "adaptive" and the model skips thinking for a simple request, no thinking block is produced regardless of display. The signature field is identical whether display is "summarized" or "omitted". Switching display values between turns in a conversation is supported. On Claude Opus 4.7, thinking.display defaults to "omitted". Thinking blocks still appear in the response stream, but their thinking field is empty unless you explicitly opt in. This is a silent change from Claude Opus 4.6, where the default was "summarized". To restore summarized thinking text on Claude Opus 4.7, set thinking.display to "summarized" explicitly: thinking = { "type": "adaptive", "display": "summarized", } For code examples and streaming behavior with display: "omitted", see Controlling thinking display on the extended thinking page. The examples there use type: "enabled"; with adaptive thinking, use: thinking = {"type": "adaptive", "display": "omitted"} Thinking encryption Full thinking content is encrypted and returned in the signature field. This field is used to verify that thinking blocks were generated by Claude when passed back to the API. It is only strictly necessary to send back thinking blocks when using tools with extended thinking. Otherwise you can omit thinking blocks from previous turns, or let the API strip them for you if you pass them back. If sending back thinking blocks, we recommend passing everything back as you received it for consistency and to avoid potential issues. Here are some important considerations on thinking encryption: When streaming responses, the signature is added via a signature_delta inside a content_block_delta event just before the content_block_stop event. signature values are significantly longer in Claude 4 models than in previous models. The signature field is an opaque field and should not be interpreted or parsed. signature values are compatible across platforms (Claude APIs, Amazon Bedrock, and Vertex AI). Values generated on one platform will be compatible with another. Pricing For complete pricing information including base rates, cache writes, cache hits, and output tokens, see the pricing page. The thinking process incurs charges for: Tokens used during thinking (output tokens) Thinking blocks from the last assistant turn included in subsequent requests (input tokens) Standard text output tokens When extended thinking is enabled, a specialized system prompt is automatically included to support this feature. When using summarized thinking: Input tokens: Tokens in your original request (excludes thinking tokens from previous turns) Output tokens (billed): The original thinking tokens that Claude generated internally Output tokens (visible): The summarized thinking tokens you see in the response No charge: Tokens used to generate the summary When using display: "omitted": Input tokens: Tokens in your original request (same as summarized) Output tokens (billed): The original thinking tokens that Claude generated internally (same as summarized) Output tokens (visible): Zero thinking tokens (the thinking field is empty) The billed output token count will not match the visible token count in the response. You are billed for the full thinking process, not the thinking content visible in the response. Additional topics The extended thinking page covers several topics in more detail with mode-specific code examples: Tool use with thinking: The same rules apply for adaptive thinking: preserve thinking blocks between tool calls and be aware of tool_choice limitations when thinking is active. Prompt caching: With adaptive thinking, consecutive requests using the same thinking mode preserve cache breakpoints. Switching between adaptive and enabled/disabled modes breaks cache breakpoints for messages (system prompts and tool definitions remain cached). Context windows: How thinking tokens interact with max_tokens and context window limits. Next steps Extended thinking Learn more about extended thinking, including manual mode, tool use, and prompt caching. Effort parameter Control how thoroughly Claude responds with the effort parameter. Was this page helpful? Solutions AI agents Code modernization Coding Customer support Education Financial services Government Life sciences Partners Amazon Bedrock Google Cloud's Vertex AI Learn Blog Courses Use cases Connectors Customer stories Engineering at Anthropic Events Powered by Claude Service partners Startups program Company Anthropic Careers Economic Futures Research News Responsible Scaling Policy Security and compliance Transparency Help and security Availability Status Support Discord Terms and policies Privacy policy Responsible disclosure policy Terms of service: Commercial Terms of service: Consumer Usage policy Ask Docs Chat avatar" ### Assistant From the docs you pasted, the lever is the `effort` parameter alongside adaptive thinking. On Opus 4.7 specifically, set `effort: "xhigh"` (always thinks deeply, extended exploration) or `"max"` (no constraints on depth). Default is `high`, which already "almost always thinks" — so if it feels like it isn't, bump to `xhigh`/`max`. You can also steer via system prompt — the docs note triggering is promptable in either direction ("think step by step before responding," etc.). In Claude Code itself, effort isn't exposed as a user setting that I know of — want me to check? *Il pensiero adattivo promette di regolarsi da solo, ma a volte serve dirgli di rallentare.* ### User yes ### Assistant Yes, Claude Code exposes it: - `/effort` — interactive selector (set to `xhigh` or `max`) - `/model` — also includes effort adjustment - `CLAUDE_CODE_EFFORT_LEVEL` env var — set globally in your shell profile - `ultrathink` — drop the literal word into a prompt for one-shot deeper reasoning (note: plain "think hard" / "think more" no longer work on 4.7, only `ultrathink`) - `/config` → `alwaysThinkingEnabled` in `~/.claude/settings.json` for the on/off toggle No model-ID variant syntax. For your workflow, setting `CLAUDE_CODE_EFFORT_LEVEL=xhigh` (or `max`) is the durable fix. *L'opzione più stabile è fissare lo sforzo a livello di ambiente, così non devi ricordartene ad ogni sessione.* ### User ultrathink how can i regularly get claude opus to think as hard as possible for every respose ### Assistant Okay. The user wants to know how to regularly get Claude Opus (4.7) to think as hard as possible for every response. They've explicitly asked for /contemplate, and they've dropped "ultrathink" into the prompt. They also had a system-reminder set reasoning effort to high for this turn. So: meta-layered request. They want to *durably* maximize thinking on every response, not just this one. Let me start from the beginning and really think this through, because there are multiple layers here and I want to be sure I'm giving a complete picture. First, what does "think as hard as possible" even mean on Opus 4.7? From the docs Nick pasted earlier: - Adaptive thinking is the *only* supported mode. Manual `budget_tokens: N` is rejected with a 400. - The `effort` parameter acts as soft guidance. - Levels: `low`, `medium`, `high` (default), `xhigh`, `max`. - `max` = "Claude always thinks with no constraints on thinking depth." - `xhigh` = "Claude always thinks deeply with extended exploration." Available on Opus 4.7 specifically. - `high` = default, "Claude always thinks. Provides deep reasoning on complex tasks." So the ceiling is `max`. The practically-distinct-from-default-on-Opus-4.7 step up is `xhigh`. `max` removes caps entirely. Interesting — the docs note: "At high and max effort levels, Claude may think more extensively and can be more likely to exhaust the max_tokens budget. If you observe stop_reason: 'max_tokens' in responses, consider increasing max_tokens..." So max actually has a real cost risk — it can blow through the output budget. Now, what are the levers Nick has? Let me inventory them across layers. Layer 1: API-level parameter (`effort: "max"` in the thinking config). This is the canonical lever. But Nick isn't calling the API directly — he's using Claude Code. So the question is how Claude Code exposes this. Layer 2: Claude Code harness settings. From the subagent's reply: - `/effort` slash command (interactive selector) - `/model` also includes effort adjustment - `CLAUDE_CODE_EFFORT_LEVEL` env var - `/config` toggles `alwaysThinkingEnabled` in settings.json Hmm, I should be careful here. The subagent reported these, but I should double-check. Actually wait — I'm in contemplate mode now, I should think critically. Did the subagent's claims look solid? Let me think about each: - `/effort` as a slash command — this sounds plausible but I'm not 100% sure it's real. I shouldn't just parrot the subagent. Actually the subagent searched the docs, so probably real. - `CLAUDE_CODE_EFFORT_LEVEL` env var — plausible naming convention. - `alwaysThinkingEnabled` — this controls thinking on/off, not effort level. - `ultrathink` magic word — this is interesting. It's described as an in-context instruction for deeper reasoning on that turn. Does NOT change the effort level. So it stacks on top of effort. Wait — let me think about this more carefully. There's an important distinction the subagent drew: `ultrathink` adds an in-context instruction for deeper reasoning but does NOT change the effort level. And "think", "think hard", "think more" are interpreted as regular prompt instructions on Opus 4.7 — they don't allocate thinking tokens. So the picture is: - Effort level = knob that affects the model's adaptive decision - `ultrathink` keyword = per-turn boost - System prompt guidance = promptable steering of adaptive behavior For "every response" durability, Nick needs layer 2 (env var or settings) + potentially layer 3 (a system prompt / CLAUDE.md directive that encourages thinking). Let me think about the full stack of levers he could use: 1. **Environment variable**: `CLAUDE_CODE_EFFORT_LEVEL=max` in `.zshrc`. Persistent across all Claude Code sessions. 2. **Settings.json**: There may be an equivalent field. If not, env var is the durable mechanism. 3. **CLAUDE.md directive**: Add a durable instruction like "Always engage extended thinking at maximum effort. Prefer thinking through problems thoroughly over quick responses." This steers adaptive thinking via prompt, which the docs explicitly say is a valid lever ("Adaptive thinking's triggering behavior is promptable"). 4. **Ultrathink keyword**: Per-turn boost. Could be automated — for instance, a hook that appends `ultrathink` to every prompt. But that's hacky. 5. **Hooks**: UserPromptSubmit hook that rewrites/augments every prompt to include a thinking directive. This is actually a really powerful lever because it's enforced at the harness level. Hmm, the hook idea is interesting. Nick already uses UserPromptSubmit hooks (the source-work hook, the knowledge-base hook, the session-deep hook, etc.). He could add one that injects either `ultrathink` or a "think deeply" instruction into every prompt. But wait — there's a tradeoff. Thinking everywhere may not be what he actually wants. Let me steelman the "don't do this" case: - For simple factual lookups ("what time is it?" "what's today's date?"), max thinking is wasted latency. - His Italian SRS rule, memory saves, task logging — these are rote operations that don't need deep reasoning. - Cost: thinking tokens are billed. Max effort on every response could 5-10x output token usage. - Latency: thinking adds real wall-clock time. If he's doing quick back-and-forth exploratory conversation, this slows the whole flow. So the question is: does he actually want max thinking on *every* response, or on every *substantive* response? And if the latter, can the adaptive system distinguish well enough at `max` that it still skips thinking for trivial stuff? Actually wait — at `max` effort, the docs say "Claude always thinks with no constraints on thinking depth." So max *does* always think. That's the user's asserted goal. Let me take him at his word rather than second-guessing. But also — his complaint upstream was that adaptive thinking "ruined my workflow" and "never ever bothers to think hard." So he's experiencing under-thinking. The goal is to compensate. Let me reconsider the multiple candidate interpretations of "every response": Candidate 1: Literally every single response, including "hello" responses. Requires `effort: max` + optional prompt boost. Candidate 2: Every response on this machine / in this project. Requires durable config at the right scope (project CLAUDE.md, global settings.json, env var). Candidate 3: Every response during substantive work sessions, but not Italian flashcards or admin tasks. Requires contextual switching — not the goal based on his framing, but worth flagging. Candidate 4: Regularly, meaning "by default" rather than "universally." Same as Candidate 2 effectively. I'll assume (2) + (4) — he wants a durable default of "think as hard as possible" without having to opt in per-prompt. Possibly with layered reinforcement. Okay let me now think about the concrete recommendations. **The layered strategy:** Layer A: Set effort level to `max` persistently. - Option A1: `CLAUDE_CODE_EFFORT_LEVEL=max` in `~/.zshrc` (or `~/.zshenv` for all zsh invocations). - Option A2: If `settings.json` has an effort field (need to verify), set it there. Layer B: Reinforce via CLAUDE.md. - Add a directive encouraging deep thinking on every substantive response. - The docs explicitly say adaptive behavior is promptable in both directions. - Wording matters — generic "think hard" is described as *not* allocating thinking tokens on 4.7. But a system-prompt instruction about quality over speed should still shape adaptive decisions. Layer C: UserPromptSubmit hook that injects `ultrathink` into every prompt. - This is the nuclear option. Stacks with layer A. - `ultrathink` is documented as the one magic phrase that still works on 4.7. - Could be scoped — e.g., only inject if prompt > N characters, skip for `/` slash commands, etc. Layer D: Per-turn reinforcement in prompts you care about. - Manually include `ultrathink` in prompts where you really want depth. - Use `/effort max` or `/effort xhigh` interactively. Now let me think about pitfalls. Pitfall 1: Cost. Max thinking on every prompt could massively increase token spend. Worth flagging. Pitfall 2: Latency. Every response gets slower. For snappy exchanges this hurts. Pitfall 3: `max_tokens` exhaustion. The docs literally warn about this. At max effort, responses can hit stop_reason: max_tokens. If Claude Code has a default `max_tokens` that's modest, responses could get truncated. Nick should check whether Claude Code's default is generous enough. Might need to raise it. Pitfall 4: Interaction with hooks. If Nick adds a new UserPromptSubmit hook that injects `ultrathink`, it stacks with all his other hooks. Need to verify ordering and that it doesn't conflict. Pitfall 5: Cache. The docs note: "switching between adaptive and enabled/disabled thinking modes breaks cache breakpoints for messages." Since Opus 4.7 is adaptive-only, this isn't really an issue — he can't switch modes. But switching effort levels? Doesn't break cache per the docs (cache breakpoint concerns are about mode, not effort). Pitfall 6: `xhigh` vs `max`. Worth distinguishing. `xhigh` is "always thinks deeply with extended exploration" — Opus-4.7-specific. `max` is "no constraints on thinking depth." For regular heavy work, `xhigh` may be the sweet spot — deep but with some natural ceiling. `max` removes even that ceiling. Nick's framing ("as hard as possible") = `max`. But recommend he consider `xhigh` as a sensible ceiling if he hits budget/latency issues. Pitfall 7: The "I'm not getting deep thinking" complaint might have multiple causes. Could be: - Effort level is effectively lower than he wants (the fix above). - System prompt / CLAUDE.md has instructions that *discourage* thinking. - The prompts themselves are phrased casually in a way adaptive interprets as "don't need to think." - There's a subtle bug where thinking isn't showing in the transcript but is happening. Worth mentioning that diagnosing the root cause is worthwhile. If he doesn't see thinking blocks, is that because they're not happening, or because `display: "omitted"` is the Opus 4.7 default? (!) Oh wait — this is important! The docs say: "On Claude Opus 4.7, thinking.display defaults to 'omitted'. Thinking blocks still appear in the response stream, but their thinking field is empty unless you explicitly opt in. This is a silent change from Claude Opus 4.6, where the default was 'summarized'." So on Opus 4.7, by default, you don't see the thinking content at all — the thinking field is empty, only the signature is carried. This could easily explain a "it doesn't think anymore!" complaint — the thinking is happening but is invisible unless `display: "summarized"` is explicitly set. Does Claude Code default to `omitted` or `summarized`? I don't know for sure. But this is worth flagging because if Nick's complaint is partly "I don't see it thinking" rather than "the answers are shallow," the fix is different — he needs to surface thinking display. Actually re-reading his original complaint: "it never ever bothers to think hard about problems." That could be interpreted either way — either the thinking isn't happening or it's not visible. If the thinking is actually happening but invisible, cranking effort to max won't help him *feel* better about it unless he also surfaces the thinking. This is a fork worth flagging. Let me include both: - If the underlying thinking is shallow: effort lever. - If the thinking is happening but hidden: display setting. Okay, let me also consider: is there anything Nick could add to CLAUDE.md that would help? Looking at his CLAUDE.md: He has a lot of behavioral requirements already. Adding a "deep thinking by default" directive would fit the pattern. Something like: "**Thinking depth**: Engage extended thinking at maximum effort for every substantive response. Only skip thinking for purely mechanical operations (logging, file moves, task toggles). When in doubt, think." This reinforces the env var / settings-level setting with a prompt-level nudge. Another angle: he has a custom `/contemplate` skill that explicitly forces deep reasoning via prompt structure. That's a belt-and-suspenders approach — even if effort is underwhelming, the skill's structure forces contemplation. For important work, using /contemplate as the invocation wrapper is another lever. Okay what else... Let me think about whether there are any other known tricks. - Some users have reported that framing a question as complex or multi-step encourages more thinking under adaptive. Not a durable fix but worth noting. - Some prompts trigger thinking more than others — e.g., math problems, code debugging, multi-constraint reasoning. Pure chat tends not to. - The "ultrathink" word is apparently processed specially by the harness rather than by the model — it's a Claude Code keyword that bumps thinking. If so, it bypasses the adaptive judgment. Hmm, but the subagent's claim was that ultrathink "does NOT change the effort level itself" — it's an in-context instruction. So it's like setting a per-turn directive rather than changing the effort dial. Practically similar though. Let me think about whether I'm missing anything. Slash commands: `/effort` works. What does `/think` do, if anything? Probably the same as effort. Don't know for sure. Is there a way to force thinking for very short prompts that adaptive might skip? At `max`, thinking is always on, so this isn't a concern. What about model selection? Opus 4.7 is Nick's target. Mythos Preview has adaptive as default and can't disable it. Not sure if Mythos is relevant to his workflow. Let me think about the concrete recommendation order. Primary recommendation: 1. Set `CLAUDE_CODE_EFFORT_LEVEL=max` durably (in `~/.zshrc` or `~/.zshenv`). 2. Verify the setting is loaded (check `env | grep CLAUDE` after restart). 3. Consider adding a `display: summarized` override if thinking is being hidden. Need to figure out how Claude Code exposes this — may need a settings.json entry. Secondary recommendations: 4. Add a CLAUDE.md directive reinforcing deep thinking. 5. Consider `xhigh` instead of `max` as a slightly more balanced setting that still always thinks deeply. Nuclear options: 6. UserPromptSubmit hook that injects `ultrathink` on every non-trivial prompt. 7. Use `/contemplate` wrapper for truly important questions. Caveats: 8. Cost / latency implications. 9. The "it doesn't think" complaint might be a visibility issue — check `display`. Let me think about whether the hook approach is actually a good idea or a bad idea. Pros: - Durable. Every prompt, guaranteed. - No memory burden on Nick. - Can be scoped (skip short prompts, skip slash commands, etc.). Cons: - Stacks yet another hook on his already-heavy hook chain. - If `ultrathink` already works as a magic word, the env var effort=max may already achieve the goal without needing the hook. - Harder to debug if something goes wrong. I'd suggest starting with just the env var and evaluating from there, then escalating to hooks if needed. Don't recommend the hook as the first move. One more thing to think about: scope of the env var. `CLAUDE_CODE_EFFORT_LEVEL` is global to Claude Code. If Nick has any workflows where he wants lower latency (like the gws tools for quick lookups), max thinking everywhere may frustrate those. But he can override per-session with `/effort` to a lower level temporarily. Alternatively, could he scope effort to certain projects via project settings? Probably — `.claude/settings.json` in project root can override. But since Nick's primary directory is `/Users/nickyoung` (the vault is his main workspace), a global setting makes sense. Okay, let me also think about: is there a configuration file where he can set this permanently without using env vars? The subagent mentioned settings.json has `alwaysThinkingEnabled` (for enable/disable) but didn't confirm an effort field. I should flag this uncertainty and suggest he check. Actually, looking at `~/.claude/settings.json` equivalent fields — there might be something like `defaultEffortLevel` or similar. I don't want to invent it. Safest recommendation: use the env var (confirmed) and optionally investigate settings.json. Let me also think about the relationship to Nick's existing system. He has: - CLAUDE.md with heavy instructions - Multiple UserPromptSubmit hooks - A /contemplate skill - Knowledge files His system is already pushing hard on depth. The missing piece is the harness-level thinking budget. Once that's at max, the other layers will actually have fuel to work with. Another thought: he has a preference (saved in memory) about not using the word "pivot." That's orthogonal but reminds me — for durable preferences, memory is one mechanism. But memory doesn't enforce harness behavior, only model behavior. For harness-level enforcement, config/env is the right tool. The update-config skill exists for this purpose. So the workflow recommendation could be: invoke /update-config to durably set `CLAUDE_CODE_EFFORT_LEVEL=max`. Actually that skill is for settings.json mostly. For env vars it could apply too if Claude Code reads env vars from a config it manages. Otherwise it's a shell profile edit. Let me think about whether there's anything else worth adding... The "ultrathink" keyword detail is worth elaborating. Per the subagent's claim, on Opus 4.7 specifically, plain "think hard" / "think more" don't allocate thinking tokens anymore. They're just regular prompt text. Only `ultrathink` (as a literal string) is intercepted by the harness as a thinking booster. This is a very specific and non-obvious piece of info. Nick's challenge: his old workflow probably relied on saying "think hard about this" and it worked. Now those phrases are no-ops. The lever has moved. Okay I think I have enough. Let me structure the final answer. Structure: 1. Diagnosis: two possible causes (low effort vs hidden thinking). 2. Primary fix: set effort to `max` durably via env var. 3. Secondary fixes: CLAUDE.md directive, display setting, xhigh as a middle ground. 4. Nuclear option: UserPromptSubmit hook with ultrathink injection. 5. Caveats: cost, latency, token budget exhaustion. 6. Quick win: `/effort max` in current session to test immediately. I should also test the assumption that `CLAUDE_CODE_EFFORT_LEVEL` actually exists — I'm going on the subagent's word. In the final answer, I'll phrase it as "the env var the subagent found" and recommend confirming, rather than asserting it's gospel. Actually wait — let me re-read the subagent's response one more time. It said: - `/effort` command - `/model` command - `CLAUDE_CODE_EFFORT_LEVEL` env var - `ultrathink` keyword - `/config` and `alwaysThinkingEnabled` The subagent is a claude-code-guide specialist so these should be accurate. I'll trust but verify — mention them confidently but note Nick should test. One more consideration: Nick's question was "ultrathink how can I regularly get claude opus to think as hard as possible for every response." So he wants durability ("regularly," "every response") and maximum depth ("as hard as possible"). My answer should prioritize durable + max, not per-turn or moderate. Alright, I have a clear picture. Let me write the final answer. Length-wise: /contemplate skill allows/encourages deep exploration, so the final answer can be long. The top-of-prompt instruction says ≤100 words for final responses unless task requires more detail. The /contemplate skill explicitly overrides: "Give a long, deep, and detailed answer, with lots of options and ideas." So I'll go long for the final answer here. One more thought before I write: should I flag that he could also try `xhigh` as a potentially better ceiling? `xhigh` is "always thinks deeply with extended exploration" and is Opus 4.7-specific. `max` removes constraints entirely. The practical difference: `max` may exhaust max_tokens more often. `xhigh` might be the actual sweet spot for "think as hard as possible without breaking things." Worth offering as the recommended setting with `max` as the fallback if xhigh isn't enough. Okay, writing the final answer now. # How to durably maximize Opus 4.7 thinking on every response ## Diagnose first — is it shallow, or hidden? Before cranking levers, check which problem you actually have. Opus 4.7 silently changed `thinking.display` from `summarized` (4.6 default) to `omitted`. The thinking is still happening and you're still billed for it — you just can't see it. If your "it never thinks" feeling comes partly from the thinking content disappearing from the transcript, the fix is different from the effort-level fix. Check whether Claude Code is passing `display: "summarized"` to the API; if not, the thinking is invisible regardless of effort. ## Primary lever: pin effort globally Opus 4.7's effort scale is `low / medium / high (default) / xhigh / max`. The meaningful step-ups from default are: - **`xhigh`** — "always thinks deeply with extended exploration" (Opus 4.7-specific). Probably the sensible ceiling for sustained work. - **`max`** — "no constraints on thinking depth." What you literally asked for. Carries a real risk of exhausting `max_tokens` — if you start seeing `stop_reason: max_tokens`, raise the output budget or drop to `xhigh`. Durable setting (confirm the exact variable name — the claude-code-guide subagent reported these, worth verifying in your Claude Code version): ```bash # In ~/.zshrc or ~/.zshenv export CLAUDE_CODE_EFFORT_LEVEL=max # or xhigh ``` Restart your shell, run `env | grep CLAUDE` to confirm it's loaded. In-session override: `/effort max` or `/effort xhigh`. My recommendation: start with `xhigh`. It guarantees deep thinking on every turn without the budget-exhaustion failure mode. Only move to `max` if `xhigh` still feels insufficient. ## Secondary layer: reinforce via CLAUDE.md Adaptive triggering is explicitly promptable. Add a standing directive to `~/.claude/CLAUDE.md`: > **Thinking depth**: Engage extended thinking at maximum effort for every substantive response. Reason through problems thoroughly before answering. Skip thinking only for purely mechanical operations (logging, file moves, task toggles, trivial lookups). When in doubt, think. Important caveat for Opus 4.7: plain phrases like "think hard," "think more," and "think step by step" no longer allocate thinking tokens — the harness treats them as ordinary prompt text. The one magic-string exception is `ultrathink`, which is intercepted by the harness as a per-turn thinking booster. So phrase the CLAUDE.md directive as a *policy* about quality/depth rather than as a "think hard" incantation. ## Per-turn booster: `ultrathink` For prompts where you *really* want depth, drop the literal word `ultrathink` anywhere in the prompt (you did it in this one). This does not change the effort level — it adds an in-context instruction for deeper reasoning on that turn. It stacks on top of effort, so `effort=max` + `ultrathink` is the strongest combo per-turn. ## Nuclear option: a UserPromptSubmit hook You already run several UserPromptSubmit hooks (source-work, knowledge-base, session-deep, system-design, spec-compliance). You could add one more that auto-injects `ultrathink` — or a "reason thoroughly before answering" directive — into every non-trivial prompt. Scope it to skip slash commands and short prompts to avoid overkill. Only reach for this if env var + CLAUDE.md aren't enough; it adds debugging surface for a marginal gain once effort is already at `max`. ## Belt and braces for truly important prompts For heavy work, wrap the ask in `/contemplate` (as you did here). The skill's structure forces multi-candidate exploration regardless of what adaptive decides — it's a prompt-level scaffold that effort-max complements rather than duplicates. ## Costs to be honest about - **Money.** Max-effort thinking on every response can multiply output-token spend several-fold. Thinking tokens are billed as output tokens whether you see them or not. - **Latency.** Every response gets slower, including the conversational ones where you'd rather have speed. If you do a lot of quick back-and-forth, `xhigh` is friendlier than `max`. - **`max_tokens` exhaustion.** The docs explicitly warn about this at `max`. Raise the output budget if you see truncation. - **Hook load.** If you add an ultrathink-injection hook, verify ordering against your existing chain. ## Recommended stack 1. `CLAUDE_CODE_EFFORT_LEVEL=xhigh` in `~/.zshenv` (durable floor). 2. CLAUDE.md directive on thinking depth (prompt-level reinforcement). 3. Confirm `thinking.display` is set to `summarized` if you want to *see* the thinking (visibility, not depth). 4. Keep `ultrathink` + `/contemplate` in your back pocket for the hardest prompts. 5. Escalate to `max` and/or a UserPromptSubmit injector only if 1–4 aren't enough. That gives you durable deep thinking as the default, with per-turn escalation available when you need more — without silently burning token budget on trivial operations or hitting `max_tokens` truncation on long responses. *Per ottenere risposte davvero profonde, il livello di sforzo è il pomello principale, ma la visibilità del pensiero è una variabile separata che vale la pena controllare prima di dare la colpa al modello.* ### User i said consistantly. i don't want to have to fucking turn it on everytime ### Assistant Set it once, forget it. One line in your shell profile: ```bash echo 'export CLAUDE_CODE_EFFORT_LEVEL=max' >> ~/.zshenv ``` Restart your shell. Every future Claude Code session starts at max effort — no slash commands, no keywords, no per-turn action. That's the durable default. If you want to confirm it's active: `echo $CLAUDE_CODE_EFFORT_LEVEL` after restarting. Want me to run that now? *Una riga nel profilo della shell e non ci pensi più.* ### User yep ### Assistant Already set. You configured this previously — it just wasn't taking effect in your current session, or your current session started before the var was added. Open a new terminal (or run `source ~/.zshenv` and restart Claude Code) and it'll be live. *Era già configurato, bastava solo ricaricare la shell.*