Veja o que sua equipe produziu na semana passada. Uma pequena parte foi a funcionalidade discutida na daily. A maior parte foi o entorno: triagem de bugs, etiquetas, um changelog, comentários de primeira análise em onze pull requests, estruturação de testes para um módulo que ninguém quer assumir, atualizações de dependências, uma página de documentação que ficou desatualizada quando o formato de uma resposta mudou. Alto volume, pouca glória e, até esta semana, custava o mesmo por token que o trabalho interessante, porque rodava no mesmo runtime.
A OpenAI lançou o GPT-6 Luna em 22 de setembro a US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de saída, com id de API gpt-6-luna e janela de contexto de 1M. Esse é o nível ao qual pertencem os 80% chatos. A pergunta útil não é se o Luna é bom, mas quais tarefas descem para lá, quais não podem descer e como escrever uma Task que um runtime barato consegue concluir.
TL;DR
Direcione o trabalho para o nível barato com base na verificabilidade, não na dificuldade. Se um resultado pode ser verificado sem refazê-lo, e uma resposta errada custa a um revisor um minuto em vez de uma tarde, ele pertence ao Luna. Mantenha no runtime caro as decisões de julgamento, qualquer coisa sobre a qual o board automatize e tudo aquilo que ninguém vai conferir. Escreva critérios de aceitação que uma máquina consiga avaliar, mantenha o esforço modesto para tarefas curtas, e deixe todo resultado voltar para a Task, onde uma pessoa o aceita.
Qual é o preço do Luna e com o que ele é comparado
As comparações publicadas pela OpenAI sobre o Luna consideram custo por tarefa, e não posições em rankings, o que é o enquadramento correto para este trabalho.
| Resultado publicado | Luna | Comparado com |
|---|---|---|
| DeepSWE 1.1 | 66,6% no esforço máximo | Comparável ao Claude Opus 5 e ao Fable 5 no médio, com 93% menos custo por tarefa que o Opus 5 e 96% menos que o Fable 5 |
| AutomationBench 1.0.6 | +5,4pp sobre seu antecessor no esforço alto | 58% menos custo por tarefa |
| OSWorld 2.0 offline | Supera o GPT-5.6 Sol no esforço médio | Cerca de um décimo do custo |
| Factualidade | Iguala o GPT-5.6 Sol no esforço mais alto | Cerca de um centésimo do custo |
Dois qualificadores acompanham esses números. A OpenAI descreve Sol e Luna como 50% mais baratos que o preço promocional do GPT-5.6. "Promocional" é escolha de palavra da OpenAI e importa: a linha de base é um desconto, não o preço de tabela. Em relação ao preço de tabela do GPT-5.6 Luna que nossa própria cobertura de lançamento documentou — US$ 1 por milhão de entrada e US$ 6 por milhão de saída —, a queda para US$ 0,10 e US$ 0,50 fica mais próxima de 90% na entrada e 92% na saída. A redução real é maior do que a manchete, e a manchete é medida contra uma promoção.
E toda comparação com a Anthropic nessa tabela é contra o Claude Opus 5. A Anthropic substituiu o Opus 5 pelo Opus 5.5 no mesmo dia em que a OpenAI publicou, a US$ 4 por milhão de entrada e US$ 20 por milhão de saída, contra os US$ 5 e US$ 25 do Opus 5. Leia essas margens como medidas em relação à geração anterior, porque foi isso que foram. Não afirmamos um vencedor entre os dois atuais carros-chefe, e nenhum dos fornecedores publicou esse confronto direto.
A Artificial Analysis, um terceiro e não nenhum dos fornecedores, coloca o Luna em 37 no seu índice de inteligência, contra 58 do Opus 5.5. O Luna não é um modelo de fronteira e não é vendido como tal. É um trabalhador competente com preço de utilitário, o que é exatamente o ponto.
A propriedade que decide o que desce
As equipes classificam o trabalho dos agentes por dificuldade. Esse é o eixo errado: a dificuldade é uma propriedade do problema, e sua exposição é uma propriedade do ciclo de revisão. Classifique por verificabilidade.
O trabalho pertence ao nível barato quando as duas condições são satisfeitas. O resultado pode ser verificado sem ser refeito, por um teste, um diff, uma regra de lint ou dez segundos de leitura. E um resultado errado custa a um revisor um minuto, não uma tarde, porque o raio de impacto é uma etiqueta, um comentário ou um arquivo.
Esse par é o motivo pelo qual a estruturação de testes se qualifica e uma revisão de segurança não, embora ambas sejam geração de texto sobre o mesmo repositório. Um teste gerado ou roda ou não roda, e você descobre isso no mesmo minuto. Uma brecha de autorização não detectada em um comentário de revisão parece exatamente igual a um comentário limpo.
O que passar adiante
| Tarefa | O que o Agent devolve | Como é verificado | Raio de impacto se estiver errado |
|---|---|---|---|
| Triagem de relatos de bug recebidos | Resumo, componente suspeito, tentativa de reprodução, sugestão de prioridade | Quatro linhas lidas ao pegar a Task | Uma Task mal encaminhada |
| Etiquetagem e metadados | Etiquetas e tipo de Task, nomeando a regra aplicada | Visível no board | Uma etiqueta errada |
| Changelog e notas de versão | Rascunho de notas a partir dos diffs mesclados de um Sprint | Diff contra os commits | Editorial, detectado antes do lançamento |
| Comentários de primeira análise de revisão | Observações como comentários, explicitamente não uma aprovação | O revisor lê ou ignora | Ruído, se nada depender disso |
| Estruturação de testes | Arquivos de teste que compilam e rodam, com lacunas óbvias sinalizadas | A execução dos testes | Build vermelho |
| Atualizações de dependências | Uma atualização por Task, com trecho do changelog e resultado dos testes | CI | Um revert |
| Acompanhamento de documentação após um merge | Edições na documentação citando o diff de origem | Revisão do diff | Uma página desatualizada continua desatualizada |
O formato unificador: cada um devolve um artefato que outra pessoa avalia em segundos, com base em evidências que o Agent anexou. Nenhum é a palavra final sobre nada, o que é o teste a aplicar quando você estender a lista para o que quer que sua equipe pegue em seguida.
O que não passar adiante
Vale explicitar três linhas divisórias, porque um nível barato convida a esses erros.
Primeira análise não é revisão. Um Agent que publica observações em um diff gera material de leitura. Não é uma aprovação, e no momento em que uma equipe trata uma primeira análise limpa como sinal de que uma mudança é segura, o nível barato foi promovido à decisão de aceitação. Seja preciso sobre o que um agente de revisão pode e não pode verificar, e rotule o comentário como primeira análise no próprio comentário.
Uma etiqueta sobre a qual o board automatiza é uma decisão, não uma nota. Se mover uma Task para um status dispara uma execução, ou se a prioridade determina o que a equipe pega em seguida, um Agent de etiquetagem está definindo a direção. Ou mantenha a automação fora desses campos, ou mantenha a etiquetagem no nível em que você confia a direção.
Trabalho que ninguém vai conferir não fica mais barato, fica invisível. Uma resposta errada barata só é barata quando alguém percebe. Se uma tarefa não tem leitor, a solução é excluir a tarefa, não adotar um runtime mais barato.
O par de decisão, então. Use o Luna quando o trabalho for de alto volume, delimitado e verificado por algo que não seja a confiança. Use o Sol ou o Opus 5.5 quando uma Task precisar manter contexto ao longo de horas, atravessar vários módulos, ou custar mais para parar no meio do que custariam os tokens. Se você roda um único Agent em um único repositório, não divida níveis de forma alguma: escolha o runtime que atende ao seu trabalho mais difícil.
Escrever uma Task que um runtime barato consegue concluir
Um Agent no Sharkly é uma configuração de trabalho salva, e não um prompt avulso. Suas instruções, Runtime, Skills, repositórios, ambiente e configurações de execução moldam como ele lida com o trabalho, então a unidade correta é um Agent por tipo de tarefa chata, e não um Agent esperto fazendo todas as sete. Uma equipe pode manter Agents separados para mudanças de código, revisão, testes, documentação ou triagem operacional sem reescrever instruções para cada Task.
Um runtime barato precisa de escopo estreito e uma linha de chegada mecânica:
SH-312 Triagem: 9 relatos de bug não atribuídos desta semana
Responsável: Triage Agent (Codex Runtime, gpt-6-luna)
Para cada relato, devolva na Task:
- reformulação em uma frase do comportamento observado
- o componente suspeito, com o arquivo ou módulo que levou até ele
- se você conseguiu reproduzi-lo localmente, e o comando exato que executou
- uma sugestão de prioridade com uma justificativa
Não altere arquivos. Não feche nem faça merge de nada.
Termine com qualquer pergunta que precise ser respondida antes da implementação.
Três coisas nessa Task fazem o trabalho. O escopo é uma passagem por nove itens, então uma falha é barata de descartar. Toda afirmação carrega sua evidência, então verificar é ler, e não reinvestigar. E as duas últimas linhas definem o limite: este Agent relata, não age.
Vale decidir uma configuração de propósito. As vitórias publicadas do Luna estão nos esforços de raciocínio alto e máximo, e o esforço é uma decisão de custo e latência, não um botão de qualidade que você deixa no topo. A Artificial Analysis, novamente um terceiro, mediu a variante de raciocínio máximo em 153,9 tokens de saída por segundo para o Luna, com cerca de 124 segundos até o primeiro token. [VERIFY] Qualquer que seja o número atual, o formato se mantém: no esforço máximo, os modelos baratos não são os que iniciam rápido. Uma tarefa de etiquetagem que pensa por dois minutos parece travada em um board. Execute tarefas curtas com esforço modesto e reserve as configurações altas para as Tasks que merecem.
Duas notas sobre acesso, já que é neste nível que as equipes fazem o onboarding. O Luna roda no Codex e no ChatGPT Work para os planos Plus, Pro, Business, Enterprise e Edu, e contas Free e Go o recebem no aplicativo de desktop. Ainda não está no Chat. No Sharkly, o modelo é definido na configuração do Runtime ou da ferramenta Computer, nunca no Agent, e o Sharkly não exibirá o nome do modelo de volta para você.
A parte que um corte de preço não resolve
Nove resumos de triagem a preços do Luna custam quase nada. Ainda assim, produzem nove coisas que uma pessoa precisa ler. Uma equipe que move todo o seu entorno para um nível barato não reduziu as decisões esperando por um humano, apenas tornou mais barato gerá-las, o que não é a mesma coisa que torná-las mais baratas de aceitar. É por isso que a fila de revisão continua sendo o teto, independentemente do que aconteça com a tarifa de tokens.
O que você pode mudar é quão legível essa fila é. Mantenha o objetivo, a execução, a evidência, os bloqueios e a revisão humana na Task, desde a solicitação até o lançamento, para que um comentário de primeira análise seja visivelmente uma primeira análise, um resumo de triagem carregue o comando que o produziu, e os itens realmente esperando por você sejam separáveis daqueles que são apenas ruído. Agentes pesquisam, executam, testam e relatam. Pessoas definem a direção, concedem autoridade e aceitam o resultado.
Se você roda vários agentes e os baratos estão prestes a se multiplicar, o Sharkly oferece um único lugar para atribuir suas Tasks, ver o que cada execução produziu e decidir o que será lançado. Conecte um Computer, crie um Agent para a sua tarefa mais chata e atribua a ele uma Task real.
