Quando eu era mais novo, pedi ao mecânico para colocar minha Harley-Davidson Heritage 2010, 1600 cc, em stage 3: motor, módulo (ECM) e várias outras mudanças. Não era vitrine. Era potência de verdade.
Na prática, o consumo caiu de 23 km por litro para 12 km por litro. Eu não precisava daquela potência o tempo todo: não rodava tanto e não corria com a moto.
Mesmo assim, você paga o consumo de stage 3 em todo quilômetro, mesmo quando o rolê não pede aquela força. No agente de código, stage 3 é reasoning effort no máximo em todo spawn: capacidade de sobra na fatura, mesmo quando a tarefa só precisa chegar na esquina.
No agente, a mesma conta: deixar reasoning effort no máximo em tarefa trivial (renomear variável, listar arquivos, formatar import) é pagar stage 3 em trajeto que não pede. O modelo aguenta. A fatura vem em cada spawn.
No texto de model routing eu falei de qual LLM entra em cada tarefa: cheap, balanced, frontier, política antes do spawn. Falta o segundo knob: effort (quanto raciocínio aquele modelo pode gastar nesta execução). Routing sem effort é manter stage 3 ligado quando a tarefa só precisa chegar na esquina.
Neste artigo
- Effort não é “modelo mais inteligente”
- O que eu chamo de effort na prática
- Modelos, effort e benchmarks públicos
- Dois eixos: tier e effort
- Como eu escolho effort por classe de tarefa
- Fan-out: effort multiplica como modelo
- Effort como política de Staff
- Onde isso encaixa no harness
1. Effort não é “modelo mais inteligente”
Model routing responde: quem executa (haiku-class, sonnet-class, opus-class, ou o equivalente no seu catálogo).
Effort responde: com quanta profundidade de raciocínio essa instância pode trabalhar agora, dentro do modelo que você já escolheu.
São decisões ortogonais. Você pode estar no tier certo e ainda pagar demais porque o harness deixou reasoning effort alto para um prompt mecânico. Ou estar no tier barato com effort alto e queimar tempo em “pensar” onde grep e teste bastavam.
A pergunta útil, depois do routing:
Para esta tarefa, qual é o menor effort que ainda entrega segurança e qualidade suficientes?
Espelha a pergunta do routing (“modelo mais barato que aguenta”), só que no eixo do orçamento de pensamento, não do catálogo de modelos.
2. O que eu chamo de effort na prática
Effort é o que o provedor ou o harness expõe como orçamento de raciocínio na chamada: nomes variam (reasoning_effort, modo “thinking”, variantes High/Medium no Cursor, etc.). O mecanismo muda; a decisão de engenharia é a mesma.
Três sinais que eu uso para classificar a tarefa antes de ligar o effort alto:
| Sinal | Effort tende a ser baixo | Effort tende a subir |
|---|---|---|
| Verificação | critério objetivo (teste, diff, linter) | julgamento subjetivo ou poucos testes |
| Ambiguidade | prompt fechado (“renomeie X em Y”) | várias hipóteses válidas |
| Risco | falha barata de reverter | auth, dinheiro, concorrência, migração |
Não é ciência exata. É política: igual ao classifier do routing, conservative quando o risco manda.
No harness-downshift, a classificação de complexidade que já existe para tier (TRIVIAL, SIMPLE, MEDIUM, COMPLEX) é o mesmo tipo de leitura de prompt que eu uso para calibrar effort: mecânico versus desenho versus rearchitect. O README do projeto não promete oráculo; promete heurística auditável. Effort entra na mesma filosofia.
3. Modelos, effort e benchmarks públicos
Eu uso benchmarks públicos para montar shortlist de modelo (SWE-bench, LiveBench com Agentic Coding e cost per successful task, Artificial Analysis, LMArena Coding e LMArena Agent). Nenhum deles, na forma pública que eu consulto, publica coluna separada por reasoning_effort ou thinking level. Eles comparam modelo (e muitas vezes harness); o segundo knob eu calibro pela documentação do provedor e pela telemetria do spawn.
A tabela abaixo resume onde o effort é real nos modelos que já entram no meu routing, e o que a documentação oficial diz que tende a subir quando você aumenta o effort. Não são notas de benchmark inventadas.
| Modelo / família | Onde o effort existe | O que tende a subir quando o effort sobe | Fonte |
|---|---|---|---|
| OpenAI reasoning (Codex: ex. família GPT-5.6 Sol / Luna no downshift) | Parâmetro reasoning.effort na Responses API; no Codex o hook pode injetar reasoning_effort no spawn do subagente |
Mais reasoning tokens antes da resposta; docs descrevem ganho em tarefas multi-step e agentic, com mais latência e custo | OpenAI — Reasoning |
xAI Grok (grok-4.6, grok-4.7; Grok Build / CLI) |
reasoning_effort: low / medium / high (e xhigh onde suportado); default high; raciocínio não desliga
|
Mais reasoning_tokens faturados; docs ligam effort alto a mais profundidade e maior latência
|
xAI — Reasoning · downshift — Grok CLI |
| Claude (Opus / Sonnet no agente) |
Extended thinking: budget_tokens (modo manual) ou adaptive thinking com output_config.effort em gerações mais novas (ver doc por modelo) |
Mais tokens de thinking na fatura; orçamento maior aumenta latência; adaptive pode omitir thinking em input fácil |
Anthropic — Extended thinking |
| Gemini (ex. 3.8 Flash no meu mix Cursor) | Thinking em modelos 2.5+ / 3.x (thinkingLevel / config de thinking na API) |
Raciocínio interno antes da resposta; mais profundidade implica mais tokens e tempo (modelo decide quanto pensar dentro do nível) | Google — Gemini thinking |
| Cursor (UI multi-provedor) |
Sem campo único de effort no Task no downshift; knob via SKU do modelo (variantes com “thinking”, “High”, linha Fast vs standard na lista de preços) |
Effort embarcado no nome/preço do modelo; na minha lista Cursor, Fast do mesmo tier costuma ser 2× preço por velocidade (preço de lista, não telemetria) | Preços na UI Cursor (artigo de model routing) + doc do provedor por modelo |
Como eu uso os benchmarks com honestidade: SWE-bench para capacidade em issues reais; LiveBench para separar Coding vs Agentic Coding e olhar cost per successful task (métrica pública do site, não minha); Artificial Analysis para qualidade × preço × latência; LMArena para preferência humana e custo por tarefa em agentes. Números de leaderboard = benchmark público. Consumo 23→12 km/L da Harley = minha experiência, não bench.
4. Dois eixos: tier e effort
Pense em uma matriz mental (não precisa de planilha no dia a dia):
effort baixo effort alto
tier barato grep, format (raro: só se tier errado)
tier médio feature local debug multi-arquivo
tier frontier review superficial incidente, race, security
O erro clássico depois de ler sobre routing: descer o modelo do subagente e deixar o effort no máximo porque “já estamos economizando”. Você fez downshift de tier e manteve stage 3 ligado na ida até a esquina.
Detalhe por provedor: §3. No Claude Code e Cursor, o downshift hoje reescreve sobretudo tier via modelo no Task; effort separado aparece onde a API expõe (Codex, Grok config). Não confunda “já roteei o filho” com “já calibrei quanto ele pensa”.
5. Como eu escolho effort por classe de tarefa
Tabela operacional. Ajuste aos nomes que seu harness expõe (low / medium / high, ou equivalente). Não é receita universal; é ponto de partida para política de time.
| Classe de tarefa | Exemplos | Tier (routing) | Effort típico | Por quê |
|---|---|---|---|---|
| Mecânica | rename, typo, format, commit message, listar arquivos | small / cheap | baixo | saída verificável; thinking longo só infla tokens |
| Cirúrgica | bug em uma função, campo novo, teste seguindo padrão | small → mid | baixo a médio | sobe effort só se o barato errar raciocínio, não execução |
| Integrada | feature em vários arquivos, refactor de módulo | mid / balanced | médio | planejamento moderado; ainda com testes no loop |
| Exploratória | “onde isso quebra?”, trace em codebase grande | mid | médio a alto | busca ampla; cuidado para não deixar alto em cada filho de exploração |
| Crítica | auth, pagamento, migração, race, security review | frontier | alto | custo de errar domina custo de pensar |
Regra que eu repito para mim:
Comece com o menor effort que a classe permite.
↓
Passou no critério (teste, review, diff)?
SIM → pare.
NÃO
↓
Faltou execução (contexto, arquivo, harness)?
Corrija harness antes de subir effort.
Faltou raciocínio?
Suba effort OU suba tier (routing).
↓
Ainda falhou em tarefa crítica?
Frontier + effort alto, com humano no loop.
Isso evita o espelho do routing article: subir modelo quando o problema era contexto. Aqui: subir effort quando o problema era profundidade de raciocínio, não ferramenta.
Exemplo ilustrativo (números redondos, não telemetria de produção): dez subagentes de exploração com effort alto podem custar mais em tokens de “pensamento” do que um subagente frontier com effort alto que resolve a hipótese certa em uma passada. Fan-out barato com effort máximo é armadilha silenciosa.
6. Fan-out: effort multiplica como modelo
Quando o harness deixa abrir subagentes, a conta deixa de ser linear. Cada filho herda ou recebe modelo e effort. Uma árvore de oito filhos “explore” com effort alto é o mesmo tipo de erro que oito filhos em opus para listar .go.
Orquestração antes da run, de novo:
- Pai (sessão principal): modelo e effort que você escolheu para coordenar.
- Filhos: tier e effort por prompt do spawn, não por padrão da sessão.
No downshift, o ponto de controle documentado é o spawn do Task (Claude Code, Cursor) ou spawn_agent (Codex): classificar, mapear tier, e no Codex ajustar reasoning_effort antes do processo filho existir. Grok: pins por role no config.
Capability Router v2 no repositório fala em piso de segurança para tarefas de alto risco (auth, migração, race): frontier independente do score. Para effort, eu trato o simétrico: tarefa crítica não recebe effort baixo só para economizar; tarefa trivial não recebe effort alto só porque o pai está em “modo sério”.
7. Effort como política de Staff
Em time, effort vira o mesmo tipo de artefato que routing em YAML:
subagent_defaults:
explore_files:
tier: small
reasoning_effort: low
implement_feature:
tier: mid
reasoning_effort: medium
security_review:
tier: frontier
reasoning_effort: high
Você deixa de perguntar “qual modelo o João deixou no dropdown?” e passa a perguntar “qual capacidade e qual profundidade esta delegação exige?”
Telemetria que eu gostaria de ver por spawn (formato, não promessa de produto):
tier escolhido
reasoning_effort (se aplicável)
complexidade classificada
retries
resultado (teste / review humano)
Só tokens por modelo não fecha a conta de effort. Dois spawns no mesmo tier com efforts diferentes podem divergir muito no total.
8. Onde isso encaixa no harness
Model routing sem effort é metade da política. O complemento é decidir quanto pensar naquela instância, principalmente em multitarefa e subagentes, onde o padrão do harness costuma ser “herda tudo do pai”.
Estou evoluindo o harness-downshift para isso: no spawn do subagente, tier de modelo e, onde o harness expõe o campo (documentado hoje para Codex com reasoning_effort, e Grok via config por role), effort alinhados à classificação da tarefa. Classifier determinístico, sem LLM no loop do router, fail-open se algo der errado. Beta honesto: compatibilidade de plano e harness muda; leia a seção de plan compatibility no README antes de instalar.
Leia o texto de model routing para a escada de tiers, mix e custo por tarefa bem-sucedida. Este texto é o par: tier certo no routing, effort certo no spawn.
Pergunta para você: no seu fluxo com subagentes, qual tarefa ainda herda effort alto (ou “thinking” máximo) só porque a sessão pai está em modo frontier? Que regra você escreveria para o primeiro filho mecânico da árvore?
