Como a migração de um agente de IA em produção para o GPT-5.6 o tornou 2,2 vezes mais rápido e 27% mais barato

 (ploy.ai)
1 pontos por GN⁺ 7 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A Ploy migrou seu agente que planeja, constrói e valida sites de marketing em produção do Claude Opus 4.8 para o GPT-5.6 Sol e o definiu como modelo padrão em todos os workspaces
  • Depois de corrigir pressupostos específicos de modelo no harness de avaliação, em uma tarefa de reconstrução da homepage o tempo médio de execução caiu de 8 minutos para 3 minutos e 42 segundos, o custo caiu 27%, de US$ 3,06 para US$ 2,22, e a pontuação visual subiu para 0,970
  • O GPT-5.6 preenchia todos os 25 parâmetros opcionais das chamadas de ferramenta com valores arbitrários, fazendo com que 52% a 64% das leituras de arquivo retornassem resultados vazios; ao transformar campos opcionais em obrigatórios e nullable, as leituras vazias caíram para 0% e as chamadas de ferramenta também diminuíram cerca de 30%
  • Devido a diferenças na estrutura de escopo de cache e throughput entre OpenAI e Anthropic, o GPT-5.6 inicialmente parecia cerca de 50% mais caro, mas, ao aplicar chaves de cache por workspace e breakpoints por camada, a taxa de acerto na primeira chamada subiu de 0% para 83,7% e os tokens de entrada não cacheados caíram 28%
  • O custo e o desempenho de uma troca de modelo dependem não só do modelo em si, mas também do orçamento de avaliação, do schema das ferramentas, da estrutura de cache e do modo de replay de raciocínio; portanto, para comparações confiáveis e operação estável, é preciso primeiro encontrar e corrigir pressupostos específicos de provedor ajustados ao modelo anterior

GPT-5.6 Sol substitui Claude Opus

  • O agente da Ploy planeja páginas de sites de marketing em produção, lê codebases, gera componentes e imagens, verifica os resultados por screenshots e decide se a tarefa foi concluída
  • Durante vários meses, nenhum modelo cumpriu os critérios para substituir Claude Opus, e o modelo padrão permaneceu por 4 meses na sequência Opus 4.7 e 4.8
  • GPT-5.6 Sol foi o primeiro a superar Opus em uma avaliação direta nas mesmas tarefas e se tornou o modelo padrão de todos os workspaces da Ploy
  • Mesmo na avaliação inicial, o tempo de execução dos builds concluídos foi menos da metade, o custo foi 27% menor e as pontuações foram iguais ou superiores às do modelo anterior, fornecendo a base para a migração
  • A Ploy usa o Vercel AI SDK, mas, durante a troca de modelo, descobriu que pressupostos específicos de provedor sobre composição de argumentos de ferramentas, cache de prompt e replay de raciocínio entre turnos permaneciam por toda a stack
  • A migração avançou corrigindo, nessa ordem, o harness de avaliação, os schemas de ferramentas, o cache de prompt e o replay de raciocínio

Corrija o harness antes de confiar nos números de avaliação

  • A suíte de avaliação executa o agente de produção em workspaces de teste fixos e cobre centenas de casos, desde tarefas de construir uma homepage do zero até decidir se uma solicitação de clonagem pode ser executada com segurança
  • Nos casos de build, um avaliador visual executa 10 verificações binárias comparando com o design de referência
    • Verifica se a área hero é uma cena fotográfica que ocupa toda a largura da tela
    • Confirma se o CTA principal é um retângulo com cantos arredondados, e não no formato pill
  • Também são executadas verificações de conteúdo, verificações de caminhos de execução de ferramentas e asserções de arquivos; em caso de falha, é analisado o trace completo da execução, incluindo chamadas de ferramenta e texto do modelo

  • Restrições ajustadas ao modo de chamada do modelo anterior

    • O orçamento de chamadas de ferramenta existente havia sido ajustado ao modo de chamadas sequenciais de Opus, mas o GPT-5.6 usa chamadas paralelas e excedia o orçamento mesmo em casos em que resolvia o problema corretamente
    • O executor de avaliação não dava suporte a leituras de arquivos em lote, algo que Opus quase não usava, mas que o GPT-5.6 usa com frequência
    • Cerca de um terço das falhas brutas ocorridas na primeira execução vieram de pressupostos do harness, não do comportamento do modelo, e tampouco estavam distribuídas uniformemente entre os modelos
    • Se os traces de execução do modelo desafiante e do modelo anterior não forem classificados primeiro, a avaliação favorece o novo modelo quanto mais ele se comportar como o antigo

  • Limiares de pontuação implícitos

    • Datasets sem minScore herdavam silenciosamente o valor padrão 1.0
    • Por isso, o GPT-5.6 foi tratado como falha mesmo recebendo uma pontuação de 0,98 no hero, e Opus também foi julgado como falha em um caso em que havia passado em todas as verificações individuais
    • Ambos os resultados eram designs defensáveis, mas foram eliminados por causa de limiares implícitos, não pelo modelo

Resultados do benchmark corrigido

  • Depois de corrigir o harness, a suíte de avaliação que reconstrói uma homepage de marca de acordo com um design de referência foi executada novamente
Média por build concluído Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Custo US$ 3,06 US$ 2,22
Tempo de execução 8 min 00 s 3 min 42 s
Tokens de entrada 2,6 milhões 1,7 milhão
Tokens de saída 33.000 17.100
Pontuação visual 0,936 0,970
  • O GPT-5.6 completou a página 2,2 vezes mais rápido, custou 27% menos e usou cerca de metade dos tokens de saída
  • A quantidade de código gerado também foi menor
    • Em um par de casos comparativos, Opus gerou 174 variáveis CSS e um globals.css de 17.957 caracteres, incluindo famílias de cores que em sua maioria não eram usadas
    • O GPT-5.6 usou 45 variáveis CSS e 2.508 caracteres, ainda assim produzindo um resultado renderizado semelhante ou melhor

  • Qualidade e consistência do design

    • O GPT-5.6 é forte em layouts limpos e com grids densos, mas tende a convergir para esse estilo se não for fortemente direcionado
    • No harness existente projetado para Opus 4.8, ele frequentemente gerava resultados limpos, mas genéricos, ignorando o sistema de design existente
    • Depois que as equipes de design e engenharia melhoraram a forma de orientar o modelo, ele passou a cumprir os padrões de aderência à marca exigidos em produção

Tratamento de parâmetros opcionais em chamadas de ferramenta

  • A ferramenta code do agente tem 25 parâmetros de nível superior, dos quais apenas action é obrigatório e os demais são opcionais
  • Claude envia apenas os 2 ou 3 parâmetros que usa, mas o GPT-5.6 envia todos os 25 em cada chamada, preenchendo campos não usados com valores plausíveis como offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • O mesmo padrão apareceu em traces de execução de code(read) coletados em produção durante 3 dias
Modelo Chamadas Chamadas contendo todos os 25 atributos
gpt-5.6 6.635 6.635, 100%
claude-opus-4.8 2.898 4, 0,1%
claude-sonnet-5 1.933 0

  • Causa das leituras de arquivo vazias

    • O problema não era simplesmente a verbosidade dos argumentos, mas o fato de que a implementação de leitura de arquivos não conseguia distinguir valores inventados arbitrariamente pelo modelo de valores pretendidos pelo usuário
    • A implementação tratava offset: 0 como um argumento real, e 52% a 64% das leituras de arquivo do GPT-5.6 retornavam resultados vazios
    • Como a ferramenta retornava success: true tanto para leituras válidas quanto para leituras vazias, o modelo não tinha como saber que estava lendo um arquivo vazio
    • Ao tentar compensar os resultados vazios, ele fazia mais chamadas, piorando também a qualidade do resultado

  • Problemas que prompt e modo strict não resolveram

    • Mesmo colocando na descrição da ferramenta uma instrução para omitir parâmetros não usados, todos os 25 eram gerados
    • Mesmo adicionando OPTIONAL, omit if unused a cada propriedade, o comportamento não mudou
    • O mesmo resultado ocorreu no modo strict da OpenAI, e adotá-lo exigiria remover pattern, format e validações de tamanho de arrays de todos os schemas
    • Como esse comportamento vem da forma como o modelo gera chamadas de função, a solução foi mudar o schema, não o prompt

  • Conversão de schema na fronteira do provedor

    • Para modelos da família OpenAI, todas as propriedades opcionais foram reescritas como propriedades obrigatórias e nullable no formato anyOf: [T, null]
    • O modelo preenche parâmetros não usados com null explícito, e o null é removido antes da validação na fronteira compartilhada de chamadas de ferramenta
    • A implementação da ferramenta não foi alterada; apenas o schema para o modelo passou a permitir representar valores não usados
    // Antes: todas as 25 chaves eram preenchidas com valores arbitrários
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Depois: envia 4 valores reais e 21 nulls, e remove os nulls antes da execução da ferramenta
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Depois da mudança, as leituras de arquivo vazias caíram de 52% para 0%
    • O número de chamadas de ferramenta necessárias para a mesma tarefa também caiu cerca de 30%, eliminando o comportamento de reler repetidamente resultados vazios

Cache de prompt ajustado ao modo da OpenAI

  • Ambos os provedores oferecem cache de prompt, mas as implementações são diferentes
  • Antes de refletir essa diferença, o GPT-5.6 parecia cerca de 50% mais caro que Opus, mas a causa era a configuração de cache, não o preço do modelo

  • Cache da Anthropic em nível de organização

    • O prompt do agente começa com um prefixo estático de cerca de 29.000 tokens, composto por schemas de ferramentas e o prompt de sistema principal, idêntico em todas as conversas
    • No Claude, os breakpoints de cache são marcados com cache_control, e o prefixo é compartilhado por toda a organização
    • Uma conversa de qualquer workspace pode usar o mesmo item compartilhado, sem limite de throughput por chave
    • A taxa de acerto do cache é de 92% a 96%

  • O que mudou no comportamento de cache do GPT-5.6

    • Modelos GPT anteriores cacheavam implicitamente correspondências parciais de prefixo, mas o GPT-5.6 removeu a correspondência parcial de prefixo
    • Como o cache implícito cria itens de prompt completos com base nas mensagens mais recentes, até uma conversa nova que compartilhe o mesmo prefixo estático de 29.000 tokens tem taxa de acerto de 0% na primeira chamada
    • Com isso, o prefixo inteiro era cobrado novamente como não cacheado em cada conversa
    • Independentemente de a aplicação usar cache ou não, o GPT-5.6 aplica um adicional de 1,25x por escrita de cache a todos os prompts não cacheados

  • Restrições de chaves de cache explícitas

    • O cache explícito exige prompt_cache_breakpoint e o obrigatório prompt_cache_key
    • A chave também faz parte da identidade do cache, portanto o mesmo prompt com chaves diferentes não gera acerto
    • Cada chave é mapeada para um nó de cache que processa cerca de 15 requisições por minuto; acima disso, a OpenAI distribui o tráfego para outros nós com caches frios independentes
    • Portanto, a unidade usada para definir a chave vira uma decisão central de design
    • Chave por conversa: novas conversas não acertavam o prefixo compartilhado, gerando 0% de acerto na primeira chamada
    • Uma chave global: todas as requisições são hasheadas para um único nó, e quando o tráfego de produção passa de 15 rpm, transborda para nós frios
    • Chave por workspace: todas as conversas de um workspace de cliente compartilham itens, mantendo baixo o tráfego por chave

  • Cache hierárquico em nível de workspace

    • A configuração real usa uma chave por workspace no formato ws:{workspaceId} e divide o prompt de sistema em camadas de breakpoints
    • O item A contém as ferramentas e o prefixo estático, reduzindo o custo da primeira chamada da sessão
    • O item B adiciona o contexto do workspace ao prefixo estático
    • O item C é a cadeia completa de prompt específica da sessão, do primeiro turno até a mensagem mais recente
    • Quando a memória do workspace muda, o item B falha, mas o item A continua acertando, de modo que apenas o tamanho do contexto alterado é reescrito, e não todos os 29.000 tokens
    • Como o item C é uma estrutura estritamente append-only, dentro da sessão ele aproveita a cadeia implícita de prompt completo da OpenAI
    • Devido ao particionamento de chaves da OpenAI, não é possível compartilhar o prefixo estático entre workspaces
    • Em contraste, a Anthropic usa cache em nível de organização sem particionamento por chave, permitindo compartilhar o prefixo
    • No GPT-5.6, cada workspace faz uma escrita fria dos 29.000 tokens uma vez por intervalo de ociosidade, com custo de cerca de US$ 0,18
    • Esse custo tem escopo limitado e é previsível

  • Resultado das correções de cache

    • A taxa de acerto do cache na primeira chamada subiu de cerca de 0% para 83,7%
    • O total de tokens de entrada não cacheados caiu 28%
    • O custo do GPT-5.6 por suíte de avaliação ficou menor que o de Opus, e toda a diferença inicial de custo vinha de uma configuração de cache incorreta
    • Comparações de custo entre modelos feitas com apenas um modelo começando com cache frio não são válidas

Mudança do replay de raciocínio para ser autocontido

  • Por padrão, a Responses API do GPT-5.6 reproduz o raciocínio de turnos anteriores usando referências a itens no lado do servidor, e em conversas de produção ocorria intermitentemente o erro Item 'rs_...' not found
  • Ao definir store: false, o SDK solicita conteúdo de raciocínio criptografado e reproduz um blob autocontido em vez de um ponteiro para estado no servidor
  • Mesmo que os bytes enviados pela aplicação tenham estrutura append-only, o estado de raciocínio no lado do servidor pode alterar o prompt efetivo
  • Com o harness de avaliação, schemas de ferramentas, cache de prompt e replay de raciocínio corrigidos, o GPT-5.6 Sol está rodando como modelo padrão de produção da Ploy

Leituras relacionadas

1 comentários

 
GN⁺ 7 시간 전
Comentários do Hacker News

  • Expressões como “esses números já justificam migrar o modelo de verdade” são ridículas demais. Quem mandou escrever o texto poderia pelo menos ter ajustado esse estilo típico de LLM
    Esse jeito de emendar frases curtas com dois-pontos, vírgulas e pontos também é péssimo e cansativo. Há boas percepções, como a observação de que o cache por correspondência parcial de prefixo desapareceu no GPT-5.6, mas não é um texto agradável de ler

    • É por isso que eu sempre mantenho um WRITING.md ao lado de AGENTS.md ou CLAUDE.md. A maioria só diz ao modelo o que construir, mas quase nunca como escrever, e os LLMs seguem diretrizes explícitas de estilo surpreendentemente bem
      Eu coloco regras para evitar dois-pontos desnecessários, travessões longos, fragmentos de frase disfarçados de ênfase e erros gramaticais que costumo cometer, e também incluo Brian Kernighan e Rob Pike como referências de escrita técnica clara, coloquial e sem afetação. A documentação não deve só ser fácil de ler, tem que dar vontade de ler
      Se você gera documentação com frequência, vale muito a pena fazer o agente consultar o WRITING.md. Muitas vezes isso melhora a legibilidade muito mais do que trocar para um modelo mais novo, e permite manter o estilo consistente mesmo mudando de modelo
    • Fica ainda pior se for uma empresa de IA. Isso só pode significar que eles não usam os modelos o suficiente para reconhecer esse estilo característico, ou não percebem que isso importa, ou não entendem o contexto geral, ou não respeitam o leitor; nenhuma dessas opções é boa
    • Você está lendo do jeito errado. É só pedir ao LLM para ler e resumir no estilo que você prefere. Melhor ainda, não leia nada diretamente e mande o agente converter em um arquivo de skills para consultar depois
    • Se suspeito que um texto foi escrito por LLM, paro de ler na hora e peço para a ferramenta de LLM que uso resumir ou reescrever. Assim, pelo menos consigo algum controle sobre o estilo da saída
    • No claude.md que uso agora, proibi a expressão “load-bearing”, porque o Claude adora isso de um jeito irritante. Às vezes ele até brinca nos comentários com algo como “load-be...most specific”, de tanto que gosta dessa expressão

  • Eu também migrei vários fluxos de trabalho diversos, pequenos e simples que antes rodavam em 5.4-nano e mini para 5.6, e no geral vi melhorias na faixa mencionada no texto; em algumas tarefas de classificação, a qualidade também subiu
    Em muitas empresas, esse tipo de upgrade de modelo é literalmente mudar uma linha de código. Nos fluxos centrais usamos uma excelente arquitetura de roteador de modelos, mas não vale a pena montar isso para tarefas simples, e ainda é preciso considerar questões de confiabilidade

    • O ponto central deste texto é justamente que o upgrade de modelo não foi uma mudança de uma linha de código
    • Qual SDK você usa? Ou é implementação própria?
    • O objetivo inicial de usar o Sol era avaliar o 5.6 nos nossos fluxos de trabalho. Antes, a qualidade dos modelos simples não era suficiente, então usávamos 5.5 para tudo; agora analisamos texto e imagens juntos para extrair dados estruturados explícitos e implícitos de dados de origem bagunçados
      Em geral, funcionou como anunciado. Ao mandar a maior parte do trabalho atual para terra, o custo caiu pela metade e o tempo de resposta melhorou 50%. Usamos luna para complementar os resultados de detecção do OpenCV; a função é bem limitada, mas é rápido e quase de graça. No nosso caso, o Sol foi só um pouco melhor que terra
      O Sol ultra também fez um ótimo trabalho na própria avaliação. Ele gerou um material grande com recomendações sensatas, uma lista de saídas para verificar e comparar manualmente, dados brutos e processados e CPM por consulta. Rodou por algumas horas sem gastar nada além da assinatura Pro, e o resultado foi 50% menos custo e 100% mais throughput

  • Minha experiência é parecida. Serviços como o OpenRouter, que vendem a ideia de failover, quase não servem para nada fora de testes em sandbox. Na prática, modelos de produção não são intercambiáveis, e ambientes de execução que fazem trabalho real de agentes dependem de muito mais características específicas de cada modelo do que se imagina
    Mesmo quando outro modelo funciona sem erro, desempenho e eficiência são outra história. Alguns modelos, como a família Claude, exigem que o prompt de sistema seja ajustado para o jeito de expressão com que se acostumaram no treinamento; outros funcionam melhor com delimitadores diferentes. Se desempenho ideal importa, é preciso ver ambiente de execução, prompt e modelo como um único sistema, e não achar que dá para trocar peças livremente

    • Como parte de LLMOps, é preciso montar um plano de failover adequado, com verificação correta de caminhos de execução de ferramentas e afins. Assim, você pode implementar o failover desejado organizando modelos suficientemente bons do mais barato para o mais caro
      Já vi gente fazer uma tabela do tipo model -> {{prompts}, {tools descriptions}, ...}, mas isso é extremo demais. A partir de certo ponto, o modelo precisa se adaptar aos nossos prompts; se não conseguir, basta tirá-lo da lista de candidatos de failover e não enviar requisições de API para ele
    • O OpenRouter não faz failover para outro modelo; ele troca para outro provedor que oferece o mesmo modelo

  • É irônico que, sob um texto cheio de percepções profundas sobre infraestrutura, metade dos comentários esteja criticando só o estilo artificial. Mesmo que o Claude tenha ajudado a polir as frases, se o texto traz um plano imediatamente aplicável para cortar 30% do orçamento de API e corrigir leituras de arquivos vazios, isso não é mais importante?

    • Algumas pessoas vão caçar defeito em qualquer coisa relacionada a IA porque odeiam o tema, mas outras provavelmente focam só nisso porque realmente não suportam esse estilo de escrita
      Pessoalmente, acho engraçado reclamar tanto do estilo. Talvez porque eu seja fraco em gramática e ortografia, foco mais no conteúdo central — conceitos, fatos, argumentos — do que na forma de apresentação. Gramática e ortografia são as árvores; a floresta é o que importa
      Se meus textos não têm muitos erros, é por causa do ditado por voz e de atalhos que eu mesmo criei. Eles corrigem o texto selecionado com um LLM local e depois substituem o original; poucas coisas melhoraram tanto minha qualidade de vida e minha escrita quanto essas duas ferramentas

  • “A partir de hoje, o agente da Ploy usa o GPT-5.6 Sol lançado hoje de manhã”: então vocês fizeram a migração com base em apenas meio dia de testes? A empresa é tocada por adolescentes?

    • Na prática, a equipe está mais para nível Staff e Senior Staff. Por meio da relação com a YC, eles tiveram acesso antecipado ao modelo preview do GPT-5.6 por cerca de uma semana para testá-lo e enviar feedback
      As avaliações rodam no GitHub CI, e é possível executar em cerca de 15 minutos mais de 115 conjuntos de avaliação de tarefas de design web e marketing, área em que a ploy.ai é especializada. Depois de ativar o modelo com feature flag do PostHog, passaram a monitorar ativamente as falhas
      Querem transferir para a Ploy o máximo possível do conhecimento adquirido ao operar a Webflow, que dá suporte a mais de 1% da internet, para apoiar uma parcela ainda maior da internet
    • É bem plausível que tenham recebido algum nível de acesso antecipado para fazer avaliações e poder escrever um post assim
    • Hoje em dia é bem fácil criar avaliações e benchmarks e executá-los nos modelos mais recentes. Como LLMs são fáceis de trocar, um bom conjunto de avaliações é muito útil, e às vezes o ganho é tão claro que nem avaliação é necessária
    • Imagino que eles tenham um dataset baseado em produção para comparar os novos modelos

  • Dizem que o agente da Ploy cria e modifica sites reais de marketing, faz planejamento, lê a base de código, escreve componentes, gera imagens, tira capturas do próprio resultado e decide quando terminou, mas mesmo sem testes rigorosos eu esperaria que o Fable fosse muito melhor do que o Opus para criar sites de marketing. Em material de apresentação, com certeza ele é muito melhor

    • Em design, o GPT-5.6 é muito melhor que o Fable
    • O 4.7 tende a seguir instruções de forma excessivamente literal, então o resultado do post original também parece bastante plausível

  • Essa solução de, só para modelos da linha OpenAI, tornar todos os atributos opcionais obrigatórios e ao mesmo tempo permitir null com anyOf: [T, null] parece meio errada. Usei apenas uma variante de MCP, mas não está claro por que as definições de tipos do TypeScript deveriam influenciar o JSON Schema enviado do agente para o backend de inferência
    A especificação do MCP tem um campo explícito para representar parâmetros opcionais, então parece haver um bug em algum ponto entre a camada de TypeScript e a descrição de ferramenta realmente transmitida. Pode ser que o backend de inferência tenha mudado de “gerar uma resposta de ferramenta válida” para “gerar uma resposta válida conforme um JSON Schema sem parâmetros opcionais”, mas sem ver a requisição real não dá para concluir

    • Isso não é bug de geração de schema nem do TypeScript, e sim um comportamento interno do function calling da OpenAI. Os pesos ajustados para uso de ferramentas tentam produzir estruturas de dados o mais completas possível. Quando o modelo vê nomes de parâmetros no contexto do system prompt, ele tende a preencher valores mesmo que não estejam no array required
    • Modelos de ponta mais recentes, incluindo Fable, Opus e 5.6, são bem soltos em chamadas de ferramenta e muitas vezes não seguem o schema com precisão. Um exemplo de modelos Claude inventando propriedades inexistentes em chamadas de ferramenta de edição/substituição do Pi pode ser visto em https://lucumr.pocoo.org/about/
      Parte da causa parece estar ligada ao fenômeno de queda de inteligência ao usar constraint decoding. A validade do schema é garantida, mas a capacidade cai bastante; então isso pode servir para classificação, sumarização e melhoria de prompt, mas em loops de agente é preciso cuidado
      Ambientes de execução como o Claude Code fazem muito pré-processamento, recuperação, limpeza etc., mas isso normalmente não aparece. Na prática, costuma ser mais fácil e melhor tornar o ambiente de execução mais flexível para se adaptar às características de cada modelo, em vez de presumir e impor precisão perfeita. Os modelos também mudam a cada um ou dois meses. É assim que se faz IA aplicada na base do feeling

  • Queria saber o valor aproximado do custo real para criar um site com Opus e com Sol, respectivamente

  • Ao migrar o workflow para o Reasonix e aproveitar cache hits no DeepSeek, o custo por requisição ficou praticamente próximo de zero, mesmo usando um provedor americano sem subsídio

    • Que configuração vocês usam e, comparando com o Pi, como fica?

  • Em vez de usar o GPT-5.6 Sol como padrão em todos os workspaces da Ploy, talvez valha considerar o Luna para parte das tarefas que realmente lidam com ferramentas. Ele é surpreendentemente competente e rápido
    O Sol é excelente para conversar com humanos e orquestrar chamadas de agentes, mas é caro demais para usar em tudo. Pelo preço de uma execução do Sol, dá para rodar o Luna cinco vezes, e a diferença estatística entre ter uma amostra e ter cinco é bem grande

    • Se cada etapa de uma execução do Luna estiver correta com probabilidade de 90%, então a chance de as cinco etapas estarem corretas é 0.9^5 = 0.59, ou seja, 59%. Talvez uma única execução do Sol tenha algo como 95% de acerto. Os números reais podem variar, mas pode sair mais barato validar no fim com o Sol
    • Sempre existe o problema de que os subagentes ficam isolados entre si. Isso tem a vantagem de manter o contexto pequeno e focado, mas, para continuar o trabalho atribuído, cada um precisa pesquisar de novo, então acabam consumindo tokens sem cache
      Dependendo de quantos agentes você usa em uma tarefa, o custo pode subir e o resultado pode até piorar