O modelo mais barato para um agente de programação é aquele que consegue fazer uma alteração passar pela revisão com a menor fatura total, não necessariamente aquele com a menor tarifa de entrada. Um agente envia repetidamente o contexto do repositório, recebe a saída das ferramentas, raciocina, escreve um patch e pode precisar de várias correções. Esta comparação usa o snapshot do catálogo de modelos ao vivo do GetVibe de 3 de outubro de 2026 e se concentra em modelos que podem ser usados em fluxos de trabalho de programação.
Snapshot de preços do catálogo
Os valores a seguir estão em USD por um milhão de tokens, primeiro entrada e depois saída. As células de preço exibidas são preenchidas a partir do catálogo do GetVibe; a data registra quando esta comparação foi verificada.
| Modelo | Tarifa de entrada / saída | Melhor primeiro teste |
|---|---|---|
| GPT-6 Luna | $0.0055 entrada · $0.0274 saída por 1M de tokens | Pequenas correções, resumos e iteração rápida |
| GPT-6.1 Sol | $0.1096 entrada · $0.548 saída por 1M de tokens | Edições em várias etapas e raciocínio mais robusto |
| GPT-6 Sol | $0.1096 entrada · $0.548 saída por 1M de tokens | Compare com o 6.1 usando os prompts existentes |
| Claude Sonnet 5.5 | $0.168 entrada · $0.84 saída por 1M de tokens | Programação no formato Messages e loops de agente |
Estas são tarifas do catálogo, não o resultado de um benchmark. A página do modelo continua sendo a fonte atual caso as tarifas mudem depois de 3 de outubro. Claude Sonnet 5.5 é útil para Claude Code porque aceita o formato Messages; os modelos GPT-6 devem ser testados por meio de uma ferramenta compatível com Responses, como Codex CLI, e não pelo Claude Code.
Use um teste de programação que meça o trabalho concluído
Escolha três tarefas de repositório: uma correção de bug localizado com um teste que falha, um pequeno recurso que envolva vários arquivos e uma refatoração com um requisito explícito de não alterar o comportamento. Congele o mesmo commit do Git, as mesmas instruções, permissões de ferramentas e comando de teste para cada execução. Avalie se a tarefa está correta, se os testes passam, quantos turnos de correção foram necessários e quanto tempo a alteração completa levou.
Não compare apenas a resposta final. Um modelo pode produzir um patch convincente que falha nos testes, causando outro turno longo. Registre o uso de entrada e saída em todos os turnos, incluindo resultados de ferramentas e prompts de correção. Calcule o custo por alteração aprovada nos testes. Execute pelo menos algumas amostras por tarefa; uma resposta sortuda não é uma classificação estável.
Por que uma tarifa baixa por token ainda pode custar mais
Os agentes frequentemente reenviam um prefixo grande: instruções do sistema, notas do repositório, esquemas de ferramentas e conversas anteriores. Os tokens de saída podem representar uma parcela maior da fatura do que prompts curtos sugerem. Um modelo que precisa de dois turnos de correção pode ser mais caro do que um que custa mais por token, mas produz um patch funcional de primeira. Leituras do cache podem mudar a economia de entradas repetidas, mas confirme se a entrada armazenada em cache é informada no uso antes de contabilizar a economia.
Mantenha o contexto concentrado. Ignore a saída do build, dependências, snapshots gerados e pacotes não relacionados. Peça ao agente para inspecionar primeiro apenas os arquivos mais prováveis. Isso reduz os tokens e frequentemente melhora a atenção. Use as orientações sobre prompt caching para prefixos repetidos e estáveis.
Com qual modelo você deve começar?
- GPT-6 Luna: uma linha de base de baixo custo sensata para alterações rotineiras e bem delimitadas. Consulte a página do modelo para ver o contexto e os recursos e, em seguida, encaminhe as tarefas nas quais ele falhar.
- GPT-6.1 Sol: compare em tarefas nas quais o planejamento e o raciocínio sobre vários arquivos são importantes. Ele tem preço inferior ao GPT-6 Sol neste snapshot do catálogo.
- GPT-6 Sol: mantenha-o na matriz se seus prompts existentes dependerem do comportamento dele; use resultados medidos para decidir se uma mudança ajuda.
- Claude Sonnet 5.5: inclua-o em fluxos de trabalho com Claude Code e baseados em Messages. Seu caminho e sua semântica de ferramentas diferem do Codex baseado em Responses, portanto compare os resultados em vez de fingir que os clientes são idênticos.
Faça a comparação ser reproduzível
Use a API compatível com OpenAI com uma chave no ambiente para clientes baseados em SDK:
export GETVIBE_API_KEY="your-dashboard-key"
python - <<'PY'
import os
from openai import OpenAI
client = OpenAI(base_url="https://getvibeapi.com/v1", api_key=os.environ["GETVIBE_API_KEY"])
result = client.chat.completions.create(
model="gpt-6-luna",
messages=[{"role": "user", "content": "Inspecione src/parser.py e corrija o caso-limite que está falhando. Execute o teste relevante."}],
max_tokens=1200,
)
print(result.choices[0].message.content)
PYUse o endpoint exato compatível com o cliente do agente. Para o Codex CLI, use a configuração da Responses API; para o Claude Code, use a configuração do Messages. Preserve os prompts de permissão e execute os agentes em uma branch para poder revisar um diff concreto.
Regra de decisão
Escolha o candidato menos caro que atenda à sua meta de taxa de aprovação e ao seu orçamento de latência nas tarefas do seu próprio repositório. Mantenha o conjunto fixo de avaliação e execute-o novamente quando o catálogo, a versão do agente ou o prompt mudar. Armazene a data, o ID do modelo, o uso e o resultado dos testes com cada observação. O snapshot do catálogo de 3 de outubro de 2026 está vinculado nas páginas dos modelos; use essas páginas para consultar os preços de hoje em vez de copiar valores desatualizados para uma planilha.
Estime o custo total da tarefa
Para o planejamento, separe o uso de entrada e saída. Se uma tarefa usar 40,000 tokens de entrada e 2,000 tokens de saída, calcule cada parcela usando as tarifas atuais por milhão do modelo selecionado na página dele e depois some-as. Esta é apenas uma linha de base: entradas armazenadas em cache, cobranças mínimas por solicitação, vários turnos do agente e novas tentativas podem alterar a fatura real. Use os detalhes de uso após uma execução de teste para substituir estimativas por totais observados.
Não confunda o tamanho do contexto com os tokens cobrados. O contexto máximo de um modelo descreve o que ele pode aceitar, não quanto custa cada solicitação. Evite que o agente de programação carregue o repositório inteiro quando apenas alguns arquivos forem relevantes. O contexto seletivo frequentemente melhora a qualidade da resposta e reduz o número de tokens enviados.
Acompanhe sinais de qualidade que afetam o custo
Para cada execução, registre se o patch foi aplicado corretamente, se os testes relevantes passaram, quantas chamadas de ferramenta falharam, quantos turnos de correção ocorreram e se um revisor aceitou a alteração. Um modelo que precisa de muitas novas tentativas pode ter um custo maior por alteração aceita, mesmo que sua tarifa por token exibida seja menor. A latência também importa: a rota mais lenta pode ser apropriada para trabalho noturno, mas inadequada para um editor interativo.
Separe erros do modelo de erros do harness. Um comando de teste ausente, um checkout desatualizado ou uma negação de permissão não devem ser avaliados como falha de raciocínio. Mantenha um trace com ID da tarefa, ID do modelo, SHA do repositório e categoria de erro com dados redigidos para que uma equipe possa repetir a mesma comparação posteriormente.
Use um fluxo de trabalho em dois níveis somente quando houver evidências
Uma estratégia de custo é tentar um modelo de menor custo para edições rotineiras e encaminhar uma tarefa depois de um sinal determinístico, como testes que falharam ou uma saída estruturada inválida. Isso pode economizar dinheiro quando a maioria das tarefas é simples. Também pode adicionar uma segunda passagem completa pelo contexto em tarefas difíceis. Meça a taxa de encaminhamento e o uso combinado antes de implantar essa estratégia.
Mantenha explícita a seleção do modelo de fallback na configuração da aplicação. Se a reprodutibilidade for importante, informe qual modelo tratou cada tarefa. Não chame silenciosamente um modelo público diferente enquanto diz a um desenvolvedor que a alteração veio do modelo original.