GPT-5.6-sol vs GPT-5.6-terra em teste prático: quanto desempenho justifica uma diferença de preço de 2x?

Teste prático: GPT-5.6-sol vs GPT-5.6-terra: quanta diferença de desempenho uma diferença de preço de 2x traz?#

gpt-5.6-sol e gpt-5.6-terra são dois modelos populares da série GPT-5.6 atualmente disponíveis para chamada direta na Crazyrouter.

Ambos já contam com 8 canais disponíveis e 7 canais de backup, mas os preços de entrada e saída diferem em exatamente 2x. Para desenvolvedores que já usam a série GPT-5.6, a pergunta que realmente vale testar é:

Os preços de entrada e saída do gpt-5.6-sol são ambos 2x os do gpt-5.6-terra. Gastando esse valor adicional, o desempenho consegue abrir uma diferença proporcionalmente grande?

Executei uma vez o mesmo conjunto de questões de probabilidade, física e engenharia em Python, totalizando 8 solicitações de API. A conclusão primeiro:

• A correção ficou praticamente empatada: ambos os modelos passaram em 4 questões.
• As duas questões de código Python passaram pelo mesmo conjunto de testes locais; o terra também foi mais rápido e mais conciso.
• O sol apresentou uma fração exata mais completa na questão de probabilidade e evitou uma cauda longa evidente na questão de física.
• Com base nos preços da página e nos tokens efetivamente usados neste teste, o custo total das 4 questões foi de aproximadamente $0.1614 contra $0.0718; na prática, o sol custou cerca de 2,25x mais.

O ponto mais interessante desta rodada é que a diferença de preço foi realmente de 2x, mas o desempenho não aumentou simplesmente na mesma proporção.

Primeiro, os preços: sol é a faixa premium do terra#

O dia do teste foi 13 de julho de 2026. A página mostrava que os dois modelos estavam com preço -35%; os preços abaixo são um retrato da página naquele momento e podem ser ajustados posteriormente.

gpt-5.6-sol:

gpt-5.6-terra:

Organizando em uma tabela:

Os preços de entrada e saída são exatamente 2x maiores. Como a página mantém quatro casas decimais na leitura de cache, ela exibe $0.3250 contra $0.1630, o que também pode ser entendido aproximadamente como 2x.

Portanto, este teste não compara apenas qual responde melhor, mas também avalia:

Se resolve corretamente a mesma questão
Se a resposta é completa
Se o código executa
Latência da resposta
Tokens de completion / reasoning
Custo estimado da solicitação com base no preço unitário da página

Configuração do teste#

A interface usada foi:

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Model A: gpt-5.6-sol
Model B: gpt-5.6-terra
temperature: 0.2

Cada questão recebeu exatamente o mesmo prompt e max_tokens para os dois modelos.

As 4 questões foram:

O critério de validação não se limitou ao HTTP 200:

• As questões de probabilidade e física foram comparadas com respostas de referência calculadas antecipadamente.
• As saídas em Python foram salvas como arquivos .py.
• O código dos dois modelos executou o mesmo conjunto de testes locais.
• Também foram registrados o modelo solicitado, o modelo retornado, finish_reason, tokens e tempo de resposta.

As 8 solicitações terminaram todas com:

HTTP 200
returned_model corresponde a requested_model
finish_reason = stop
Conteúdo visível não vazio

Resultado geral: empate em correção, sem empate em custo#

Primeiro, os resultados mais importantes:

Se a pontuação considerar apenas “a tarefa principal foi concluída”, esta rodada termina em 4:4.

Mas a diferença de custo é clara:

A fórmula de estimativa é:

Custo ≈
(prompt_tokens - cached_tokens) × input_price
+ cached_tokens × cache_read_price
+ completion_tokens × output_price

Em seguida, divida por 1.000.000.

Trata-se de um cálculo aproximado com base nos preços públicos da página, não de uma auditoria de cobrança. A cobrança efetiva deve seguir os logs e as regras de faturamento da plataforma.

Por que o preço de tabela é 2x, mas o custo final pode chegar a 2,25x? Porque o tamanho das saídas também é diferente. No total das 4 questões:

gpt-5.6-sol completion tokens:   7,391
gpt-5.6-terra completion tokens: 6,481

Nesta rodada, o sol gerou aproximadamente 14% mais saída; somado ao preço de saída 2x maior, o custo estimado por solicitação da questão de roteamento estável chegou a 2,64x o do terra.

Primeira questão: ambas as respostas de probabilidade estão corretas, mas a expressão exata do sol é mais completa#

A questão de probabilidade foi:

P(H)=0.62, P(T)=0.38.
Lance repetidamente até que HHTH apareça pela primeira vez.
Calcule o número esperado de lançamentos e faça a derivação usando equações de estado.

Resposta de referência:

E[N] = 7162950 / 566029 ≈ 12.6547

Os dois modelos estabeleceram corretamente os estados:

S0 = vazio
S1 = H
S2 = HH
S3 = HHT
S4 = HHTH

Ambos também explicaram a transição-chave: depois de HH, se aparecer outro H, obtém-se HHH; seu maior sufixo válido ainda é HH, portanto o estado permanece em S2.

Os dois chegaram a:

E0 = 1 / (p^3 q) + 1 / p ≈ 12.6547

A diferença está na apresentação da resposta:

• sol continuou a simplificação e chegou a 7162950 / 566029.
• terra forneceu a fórmula correta e 12.6547, mas não a converteu para a fração exata solicitada.

Portanto, terra não errou o cálculo; apenas faltou uma etapa na expressão exata.

O tempo das duas respostas foi praticamente igual:

sol:   33.0s
terra: 33.2s

Curiosamente, terra usou mais reasoning tokens: 999 contra 710, embora sua resposta final visível tenha sido mais curta. Isso mostra que preço menor não significa necessariamente menos raciocínio interno; é preciso avaliar cada tarefa separadamente.

Segunda questão: código de agregação de logs, terra mais barato e também um pouco mais rápido#

A segunda questão pedia a implementação de:

aggregate_model_usage(events, window_start, window_end)

A especificação incluía:

Contabilizar apenas eventos em [window_start, window_end)
Solicitações com falha contam apenas em requests; não acumulam token nem cost
user/model ausentes são classificados como unknown
Calcular cache_hit_rate
top_users em ordem decrescente de cost; em caso de empate, em ordem crescente de nome de usuário
Não modificar os objetos de entrada

O código dos dois modelos passou no mesmo conjunto de testes locais.

Nesta questão, terra não deixou de cobrir limites importantes por ser mais barato e ainda foi cerca de 2,2 segundos mais rápido. Para funções de backend com especificação clara e validação por testes, a relação preço-desempenho de terra se destaca.

Terceira questão: ambos acertaram a física, mas terra teve uma cauda longa de 168 segundos#

A questão de física tinha três etapas:

Deslizamento em um plano inclinado rugoso
Colisão perfeitamente inelástica
Compressão de uma mola horizontal sob atrito

Resposta de referência:

v1 ≈ 6.10 m/s
v2 ≈ 2.44 m/s
x  ≈ 0.302 m

Os dois modelos acertaram tudo e distinguiram corretamente:

• Na etapa do plano inclinado, usar a relação trabalho-energia ou a segunda lei de Newton equivalente.
• No instante da colisão, usar conservação do momento linear; a energia mecânica não é conservada.
• Na etapa de compressão da mola, usar a relação de energia que inclui o trabalho do atrito.

A correção continuou empatada, mas a diferença de tempo cresceu de repente:

sol:    24.7s
terra: 168.2s

A saída de terra foi, na verdade, mais curta: 1,059 completion tokens, contra 1,284 de sol. Portanto, desta vez a cauda longa não pode ser simplesmente atribuída a uma saída excessiva. É mais provável que esteja relacionada ao raciocínio naquele momento, à carga do canal ou ao estado do roteamento.

Este é apenas um exemplo, e não permite concluir que terra seja sempre lento em questões de física. Ainda assim, ele reforça um ponto: mesmo que modelos de baixo custo tenham boa velocidade média, é preciso observar separadamente as caudas P95/P99, em vez de considerar apenas a latência média.

Quarta questão: código de roteamento estável, terra mais rápido, saída mais curta e custo menor#

A última questão pedia a implementação de:

cheapest_stable_route(
    nodes,
    edges,
    start,
    target,
    banned_nodes=None,
    max_hops=None,
    min_reliability=0.0,
)

A regra de escolha não era um caminho mínimo comum, mas:

Primeiro, escolher o menor total cost
Em caso de mesmo cost, escolher a menor total latency
Persistindo o empate, escolher a maior reliability
Persistindo o empate, escolher o path lexicograficamente menor
Também lidar com banned_nodes, max_hops e o limite mínimo de confiabilidade

O código dos dois modelos passou nos testes de cost, latency, reliability, ordem lexicográfica, nós proibidos, número máximo de saltos e arestas inválidas.

Esta foi a tarefa de melhor desempenho de terra nesta rodada:

• Cerca de 14,7 segundos mais rápido.
• Cerca de 26% menos completion tokens.
• reasoning tokens equivalentes a aproximadamente metade dos de sol.
• Também passou nos testes, com custo estimado de apenas cerca de 38% do custo de sol.

Se a carga de trabalho real for composta principalmente por esse tipo de código Python verificável, o sol, mais caro, não demonstrou um benefício correspondente nesta questão.

Como interpretar esses dois modelos populares já disponíveis#

Esta rodada não deve ser apresentada como "terra é uma versão reduzida" ou "sol entrega exatamente o que custa". Os resultados reais se parecem mais com dois níveis diferentes:

Vantagens de gpt-5.6-terra#

• Os preços de entrada e saída são metade dos de sol.
• A correção central empatou nas 4 questões.
• As duas questões de código passaram nos testes e ambas foram mais rápidas que sol.
• As saídas de código de engenharia foram mais curtas, com cerca de 12% menos completion tokens no total desta rodada.
• O custo total estimado das 4 questões foi cerca de 55% menor que o de sol.

Vantagens de gpt-5.6-sol#

• A entrega da resposta exata na questão de probabilidade foi mais completa.
• Na questão de física, a resposta desta rodada foi claramente mais rápida e não apresentou a cauda longa de terra.
• A saída para a questão de roteamento estável foi mais detalhada, adequada para cenários que exigem mais detalhes de implementação.

Uma forma mais prática de usar#

Para equipes que já utilizam a série GPT-5.6, é possível distribuir as tarefas por tipo:

Geração frequente de código testável: priorizar terra
Processamento em lote de logs e tarefas estruturadas: priorizar terra
Derivações matemáticas que exigem expressão exata: testar sol primeiro
Sensibilidade a caudas longas em derivações complexas: manter também uma rota sol
Todas as saídas de código: encaminhar para testes automatizados

Não se trata de "colocar em produção ou não", mas de, depois que os dois modelos populares já estão disponíveis, obter resultados mais eficazes por dólar.

Limitações desta rodada de testes#

É necessário deixar claro que este é um pequeno conjunto de amostras únicas, não um benchmark de longo prazo.

Ele pode demonstrar:

As 8 solicitações desta vez foram todas bem-sucedidas
Os dois modelos concluíram as 4 tarefas
As duas questões de código passaram no mesmo conjunto de testes
Nesta rodada, token, estimativa de custo e tempo apresentaram as diferenças descritas acima

Ele não pode demonstrar:

Que a questão de física de terra sempre exigirá 168 segundos no longo prazo
Que sol é mais preciso em todas as questões de matemática
Que terra é mais rápido em todas as questões de código
Que 4 questões podem representar todas as cargas de produção

Uma próxima etapa mais rigorosa seria repetir cada tipo de tarefa de 20 a 50 vezes e observar:

Taxa de sucesso
Latência P50 / P95 / P99
Latência até o primeiro token
Média de completion tokens
Custo real por tarefa aprovada

FAQ#

A resposta do GPT-5.6-terra é pior que a do GPT-5.6-sol?#

Não é possível chegar a essa conclusão nesta rodada. A correção central das quatro questões ficou em 4:4, e as duas questões de código também passaram integralmente nos testes locais. A principal diferença é que o terra não continuou simplificando a fração exata na questão de probabilidade, e não que a resposta estivesse errada.

Por que o preço de tabela difere em apenas 2x, mas o custo medido chega a uma diferença de 2,25x?#

Porque a quantidade de tokens de saída também é diferente. Nas quatro questões, o sol gerou 7,391 tokens de conclusão, enquanto o terra gerou 6,481. O preço unitário mais alto para saída, somado a uma saída mais longa, fez a diferença de custo na questão de roteamento estável chegar a cerca de 2.64x.

A questão de física do terra sempre terá latência de 168 segundos no longo prazo?#

Não é possível tirar essa conclusão com base em uma única solicitação. Este resultado apenas mostra que essa solicitação apresentou uma cauda longa significativa. Uma avaliação de longo prazo exige amostragem repetida e a observação das latências P50, P95 e P99.

Qual modelo é mais adequado para geração de código?#

Nas duas tarefas executáveis em Python desta rodada, ambos passaram nos testes; o terra foi mais rápido, gerou uma saída mais curta e teve menor custo. Outros tipos de código ainda devem ser reavaliados usando seu próprio conjunto de tarefas reais.

Conclusão final#

Nesta rodada, gpt-5.6-sol e gpt-5.6-terra têm uma diferença de preço de 2x, mas a correção não apresentou uma diferença de 2x, nem mesmo de uma questão.

O terra demonstrou uma relação custo-benefício muito forte nas duas tarefas de código executável: passou nos mesmos testes, foi mais rápido, gerou uma saída mais curta e custou aproximadamente entre um terço e metade do sol.

O valor do sol aparece principalmente em respostas exatas mais completas e em um tempo de resposta mais estável na questão complexa de física desta rodada. Ele não supera o outro modelo em todos os aspectos, mas o preço adicional pode fazer sentido em tarefas sensíveis à qualidade da expressão e à cauda longa.

Portanto, a conclusão mais precisa desta vez é:

gpt-5.6-terra se parece mais com uma opção principal de alto custo-benefício, enquanto o gpt-5.6-sol se parece mais com uma faixa de preço mais alta que complementa tarefas de expressão precisa e raciocínio complexo. Agora que os dois modelos estão disponíveis, rotear por tarefa é mais valioso do que considerar apenas o modelo ou apenas o preço.

Reproduzindo os testes com Crazyrouter#

Este artigo realizou os testes pela API compatível com OpenAI da Crazyrouter. Para reproduzi-los, use o mesmo prompt, temperature, max_tokens e script de validação para ambos os modelos.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)

response = client.chat.completions.create(
    model="gpt-5.6-terra",
    temperature=0.2,
    max_tokens=3600,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)

print(response.model)
print(response.choices[0].finish_reason)
print(response.usage)
print(response.choices[0].message.content)

Altere model para gpt-5.6-sol, execute novamente e rode o mesmo conjunto de testes sobre os resultados de código para obter dados comparáveis.

• Cadastro: https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=gpt56_sol_terra_price_performance&utm_content=gpt-56-sol-vs-gpt-56-terra-price-performance-2026-pt__body_cta
• URL base da API: https://cn.crazyrouter.com/v1
• Registre: requested_model, returned_model, finish_reason, reasoning_tokens, tokens em cache, duração total e resultados dos testes de código。