Há um tipo particular de reunião que acontece em toda equipe que constrói em cima de LLMs de fronteira. Alguém compartilha o último ranking de benchmarks. Outra pessoa aponta que as posições mudaram desde o mês passado. Uma terceira observa que o modelo que a equipe está usando no momento caiu duas posições em alguma métrica de que nenhum deles tinha ouvido falar três semanas atrás. Ao final da reunião, ninguém tem certeza se deve migrar, e a conversa é reagendada para o próximo trimestre.
O problema dessa reunião não são as pessoas nela. É que benchmarks medem tarefas sintéticas, e seu produto não é uma tarefa sintética. O ranking mostra como um modelo se sai no MMLU, no SWE-bench Verified, no GPQA Diamond — testes projetados por pesquisadores para serem mensuráveis entre modelos. Nenhum desses testes se parece com os prompts que seu aplicativo realmente envia em produção. Nenhum captura como um modelo lida com o tipo específico de entrada bagunçada e moldada pelo domínio que seus usuários geram.
Este texto percorre exatamente o exercício que benchmarks não conseguem fazer. Três prompts concretos, projetados para serem enviados a GPT-5.5, Claude Sonnet 4.6 e Gemini 3.1 Pro por meio do mesmo endpoint compatível com OpenAI, com as mesmas configurações de temperatura e sem prompting extra. Os prompts abrangem três categorias que tocam a maioria das cargas de trabalho em produção: extração estruturada de um documento bagunçado, uma tarefa de planejamento pesada em raciocínio e geração de código sob restrições. As observações abaixo são os padrões comportamentais que equipes executando este tipo de comparação relatam de forma consistente — os padrões que você veria por si mesmo se executasse esses prompts na sua própria configuração.
Nos rankings, esses três modelos marcam dentro de 0.8 pontos percentuais um do outro no SWE-bench Verified. Na prática, eles se comportam de forma muito diferente. A escolha entre eles não é sobre qual pontua mais alto nos benchmarks — é sobre qual padrão de comportamento se ajusta à sua carga de trabalho.
O que os benchmarks medem e o que deixam de fora
Benchmarks existem porque precisam. Os provedores de modelos precisam de testes padronizados para fazer declarações de capacidade, pesquisadores precisam deles para publicar comparações, e o resto de nós precisa deles para ter qualquer ponto de partida objetivo para avaliar modelos. Eles são úteis. Eles também são incompletos de maneiras que importam para uso em produção.
Três limitações específicas merecem ser explicitadas, porque cada uma aparece nos exemplos de prompt abaixo.
- Benchmarks medem capacidade isolada, não padrões de comportamento. SWE-bench Verified diz a você se um modelo consegue resolver um tipo específico de issue do GitHub. Não diz se o modelo tende a superengenheirar problemas simples, se faz perguntas de esclarecimento quando o prompt é ambíguo, ou se produz saída que corresponde à estrutura que você pediu de primeira. Essas são as coisas que você observará diariamente em produção.
- Benchmarks são alvo de tuning. Quando um lançamento de modelo destaca de forma proeminente sua pontuação em um benchmark específico, isso é um sinal de que o modelo foi pelo menos parcialmente otimizado para aquele benchmark. Desempenho no mundo real e desempenho em benchmark podem divergir — às vezes substancialmente — quando um modelo sai das condições para as quais o benchmark foi projetado.
- Benchmarks agregam. Uma diferença de 0.8 pontos percentuais na pontuação do SWE-bench Verified pode esconder o fato de que o Modelo A é muito melhor em uma categoria específica de tarefa e pior em outra, enquanto o Modelo B é consistente em todas. A agregação colapsa informações de que você precisa para tomar uma decisão.
O exercício abaixo é projetado para trazer à tona exatamente o tipo de informação que os benchmarks agregam. O objetivo não é declarar um vencedor — é mostrar as perguntas que você deve fazer quando executar o mesmo exercício nos seus próprios prompts.
A configuração
Três prompts, escolhidos porque mapeiam para categorias que a maioria das cargas de trabalho em produção atinge. A configuração: cada prompt enviado a todos os três modelos com parâmetros idênticos (temperatura 0.3, sem override de system prompt, formato de resposta padrão), acessados por meio de um único endpoint compatível com OpenAI para que a comparação seja justa — sem peculiaridades de SDK específicas do provedor, sem mapeamentos de parâmetros diferentes, sem risco de um modelo receber tratamento especial por causa de como a requisição é construída.
Os prompts em si estão abaixo, como blocos de código que você pode copiar e executar. As descrições comportamentais que seguem cada um são os padrões que as equipes relatam consistentemente ao executar esse tipo de comparação — padrões documentados em vários estudos de terceiros em 2026, e o tipo de coisa que você deve esperar ver por si mesmo quando executar esses prompts na sua própria configuração. Executá-lo você mesmo é o objetivo; o artigo existe para dar a você a estrutura e os prompts iniciais para fazer isso.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
Prompt 1: Extração estruturada de um documento bagunçado
Esta é a tarefa corriqueira de metade dos recursos de LLM lançados em 2026. Pegue uma entrada não estruturada — um e-mail, um tíquete de suporte, uma transcrição de reunião, um formulário escaneado — e extraia campos específicos em um objeto estruturado. O prompt abaixo pede a cada modelo que extraia sete campos de um e-mail de suporte ao cliente deliberadamente bagunçado contendo informações parciais, sinais conflitantes e um campo que não está presente no texto-fonte.
O prompt
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
O que observar
Três coisas. Primeiro, se o modelo adere ao esquema JSON solicitado sem invenções. Segundo, como o modelo lida com o campo que não existe na fonte (escalation_history — o cliente não menciona contato prévio sobre este problema) — ele admite ausência ou inventa algo plausível? Terceiro, se o modelo produz comentários adicionais fora do JSON, exigindo parsing a jusante para remover o invólucro. O campo de urgência também vale atenção: “5 dias” não é imediato, mas o cliente está claramente ansioso, o que deixa espaço para interpretação.
O que equipes executando isto relatam consistentemente
GPT-5.5. Normalmente produz JSON limpo na primeira tentativa. A aderência ao esquema é sólida; todo campo solicitado está presente e o formato é analisável sem pré-processamento. Para campos ausentes, o GPT-5.5 tende a retornar um null explícito. Geralmente não envolve o JSON em cercas de código markdown nem inclui explicações em prosa, o que torna o parsing subsequente trivial. Em decisões interpretativas ambíguas, como a classificação de urgência aqui, o GPT-5.5 tende a ser mais conservador que os outros dois — onde Claude e Gemini podem classificar o tíquete como “high” com base no tom emocional do cliente, o GPT-5.5 frequentemente ancora na janela concreta de 5 dias e chega a “medium”.
Claude Sonnet 4.6. Também produz JSON limpo, e costuma ser o mais preciso dos três ao seguir o esquema solicitado. Onde o GPT-5.5 deixa um campo ausente como null, o Claude frequentemente adiciona campos não solicitados sinalizando problemas de qualidade de dados — uma chave “notes” ou “data_quality_notes” que não foi pedida, mas contém informações realmente úteis. Esse campo extra é útil para revisores humanos, mas causa falhas se seu parser subsequente for estrito quanto ao esquema. Este é um padrão recorrente com o Claude: alta qualidade, porém às vezes mais minucioso do que o prompt pediu, exigindo instruções explícitas para restringir.
Gemini 3.1 Pro. Normalmente produz a saída mais econômica dos três. Todos os campos solicitados, sem campos extras, sem prosa ao redor. Aderência ao esquema exatamente como solicitado. Uma peculiaridade a saber: para campos ausentes, o Gemini tende a retornar uma string vazia em vez de null. Parsers JSON estritos que distinguem entre esses dois notarão a diferença; parsers permissivos não notarão. O comportamento é suficientemente consistente entre execuções para parecer uma preferência do modelo, não um artefato.
O que isso diz a você
Todos os três modelos conseguem fazer extração estruturada. As diferenças estão na margem comportamental em torno do esquema solicitado. Se seu sistema subsequente é estrito quanto ao esquema e trata campos extras como erros, Gemini 3.1 Pro e GPT-5.5 são escolhas mais seguras. Se você quer que o modelo evidencie problemas de qualidade de dados sem ser solicitado, Claude Sonnet 4.6 é mais útil. Nada disso aparece em um benchmark.
Prompt 2: Uma tarefa de planejamento pesada em raciocínio
Este prompt pede que os modelos planejem uma investigação de múltiplas etapas: uma pergunta de pesquisa com três restrições implícitas que um modelo cuidadoso deve identificar antes de sequenciar o trabalho. O tipo de tarefa que uma aplicação orientada a agentes delegaria a um LLM como a etapa de planejamento antes que quaisquer ferramentas fossem invocadas.
O prompt
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
As restrições implícitas que valem observar: a pergunta nunca define o que “churn” significa (encerramento de conta? sem logins? sem compras?), não especifica como controlar variáveis de confusão (usuários de baixo engajamento desistem por muitas razões não relacionadas à feature X), e não estabelece um grupo de comparação de referência. Um planejador cuidadoso deve evidenciar as três antes de produzir as etapas.
O que observar
Se o modelo realmente raciocina sobre o problema ou produz uma sequência de etapas com aparência plausível que não se sustenta quando examinada. Se ele identifica as restrições implícitas sem ser avisado delas. E se as dependências entre etapas estão corretas — um plano que parece bom, mas tem a etapa três dependendo de um resultado que a etapa cinco produziria, é inútil na prática.
O que equipes executando isto relatam consistentemente
GPT-5.5. Normalmente produz o plano operacionalmente mais utilizável. O raciocínio tende a ser visível — o GPT-5.5 enumera suas suposições sobre as restrições implícitas (definição de churn, grupo de controle, variáveis de confusão) antes de expor as etapas, o que facilita identificar onde sua interpretação difere do pretendido. As dependências de etapas são identificadas e rotuladas de forma confiável. A saída costuma incluir uma seção destacando quais etapas podem ser paralelizadas, o que não foi solicitado, mas agrega valor genuíno. Este é o tipo de tarefa em que o treinamento de uso de ferramentas e agente do GPT-5.5 aparece — o comportamento de planejamento é moldado pela suposição de que a execução subsequente seguirá.
Claude Sonnet 4.6. Normalmente produz o plano mais cuidadoso, no sentido literal — o plano do Claude frequentemente inclui considerações que os outros dois modelos não levantam. Em uma pergunta como esta, o Claude provavelmente apontará a questão metodológica de correlação vs causalidade, notará que “não usar a feature X” pode ser um sintoma de churn e não uma causa, e identificará explicitamente restrições que não foram explicitadas, mas que um analista atento deveria notar. A desvantagem: o plano pode ser mais longo do que o necessário, e etapas individuais às vezes superengenheiradas para a pergunta em si. O padrão é consistente com o comportamento do Claude em outros contextos — cuidado em nível de especialista, às vezes além do que a tarefa requer.
Gemini 3.1 Pro. Normalmente produz o plano mais claramente estruturado, com o grafo de dependências mais nítido. A qualidade do raciocínio é alta — o Gemini identifica de forma confiável as restrições implícitas, decompõe o problema em uma sequência defensável e produz instruções passo a passo que realmente seriam executadas. O ponto negativo: o plano pode soar um tanto mecânico. Faz o trabalho, mas tende a não evidenciar as sutilezas metodológicas que o Claude levanta, nem os insights de paralelização que o GPT-5.5 inclui. Isto combina com o padrão mais amplo do Gemini — forte em qualidade de raciocínio, mais pragmático nas decisões adjacentes.
O que isso diz a você
A qualidade do raciocínio nesta tarefa é alta em todos os três modelos. As diferenças estão no comportamento adjacente — o que o modelo adiciona além do pedido literal. GPT-5.5 adiciona pragmatismo operacional (paralelização, dicas de execução). Claude adiciona cuidado de especialista (metodologia, casos de borda, nuance estatística). Gemini adiciona clareza e economia. Nenhuma dessas é uma escolha errada. Qual delas se ajusta à sua aplicação depende do que você quer que o modelo faça quando terminar a tarefa que você pediu.
Prompt 3: Geração de código com restrições específicas
Este prompt pede que os modelos implementem uma função pequena porém não trivial: uma função Python que recebe uma lista de eventos com timestamp e retorna o maior intervalo entre eventos consecutivos, tratando quatro casos de borda. As restrições são explícitas; a intenção é testar geração de código sob restrições, não o teto de capacidade — todo modelo consegue escrever essa função. O que varia é como lidam com as restrições.
O prompt
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
O que observar
Se o modelo aborda todos os quatro casos de borda ou omite silenciosamente alguns. Se as type hints são precisas ou boilerplate. Se a implementação escolhe um algoritmo defensável (ordenar e varrer) ou algo exótico. E se o modelo respeita a restrição “sem testes, sem exemplos de uso” no fim do prompt — este é o tipo de instrução no final do prompt que modelos com forte obediência a instruções irão honrar e modelos mais fracos irão violar silenciosamente.
O que equipes executando isto relatam consistentemente
GPT-5.5. Normalmente produz o código mais minuciosamente engenheirado. Todos os quatro casos de borda tratados com ramificações explícitas, type hints precisas (frequentemente incluindo Optional ou Union para valores de retorno de casos de borda), e uma docstring com chamadas de exemplo. A implementação geralmente escolhe o algoritmo óbvio — ordenar, varrer, rastrear o maior intervalo — e está correta. Ponto a saber: o GPT-5.5 frequentemente inclui testes unitários ou exemplos de uso mesmo quando o prompt pede explicitamente apenas a função. Este é o trade-off com modelos operacionalmente pragmáticos — eles adicionam o que acham que você vai precisar, mesmo quando você pede para não.
Claude Sonnet 4.6. Normalmente produz o código mais legível. A função é concisa, casos de borda tratados com um padrão limpo de guard clauses no topo, type hints precisas e mínimas. O Claude frequentemente inclui um comentário cuidadoso explicando uma decisão que o prompt deixou em aberto — por exemplo, sobre timestamps duplicados, tratá-los como intervalos de comprimento zero e explicar por quê, o que é uma decisão defensável que o prompt não especificou. O Claude tende a respeitar a restrição “sem testes” de forma mais confiável que o GPT-5.5. A função em si é a mais manutenível das três. Consistente com a reputação do Claude em qualidade de código: limpa, idiomática, com toque de especialista.
Gemini 3.1 Pro. Normalmente produz o código mais econômico dos três. A função é correta, casos de borda tratados, implementação mais curta. Docstring geralmente de uma linha. Type hints presentes e precisas. A solução do Gemini raramente inclui testes ou comentários extensos, e não superengenheirra — exatamente o que o prompt pediu. Para um desenvolvedor que quer uma função funcional e pretende adicionar testes separadamente, este é o caminho mais direto. Para um desenvolvedor que quer que o modelo também faça o trabalho ao redor, os outros dois entregam mais (quer você tenha pedido ou não).
O que isso diz a você
Todos os três modelos conseguem escrever a função. A diferença comportamental está em quanto trabalho ao redor cada modelo faz além do pedido literal — e o quão bem cada um respeita instruções explícitas de “não adicionar X”. O GPT-5.5 pende para minúcia, mesmo quando isso foi dispensado no prompt. O Claude pende para o ofício (código legível, comentários ponderados sobre decisões). O Gemini pende para a economia (fazer exatamente o que foi pedido, nada mais). Para fluxos de trabalho orientados a agentes onde a saída do modelo vai diretamente para uma base de código de produção, o comportamento desejado depende do que seu processo de revisão subsequente espera — e de quão estritamente você precisa que instruções negativas sejam seguidas.
Os padrões que emergem
Ao longo dos três prompts acima, três padrões comportamentais consistentes emergem dos estudos comparativos e relatos de desenvolvedores publicados ao longo de 2026. Estes não são afirmações de capacidade — todo modelo lida com toda tarefa em alto nível. São tendências, o tipo de coisa que você só vê quando equipes observam o mesmo modelo lidar com dezenas de prompts. Execute os prompts acima na sua própria configuração e você verá os mesmos padrões; o artigo existe para dar a você a estrutura para reconhecer o que está vendo quando o fizer.
| Modelo | Tendência comportamental | Se encaixa melhor quando… |
|---|---|---|
| GPT-5.5 | Pragmático operacionalmente. Adiciona dicas de execução, codificação defensiva e saída amigável a etapas subsequentes. Forte em tarefas moldadas por uso de ferramentas e agentes. | Sua aplicação encadeia a saída do modelo em execução posterior — agentes, workflows ou pipelines onde o próximo passo é automatizado. |
| Claude Sonnet 4.6 | Cuidado em nível de especialista. Traz considerações além do pedido literal, levanta questões de ética e metodologia, produz código altamente legível. | Sua aplicação tem um humano revisando a saída do modelo — geração de conteúdo, revisão de código, análise onde o capricho importa. |
| Gemini 3.1 Pro | Econômico e direto. Faz exatamente o que foi pedido, nada mais. Aderência de esquema mais limpa e menor saída de tokens para trabalho equivalente. | Sua aplicação tem requisitos de saída estritos, custo previsível é prioridade, ou você quer que o modelo seja uma ferramenta precisa em vez de um colaborador reflexivo. |
Uma ressalva importante. Esses padrões são tendências, não regras. Cada modelo pode ser conduzido a qualquer um desses comportamentos com prompting apropriado — um system prompt suficientemente detalhado fará o Gemini adicionar testes, ou restringirá o Claude à saída mínima, ou fará o GPT-5.5 pular os testes unitários. O ponto é o que cada modelo faz por padrão, antes de você começar a direcioná-lo. O comportamento padrão é o que você vivencia em produção, a menos que ativamente faça prompting contra ele.
Como testar na sua própria carga de trabalho
O exercício acima é replicável em qualquer carga de trabalho, e deveria ser. Pontuações de benchmark são úteis como primeiro filtro, mas os padrões de comportamento do modelo que importam para sua aplicação específica só são visíveis quando você observa os modelos lidarem com seus prompts específicos.
Um guia prático para executar o exercício no seu próprio tráfego:
- Escolha três categorias de prompt representativas. Não três prompts aleatórios — três categorias que abrangem sua carga de trabalho. A maioria dos sistemas de produção pode ser decomposta em um punhado de tipos de prompt (extração, classificação, geração, raciocínio, código, sumarização). Escolha as categorias que respondem pela maior parte do seu tráfego.
- Selecione 20–30 exemplos por categoria. Idealmente, do tráfego real. Anonimize quando necessário. O ponto é que os prompts devem se parecer com o que sua aplicação realmente vê, não com questões de benchmark. Vinte exemplos por categoria bastam para ver padrões; trinta bastam para ter confiança.
- Execute-os por um único endpoint, todos os modelos. Um endpoint agregador compatível com OpenAI torna isso dramaticamente mais rápido do que executar cada modelo pelo seu próprio SDK. O código no topo deste artigo é toda a configuração. A mesma temperatura, os mesmos parâmetros, o mesmo prompt — as diferenças na saída são as diferenças entre os modelos.
- Avalie qualitativamente antes de quantitativamente. Examine visualmente as saídas primeiro. Os padrões comportamentais geralmente são óbvios nas primeiras dúzias de prompts. Uma vez que você tenha uma hipótese sobre como cada modelo se comporta na sua carga de trabalho, aí sim construa uma rubrica para avaliar — mas a hipótese vem da observação, não de um template de avaliação pré-fabricado.
- Preste atenção ao que o modelo adiciona. A pergunta de benchmark é se o modelo acerta a resposta. A pergunta comportamental é o que mais o modelo faz. Ele adiciona testes? Explica seu raciocínio? Levanta preocupações? Produz campos extras que você não pediu? É aqui que vivem as diferenças entre os modelos.
- Escolha o modelo que combina com seu padrão subsequente. Se seu processo subsequente é automatizado, você quer um modelo cujo comportamento padrão produza saída limpa e analisável. Se seu processo subsequente é de revisão humana, você quer um modelo cujo comportamento padrão adicione o tipo de julgamento que um revisor humano gostaria de ver. A resposta certa depende do que vem depois do modelo.
Conclusão
A escolha entre GPT-5.5, Claude Sonnet 4.6 e Gemini 3.1 Pro não é sobre qual modelo é o melhor. É sobre qual modelo se ajusta ao formato da sua carga de trabalho — e esse formato é algo que benchmarks não conseguem ver. O exercício acima é replicável em uma tarde se você tiver os prompts selecionados; o valor de fazê-lo é que você para de adivinhar e começa a observar.
Para equipes executando o exercício por conta própria: a configuração mais fácil é um único endpoint compatível com OpenAI que expõe todos os três modelos por trás de uma credencial. CometAPI é um caminho; você aponta seu SDK OpenAI existente para uma URL base diferente e o parâmetro de modelo vira a variável. O texto complementar, A Comparação de Preços de APIs de LLM em 2026, cobre o lado de custo da mesma decisão — juntos, eles dão a você o panorama comportamental e financeiro de que precisa para escolher bem.
Benchmarks dizem o que um modelo pode fazer. Padrões de comportamento dizem o que um modelo fará, por padrão, nos seus prompts. A primeira resposta é publicada. A segunda você precisa observar por conta própria. Vinte prompts por categoria, uma tarde, e você terá uma resposta que nenhum ranking jamais produzirá.
Pronto para integrar com confiabilidade? Acesse a CometAPI e a Documentação da API para acesso contínuo ao Claude Fable 5 ao lado de outros modelos de fronteira, faturamento unificado e confiabilidade em nível corporativo. Cadastre-se hoje e comece com créditos generosos para novos usuários — seu próximo projeto de destaque aguarda.