Reasoning models em produção: quando o trade de latência vale a pena

Você abriu o problema na main, copiou o prompt no Sonnet 4.5 e a resposta veio errada. Não errada de detalhe. Errada de arquitetura. O modelo entendeu a pergunta, mas pulou três passos no meio.

Aí você liga extended_thinking. Espera quarenta segundos. Vem a resposta certa, com o raciocínio explícito até o bug.

Esse é o trade. E em maio/2026, depois de quinze meses convivendo com reasoning model em produção, dá pra falar com número na mesa: quando vale chamar o3, R1 ou Sonnet com thinking ligado — e quando o melhor que você faz é não chamar.

TL;DR

O que é: reasoning model gera tokens internos de cadeia de pensamento antes da resposta final. Custa mais tempo e mais token, mas resolve problema que o modelo "normal" não fecha.
Players em maio/2026: OpenAI o3 e o3-mini, DeepSeek-R1 (open source, MIT), Claude Sonnet 4.5 com extended_thinking.
Custo real: output 2x a 5x do modelo base, e 3x a 10x de latência. Em problema multi-step, é exatamente o que você quer.
Quando usar: planejamento multi-step, debugging de bug não-local, refatoração com restrição, agente que precisa decidir ordem de ferramenta.
Quando não usar: extração, classificação, sumário curto, código de boilerplate, pergunta factual.

O contexto: o que reasoning model muda

Reasoning model não é um modelo "mais inteligente". É um modelo que pensa em voz alta, e essa voz interna é cobrada como output token.

A ideia consolidou com o o1 da OpenAI em setembro/2024, e ganhou força definitiva com o paper do DeepSeek-R1 em janeiro/2025, que mostrou que dá pra treinar reasoning via RL puro, sem dataset humano gigantesco, e ainda liberar o resultado sob MIT.

Em maio/2026, a paisagem está estável o bastante pra você fazer escolha real:

A OpenAI tem o3 e o3-mini, com reasoning_effort controlável (low, medium, high).
A DeepSeek tem R1 atualizado, 671B parâmetros em MoE com ~37B ativos por token, a $0.55 input cache miss e $2.19 output por milhão. Contra os $60 de output do o3, é trinta vezes mais barato.
A Anthropic tem Sonnet 4.5 com extended_thinking controlado por budget_tokens. No 4.6, isso virou adaptive_thinking. No Opus 4.7, extended_thinking foi removido e retorna 400 — só adaptive.

São três sabores do mesmo trade: gastar mais token e tempo agora pra acertar resposta que o modelo base erraria.

O trade real: o que muda no número

Pega o3 da OpenAI. Throughput médio fica em torno de 17 tokens por segundo, o que faz uma resposta de mil tokens demorar quase um minuto. Sonnet 4.5 com thinking ligado, dependendo do budget_tokens, gasta de dez a quarenta segundos pra mesma pergunta que o modelo base resolveria em três.

E o consumo de token cresce não-linearmente. Um agente que normalmente gasta 1.2k tokens de output por turno passa a gastar 6k a 8k quando reasoning está ligado — porque o "thinking" inteiro entra na cobrança como output, mesmo que você só leia o sumário.

A conta em ordem de grandeza:

Eixo	Sonnet 4.5 sem thinking	Sonnet 4.5 com `extended_thinking`
Latência por turno	~3s	12s a 40s
Tokens de output	~1.2k	~6k a 8k
Custo por turno	1x	5x a 7x
Acerto em planning multi-step	baseline	sensivelmente acima

A última linha é onde o trade fica honesto. A Cognition AI publicou em setembro/2024 que trocar subsistemas internos do Devin de GPT-4o pro o1 trouxe "meaningful improvements" no benchmark interno cognition-golden, especialmente em tasks de planning de longo prazo. Eles não destrincharam número exato dessa virada — mas, em conversa com gente construindo agente, o ganho típico em planning fica entre 15% e 25% acima do modelo base.

Pra uma loja respondendo "qual o preço do tênis Nike Air?", esse trade é absurdo. Pra um agente que precisa quebrar uma migration em três passos, escolher ordem das constraints e prever rollback, é exatamente o trade que você quer.

Os três players em maio/2026

OpenAI o3 (e o3-mini)

Modelo: o3, o3-mini. Controle por reasoning_effort (low, medium, high).

from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="o3",
    reasoning_effort="high",
    messages=[
        {"role": "user", "content": "Refatore essa migration mantendo zero downtime: ..."}
    ],
)

Preço: $15 input / $60 output por milhão. É o player mais caro. Compensa quando o erro custa mais que o token — code review de produção, planejamento de migração de banco, análise financeira.

DeepSeek-R1

Modelo: deepseek-reasoner via API oficial, ou self-host (MIT). 671B MoE, ~37B ativos por token.

from openai import OpenAI

client = OpenAI(api_key="...", base_url="https://api.deepseek.com")

response = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=[
        {"role": "user", "content": "Resolva essa prova combinatória: ..."}
    ],
)

Preço API: $0.55 input cache miss / $2.19 output. Em AIME 2024 chega a 79.8% contra ~83% do o3 — diferença pequena pra custo trinta vezes menor.

Onde quebra: cobertura em português técnico é pior que o3 e Sonnet. Use quando o domínio é matemática, código e prova lógica em inglês.

Claude Sonnet 4.5 com `extended_thinking`

Modelo: claude-sonnet-4-5 com bloco thinking na request.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[
        {
            "role": "user",
            "content": "Esse teste tá flakando. Stack: Laravel 11, Pest, MySQL 8. ..."
        }
    ],
)

budget_tokens é o orçamento que Claude pode gastar pensando, e tem que ser menor que max_tokens. Em problemas de complexidade média, 4k a 8k já entrega 90% do ganho — 32k é overkill na maioria dos casos.

Particularidade: você paga pelos tokens completos de raciocínio, mesmo que receba só o sumário (e mesmo com display: "omitted"). Confira a fatura, não a contagem da resposta.

O pattern de produção: roteador classifier

Aqui é onde o time que sabe operar reasoning model se separa do time que botou o3 em tudo e estourou o budget no terceiro dia.

O pattern é simples: você não envia tudo pro reasoning. Coloca um classifier barato na frente que olha pra query e decide qual modelo recebe.

ROUTING_PROMPT = """
Classifique a query do usuário em uma das categorias:

- fast: extração simples, classificação binária, sumário de 1 parágrafo
- standard: explicação técnica, código simples, refatoração local
- reasoning: planejamento multi-step, debugging de bug não-local, prova lógica, ordem de operações com restrição

Responda APENAS com a categoria. Sem explicar.

Query: {query}
"""

def route(query: str) -> str:
    decision = client.messages.create(
        model="claude-haiku-4-5",
        max_tokens=10,
        messages=[{"role": "user", "content": ROUTING_PROMPT.format(query=query)}],
    )
    return decision.content[0].text.strip().lower()

def answer(query: str):
    category = route(query)
    if category == "fast":
        return call_haiku(query)
    if category == "standard":
        return call_sonnet(query, thinking=None)
    return call_sonnet(
        query,
        thinking={"type": "enabled", "budget_tokens": 8000},
    )

Haiku 4.5 classifica em duzentos milissegundos por uma fração de centavo. Você só paga reasoning quando a query realmente pede.

Detalhe que evita pegadinha: o classifier também precisa de eval. Monte 50 queries reais do seu produto, classifique manualmente, rode o roteador, mede precisão. Se passa de 90%, tá bom. Se fica abaixo de 80%, ajusta o prompt do classifier antes de subir.

A regra dos 12/4/40

Time que opera reasoning model com cabeça em produção converge numa proporção parecida — e dá pra usar como régua mental ao calibrar o roteador.

12% das queries vão pro reasoning model. O resto é fast ou standard.
4% do custo total vem do reasoning. Boa parte é amortizada por cache e batch.
40% do valor percebido do produto vem dessas 12%.

Por quê? Porque as queries que pedem reasoning são exatamente as que o usuário fica feliz por receber resposta certa. "Por que minha query Eloquent tá lenta com esses três joins encadeados?" é uma query em mil. Mas é a query em que o dev senta, fica vinte minutos lendo a resposta e fala "esse produto vale o que custa".

Se o seu produto está em 30%/30%/30%, você está chamando reasoning em coisa que não precisava. Se está em 5%/2%/15%, está subutilizando — provavelmente o classifier está mandando reasoning pra fast por medo de latência.

Calibra o classifier até bater perto da regra 12/4/40 e o ROI fica óbvio na fatura.

Onde reasoning model quebra

Não é tudo flor.

Streaming UX. Reasoning roda fechado. O usuário fica olhando "thinking..." por 30 segundos sem ver token saindo. Se o seu produto tem expectativa de resposta progressiva (chat interativo), reasoning quebra a UX. Solução: indicador de progresso explícito ("analisando arquitetura..."), ou modo fast por default com botão "pensar mais".
Tool use complexo. A doc oficial do Anthropic recomenda extended_thinking pra tool use simples e não-sequencial. Pra cadeia longa de tool calls, a recomendação muda pro padrão think tool (uma ferramenta think que o agente chama explicitamente), porque o modelo perde foco entre rounds.
Cache. Mudar budget_tokens invalida prompt cache. Se você economizava 90% em input por cache hit, ligar/desligar thinking quebra isso. Decida o budget cedo, fixa, e muda só com eval na mão.
Custo escondido. Token de thinking é cobrado mesmo com display: "omitted". Você economiza latência, não dinheiro.

FAQ

Reasoning model vale a pena num app PHP/Laravel?

Vale quando o app tem fluxo de decisão complexo: workflow de aprovação multi-step, parser de documento jurídico, planejamento de fila de jobs. Não vale pra CRUD, autenticação ou render de tela. Use o classifier pra direcionar.

DeepSeek-R1 self-host compensa?

Compensa se você tem GPU grande (cluster H100/H200, mínimo 8x pra MoE 671B) e volume alto pra amortizar. Pra volume médio, a API oficial DeepSeek a $2.19/MTok output sai mais barata que electricity + ops.

Como medir se reasoning melhorou minha aplicação?

Monte um conjunto de 30 a 50 queries de produção em que o modelo base errou. Roda no reasoning. Mede taxa de acerto. Compara latência e custo. Sem esse conjunto, qualquer escolha vira chute.

Posso usar reasoning model no Cursor ou no Claude Code?

Sim. Tanto o Cursor quanto o Claude Code permitem escolher reasoning model no editor. Vantagem: o IDE faz parte do trabalho de classifier por você — pedido de refator longo automaticamente cai no thinking model.

Conclusão

Reasoning model não é "modelo melhor". É modelo que cobra mais pra te entregar resposta numa classe específica de problema. Se você joga reasoning em tudo, queima budget e quebra UX. Se foge dele em tudo, deixa 40% do valor do seu produto na mesa.

O dev sênior em 2026 não está mais decidindo "qual modelo é o melhor". Está construindo roteador, calibrando classifier, medindo eval e olhando fatura. É menos sexy do que tweet de "o3 changes everything", e é muito mais útil.

Esse tipo de conversa, com código rodando e fatura aberta em vez de slide motivacional, é o que rola na Beer and Code, a melhor comunidade de AI engineering em português, com grupo no WhatsApp aberto pra quem está construindo IA em produção.