Equipes com modelos mistos: trabalhadores baratos, um revisor caro e o handoff entre eles

A tabela de preços de 2026-09-22 sugere um desenho óbvio. Coloque o GPT-6 Luna a US$ 0,10 por milhão de tokens de entrada no trabalho que ninguém quer fazer, coloque o Claude Opus 5.5 a US$ 4 no Agent que faz a checagem, e você mantém a maior parte da capacidade por uma fração da conta. Muitas equipes estão montando isso esta semana, e a maioria vai construir algo que parece revisão, mas não é.

A falha não está em nenhum dos dois modelos. Está no que atravessa a lacuna entre eles. Um revisor que lê o resumo que o worker faz do próprio trabalho está lendo uma alegação, e a única coisa que ele pode devolver é um julgamento sobre uma alegação. O diff passou, diz o worker. Parece bom, diz o revisor. Uma pessoa aprova porque dois modelos concordaram — que é o tipo de concordância menos informativo que existe.

Então a pergunta interessante em um Crew multimodelo não é qual modelo vai onde. É o que o handoff precisa carregar.

O que é um Crew multimodelo

Um Crew multimodelo é um grupo de Agents em que o Runtime é escolhido por função, e não por equipe, e em que pelo menos uma função existe apenas para verificar a saída das outras.

Um Agent revisor não é uma aprovação. É uma segunda opinião com custo, produzida antes que uma pessoa olhe, para que a pessoa leia uma lista mais curta. Os Agents pesquisam, executam, testam e reportam. As pessoas definem a direção, concedem autoridade e aceitam o resultado. Colocar um modelo caro no meio dessa frase não move a última oração.

Os três níveis, conforme publicados pelos fornecedores

A OpenAI descreve Sol e Luna como 50% mais baratos que o preço promocional do GPT-5.6, e "promocional" é uma palavra que fala por si: a linha de base já é um valor com desconto. A OpenAI também afirma que o GPT-6 Astra "continua sendo nosso melhor modelo em todos os aspectos".

Um alerta antes que alguém enxergue um ranking nesse recorte. O post de lançamento da OpenAI compara Sol e Luna com o Claude Opus 5, porque o Opus 5.5 não existia quando o texto foi escrito e chegou horas depois, custando 40% menos por execução que o Opus 5, segundo a própria Anthropic. Ninguém refez essa comparação, e os dois fornecedores não usam o mesmo harness. Escolha as funções pelo preço e pelo comportamento observado no seu próprio repositório.

O que cada fornecedor de fato diz sobre o próprio modelo já basta para atribuir funções. Sobre o Luna, a OpenAI relata 66,6% no DeepSWE 1.1 com esforço máximo de raciocínio, 93% mais barato por tarefa que o Claude Opus 5 e 96% mais barato que o Fable 5, além de, com esforço maior, um resultado de factualidade equivalente ao GPT-5.6 Sol por cerca de um centésimo do custo. É um modelo que você pode apontar para volume. Sobre o Opus 5.5, a Anthropic relata 66,4% no Terminal-Bench 4.0, 54,4% no FrontierCode v1.1, 81,8% no OSWorld 2.0, 128k de saída máxima e permanência na tarefa por 18 horas ou mais. É um modelo que você pode apontar para julgamento.

Ler é a metade barata de um modelo caro

O motivo pelo qual esse desenho sobrevive ao contato com uma fatura é o cache, e é a assimetria que decide o design.

A leitura de entrada em cache do Opus 5.5 custa US$ 0,20 por milhão. Isso é um vigésimo da sua própria tarifa de entrada sem cache e o dobro da tarifa sem cache do Luna. A saída dele custa US$ 20 por milhão, quarenta vezes os US$ 0,50 do Luna. Ou seja: um revisor que lê uma quantidade enorme e escreve vinte linhas sai quase de graça; um que narra longamente, não.

Isso dá uma regra com comprovante por trás: o revisor lê tudo e não diz quase nada. Entregue a ele o prefixo do repositório, as convenções, o diff e o pacote abaixo, e depois limite o que ele retorna.

O lado do worker também faz cache. O GPT-6 aumenta as taxas de acerto por padrão, com 90% de desconto nas leituras de entrada em cache, adiciona breakpoints explícitos para que você escolha onde termina um prefixo em cache e não invalida mais o cache quando você muda o esforço de raciocínio ou a disponibilidade de ferramentas. O GitHub relata mais de 50% menos tokens de prompt precisando de processamento novo em bilhões de requisições. Para uma frota de workers Luna relendo o mesmo repositório o dia inteiro, isso representa a maior parte da conta.

O que o handoff precisa carregar

Aqui está o artefato: um modelo de handoff feito para um leitor que é um modelo. O worker o devolve para a Task quando para, e o revisor lê apenas isso, mais o diff.

SH-312  Add retry with backoff to the webhook sender
Worker:   Agent "backend-worker" - Runtime Codex on gpt-6-luna
Attempts: 2 (attempt 1 failed on lint)
Diff:     4 files, +118 / -12   (worktree sh-312, commit a91f4c2)

Commands run, verbatim:
  $ pnpm lint            exit 0
  $ pnpm typecheck       exit 0
  $ pnpm test -- sender  exit 0   14 passed, 0 failed, 3 skipped
  $ pnpm build           exit 0

Not done:
  - The 3 skipped tests need a live webhook endpoint. Not run.
  - Did not touch the queue consumer, which has the same bug.

Assumptions made:
  - Max 5 retries, ceiling 30s. No spec said. Copied the values
    already used in payments/retry.ts.

Stopped because: acceptance criteria met.

Quatro propriedades fazem esse pacote valer os tokens que custa.

São artefatos, não narrativa. Comandos e códigos de saída podem ser executados de novo. "Verifiquei o comportamento" não pode ser checado por ninguém.

Ele declara o que não foi feito. Os testes ignorados e o consumer intocado são exatamente as duas coisas que um resumo teria deixado de fora, e são as duas de que um revisor mais precisa. Peça explicitamente pelas ausências, ou um resumo bem arrumado não vai incluí-las.

Ele registra as suposições. Toda Task delimitada contém uma decisão que a especificação não tomou. Registrada por escrito, ela é um item de revisão. Deixada de fora, é uma surpresa em produção um mês depois.

Ele nomeia um motivo de parada. Concluído, bloqueado, sem orçamento e falhou duas vezes parecem idênticos em um repositório e significam coisas diferentes em um quadro.

O que o revisor retorna

REVIEWER  Agent "review" - Runtime Claude Code on claude-opus-5-5
Reads:  repository prefix (cached), the packet, the full diff
Writes: at most 20 lines

VERDICT      changes requested
CHECKED      4 commands re-run, all exit 0. Backoff ceiling honoured.
UNVERIFIED   3 skipped tests. No evidence the retry path ever runs.
BLOCKING     Retry wraps the 4xx branch. A 422 will be retried 5 times.
FOR A PERSON Queue consumer has the same bug and is out of scope.
             Split SH-312, or widen it?

A linha UNVERIFIED é o que faz o revisor valer o preço. Um worker barato não vai dizer quais das suas alegações não se apoiam em nada — em parte porque ele mesmo não sabe. Um modelo caro lendo um pacote estruturado consegue separar o que confirmou do que aceitou por confiança, e essa separação é o produto da etapa de revisão. A linha FOR A PERSON é a outra metade: o revisor não decide escopo, ele devolve a pergunta para a Task.

A fronteira que mantém isso honesto: um Agent revisor pode reexecutar comandos, ler o diff e sinalizar a diferença entre evidência e afirmação. Ele não pode dizer se essa era a funcionalidade certa. O que um Agent de revisão pode e não pode verificar é uma lista fixa, e ela fica mais curta, não mais longa, quando o revisor é caro.

Dois modos de falha a observar

A latência é o primeiro, e é contraintuitivo. A Artificial Analysis, uma terceira parte, e não um dos fornecedores, mediu as variantes de raciocínio "max" em 124,23 segundos até o primeiro token para o Luna e 102,15 segundos para o Sol. [VERIFY] Confirme esses números na listagem atual antes de se apoiar neles. O desenho importa mais do que os dígitos: com esforço de raciocínio alto, os modelos baratos não são os que iniciam rápido, então um Crew multimodelo tem workers que parecem travados e um revisor esperando por eles. Isso é um problema de status, não um problema de modelo.

O volume de revisão é o segundo. Dez workers Luna produzem dez pacotes. Se o revisor aprova nove e escala um, você converteu dez execuções de agente em uma decisão humana, que é o objetivo. Se ele escala seis, você pagou pela revisão e ainda deve seis decisões — e a fila de revisão já era o gargalo. Acompanhe a taxa de escalonamento por worker Agent ao longo de um Sprint. Ela diz se o pacote está raso demais ou as Tasks grandes demais, muito antes de a fatura dizer.

Quando não fazer isso

Use um único modelo para tudo quando uma pessoa roda um ou dois Agents em um repositório. O pacote é custo extra, o revisor é uma segunda conta, e você é o revisor de qualquer forma.

Use um Crew multimodelo quando vários Agents rodam em paralelo, quando mais de uma pessoa pode iniciar uma execução, ou quando o trabalho concluído já ultrapassou o tempo que qualquer um tem para lê-lo.

E não coloque o modelo caro na revisão quando o trabalho em si é a parte difícil. Uma migração que precisa manter contexto por horas pertence ao Opus 5.5 diretamente, com um Agent barato escrevendo o pacote depois. Escolher por função significa escolher por Task, e não uma vez por equipe — por isso casar modelos com funções de agente é uma regra que se escreve, e não um hábito que seis pessoas guardam para si.

O número que não se moveu

O custo por tarefa concluída caiu bastante nos dois lados deste lançamento. A OpenAI relata que seu pesquisador mediano gasta mais de US$ 600 por dia com agentes de código, com o percentil 90 acima de US$ 7.000. Equipes abaixo dessa linha agora podem pagar por várias vezes mais trabalho de agente do que na semana passada.

As horas de revisor continuam exatamente onde estavam. Um Crew multimodelo se paga ao transformar mais saída barata em menos decisões humanas, e isso só acontece se o handoff carregar evidências em vez de um resumo. Mantenha o objetivo, o diff, os comandos, os bloqueios, as alegações não verificadas e a revisão humana retornando à Task, da solicitação à entrega, e a divisão de modelos se torna uma configuração que você pode mudar no próximo trimestre sem mudar a forma como qualquer pessoa trabalha.

A Sharkly não roda o modelo nem o escolhe por você. Ela é a camada compartilhada de Task, Computer, contexto e revisão em torno das ferramentas que fazem isso — que é onde um handoff precisa viver se um revisor e uma pessoa forem lê-lo. Se você já roda vários agentes de código: conecte um Computer, crie um worker Agent e um reviewer Agent, e faça o worker devolver esse pacote em alguma tarefa sem graça.