Claude Code Opus effort 가이드: Extra high·Max·Ultracode는 언제 쓸까
Claude Code에서 Opus의 effort를 높여야 할 때는 언제일까요? Extra high, Max, Ultracode의 차이를 구분하고, UI 수정부터 복잡한 버그 분석까지 작업에 맞는 설정과 전환 기준을 구체적인 명령과 프롬프트로 정리합니다.
Claude Code 공식 웹사이트에서 소개하는 Opus를 사용하더라도, 모든 요청을 가장 높은 설정으로 처리할 필요는 없습니다. 화면을 보며 작은 수정을 반복할 때와 여러 원인을 검토하며 버그를 추적할 때는 기다릴 만한 작업의 양이 다릅니다.
작은 변경은 빠르게 확인하고, 판단이 어려운 구간에서 effort를 올리고, 나눌 수 있는 큰 작업에서 Ultracode를 검토하세요. 아래 추천은 작업 운영을 위한 제안이며 성능 벤치마크 결과가 아닙니다. 기능과 명령은 2026년 10월 19일 공식 문서를 확인했으며, Ultracode의 분리된 토글 설명은 Claude Code v2.1.284 이상을 기준으로 합니다.
먼저, 세 이름의 차이를 구분하기
| 표시·입력값 | 무엇을 조절하나 | 선택할 때의 질문 |
|---|---|---|
Extra high · xhigh | 높은 추론 노력 | 여러 조건과 원인을 더 깊이 검토해야 하나? |
Max · max | 가장 높은 추론 노력 | 더 기다리고 더 많은 토큰을 써서라도 어려운 판단을 재검토할 가치가 있나? |
Ultracode · ultracode | 동적 워크플로 구성 | 작업을 조사·구현·검증 등으로 나누어 진행할 실익이 있나? |
low → medium → high → xhigh → max는 effort 단계입니다. 다만 Ultracode를 Max보다 한 단계 높은 effort로 해석하면 안 됩니다. 최신 버전에서는 effort와 별도로 켜고 끌 수 있습니다. 또 구독 상품인 Max 요금제와 max effort는 서로 다른 개념입니다. 모델 설정 문서
공식 공개 문서의 effort 비교 표를 캡처했습니다. 마지막 행은 Ultracode를 모델 effort와 구분합니다. (출처: Claude Code Docs, 2026-10-19 캡처 · 이미지 크게 보기)
effort는 고정된 대기 시간이나 정답 보증이 아닙니다. 응답·도구 호출·추론에 사용하는 토큰에 영향을 주므로, 같은 작업이라도 시간과 사용량이 달라질 수 있습니다. max를 사용해도 컨텍스트 한도나 서비스 사용 한도가 사라지지는 않습니다. Effort API 문서
내 Opus 버전의 기본값부터 확인하기
현재 Claude Code 문서의 기본값은 Opus 5.5는 medium, Opus 5와 4.8은 high, Opus 4.7은 xhigh입니다. Opus 4.6은 xhigh를 지원하지 않습니다. 설정·환경 변수·조직 정책이 적용되면 실제 값은 달라질 수 있습니다. 모델별 지원 단계와 기본값
따라서 “Opus는 무조건 Extra high로 시작한다”는 조언을 모든 버전에 적용하지 마세요. 모델이 바뀌면 평소 처리하는 작은 작업으로 기본값의 결과부터 확인하는 편이 좋습니다. 모델이 다르면 같은 effort 이름을 동일한 연산량이나 품질로 비교할 수도 없습니다.
터미널에서 버전을 확인하고, 세션 안에서는 모델과 적용된 effort를 확인합니다. /model은 선택기를 여는 명령입니다.
claude --version/model
/effort status작업별로 어디서 시작할까
다음 표는 Opus 5.5를 사용하는 대화형 바이브 코딩의 시작점입니다. 한 번에 완성하려 하기보다, 결과를 보고 다음 단계를 고르는 운영 예시입니다.
| 지금 하는 작업 | 시작 설정 | 올려야 할 신호 |
|---|---|---|
| 문구, 색상, 여백처럼 결과를 바로 보는 수정 | low 또는 medium | 상태·접근성 등 다른 동작까지 영향을 받음 |
| 요구사항과 완료 조건이 정해진 기능 하나 | medium | 예외 처리나 기존 규칙을 빠뜨림 |
| 폼 검증, 오류 처리, 기존 기능의 버그 수정 | high | 여러 원인이 얽혀 한 가설로 설명되지 않음 |
| 상태 동기화, 비동기 순서, 구조 변경의 영향 분석 | xhigh | 반례가 남고 기존 접근으로 해결되지 않음 |
| 재현 자료를 갖춘 어려운 원인 분석, 설계 반례 검토 | max를 한정 사용 | 검증 가능한 새 근거 없이 분석만 반복되면 중단 |
| UI·데이터·테스트처럼 분담 가능한 큰 기능 | 적절한 effort + Ultracode | 역할·입출력·통합 기준을 먼저 정할 수 있음 |
파일 수만으로 판단하지는 마세요. 파일 20개에서 같은 문구를 바꾸는 작업보다, 파일 하나에서 발생하는 비동기 경쟁 상태가 더 어려울 수 있습니다. 변경량보다 판단의 불확실성과 오류의 영향을 보세요.
Extra high: 연결된 조건을 놓치기 시작할 때
예를 들어 검색창의 결과가 가끔 이전 검색어로 되돌아간다고 합시다. 단순한 화면 수정처럼 보여도 요청 순서, 응답 지연, 취소 처리, 상태 갱신 규칙을 함께 살펴야 합니다. 이런 경우 xhigh로 올려 원인별 증거를 정리하게 하는 방식이 유용합니다.
Claude Code 입력창에서 실행합니다.
/effort xhigh이어 다음처럼 요청합니다.
검색어를 빠르게 바꾸면 이전 검색 결과가 마지막에 표시됩니다. 재현 순서와 네트워크 로그를 기준으로 요청 생성, 응답 도착, 화면 반영 순서를 추적해 주세요. 가능한 원인을 구분하고, 각 원인을 배제하거나 확인할 관측값을 제시한 뒤 가장 작은 수정과 회귀 테스트를 작성해 주세요.
핵심은 “더 생각해 줘” 대신 어떤 근거를 연결해야 하는지 알려 주는 것입니다. 원인과 수정 방법이 확인되면 후속 문구 정리나 스타일 수정까지 계속 xhigh로 처리할 필요는 없습니다.
Max: 해결되지 않은 핵심 질문에 한정하기
max는 충분한 재현 자료를 제공했는데도 중요한 반례가 남는 상황에서 검토할 만합니다. 예를 들면 여러 클라이언트가 동시에 문서를 수정할 때 변경 내용이 사라지는 문제입니다. 원인 분석보다 로그가 부족한 상황이라면, effort를 올리기 전에 관측 지점을 추가해야 합니다.
/effort max두 사용자가 동시에 저장할 때 한쪽 수정이 유실됩니다. 첨부한 재현 테스트와 이벤트 순서를 사용해 현재 병합 규칙의 반례를 찾으세요. 제안한 수정이 단일 사용자 저장과 재접속 복구를 깨뜨리지 않는지 확인하고, 가설·증거·미확인 항목을 구분해 주세요. 근거 없이 전체 저장 구조를 교체하지 마세요.
종료 조건도 함께 정합니다. 이 예에서는 유실을 재현하는 테스트가 통과하고, 기존 저장·복구 테스트가 유지되며, 남은 제약이 설명되면 종료입니다. 더 긴 답변이나 더 많은 파일 변경을 성공 지표로 삼지 않습니다.
Anthropic도 max에서 추가 비용에 비해 개선이 작거나 과도한 검토가 발생할 수 있다고 설명합니다. 어려운 질문 하나가 해결되면 일상 설정으로 돌아오는 편이 좋습니다. 공식 effort 선택 안내
Ultracode: 분담과 통합이 필요한 작업에 사용하기
Ultracode를 켜면 Claude Code가 실질적인 작업에 동적 워크플로를 구성합니다. 여러 서브에이전트의 작업을 단계별로 조정하는 방식이므로, 단일 응답을 더 오래 생각하게 하는 것과 목적이 다릅니다. 동적 워크플로 공식 문서
예를 들어 “설정 페이지에 알림 기능 추가”는 저장 형식 조사, UI 구현, 오류 처리, 테스트를 나누어 검토할 수 있습니다. 반대로 버튼의 여백만 바꾸는 작업은 분담·결과 전달·통합 과정이 부담이 될 수 있습니다.
v2.1.284 이상에서는 현재 effort를 유지하며 토글할 수 있습니다. 첫 줄로 켜고, 해당 작업을 끝낸 뒤 두 번째 줄로 끕니다. 두 줄을 연달아 실행하는 절차가 아닙니다.
/effort ultracode
/effort ultracode off알림 설정 기능을 구현해 주세요. 먼저 현재 저장 방식과 UI 규칙을 조사하고, 독립적으로 진행할 수 있는 작업의 경계를 제안해 주세요. 공통 데이터 형식을 확정한 뒤 구현을 나누고, 마지막에는 통합 테스트를 실행해 주세요. 완료 기준은 설정 유지, 저장 실패 안내, 키보드 조작, 기존 설정의 호환성입니다.
실행 후에는 /workflows로 단계와 진행 상황을 확인할 수 있습니다. 같은 파일이나 공통 데이터 형식을 여러 작업이 동시에 바꾸어야 한다면, 먼저 공유 계약을 정하고 순서대로 처리하도록 요청하세요. 에이전트를 늘린다고 통합 문제가 자동으로 해결되지는 않습니다.
버전 차이에 주의하세요. v2.1.284 이전에는 Ultracode가 xhigh와 결합되어 동작했습니다. 지금도 시작 옵션 claude --effort ultracode는 Ultracode를 켜면서 effort를 xhigh로 설정합니다. 현재 세션의 /effort ultracode 토글과 효과가 같지 않습니다. 지원 모델과 워크플로 사용 가능 여부도 확인해야 합니다. Ultracode 설정 설명 · CLI 옵션
설정의 적용 범위와 복귀 방법
기본 설정을 계속 바꾸는 것이 부담스럽다면, 이번 실행에만 effort를 지정해 시작할 수 있습니다.
claude --model opus --effort high--effort는 해당 세션에 적용됩니다. 대화형 /effort high처럼 직접 입력한 일반 단계는 모델별 기본값으로 저장될 수 있으며, max는 환경 변수로 지정한 경우를 제외하면 현재 세션에만 적용됩니다. /effort auto는 현재 모델에 저장한 effort 선택을 해제합니다. 실제 적용값은 /effort status로 확인하세요. CLI 참조 · effort 설정과 저장 범위
바꾼 값이 적용되지 않는다면 CLAUDE_CODE_EFFORT_LEVEL, 프로젝트 설정, 조직의 effort 상한을 확인합니다. 명령이 없거나 표시가 다르면 claude --version과 /help로 설치된 버전의 지원 범위를 먼저 확인하세요.
비슷하게 들리는 ultrathink도 구분할 필요가 있습니다. 현재 공식 문서에서는 프롬프트에 이 단어를 넣으면 그 턴에 더 깊은 추론을 요청하는 지시가 추가되지만, API로 보내는 effort 값은 바뀌지 않는다고 설명합니다. max 선택이나 Ultracode 활성화의 대체 명령이 아닙니다. ultrathink 설명
높은 설정이 도움이 되었는지 확인하는 법
첫 응답까지의 시간보다 검증을 마칠 때까지의 총시간을 기록해 보세요. 작은 기능, 상태 관련 버그, 구조 변경처럼 서로 다른 작업을 고르고, 같은 코드 상태·요구사항·완료 조건으로 비교합니다. 각 실행은 별도 세션과 깨끗한 작업 복사본에서 시작해야 앞선 답변이나 수정이 다음 실험에 섞이지 않습니다.
기록할 것은 네 가지면 충분합니다.
- 처음 결과가 완료 조건을 얼마나 충족했는가.
- 사람이 다시 설명하거나 수정한 횟수는 몇 번인가.
- 테스트·화면 확인을 포함해 완료까지 얼마나 걸렸는가.
- 토큰 또는 구독 사용량이 얼마나 늘었는가.
현재 /usage에서는 사용량을 확인할 수 있습니다. 구독 사용자는 플랜 사용량을 보고, API 사용자는 토큰·비용 추정치를 살펴보세요. 세션의 달러 추정치를 구독자의 추가 청구액으로 해석하면 안 됩니다. 공식 사용량 안내
높인 설정이 같은 품질을 더 늦게 만들거나 수정 범위만 넓힌다면 낮추세요. 반대로 중요한 조건 누락과 재작업이 줄어든다면 그 종류의 작업에 유지할 이유가 있습니다. 한 번의 성공을 모든 작업의 기본값으로 일반화하지 않는 것이 좋습니다.
다음 작업에서는 먼저 목표, 수정 범위, 재현 자료, 완료 조건을 적고 기본 effort로 시작해 보세요. 원인 연결이 어렵다면 xhigh, 남은 핵심 반례를 깊이 검토해야 한다면 한정된 max, 작업 분담의 이득이 분명하다면 Ultracode를 선택하면 됩니다.
When should you raise Opus effort in Claude Code? This guide separates Extra high, Max, and Ultracode, then gives practical settings, switching criteria, commands, and prompts for everything from UI edits to difficult debugging.
Even when using Opus in Claude Code, you do not need the highest setting for every request. Iterating on a screen and investigating a bug with several possible causes call for different amounts of work between your reviews.
Review small changes quickly, raise effort when judgment gets difficult, and consider Ultracode for larger tasks that benefit from division of work. The recommendations below are workflow suggestions, not benchmark results. Features and commands were checked against official documentation on October 19, 2026. The separate Ultracode toggle described here requires Claude Code v2.1.284 or later.
First, separate the three names
| Label or value | What it controls | A useful question |
|---|---|---|
Extra high · xhigh |
High reasoning effort | Do several conditions or possible causes need deeper investigation? |
Max · max |
The highest reasoning effort | Is revisiting a difficult decision worth more time and tokens? |
Ultracode · ultracode |
Dynamic workflow orchestration | Would dividing the work into investigation, implementation, and verification help? |
low → medium → high → xhigh → max is the effort scale. Ultracode is not another effort level above Max. Recent versions let you toggle it independently of effort. The Max subscription plan is also separate from max effort. Model configuration documentation
A capture of the effort comparison in the official public documentation. The final row distinguishes Ultracode from model effort. (Source: Claude Code Docs, captured 2026-10-19 · View larger image)
Effort is neither a fixed waiting time nor a guarantee of correctness. It affects tokens used for responses, tool calls, and reasoning, so time and usage can vary even for the same task. Choosing max does not remove context limits or service usage limits. Effort API documentation
Check the default for your Opus version
The current Claude Code documentation lists medium for Opus 5.5, high for Opus 5 and 4.8, and xhigh for Opus 4.7 as defaults. Opus 4.6 does not support xhigh. Settings, environment variables, and organizational policies can change the effective value. Supported levels and defaults
Do not apply advice to “always start Opus at Extra high” to every version. After changing models, try the default on a small task you regularly perform. Identical effort names across different models do not imply identical compute or quality.
Check the version in your terminal, then check the model and effective effort inside the session. /model opens the model picker.
claude --version
/model
/effort status
Where to start for each task
These are starting points for interactive vibe coding with Opus 5.5. Treat them as a way to inspect a result and choose the next step, rather than expecting every task to finish in one pass.
| Current task | Starting setting | Signal to raise it |
|---|---|---|
| Copy, colors, and spacing you can inspect immediately | low or medium |
The change also affects state, accessibility, or other behavior |
| One feature with clear requirements and acceptance criteria | medium |
Exceptions or existing conventions are being missed |
| Form validation, error handling, or a bug in existing behavior | high |
Several causes interact and one hypothesis cannot explain them |
| State synchronization, asynchronous ordering, or architectural impact analysis | xhigh |
Counterexamples remain and the current approach is failing |
| A difficult investigation with reproduction evidence, or design counterexample analysis | Limited use of max |
Stop if analysis repeats without new, testable evidence |
| A large feature with separable UI, data, and testing work | Appropriate effort + Ultracode | You can define roles, inputs, outputs, and integration criteria first |
Do not judge by file count alone. Replacing the same text in 20 files can be easier than resolving a race condition in one file. Look at uncertainty and the consequences of errors, not just change volume.
Extra high: when connected conditions are being missed
Suppose search results sometimes revert to an earlier query. What looks like a small UI issue may involve request order, response delays, cancellation, and state updates. Raising effort to xhigh can be useful when asking for evidence organized by possible cause.
Run this at the Claude Code prompt:
/effort xhigh
Then ask:
When I change the search query quickly, an earlier query's results appear last. Use the reproduction steps and network logs to trace request creation, response arrival, and UI updates. Separate the possible causes, identify observations that confirm or rule out each one, then write the smallest fix and a regression test.
The key is to specify which evidence needs connecting, rather than simply asking for more thought. Once the cause and fix are established, subsequent copy or styling edits do not need to stay at xhigh.
Max: reserve it for a specific unresolved question
Consider max when an important counterexample remains despite providing sufficient reproduction evidence. One example is edits disappearing when several clients update the same document. If the real problem is missing logs, add observation points before raising effort.
/effort max
One user's changes are lost when two users save simultaneously. Use the attached reproduction test and event sequence to find a counterexample to the current merge rules. Check that the proposed fix preserves single-user saving and recovery after reconnecting. Separate hypotheses, evidence, and unknowns. Do not replace the entire storage architecture without evidence.
Define a stopping condition too. Here, finish when the data-loss reproduction test passes, existing save and recovery tests still pass, and remaining limitations are explained. A longer answer or more changed files is not a success measure.
Anthropic also describes cases where max delivers small gains for additional cost or leads to excessive deliberation. Return to your everyday setting once the difficult question is resolved. Official guide to choosing effort
Ultracode: use it when division and integration help
With Ultracode enabled, Claude Code builds dynamic workflows for substantive tasks. It coordinates subagents through stages, serving a different purpose from making one response reason for longer. Official dynamic workflows documentation
For example, adding notification preferences to a settings page can involve investigating the storage format, implementing the UI, handling errors, and testing. A button-spacing change may not justify the coordination, handoffs, and integration.
On v2.1.284 and later, you can toggle Ultracode while keeping the current effort. The first command enables it; use the second after finishing that task. These are not two commands to run consecutively.
/effort ultracode
/effort ultracode off
Implement notification preferences. First investigate the existing storage approach and UI conventions, then propose boundaries for independently executable work. Agree on the shared data format before dividing implementation, and run integration tests at the end. Acceptance criteria: preferences persist, save failures are explained, keyboard operation works, and existing settings remain compatible.
Use /workflows to inspect stages and progress. If several tasks need to modify the same file or shared data format, ask for a common contract first and sequence the dependent work. More agents do not automatically solve integration problems.
Version differences matter. Before v2.1.284, Ultracode was coupled to xhigh. The startup option claude --effort ultracode still enables Ultracode and sets effort to xhigh. Its effect differs from the in-session /effort ultracode toggle. Also check model support and whether workflows are available. Ultracode settings · CLI options
Scope, persistence, and returning to your usual setting
To avoid repeatedly changing your default, specify effort for just one launch:
claude --model opus --effort high
--effort applies to that session. An ordinary level entered interactively, such as /effort high, can be saved as the model's default. max applies only to the current session unless set through the environment variable. /effort auto clears the saved effort choice for the active model. Check the effective value with /effort status. CLI reference · Setting effort and its persistence
If a change does not take effect, check CLAUDE_CODE_EFFORT_LEVEL, project settings, and organizational effort caps. If a command or label is missing, use claude --version and /help to check what the installed version supports.
The similar-sounding ultrathink is different too. Current documentation says including it in a prompt adds an instruction requesting deeper reasoning for that turn, without changing the effort value sent to the API. It is not a replacement command for selecting max or enabling Ultracode. How ultrathink works
Check whether the higher setting actually helped
Record total time to verified completion, rather than just time to the first response. Choose different kinds of work—a small feature, a state-related bug, and an architectural change—and compare the same code state, requirements, and acceptance criteria. Start each run in a separate session with a clean working copy so earlier answers or edits do not influence the next experiment.
Four observations are enough:
- How well did the first result meet the acceptance criteria?
- How many times did a person need to clarify or correct it?
- How long did completion take, including tests and visual checks?
- How much token or subscription usage did it consume?
Current versions expose usage through /usage. Subscribers should inspect plan usage; API users should inspect token and cost estimates. Do not interpret a session's dollar estimate as an additional subscription charge. Official usage guidance
Lower the setting if it produces the same quality more slowly or merely expands the change. Keep it for that kind of work if it reduces missed requirements and rework. One successful task is not enough to justify a universal default.
For your next task, write down the goal, scope, reproduction evidence, and acceptance criteria, then start at the default effort. Choose xhigh when connecting causes gets difficult, limited max for a remaining critical counterexample, and Ultracode when dividing the work has clear benefits.
什么时候应该提高 Claude Code 中 Opus 的 effort？本文区分 Extra high、Max 和 Ultracode，并通过具体命令与提示词，介绍从 UI 修改到复杂调试的设置选择与切换标准。
即使使用 Claude Code 官方网站介绍的 Opus，也不必为每个请求选择最高设置。一边看界面一边做小调整，与排查存在多种可能原因的故障，需要等待的工作量并不相同。
小改动要快速检查，判断困难时提高 effort，可合理拆分的大任务再考虑 Ultracode。 下文是工作方法建议，不是性能基准测试结果。功能和命令依据 2026 年 10 月 19 日查阅的官方文档；Ultracode 独立开关的说明适用于 Claude Code v2.1.284 及以上版本。
先区分这三个名称
| 显示名称或输入值 | 调节的内容 | 选择时要问的问题 |
|---|---|---|
Extra high · xhigh |
较高的推理力度 | 是否需要深入分析多个条件和可能原因？ |
Max · max |
最高的推理力度 | 是否值得投入更多时间和 token，重新审视困难判断？ |
Ultracode · ultracode |
动态工作流编排 | 将任务拆成调查、实现和验证等阶段是否有益？ |
low → medium → high → xhigh → max 是 effort 的等级序列。不要把 Ultracode 理解成高于 Max 的一级。 新版本允许独立于 effort 开关它。另外，订阅产品 Max 套餐与 max effort 是不同概念。模型配置文档
官方公开文档中的 effort 对照表截图。最后一行区分了 Ultracode 与模型 effort。(来源：Claude Code Docs，2026-10-19 截图 · 查看大图)
effort 并不是固定的等待时间，也不保证答案正确。它影响回复、工具调用和推理所消耗的 token，因此同一任务的耗时与用量也可能变化。使用 max 不会取消上下文限制或服务用量限制。Effort API 文档
先确认你的 Opus 版本默认值
当前 Claude Code 文档列出的默认值是：Opus 5.5 为 medium，Opus 5 和 4.8 为 high，Opus 4.7 为 xhigh。Opus 4.6 不支持 xhigh。设置、环境变量及组织策略可能改变实际生效值。各模型支持的等级与默认值
因此，不要把“Opus 一律从 Extra high 开始”的建议套用到所有版本。换模型后，先用日常的小任务检查默认值的结果。不同模型的同名 effort 也不代表相同的计算量或质量。
在终端检查版本，再在会话中检查模型与实际 effort。/model 会打开模型选择器。
claude --version
/model
/effort status
不同任务从哪里开始
下表适用于使用 Opus 5.5 进行交互式氛围编程。它提供的是观察结果并选择下一步的起点，而不是要求一次完成所有工作。
| 当前任务 | 起始设置 | 需要提高的信号 |
|---|---|---|
| 可以立即检查的文案、颜色与间距修改 | low 或 medium |
同时影响状态、无障碍或其他行为 |
| 需求和验收条件明确的单个功能 | medium |
遗漏异常处理或既有规则 |
| 表单校验、错误处理、既有功能修复 | high |
多个原因相互作用，单一假设无法解释 |
| 状态同步、异步顺序、结构变更影响分析 | xhigh |
仍有反例，现有方法无法解决 |
| 有复现资料的复杂原因调查、设计反例检查 | 限定使用 max |
没有新的可验证证据、只重复分析时停止 |
| 可拆分为 UI、数据、测试的大功能 | 合适的 effort + Ultracode | 能先定义角色、输入输出与集成标准 |
不要只看文件数量。在 20 个文件里替换同一段文案，可能比修复一个文件中的异步竞争条件更简单。关注判断的不确定性和错误影响，而不只是改动量。
Extra high：开始遗漏关联条件时
假设搜索结果偶尔跳回较早的搜索词。表面上是一个小界面问题，实际上可能需要同时检查请求顺序、响应延迟、取消处理和状态更新。此时提高到 xhigh，要求按可能原因整理证据，会更有针对性。
在 Claude Code 输入框执行：
/effort xhigh
然后提出这样的请求：
快速切换搜索词时，旧搜索词的结果最后显示出来。请依据复现步骤与网络日志，追踪请求生成、响应到达和界面更新的顺序。区分可能原因，列出可以确认或排除各原因的观测值，再编写最小修复和回归测试。
关键是说明需要连接哪些证据，而不只是要求“多想一想”。原因和修复方案确定后，后续文案或样式调整就不必一直保持 xhigh。
Max：限定用于尚未解决的核心问题
如果已经提供充分的复现资料，但仍有重要反例，可以考虑 max。例如，多名客户端同时编辑文档时，有人的修改会消失。如果真正缺少的是日志，应先增加观测点，再考虑提高 effort。
/effort max
两名用户同时保存时，一方的修改会丢失。请使用附带的复现测试和事件顺序，找出当前合并规则的反例。确认修复不会破坏单用户保存和断线重连恢复，并区分假设、证据与未知项。不要在缺乏证据时替换整个存储架构。
同时定义结束条件。在这个例子中，丢失问题的复现测试通过、原有保存与恢复测试继续通过、剩余限制得到说明，就应结束。回复更长、修改文件更多，都不能作为成功指标。
Anthropic 也说明，max 的额外成本有时只带来有限改进，甚至可能导致过度推敲。困难问题解决后，适合回到日常设置。官方 effort 选择指南
Ultracode：适合需要分工和集成的工作
启用 Ultracode 后，Claude Code 会为实质性任务构建动态工作流。它按阶段协调多个子智能体，因此目的不同于让单次回复思考更久。动态工作流官方文档
例如，为设置页面添加通知偏好，可以拆成存储格式调查、UI 实现、错误处理和测试。而只修改按钮间距，可能不值得承担分工、交接与集成的开销。
v2.1.284 及以上版本可以保持当前 effort，仅切换 Ultracode。第一行用于开启，完成该任务后再用第二行关闭；不是让你连续执行这两行。
/effort ultracode
/effort ultracode off
请实现通知设置。先调查现有存储方式和 UI 规则，提出可独立开展的工作边界。确认共享数据格式后再分配实现工作，最后运行集成测试。验收条件是设置能够保留、保存失败有提示、支持键盘操作，并兼容现有设置。
执行后，可以通过 /workflows 查看阶段和进度。如果多个任务都要修改同一文件或共享数据格式，应先约定公共契约，再按依赖顺序处理。增加智能体数量不会自动解决集成问题。
注意版本差异。 v2.1.284 之前，Ultracode 与 xhigh 绑定。现在启动选项 claude --effort ultracode 仍会同时开启 Ultracode，并把 effort 设为 xhigh。它与会话中的 /effort ultracode 开关效果不同。还应检查模型是否支持，以及工作流是否可用。Ultracode 设置说明 · CLI 选项
设置范围、保存与恢复
如果不想反复修改默认设置，可以仅为本次启动指定 effort：
claude --model opus --effort high
--effort 适用于该会话。交互式输入的普通等级，例如 /effort high，可能保存为该模型的默认值；max 除通过环境变量设置的情况外，仅适用于当前会话。/effort auto 清除当前模型已保存的 effort 选择。用 /effort status 检查实际值。CLI 参考 · effort 设置及保存范围
若修改没有生效，检查 CLAUDE_CODE_EFFORT_LEVEL、项目设置和组织的 effort 上限。若命令不存在或显示不同，先用 claude --version 与 /help 确认安装版本的支持范围。
名称相近的 ultrathink 也需要区分。当前官方文档说明，在提示词中加入该词会为当前轮次添加更深入推理的指令，但不会改变发送给 API 的 effort 值。它不能替代选择 max 或启用 Ultracode 的命令。ultrathink 说明
如何判断提高设置是否有帮助
记录完成验证所需的总时间，而不只是首次回复时间。选择小功能、状态相关故障、结构变更等不同任务，使用相同代码状态、需求和验收条件进行比较。每次运行都从独立会话和干净的工作副本开始，避免前一次答案或修改影响下一次实验。
记录四项即可：
- 第一版结果满足了多少验收条件？
- 人工重新说明或修改了多少次？
- 包含测试与界面检查，完成共用了多久？
- 消耗了多少 token 或订阅用量？
当前可以通过 /usage 查看用量。订阅用户看套餐用量，API 用户看 token 与费用估算。不要把会话中的美元估算当作订阅用户的额外账单。官方用量说明
如果提高设置只是更慢地得到相同质量，或无谓扩大修改范围，就降低它。如果减少了重要条件遗漏与返工，则可以在这类任务中保留。不要因一次成功就将其设为所有工作的默认值。
下次任务先写明目标、修改范围、复现资料与验收条件，再从默认 effort 开始。难以连接原因时选 xhigh，需要深入检查剩余关键反例时限定使用 max，明确能从任务分工中获益时再选 Ultracode。
Claude CodeでOpusのeffortを上げるべきタイミングはいつでしょうか。Extra high・Max・Ultracodeの違いを整理し、UI修正から複雑なバグ調査まで、作業に合う設定と切り替え基準を具体的なコマンドやプロンプトで紹介します。
Claude Code公式サイトで紹介されているOpusを使う場合も、すべての依頼で最高の設定を選ぶ必要はありません。画面を見ながら小さく直す作業と、複数の原因を検討してバグを追う作業では、待つ価値のある作業量が異なります。
小さな変更はすぐに確認し、判断が難しい場面でeffortを上げ、分担できる大きな作業でUltracodeを検討しましょう。 以下は作業の進め方に関する提案であり、ベンチマーク結果ではありません。機能とコマンドは2026年10月19日に公式ドキュメントで確認しました。Ultracodeを独立して切り替える説明は、Claude Code v2.1.284以降が対象です。
まず、3つの名前の違いを整理する
| 表示名・入力値 | 調整するもの | 選ぶときの問い |
|---|---|---|
Extra high · xhigh |
高い推論努力 | 複数の条件や原因をさらに深く検討する必要があるか？ |
Max · max |
最も高い推論努力 | 時間とトークンをさらに使っても、難しい判断を再検討する価値があるか？ |
Ultracode · ultracode |
動的ワークフローの構成 | 調査・実装・検証などに作業を分ける利点があるか？ |
low → medium → high → xhigh → maxがeffortの段階です。UltracodeをMaxのさらに上の段階と捉えないでください。 最近のバージョンでは、effortとは別にオン・オフを切り替えられます。また、サブスクリプションのMaxプランとmax effortも別の概念です。モデル設定ドキュメント
公式の公開ドキュメントにあるeffort比較表のキャプチャです。最後の行はUltracodeをモデルのeffortと区別しています。(出典：Claude Code Docs、2026-10-19撮影 · 画像を大きく見る)
effortは固定の待ち時間でも、正解の保証でもありません。応答・ツール呼び出し・推論に使うトークンに影響するため、同じ作業でも時間と使用量は変わり得ます。maxにしても、コンテキストやサービスの使用量の上限がなくなるわけではありません。Effort APIドキュメント
自分のOpusバージョンの既定値を確認する
現在のClaude Codeドキュメントでは、既定値はOpus 5.5がmedium、Opus 5と4.8がhigh、Opus 4.7がxhighです。Opus 4.6はxhighに対応していません。設定・環境変数・組織のポリシーによって、実際の値は変わる場合があります。モデル別の対応段階と既定値
したがって、「Opusは必ずExtra highから始める」という助言をすべてのバージョンに当てはめないでください。モデルを変更したら、普段の小さな作業で既定値の結果を確かめるのがおすすめです。モデルが異なれば、同名のeffortが同じ計算量や品質を表すとも限りません。
ターミナルでバージョンを確認し、セッション内でモデルと有効なeffortを確認します。/modelはモデル選択画面を開くコマンドです。
claude --version
/model
/effort status
作業ごとの開始設定
以下はOpus 5.5で対話しながらバイブコーディングする場合の出発点です。一度ですべて完成させるより、結果を見て次を選ぶための運用例として使ってください。
| 今の作業 | 開始設定 | 上げる目安 |
|---|---|---|
| すぐに確認できる文言・色・余白の修正 | lowまたはmedium |
状態やアクセシビリティなど他の動作にも影響する |
| 要件と完了条件が明確な機能1つ | medium |
例外処理や既存のルールを見落とす |
| フォーム検証・エラー処理・既存機能のバグ修正 | high |
複数の原因が絡み、1つの仮説では説明できない |
| 状態同期・非同期の順序・構造変更の影響分析 | xhigh |
反例が残り、現在の方法では解決できない |
| 再現資料のある難しい原因調査・設計の反例検討 | maxを限定的に使用 |
検証できる新しい根拠がなく、分析だけを繰り返すなら止める |
| UI・データ・テストなどに分担できる大きな機能 | 適切なeffort + Ultracode | 役割・入出力・統合基準を先に決められる |
ファイル数だけで判断しないでください。20ファイルで同じ文言を置換する作業より、1ファイルの非同期競合を直す方が難しいこともあります。変更量より、判断の不確実さと誤りの影響を見ましょう。
Extra high：関連する条件を見落とし始めたとき
検索結果がときどき以前の検索語の結果に戻るとします。小さな画面修正に見えても、リクエストの順序、応答の遅延、キャンセル、状態更新をまとめて調べる必要があります。このような場面ではxhighに上げ、原因ごとに証拠を整理させる方法が役立ちます。
Claude Codeの入力欄で実行します。
/effort xhigh
続けて、次のように依頼します。
検索語を素早く変更すると、以前の検索結果が最後に表示されます。再現手順とネットワークログを使い、リクエスト生成・応答到着・画面反映の順序を追ってください。原因候補を分け、それぞれを確認または除外できる観測値を示したうえで、最小限の修正と回帰テストを作成してください。
ポイントは、単に「もっと考えて」と言うのではなく、どの証拠をつなぐ必要があるかを伝えることです。原因と修正方法が分かれば、その後の文言やスタイルの修正までxhighを続ける必要はありません。
Max：未解決の核心的な問いに限定する
十分な再現資料を渡しても重要な反例が残る場合は、maxを検討できます。複数のクライアントが同時に文書を更新すると変更が消える、といった問題です。本当に足りないのがログなら、effortを上げる前に観測点を増やしましょう。
/effort max
2人が同時に保存すると、片方の変更が失われます。添付の再現テストとイベントの順序を使い、現在のマージ規則の反例を探してください。修正案が単独ユーザーの保存や再接続後の復旧を壊さないか確認し、仮説・証拠・未確認事項を分けてください。根拠なく保存の仕組み全体を置き換えないでください。
終了条件も決めます。この例なら、変更消失を再現するテストが通り、既存の保存・復旧テストが維持され、残る制約が説明されれば終了です。長い回答や変更ファイル数の増加を成功指標にしません。
Anthropicも、maxでは追加コストに対する改善が小さかったり、考えすぎが起きたりする場合があると説明しています。難しい問いが解決したら、日常の設定に戻すのがおすすめです。公式effort選択ガイド
Ultracode：分担と統合に意味がある作業で使う
Ultracodeを有効にすると、Claude Codeは実質的な作業に動的ワークフローを構成します。複数のサブエージェントを段階ごとに調整するため、1つの応答を長く考えさせることとは目的が異なります。動的ワークフローの公式ドキュメント
たとえば設定ページに通知設定を追加するなら、保存形式の調査、UI実装、エラー処理、テストに分けられます。一方、ボタンの余白だけを直す作業では、分担・引き継ぎ・統合の負担が上回る可能性があります。
v2.1.284以降では現在のeffortを維持して切り替えられます。1行目で有効にし、その作業を終えてから2行目で無効にします。2行を続けて実行する手順ではありません。
/effort ultracode
/effort ultracode off
通知設定を実装してください。まず既存の保存方法とUIルールを調べ、独立して進められる作業の境界を提案してください。共通のデータ形式を確定してから実装を分担し、最後に統合テストを実行してください。完了条件は、設定の保持、保存失敗の案内、キーボード操作、既存設定との互換性です。
実行後は/workflowsで段階と進捗を確認できます。同じファイルや共通のデータ形式を複数の作業が変更するなら、先に共通の契約を決め、依存関係に沿って順番に処理させましょう。エージェントを増やしても、統合の問題が自動で解決するわけではありません。
バージョンの違いに注意してください。 v2.1.284より前では、Ultracodeはxhighと結び付いていました。今も起動オプションclaude --effort ultracodeは、Ultracodeを有効にすると同時にeffortをxhighへ設定します。セッション内の/effort ultracodeとは効果が異なります。対応モデルとワークフローが利用可能かも確認してください。Ultracodeの設定説明 · CLIオプション
設定の適用範囲と戻し方
既定値を繰り返し変更したくない場合は、今回の起動だけにeffortを指定できます。
claude --model opus --effort high
--effortはそのセッションに適用されます。対話中に直接入力した/effort highのような通常の段階は、モデル別の既定値として保存されることがあります。maxは環境変数で指定した場合を除き、現在のセッションだけに適用されます。/effort autoは現在のモデルに保存されたeffortの選択を解除します。実際の適用値は/effort statusで確認してください。CLIリファレンス · effortの設定と保存範囲
変更が反映されないなら、CLAUDE_CODE_EFFORT_LEVEL、プロジェクト設定、組織のeffort上限を確認します。コマンドがない、表示が違う場合は、claude --versionと/helpでインストール済みバージョンの対応範囲を調べてください。
名前が似ているultrathinkも区別しましょう。現在の公式ドキュメントでは、プロンプトにこの単語を含めると、そのターンで深い推論を求める指示が追加されますが、APIへ送るeffort値は変わらないと説明されています。maxの選択やUltracodeの有効化を代替するコマンドではありません。ultrathinkの説明
高い設定が役立ったかを確かめる
最初の応答までの時間より、検証を終えるまでの合計時間を記録してみましょう。小さな機能、状態に関するバグ、構造変更などを選び、同じコード状態・要件・完了条件で比較します。各実行は別のセッションとクリーンな作業コピーから始め、前の回答や変更が次の実験に混ざらないようにします。
記録するのは4点で十分です。
- 最初の結果が完了条件をどの程度満たしたか。
- 人が説明し直したり修正したりした回数。
- テストと画面確認を含め、完了までにかかった時間。
- 消費したトークンまたはサブスクリプションの使用量。
現在は/usageで使用量を確認できます。サブスクリプション利用者はプランの使用量を、API利用者はトークンとコストの推計を確認してください。セッションのドル表示を、サブスクリプションへの追加請求額と解釈しないでください。公式の使用量ガイド
設定を上げても同じ品質になるまで時間が増えるだけ、あるいは変更範囲が広がるだけなら下げましょう。重要な条件の見落としや手戻りが減るなら、その種類の作業で維持する理由があります。1回の成功をすべての作業の既定値に一般化しないことが大切です。
次の作業では、まず目標・変更範囲・再現資料・完了条件を書き、既定のeffortで始めてください。原因のつながりを追うのが難しければxhigh、残った重要な反例を深く検討するなら限定的なmax、分担の利点が明確ならUltracodeを選びましょう。
¿Cuándo conviene subir el effort de Opus en Claude Code? Esta guía distingue Extra high, Max y Ultracode, y ofrece ajustes, criterios de cambio, comandos y prompts para tareas que van desde pequeños cambios de interfaz hasta una depuración compleja.
Incluso usando Opus en Claude Code, no hace falta elegir el ajuste más alto para cada petición. Retocar una pantalla mientras la revisas e investigar un fallo con varias causas posibles requieren cantidades distintas de trabajo entre revisiones.
Comprueba pronto los cambios pequeños, sube el effort cuando el razonamiento se complique y considera Ultracode para tareas grandes que puedan dividirse. Las recomendaciones siguientes son propuestas de trabajo, no resultados de benchmarks. Las funciones y los comandos se contrastaron con la documentación oficial el 19 de octubre de 2026. El interruptor independiente de Ultracode descrito aquí requiere Claude Code v2.1.284 o posterior.
Primero, distingue los tres nombres
| Nombre o valor | Qué controla | Pregunta para elegir |
|---|---|---|
Extra high · xhigh |
Un esfuerzo de razonamiento elevado | ¿Hay que analizar con más profundidad varias condiciones o causas? |
Max · max |
El máximo esfuerzo de razonamiento | ¿Merece la pena gastar más tiempo y tokens para revisar una decisión difícil? |
Ultracode · ultracode |
La organización de flujos dinámicos | ¿Ayudaría dividir el trabajo en investigación, implementación y verificación? |
low → medium → high → xhigh → max es la escala de effort. Ultracode no es otro nivel por encima de Max. Las versiones recientes permiten activarlo independientemente del effort. Además, el plan de suscripción Max y el effort max son conceptos distintos. Documentación de configuración del modelo
Captura de la tabla de effort de la documentación oficial pública. La última fila distingue Ultracode del effort del modelo. (Fuente: Claude Code Docs, captura del 2026-10-19 · Ver imagen ampliada)
El effort no fija un tiempo de espera ni garantiza una respuesta correcta. Afecta a los tokens empleados en respuestas, llamadas a herramientas y razonamiento, por lo que el tiempo y el consumo pueden variar incluso para una misma tarea. Elegir max no elimina los límites de contexto ni de uso del servicio. Documentación de Effort en la API
Comprueba el valor predeterminado de tu versión de Opus
La documentación actual de Claude Code indica medium para Opus 5.5, high para Opus 5 y 4.8, y xhigh para Opus 4.7 como valores predeterminados. Opus 4.6 no admite xhigh. Los ajustes, las variables de entorno y las políticas de la organización pueden cambiar el valor efectivo. Niveles admitidos y valores predeterminados
No apliques el consejo de «empezar siempre con Extra high en Opus» a todas las versiones. Al cambiar de modelo, prueba el valor predeterminado con una tarea pequeña habitual. El mismo nombre de effort en dos modelos tampoco implica idéntico cómputo o calidad.
Comprueba la versión en el terminal y, dentro de la sesión, el modelo y el effort efectivo. /model abre el selector de modelos.
claude --version
/model
/effort status
Por dónde empezar según la tarea
Estos son puntos de partida para vibe coding interactivo con Opus 5.5. Sirven para revisar el resultado y decidir el siguiente paso, sin esperar que todo se resuelva en una sola pasada.
| Tarea actual | Ajuste inicial | Señal para subirlo |
|---|---|---|
| Textos, colores o espaciado que puedes comprobar al instante | low o medium |
El cambio también afecta al estado, la accesibilidad u otros comportamientos |
| Una función con requisitos y criterios de aceptación claros | medium |
Se omiten excepciones o convenciones existentes |
| Validación de formularios, errores o fallos en funciones existentes | high |
Interactúan varias causas y una hipótesis no las explica |
| Sincronización de estado, orden asíncrono o impacto de cambios estructurales | xhigh |
Quedan contraejemplos y el enfoque actual no funciona |
| Investigación difícil con una reproducción o revisión de contraejemplos de diseño | Uso limitado de max |
Detenerse si repite análisis sin nuevas pruebas verificables |
| Una función grande con trabajo separable de interfaz, datos y pruebas | Effort adecuado + Ultracode | Puedes definir antes responsabilidades, entradas, salidas e integración |
No juzgues solo por el número de archivos. Sustituir el mismo texto en 20 archivos puede ser más fácil que resolver una condición de carrera en uno. Considera la incertidumbre y las consecuencias del error, no solo el volumen de cambios.
Extra high: cuando se pierden condiciones relacionadas
Imagina que los resultados de búsqueda vuelven a veces a una consulta anterior. Lo que parece un pequeño fallo visual puede implicar el orden de las peticiones, retrasos de respuesta, cancelaciones y actualización del estado. Subir a xhigh puede ayudar al pedir que se organice la evidencia por causa posible.
Ejecuta esto en el cuadro de entrada de Claude Code:
/effort xhigh
Después pide algo así:
Cuando cambio rápidamente la consulta, los resultados de una consulta anterior aparecen al final. Usa los pasos de reproducción y los registros de red para seguir la creación de peticiones, la llegada de respuestas y la actualización de la interfaz. Distingue las causas posibles e indica qué observaciones confirman o descartan cada una. Después escribe la corrección mínima y una prueba de regresión.
La clave es indicar qué evidencias deben relacionarse, en lugar de pedir simplemente que piense más. Una vez aclarados la causa y el arreglo, los cambios posteriores de texto o estilo no tienen por qué seguir en xhigh.
Max: limítalo a una pregunta importante sin resolver
Considera max cuando persista un contraejemplo importante pese a aportar suficiente información de reproducción. Por ejemplo, cuando desaparecen cambios al editar un documento desde varios clientes a la vez. Si faltan registros, añade puntos de observación antes de subir el effort.
/effort max
Cuando dos usuarios guardan simultáneamente, se pierden los cambios de uno. Usa la prueba de reproducción adjunta y la secuencia de eventos para encontrar un contraejemplo de las reglas de combinación actuales. Comprueba que la corrección propuesta conserva el guardado de un solo usuario y la recuperación tras reconectar. Separa hipótesis, evidencias e incógnitas. No sustituyas toda la arquitectura de almacenamiento sin evidencia.
Define también cuándo terminar. Aquí sería cuando pase la prueba que reproduce la pérdida, sigan pasando las pruebas existentes de guardado y recuperación, y se expliquen las limitaciones restantes. Una respuesta más larga o más archivos modificados no son medidas de éxito.
Anthropic también describe casos en los que max aporta mejoras pequeñas para su coste adicional o lleva a una deliberación excesiva. Vuelve a tu ajuste habitual cuando la pregunta difícil esté resuelta. Guía oficial para elegir effort
Ultracode: cuando dividir e integrar el trabajo aporta valor
Al activar Ultracode, Claude Code crea flujos dinámicos para tareas sustanciales. Coordina subagentes por etapas, con un propósito distinto al de prolongar el razonamiento de una respuesta. Documentación oficial de flujos dinámicos
Por ejemplo, añadir preferencias de notificación puede dividirse en investigar el formato de almacenamiento, implementar la interfaz, gestionar errores y probar. Un cambio de espaciado de un botón quizá no justifique la coordinación, los traspasos y la integración.
En v2.1.284 y posteriores puedes cambiar Ultracode manteniendo el effort actual. El primer comando lo activa; usa el segundo cuando termines esa tarea. No son dos comandos que debas ejecutar seguidos.
/effort ultracode
/effort ultracode off
Implementa las preferencias de notificación. Investiga primero el almacenamiento actual y las convenciones de la interfaz, y propón límites para el trabajo que pueda avanzar de forma independiente. Acuerda el formato de datos compartido antes de dividir la implementación y ejecuta pruebas de integración al final. Criterios de aceptación: preferencias persistentes, aviso si falla el guardado, manejo con teclado y compatibilidad con la configuración existente.
Con /workflows puedes consultar etapas y progreso. Si varias tareas deben modificar el mismo archivo o formato de datos, pide primero un contrato común y ordena el trabajo dependiente. Aumentar el número de agentes no resuelve automáticamente los problemas de integración.
Ten en cuenta la versión. Antes de v2.1.284, Ultracode estaba ligado a xhigh. La opción de inicio claude --effort ultracode sigue activando Ultracode y fijando el effort en xhigh. Su efecto difiere del interruptor /effort ultracode dentro de la sesión. Comprueba también la compatibilidad del modelo y la disponibilidad de flujos. Ajustes de Ultracode · Opciones de CLI
Alcance, persistencia y vuelta al ajuste habitual
Si no quieres cambiar repetidamente tu valor predeterminado, especifica el effort solo para un inicio:
claude --model opus --effort high
--effort se aplica a esa sesión. Un nivel normal introducido de forma interactiva, como /effort high, puede guardarse como predeterminado para el modelo. max se aplica solo a la sesión actual, salvo que se configure mediante la variable de entorno. /effort auto borra la elección de effort guardada para el modelo activo. Comprueba el valor efectivo con /effort status. Referencia de CLI · Configuración y persistencia del effort
Si un cambio no se aplica, revisa CLAUDE_CODE_EFFORT_LEVEL, la configuración del proyecto y los límites de effort de la organización. Si falta un comando o la etiqueta es distinta, consulta claude --version y /help para comprobar qué admite la versión instalada.
También conviene distinguir ultrathink, pese al parecido del nombre. La documentación actual explica que incluirlo en el prompt añade una instrucción de razonamiento más profundo para ese turno, sin cambiar el valor de effort enviado a la API. No sustituye al comando para elegir max ni al que activa Ultracode. Cómo funciona ultrathink
Cómo comprobar si subir el ajuste ayudó
Registra el tiempo total hasta completar la verificación, no solo el tiempo de la primera respuesta. Elige tareas distintas —una función pequeña, un fallo de estado y un cambio estructural— y compara el mismo estado del código, requisitos y criterios de aceptación. Inicia cada ejecución en una sesión independiente y una copia de trabajo limpia, para que las respuestas o cambios anteriores no influyan en el siguiente experimento.
Basta con registrar cuatro cosas:
- En qué medida el primer resultado cumplió los criterios de aceptación.
- Cuántas veces una persona tuvo que aclarar o corregir algo.
- Cuánto tardó en completarse, incluidas pruebas y comprobaciones visuales.
- Cuántos tokens o cuánto uso de la suscripción consumió.
Las versiones actuales muestran el consumo mediante /usage. Los suscriptores deben consultar el uso de su plan; los usuarios de API, las estimaciones de tokens y coste. No interpretes la estimación en dólares de una sesión como un cargo adicional de la suscripción. Guía oficial de uso
Baja el ajuste si produce la misma calidad más lentamente o solo amplía el cambio. Mantenlo para ese tipo de tarea si reduce los requisitos omitidos y el retrabajo. Un éxito aislado no justifica convertirlo en valor universal.
En tu próxima tarea, escribe primero el objetivo, el alcance, la evidencia de reproducción y los criterios de aceptación, y empieza con el effort predeterminado. Elige xhigh cuando cueste relacionar causas, un uso limitado de max para un contraejemplo crítico pendiente y Ultracode cuando dividir el trabajo tenga ventajas claras.