ATUALIZADO 08-SET-20266 provedores · 16 modelosPlano visível antes da execuçãoReserva em outra família por tipo de tarefaJuiz que reprova e refazCatálogo v5.0850 testes
Orquestrador multi-LLM em paralelo
Uma demanda em português vira um plano de tarefas com dependências, e cada tarefa vai ao modelo previsto para o tipo dela, com uma reserva de outra família pronta se o primeiro falhar.
O plano inteiro aparece na tela antes da primeira tarefa executar, com a rota e o motivo de cada escolha. O parque tem hoje 16 modelos configurados em 6 provedores, 23 tipos de tarefa roteados e 850 testes passando no master.
Juizabaixo de 60% reprova · refaz as 2 piores · entrega marcada, saída 3
Cache48 h acima de 80% · 24 h acima de 60% · nada abaixo
Teto de custo25 dólares por execução · 300 por dia · teto diário por provedor
Suíte de testes850 passando · 1 com falha esperada
O que o orquestrador decide quando uma demanda chega?
Ele decide quatro coisas, nesta ordem: em quantas tarefas a demanda se divide, qual modelo atende cada tarefa, o que fazer quando esse modelo falha e se o resultado merece ser entregue sem ressalva.
Imagine uma demanda de 40 palavras que pede uma pesquisa de mercado e um artigo a partir dela. O orquestrador divide o pedido em quatro tarefas: pesquisa, análise, redação e revisão. A pesquisa e a análise não dependem de nada e rodam juntas na primeira onda (onda: lote de tarefas que rodam ao mesmo tempo). A redação espera as duas; a revisão espera a redação. Cada tarefa recebe um tipo de tarefa (tipo de tarefa: a categoria do pedido, como pesquisa, redação ou código), e o tipo aponta para um modelo padrão com uma fila de reservas atrás dele (reserva: o modelo que assume quando o principal falha).
Se a pesquisa cai num provedor sem saldo, a chamada vai à reserva de outra família sem parar a onda. Se a redação sai fraca, um juiz (juiz: modelo de outra família que dá nota à resposta) reprova, e o sistema refaz a tarefa num modelo um degrau acima. A entrega sai de qualquer jeito, marcada quando o juiz reprovou, com um código de saída próprio para quem automatiza.
Painel executivo
O que está rodando hoje
Estado do sistema em 8 de setembro de 2026, depois da Sprint 30 (parque v5.0) e da verificação com crédito nas seis APIs. Os números vêm do manifest do repositório e o papel de cada modelo vem do catálogo v5.0.
Catálogo YAML v5.0, atualizado em 7 de setembro de 2026
Cada cartão traz o provedor, o modelo e o tipo de tarefa que ele atende primeiro; o teto ao lado (teto: a fatia máxima de um plano que um provedor pode receber) vale para a família inteira. Procure o modelo mais caro de cada família: ele só é padrão em arquitetura e revisão crítica, e desce um degrau nos outros tipos.
Anthropicteto 45%
Claude Fable 5.1
Architecture e critical_review na faixa frontier
Anthropicteto 45%
Claude Opus 5
Reserva do frontier em recusa e segunda vaga de copy
Anthropicteto 45%
Claude Sonnet 5
Reserva da decomposição, primário de review e code_review
Anthropicteto 45%
Claude Haiku 4.5
Degrau 4 do bulk e segunda vaga de summarization
OpenAIteto 50%
GPT-6 Astra
Frontier de outra família: code high e terceira vaga de architecture e critical_review
OpenAIteto 50%
GPT-5.5
Primário de copy e de translation
OpenAIteto 50%
GPT-5.6 Sol
Primário de code em low e medium, reforço técnico de outra família
OpenAIteto 50%
GPT-5.6 Luna
Degrau 2 do bulk curto e juiz barato
Googleteto 60%
Gemini 3.1 Pro (preview)
Decompositor da demanda, primário de analysis e de síntese longa
Googleteto 60%
Gemini 3.8 Flash
Bulk primário e juiz preferido, nunca da mesma família do produtor
Perplexityteto 50%
Agent API (preset high)
Primário de research e fact_check, com citações
Perplexityteto 50%
Agent API (preset low)
Primário de realtime_search e current_events; reserva de social e marca
xAIteto 35%
Grok 4.6
Social e marca, com busca viva na linha do tempo do X; segunda vaga da web viva
xAIteto 35%
Grok 4.20 Reasoning
Decomposição multi-perspectiva com raciocínio estendido
Groqteto 35%
gpt-oss-120b (Groq)
Degrau 3 do bulk e âncora barata do redirecionamento por custo
Groqteto 35%
Groq Compound
Terceira rota de web viva, de família distinta
O que mudou nas regras por último, e o que veio antes
08 set
Verificação do parque v5.0 com saldo nas seis contas, e três correções na PR #24
Com as três contas recarregadas, a verificação contra os seis provedores expôs três defeitos, corrigidos na PR #24: a parada antecipada pulava a redação final que dependia de tarefas já concluídas, o juiz cortava a própria nota antes de fechar o JSON, e a leitura de cache do Fable 5.1 era cobrada a 0,10 do preço quando a tabela diz 0,025.
07 set
Sprint 30 · Parque v5.0: GPT-6 Astra, Claude Fable 5.1, Gemini 3.8 Flash e Groq de volta (PR #23)
Reforma em cinco rodadas contra as APIs vivas: 16 apelidos em 6 provedores, preços corrigidos pela tabela oficial lida em 7 de setembro, OpenAI pela Responses API, Perplexity pela Agent API por padrão, Groq pela rota compatível com OpenAI e xAI com custo faturado. O Astra entra na terceira posição da fila de arquitetura e revisão crítica e sobe do Sol em código de complexidade alta; o trabalho curto em volume ganha Luna e Groq; o monitoramento passa a ter três rotas de web viva.
27 ago
Sprint 29 · Perplexity confiável: pesquisa profunda em série, sem retentativa de timeout, custo completo e âncora de data no juiz
Cinco defeitos com prova depois da rodada do menu Redes sociais: o estouro de tempo era aritmética da retentativa; várias pesquisas profundas em paralelo devolviam 429 e abriam o disjuntor; os locks nasciam no primeiro event loop e derrubavam as pesquisas em thread pool; o razão de custo ignorava a taxa por requisição; e o juiz, sem data de referência, tratava fato de 2026 como futuro.
23 ago
Sprint 28 · Pesquisa profunda da Perplexity sem resposta vazia (catálogo v4.6)
Demandas de pesquisa voltavam sem entregável com HTTP 200: o raciocínio consumia o teto de tokens e a resposta vinha vazia, e o cliente aceitava vazio como sucesso. Entraram um piso de tokens para modelos que raciocinam, um guarda de resposta vazia que cai para a fila de reservas, aviso de truncamento e custo lido do campo de uso da API.
27 ago
Wave Agosto 2026 · o orquestrador pesquisou o próprio estado da arte, e dois provedores mudaram de contrato
A pesquisa rodou em dez rodadas com quatro provedores e o contexto resultante foi distribuído a seis repositórios. No caminho, a API da xAI passou a devolver 410 na rota antiga de busca, e o apelido grok assumiu a dívida de migrar para a rota de respostas com as ferramentas de busca no X e na web. Pesquisa profunda em paralelo passou a ser vetada, com a pesquisa rápida em série como plano B.
O 3.7 Flash entrou em GA em 13 de agosto e assumiu o apelido gemini_flash no dia seguinte, em troca direta: mesmo contexto de 1M, mesmos métodos e mesmo preço de tabela, agora raciocinando por padrão. O catálogo registrou a tabela, e os candidatos grok-4.3 e gemini-3.1-flash-lite ficaram adiados até validação de qualidade.
jun-jul
Sprints 14 a 24 · Parque e qualidade
Onze sprints montaram o parque atual por evidência de bench e fecharam os laços de qualidade: faixa de topo, ida e volta da xAI, verificador em cascata entre ondas, painel de juízes de famílias distintas, roteador com janela de 50 amostras, timeout por requisição e juiz com consequência real.
abr-mai
Sprints 1 a 13 · Fundação
Pipeline em ondas sobre o grafo de dependências, roteamento por tipo de tarefa com filas de reserva, cache exato e semântico, governança de custo com limites diários, disjuntor por provedor e as duas diretrizes editoriais que seguem valendo.
A entrada mais recente é a verificação de 8 de setembro de 2026, sobre a Sprint 30, de 7 de setembro, com 850 testes passando no master.Histórico completo no GitHub
O que aparece na tela antes de a primeira chamada ser paga
O plano inteiro aparece antes de qualquer tarefa executar: a faixa da demanda, as ondas em ordem e, por tarefa, o modelo escolhido e o motivo da escolha. Os comandos de plano e de simulação imprimem o mesmo bloco e param ali; a única chamada paga até esse ponto é a decomposição.
A figura reproduz o relatório de planejamento de um plano hipotético. Procure a coluna de origem: ela diz se a rota veio da tabela do tipo de tarefa, da pré-alocação com teto por provedor ou do roteador adaptativo, e é a mesma informação que a execução repete quando abre cada tarefa.
O que o relatório de planejamento imprime
PLANO: demanda classificada como <SIMPLE | MODERATE | COMPLEX> (pontuação <n>)
Tarefas: 7 Ondas: 4 Resolvidas por código: <n> Do cache: <n>
[t1] research (medium) -> perplexity (sonar-deep-research (Agent API preset high)) [rota prevista do tipo]
[t2] research (medium) -> perplexity (sonar-deep-research (Agent API preset high)) [rota prevista do tipo]
[t3] analysis (high) -> gemini (gemini-3.1-pro-preview) [rota prevista do tipo]
[t4] classification (low) -> gemini_flash (gemini-3.8-flash) [pré-alocação com teto]
[t5] writing (high) -> gpt4o (gpt-5.5) [rota prevista do tipo]
[t6] fact_check (medium) -> perplexity (sonar-deep-research (Agent API preset high)) [roteador adaptativo]
[t7] review (medium) -> claude_sonnet (claude-sonnet-5) [rota prevista do tipo]
Onda 1: t1, t2
Onda 2: t3, t4 depende de: t1, t2
Onda 3: t5 depende de: t3, t4
Onda 4: t6, t7 depende de: t5
Custo estimado do plano: US$ <estimativa calibrada> Limite por execução: US$ <limite>
Teto de saída por tarefa: <n> por tipo de tarefa Famílias no plano: <n> de 6
Exemplo para o plano hipotético desta aba; onde o programa imprime um número medido, o exemplo mostra um marcador entre sinais de menor e maior. Cada linha de tarefa diz o id, o tipo, a complexidade, o apelido e o id do modelo, e entre colchetes a origem da decisão. As origens possíveis: rota prevista do tipo, pré-alocação com teto, roteador adaptativo; a quarta, resolvida por código, aparece quando a descrição casa com uma operação do gate code-first. Fonte: orchestrator.py:1131-1218.
Com que peças o sistema é feito
O sistema é Python com tipagem em todas as camadas e o mínimo de dependência externa: cliente HTTP assíncrono, SQLite para o registro de gasto e YAML para o catálogo de modelos. Cada peça abaixo responde por uma decisão descrita nas outras abas.
Python 3.12 + httpx async
Cliente HTTP unificado para os 6 provedores, sem SDKs oficiais: espera exponencial em 429, balde de tokens por provedor com locks por event loop, pool de conexões com encerramento real, tempo limite por requisição e escrita atômica dos arquivos de estado.
Um adaptador por provedor
OpenAI pela Responses API (reasoning.effort só no Astra), Anthropic concatenando todos os blocos de texto com reserva no servidor opcional, Perplexity pela Agent API com usage.cost prevalecendo, Groq pela rota compatível com OpenAI, xAI com custo faturado pela própria API. Cada rota nova tem variável de ambiente para voltar à anterior.
Pydantic v2
Modelos tipados de Task, Plan, TaskResult e ExecutionReport, com validação em tempo de execução e serialização JSON. O relatório de planejamento vive dentro do ExecutionReport, então auditar um run passado não exige reexecutar nada.
Click + Rich CLI
Tabelas, spinners, linha do tempo e saída FinOps estruturada. Os comandos plan e run --dry-run imprimem o relatório de planejamento completo sem gastar; models lista os 16 apelidos e models --verify compara o catálogo com os endpoints /models vivos sem custo de tokens.
Catálogo YAML como fonte única
O model_catalog.yaml é a fonte única em tempo de execução, com recarga por variável de ambiente. Versão v5.0 (07/09/2026): 6 provedores e 16 modelos documentados, com preço de tabela, teto de saída e capacidades por modelo. O validador compara id e preço com o config.py, e doctor --live acusa deriva contra a API viva.
stdlib http.server
Endpoints /health e /metrics sem dependência externa, pelo comando serve. Reporta a saúde dos 6 provedores, e quem estiver com o disjuntor aberto ou sem crédito aparece como degradado.
Chart.js no dashboard HTML
Dashboard estático auto-contido com 6 gráficos, cartões de KPI e a tabela dos 10 últimos runs. Roda em qualquer servidor estático, sem backend.
pytest + pytest-cov
850 testes no master 3c88f10 (8 de setembro de 2026), com a suíte local do Windows idêntica ao CI Linux. A suíte isola o saldo real dos provedores desde a Sprint 29, e a refatoração 5.1 pôs o ruff no CI.
Disjuntor por provedor
Três falhas consecutivas abrem o disjuntor por 90 segundos e as tarefas seguintes desviam de imediato pelo registro compartilhado; um sucesso fecha, uma falha reabre. Provedor sem crédito sai da rota por 30 minutos (GEO_OUTAGE_TTL). O estado é compartilhado entre as tarefas do mesmo run.
Observabilidade sempre ativa
Relatório de planejamento antes da primeira chamada, eventos [EXEC] e [OK] por tarefa no pipeline e [CALL] com resultado explícito no SDK avulso. Tudo em stderr, com opt-out por variável de ambiente, nunca opt-in.
Rastro DAAO em sombra
A decisão-sombra de roteamento é gravada em JSONL ao lado do apelido real, com a versão da política em cada linha, e um script agrega por célula com contagem, concordância e principais divergências. Só registro: nenhuma chamada de API.
GitHub Actions CI
Matriz Python 3.11 e 3.12, smoke do doctor, validador de catálogo, upload de cobertura, ruff, guarda de segredos como pre-commit, bandit, pip-audit e gitleaks.
Para quem avalia o orquestrador, o teste mais barato é rodar o comando de plano sobre uma demanda própria: ele mostra as rotas e os motivos pelo custo de uma decomposição. Para quem já usa, a marca do juiz na entrega é o sinal de conferir o texto antes de publicar; sem a marca, a entrega passou pela nota mínima de 60%.
Por onde uma demanda passa até virar entrega?
A demanda atravessa 13 fases, e só três delas pagam chamada de modelo: a decomposição em tarefas, a execução das tarefas e o julgamento. As demais são código que lê, compara e decide sem rede.
Antes de qualquer chamada, um refinador sem modelo lê a demanda e estima a complexidade de 1 a 10 pela contagem de palavras: menos de 15 palavras partem de 2, menos de 50 partem de 4, 50 ou mais partem de 6, com um ponto a mais por sinal de várias etapas, por várias entidades citadas e por pedido que junta pesquisa e criação. A decomposição em tarefas vai ao modelo padrão dessa fase, o Gemini; se a rede falha, uma única tentativa vai a outra família; se o JSON vem quebrado, um reparo em quatro passos tenta salvar as tarefas inteiras e, se ainda assim não há plano, o processo sai com código 4 sem ter executado nada.
Com o plano em mãos, o classificador soma pontos: palavras da demanda, número de tarefas e domínios distintos. Até 2 pontos a demanda é simples e usa no máximo 2 modelos; até 5 é moderada, com 3; acima disso é complexa, com 5. Cada tarefa recebe uma complexidade própria (baixa, média ou alta) pelo tipo, pelas palavras-chave e pelo comprimento da descrição: até 180 caracteres desce um degrau, 600 ou mais sobe um, e três ou mais dependências sobem outro.
Ainda sem executar tarefa nenhuma, o sistema resolve por código o que dispensa modelo (contar palavras, validar JSON, extrair URLs), funde tarefas do mesmo tipo com mais de 70% de palavras em comum, e consulta o cache: primeiro por semelhança (cosseno acima de 0,85 entre descrições do mesmo tipo), depois por igualdade exata com 24 horas de validade. Redação e pesquisa só aceitam cache exato, porque briefings parecidos de públicos diferentes não podem trocar de resposta. Se a estimativa de custo do que sobrou passa de 25 dólares, a execução aborta antes da primeira chamada.
A figura mostra as fases em ordem e os pontos em que a demanda pode desviar. Procure os desvios: cada um é uma pergunta com duas saídas, e a resposta decide se a demanda segue, volta uma fase ou para com código de saída próprio.
As 43 bifurcações, em seis etapas
Cada painel é uma etapa da execução, na ordem em que o código decide. Leia cada bifurcação de cima para baixo: a pergunta, o que acontece no sim e no não, e para onde cada ramo segue. O limiar que decide a pergunta aparece sob ela; a fonte no repositório do orquestrador aparece ao passar o cursor e na lista abaixo da figura.
1. Modo de simulação
Pergunta:
O operador pediu o run em modo de simulação (--dry-run)?
Sim:
Só a decomposição roda e o relatório de planejamento é impresso e salvo. Nenhum modelo de execução é chamado. Destino: Refinador de prompt, sem modelo.
Não:
O run completo começa: refinamento, decomposição, planejamento, cache, orçamento, ondas e juiz. Destino: Refinador de prompt, sem modelo.
Fonte:
cli.py:493-521
2. Refinador de prompt, sem modelo
Pergunta:
A demanda traz dois ou mais marcadores de português?
Sim:
O refinador marca o idioma como pt-BR e segue com intenção, entidades, formato pedido e uma estimativa de complexidade de 1 a 10. Zero chamadas de API. Destino: Planejamento: Decomposição: falha de transporte.
Não:
O idioma fica como inglês; o restante do refinamento é o mesmo. O texto refinado vai só para a decomposição; o relatório e o juiz veem a demanda original. Destino: Planejamento: Decomposição: falha de transporte.
Limiar:
2 marcadores de pt-BR; complexidade 2/4/6 por menos de 15, menos de 50 ou 50 ou mais palavras
A primeira chamada de decomposição (Gemini 3.1 Pro) falhou por rede, erro HTTP ou disjuntor aberto?
Sim:
Uma única repetição em outra família: Sonnet 5. Se ela também falha, a exceção sobe e o run termina com código 1. Destino: Decomposição: plano legível.
Não:
A resposta chega e vai para a leitura do plano. Destino: Decomposição: plano legível.
Limiar:
1 repetição; tempo limite de 300 segundos vezes o multiplicador global; teto de 24.000 tokens na resposta
Fonte:
orchestrator.py:329-333, :379-423, :1612
2. Decomposição: plano legível
Pergunta:
O JSON do plano ficou legível depois da cascata de reparo (tirar cercas, fatiar entre chaves, fechar truncamento)?
Sim:
O plano é aceito. Tipo de tarefa fora dos 23 configurados vira writing; o teto de tokens sugerido por tarefa é honrado. Destino: Classe da demanda: SIMPLE.
Não:
Uma repetição com a configuração alternativa. Se colapsar de novo, o evento vai ao histórico de qualidade e o run termina com código 4, sem executar nada. Destino: Fim: código de saída 4, depois da repetição.
A pontuação da demanda (tamanho, número de tarefas, domínios distintos, sinal premium) ficou em 2,0 ou menos?
Sim:
Demanda SIMPLE: até 2 modelos participam e o roteamento segue a rota prevista de cada tipo de tarefa. Destino: Complexidade por tarefa, camada 1: padrão do tipo.
Não:
A pontuação passa para a pergunta seguinte, entre MODERATE e COMPLEX. Destino: Classe da demanda: MODERATE ou COMPLEX.
Demanda MODERATE: até 3 modelos; se o primário do tipo tem taxa de sucesso abaixo de 70% na janela recente e a reserva está usável, a reserva assume. Destino: Complexidade por tarefa, camada 1: padrão do tipo.
Não:
Demanda COMPLEX: até 5 modelos, garantia de 4 famílias distintas e piso de qualidade (Haiku sobe para Sonnet 5). Destino: Complexidade por tarefa, camada 1: padrão do tipo.
Limiar:
5,0 pontos; primário abaixo de 0,70 de sucesso cede à reserva em MODERATE
Complexidade inicial MEDIUM, inclusive para code, review e architecture. Destino: Complexidade, camada 2: palavras-chave.
Fonte:
orchestrator.py:1652-1684
6. Complexidade, camada 2: palavras-chave
Pergunta:
A descrição tem palavra-chave de alta complexidade sem nenhuma de baixa (ou o inverso)?
Sim:
Só alta: vira HIGH. Só baixa: vira LOW. Destino: Complexidade, camada 3: tamanho da descrição.
Não:
Ambas ou nenhuma: a complexidade da camada anterior fica. Destino: Complexidade, camada 3: tamanho da descrição.
Fonte:
orchestrator.py:1636-1646, :1687-1692
7. Complexidade, camada 3: tamanho da descrição
Pergunta:
A descrição tem 180 caracteres ou menos?
Sim:
HIGH desce para MEDIUM (nunca direto para LOW); MEDIUM desce para LOW só nos tipos de baixa complexidade. Destino: Complexidade, camada 4: dependências.
Não:
Com 600 caracteres ou mais, sobe um degrau: LOW vira MEDIUM, MEDIUM vira HIGH. Entre 181 e 599, nada muda. Destino: Complexidade, camada 4: dependências.
Limiar:
180 e 600 caracteres
Fonte:
orchestrator.py:1649-1650, :1696-1706
8. Complexidade, camada 4: dependências
Pergunta:
A tarefa depende de 3 ou mais tarefas?
Sim:
Sobe um degrau: LOW vira MEDIUM, MEDIUM vira HIGH. Integrar muitas saídas é trabalho de modelo maior. Destino: Gate code-first: resolve sem modelo.
Não:
A complexidade fica como está. Destino: Gate code-first: resolve sem modelo.
Limiar:
3 dependências
Fonte:
orchestrator.py:1709-1713
9. Gate code-first: resolve sem modelo
Pergunta:
A descrição casa com uma operação resolvida por código (contar palavras, extrair links, validar JSON, detectar idioma, formatar lista, extrair entidades, calcular, mesclar textos)?
Sim:
A tarefa é concluída na hora, com custo zero e sem chamada de API, e sai da fila de execução. Destino: Deduplicação.
Não:
A tarefa segue para um modelo. Destino: Deduplicação.
Fonte:
code_executor.py:271-347; orchestrator.py:530-550
10. Deduplicação
Pergunta:
Duas tarefas do mesmo tipo têm mais de 70% de palavras em comum (cosseno aproximado sobre conjuntos de palavras)?
Sim:
A segunda é absorvida pela primeira; a descrição ganha a marca da mesclagem e todas as dependências que apontavam para ela são reescritas. Destino: Equilíbrio de famílias.
Não:
As duas ficam. Destino: Equilíbrio de famílias.
Limiar:
0,70
Fonte:
orchestrator.py:1848-1897
11. Equilíbrio de famílias
Pergunta:
O plano tem 3 ou mais tarefas e alguma das quatro famílias base (Anthropic, OpenAI, Google, Perplexity) ficou sem tarefa?
Sim:
O orquestrador injeta uma tarefa do tipo previsto para a família ausente (research, summarization, writing ou review), desde que a rota prevista daquele tipo ainda aponte para ela. xAI e Groq ficam de fora dessa injeção. Destino: Pré-alocação com teto de participação.
Não:
Segue. Concentração acima de 30% numa família só gera aviso, sem ação. Destino: Pré-alocação com teto de participação.
Limiar:
3 tarefas; aviso acima de 0,30
Fonte:
orchestrator.py:1728-1842
12. Pré-alocação com teto de participação
Pergunta:
Depois do roteamento inicial, alguma família passou do teto de participação (Anthropic 45%, OpenAI 50%, Google 60%, Perplexity 50%, xAI 35%, Groq 35%)?
Sim:
A tarefa de menor complexidade daquela família migra para a primeira vaga usável da fila que pertença a outra família abaixo do teto. architecture e critical_review têm pino e nunca saem primeiro. Se nenhuma troca cabe, a distribuição fora do teto é mantida com aviso. Destino: Garantia de diversidade.
Não:
A pré-alocação fecha e é registrada por tarefa. Destino: Garantia de diversidade.
Limiar:
0,45 / 0,50 / 0,60 / 0,50 / 0,35 / 0,35; até 2 vezes o tamanho do plano em iterações
Fonte:
smart_router.py:866-997; config.py:1523
13. Garantia de diversidade
Pergunta:
A demanda é COMPLEX, tem 5 ou mais tarefas e conta menos de 4 famílias distintas?
Sim:
Para cada família ausente, no máximo uma tarefa é promovida ao modelo indicado para ela, se usável. Todos os registros de uso da sessão são zerados depois, porque o rebalanceamento contou atribuições fantasma. Destino: Relatório de planejamento.
Não:
Diversidade OK: o plano fica intocado. Destino: Relatório de planejamento.
O relatório sai no terminal e é persistido no relatório final: classe da demanda, ondas em ordem e, por tarefa, apelido, modelo e origem da decisão. Destino: Cache e orçamento: Cache semântico.
Não:
O mesmo relatório sai do mesmo jeito. Ele é emitido sempre, antes da primeira chamada de execução; até aqui só a decomposição foi paga. Destino: Cache e orçamento: Cache semântico.
Fonte:
orchestrator.py:595-600, :1131-1218
1. Cache semântico
Pergunta:
Existe uma entrada viva do mesmo tipo com similaridade de texto (TF-IDF com cosseno) de 0,85 ou mais, e o tipo aceita similaridade?
Sim:
A tarefa recebe o resultado guardado, com custo zero. Destino: Anel 1: orçamento por run.
Não:
Copy, research e fact_check aceitam só correspondência exata. Sem hit, a tarefa vai ao cache exato. Destino: Cache exato.
Alguma tarefa ficou fora do cache e do gate code-first?
Sim:
O pipeline é construído com os resultados do cache pré-carregados. Destino: Ondas por dependência.
Não:
Nenhum pipeline é construído: os resultados são os do cache e o run pula direto para o juiz. Destino: Qualidade: Juiz único ou painel.
Fonte:
orchestrator.py:650-676
2. Ondas por dependência
Pergunta:
Há tarefa restante cujas dependências nunca se completam (ciclo ou dependência quebrada)?
Sim:
Tudo o que restou vai para uma onda final e falha de forma controlada, com registro no log. Destino: Segregação do Google.
Não:
Cada onda reúne as tarefas cujas dependências já foram concluídas; as tarefas de uma onda rodam em paralelo. Destino: Segregação do Google.
Fonte:
pipeline.py:548-577
3. Segregação do Google
Pergunta:
A tarefa da onda vai para um modelo do Google?
Sim:
Roda em série com as outras do Google na mesma onda, com o intervalo mínimo do limitador de requisições entre elas. Destino: Escolha do modelo na fila.
Não:
Roda em paralelo com as demais da onda. Um ponto de retomada é salvo antes de cada onda. Destino: Escolha do modelo na fila.
Fonte:
pipeline.py:405-433, :981-1003
4. Escolha do modelo na fila
Pergunta:
É a primeira tentativa desta tarefa?
Sim:
Honra a pré-alocação se o modelo está usável; senão aplica, nesta ordem, o teto de concentração de 90%, a escada Claude, a escada OpenAI e a opção de forçar cinco modelos, e registra o uso na sessão. Destino: Fila de reservas esgotada?.
Não:
Pega o próximo usável da fila que ainda não foi tentado, sem teto, sem escadas e sem registrar uso de novo: é continuação da mesma tarefa. Destino: Fila de reservas esgotada?.
Limiar:
teto de concentração 0,90 só com 5 ou mais tarefas na sessão
Fonte:
router.py:1088-1136, :726, :911-946
5. Fila de reservas esgotada?
Pergunta:
Ainda há na fila algum modelo usável que não foi tentado?
Sim:
O modelo é chamado. Destino: Anel 3: teto do provedor por chamada.
Não:
A tarefa termina falha com a mensagem de que nenhum modelo está disponível na fila e vai ao gate de replanejamento. Destino: Replanejamento de subárvore.
Fonte:
router.py:1101-1104; pipeline.py:2046-2055
6. Anel 3: teto do provedor por chamada
Pergunta:
O provedor escolhido está em 95% do teto diário (ou o gasto global do dia em 95% de US$ 300)?
Sim:
Redireciona para o modelo mais barato disponível, respeitando o teto de participação quando possível. Se o alvo também estourou, a tarefa recebe resultado falho e a fila avança. Destino: A chamada devolveu texto?.
Não:
A chamada acontece, com tempo limite e teto de tokens do tipo de tarefa. Destino: A chamada devolveu texto?.
A chamada terminou com sucesso e com texto na resposta?
Sim:
O sucesso de transporte é registrado para o roteador adaptativo e a saída vai aos gates de conteúdo. Destino: Verificação de código.
Não:
A falha é registrada, o log mostra [FAIL] e a fila avança para o próximo modelo. Recusa do classificador, resposta vazia e teto de tokens sem texto contam como falha. Destino: volta a Escolha do modelo na fila.
Fonte:
pipeline.py:1937-2043; llm_client.py:1025-1044
8. Verificação de código
Pergunta:
O tipo é code e a saída falhou na análise sintática executada localmente?
Sim:
O mesmo modelo recebe o erro literal e corrige, até 2 vezes por tarefa e 6 por run. Se desiste, a saída fica marcada como degradada, nunca como falha. Destino: Gate heurístico por tipo.
Não:
Segue ao gate heurístico. Destino: Gate heurístico por tipo.
Limiar:
2 correções por tarefa; 6 por run
Fonte:
pipeline.py:1583, :1973-1976; config.py:895-902
9. Gate heurístico por tipo
Pergunta:
A saída passou no gate do tipo (writing: 200 caracteres e sem duas seções vazias; code: chaves equilibradas e sem TODO; research: fonte ou link citado)?
Sim:
Resultado aceito. Se houve mais de uma tentativa, conta como salvamento pela reserva. Destino: Qualidade: Cascata entre ondas: elegível?.
Não:
O evento vai ao histórico de qualidade com nota zero, sem punir o modelo no roteamento (falso positivo sintático). A saída fica guardada como melhor até agora e a fila avança. Destino: volta a Escolha do modelo na fila.
Limiar:
200 caracteres; desequilíbrio de chaves acima de 20%
Fonte:
pipeline.py:700-791, :1979-2019
10. Veto à parada antecipada
Pergunta:
Alguma tarefa pendente depende de uma tarefa já concluída com sucesso?
Sim:
A parada antecipada nem é consultada: o run segue para a próxima onda. Cobertura de palavras da demanda não mede consolidação. Destino: volta a Ondas por dependência.
Não:
A parada antecipada é consultada. Destino: Parada antecipada.
Fonte:
pipeline.py:464-493, :535
11. Parada antecipada
Pergunta:
Restam mais de 2 tarefas e mais de 80% das palavras-chave da demanda já aparecem nas saídas concluídas?
Sim:
O laço de ondas encerra: as tarefas restantes não rodam. Destino: Qualidade: Juiz único ou painel.
Não:
Próxima onda. Com 2 tarefas ou menos, o run só termina o que falta. Destino: volta a Ondas por dependência.
Limiar:
0,80 de cobertura; 2 tarefas
Fonte:
smart_router.py:1185-1254
12. Replanejamento de subárvore
Pergunta:
A tarefa esgotou a fila, o replanejamento ainda não foi usado neste run, e há tarefas pendentes que dependem dela?
Sim:
O uso é contado antes da chamada. Um modelo propõe uma tarefa substituta, que muda de conteúdo sob o mesmo id e roda pelo caminho real (fila, gates, orçamento). Sucesso sai sempre marcado como degradado; falha restaura a original. Destino: volta a Veto à parada antecipada.
Não:
A falha fica. Cada tarefa que dependia dela recebe um bloco de lacuna no prompt: a saída não existe e não deve ser inventada. Destino: volta a Veto à parada antecipada.
Limiar:
1 replanejamento por run (REPLAN_MAX)
Fonte:
pipeline.py:1748-1869, :815-833; config.py:940
1. Cascata entre ondas: elegível?
Pergunta:
Ao fim da onda, a saída veio de um modelo econômico (Flash, Haiku, Luna, Groq), tem 80 caracteres ou mais e alimenta a onda seguinte?
Sim:
Um verificador de outra família dá nota de 0 a 10 à saída, com o mesmo verificador fixado para a re-pontuação. Destino: Cascata: nota mínima.
Não:
Sem verificação: a saída segue como está. Destino: Execução: Veto à parada antecipada.
Limiar:
80 caracteres; 3 escalações por run
Fonte:
pipeline.py:1399-1436; config.py:744-746
2. Cascata: nota mínima
Pergunta:
A nota do verificador é 6,0 ou mais?
Sim:
Aprovada. A nota alimenta o canal de qualidade do roteador, sem tocar o canal de transporte. Destino: Execução: Veto à parada antecipada.
Não:
Escala uma vez para o primeiro modelo não econômico usável da fila e re-pontua. Se ainda ficar abaixo de 6,0, fica a melhor das duas saídas, marcada como degradada. Nunca escala de novo. Destino: Execução: Veto à parada antecipada.
Limiar:
6,0 (CASCADE_MIN_SCORE)
Fonte:
pipeline.py:1438-1538, :1238; config.py:741
3. Juiz único ou painel
Pergunta:
O plano tem writing, copywriting, seo, architecture ou critical_review?
Sim:
Painel 2 de 3: até 3 juízes de famílias distintas, excluindo a família que produziu o texto, com mediana por dimensão e veredito mediano. Com menos de 2 juízes ou menos de 2 notas válidas, degrada para juiz único. Destino: Falha técnica do juiz.
Não:
Juiz único: o primeiro da lista de preferência (Gemini Flash, Haiku, Luna, GPT-5.5, Groq) que esteja usável e não seja da família do produtor. Destino: Falha técnica do juiz.
Limiar:
2 de 3 votos; consolidado truncado em 4.000 caracteres
O juiz lançou exceção ou devolveu JSON ilegível mesmo depois do resgate de resposta truncada?
Sim:
Uma repetição em outra família, com nome e família diferentes do juiz que falhou e da família do produtor. Se falhar de novo, REPROVADO_TECNICO: todas as notas zero e nada vai ao cache. Destino: Veredito consolidado.
Não:
As cinco notas de 0 a 10 somam até 50 e viram percentual. Destino: Veredito consolidado.
Limiar:
1 repetição; teto de 4.000 tokens na resposta do juiz
Fonte:
quality_judge.py:99-122, :227-297, :314, :392
5. Veredito consolidado
Pergunta:
O percentual ficou em 80% ou mais?
Sim:
APROVADO. Destino: Amostra estratificada de tarefas.
Não:
De 60% a 79%, APROVADO_COM_RESSALVAS. Abaixo de 60%, REPROVADO, com as críticas registradas para a re-execução. Destino: Amostra estratificada de tarefas.
Limiar:
80% e 60%
Fonte:
quality_judge.py:299-306, :411-434
6. Amostra estratificada de tarefas
Pergunta:
Há resultados novos (fora do cache) para julgar um a um?
Sim:
Até 2 piores notas da cascata, até 3 tarefas premium ou frontier e 1 aleatória reproduzível pela semente do id do run, com teto de 6, cada uma julgada por juiz único. Destino: Agregação do veredito do run.
Não:
Sem amostra: o veredito consolidado decide sozinho. Destino: Saída: O que vai ao cache.
Na amostra, alguma tarefa premium ou frontier reprovou, ou metade ou mais das tarefas julgadas reprovou?
Sim:
A amostra vale REPROVADO. Destino: Re-execução dirigida.
Não:
Alguma reprovada vale APROVADO_COM_RESSALVAS; nenhuma, e o consolidado vale. O veredito do run é o pior entre o consolidado e a amostra. Tarefas com falha técnica do juiz não votam. Destino: Re-execução dirigida.
Limiar:
1 premium reprovada ou 50% da amostra
Fonte:
orchestrator.py:1374-1421
8. Re-execução dirigida
Pergunta:
O veredito do run é REPROVADO e a re-execução ainda não rodou?
Sim:
As 2 piores tarefas (reprovadas primeiro, depois menores percentuais) sobem um degrau ou trocam de família, com as críticas sanitizadas no prompt e sub-orçamento próprio. Cada uma substitui a original só se a nova nota for maior. Se algo foi substituído, a amostra re-julgada decide sozinha. Uma rodada por run. Destino: Saída: O que vai ao cache.
Não:
Segue ao cache com o veredito atual. Destino: Saída: O que vai ao cache.
Validade de 48 horas no cache exato e no semântico. Ficam de fora, mesmo assim, as tarefas reprovadas na amostra, as degradadas e as construídas sobre lacuna. Destino: Código de saída: tarefa falha.
Não:
De 60% a 79%, validade de 24 horas com as mesmas exclusões. REPROVADO ou REPROVADO_TECNICO: validade zero, nada é gravado por nenhum dos dois caches. Destino: Código de saída: tarefa falha.
Limiar:
48 h, 24 h ou 0
Fonte:
orchestrator.py:910-970; quality_judge.py:603
2. Código de saída: tarefa falha
Pergunta:
Alguma tarefa terminou falha?
Sim:
Código de saída 1. O relatório é gravado com o que foi entregue. Destino: Fim: código de saída 1.
Não:
Segue à pergunta de qualidade. Destino: Código de saída: sinal de qualidade.
Fonte:
cli.py:537-539
3. Código de saída: sinal de qualidade
Pergunta:
O sinal de qualidade do run é REPROVADO ou REPROVADO_TECNICO?
Sim:
Código de saída 3: o entregável sai, marcado. Nunca é segurado. Destino: Fim: código de saída 3.
Não:
Código de saída 0. O vigia de gasto roda depois e compara o dia com a mediana dos 14 anteriores. Destino: Fim: código de saída 0.
Fonte:
cli.py:544-553, :419; spend_watch.py:128
Losango é pergunta; caixa verde é o ramo sim e caixa âmbar é o ramo não; a pílula cinza de cantos redondos é fim de fluxo com código de saída; a caixa de borda roxa é volta a um nó anterior, que é como os laços de ondas e de retentativa aparecem sem ciclo desenhado.
Entre a escolha do modelo e a rede há um adaptador por provedor, e cada um faz uma coisa diferente. Procure na figura o que muda de coluna para coluna: a Anthropic recebe o prompt em dois blocos para reaproveitar o cache, a Google tem uma reserva interna (o Flash da mesma família) quando responde 503, a Perplexity e a Groq cobram taxa por busca além dos tokens, e a xAI devolve o custo faturado em vez de estimado.
Uma chamada, quatro barreiras, seis adaptadores
As quatro barreiras ficam entre a escolha do modelo e a rede. A queda e o disjuntor tiram o provedor da rota e a fila avança em milissegundos; o limitador segura a chamada até abrir vaga, então saturar requisições por minuto nunca abre o disjuntor. A barra colorida em cada adaptador é a cor do provedor, sem outro significado.
Anthropic
Messages API. 60 requisições por minuto, rajada 3.
O que faz de diferente
Único que recebe o prompt de sistema em dois blocos: a base estável com marca de cache e o sufixo dinâmico fora dela, para o prefixo cacheado ficar idêntico entre tarefas.
Envia o nível de esforço (quanto raciocínio gastar) só para os modelos com raciocínio por padrão e sob a chave GEO_CLAUDE5_EFFORT.
Recusa do classificador de segurança e teto de tokens sem bloco de texto viram falha, com reserva opcional no próprio servidor dentro da família.
Piso de caracteres para ligar o cache varia por modelo (512 tokens no Fable e Opus 5; 1024 no Sonnet 5; modelo desconhecido usa 4096 por segurança).
Cache e contexto longo: Escrita de cache custa 1,25x o preço de entrada (5 minutos) ou 2,0x (1 hora). Leitura de cache custa 0,10x o preço de entrada na família e 0,025x no Fable 5.1.
Responses API (POST /v1/responses), com Chat Completions como rota de retorno. 90 requisições por minuto, rajada 5.
O que faz de diferente
Envia o nível de esforço só para os modelos de raciocínio configurados (Astra), como reasoning.effort.
Nunca envia temperatura nem top_p; usa instructions, max_output_tokens e store=false.
Prompt de sistema e sufixo vão concatenados na ordem estável para dinâmico, o que ainda favorece o cache implícito do provedor.
Cache e contexto longo: Entrada em cache é cobrada à parte, com preço por modelo. Acima de 272 mil tokens no prompt, o preço aplica o multiplicador de contexto longo: 2x na entrada e 1,5x na saída.
llm_client.py:140-177, :1117-1163, :1213
Google
generateContent. 60 requisições por minuto, rajada 5.
O que faz de diferente
Em erro 503 no modelo principal, tenta o modelo de reserva da mesma família (3.8 Flash) antes de devolver a falha à fila.
Tarefas do Google numa mesma onda rodam em série, com o intervalo mínimo do limitador entre elas.
O raciocínio do Flash é cobrado como saída e somado ao custo.
Cache e contexto longo: Preço fixo por modelo na tabela do cliente; não há faixa por tamanho de contexto.
Chat Completions e Responses (Agent Tools API com x_search e web_search). 60 requisições por minuto, rajada 3.
O que faz de diferente
Duas rotas; a busca viva na linha do tempo do X vai pela Responses.
O custo faturado vem na própria resposta em unidades de dez bilionésimos de dólar; sem essa informação, o cliente calcula por token.
Cobrança fora do preço por fragmento: Busca viva é cobrada pelo próprio provedor dentro do custo faturado.
llm_client.py:221-224, :1781-1909, :2042
Groq
Chat Completions compatível com OpenAI. 30 requisições por minuto, rajada 3.
O que faz de diferente
Envia reasoning_effort por tipo de tarefa, com low como padrão quando o tipo não vem.
O Groq Compound executa busca web e código como ferramentas, contadas no cliente pelas ferramentas executadas.
Cobrança fora do preço por fragmento: US$ 0,005 por busca executada (search, web_search, browser_search).
llm_client.py:201-202, :1964-2002
Dois laços corrigem o rumo durante a execução: um verificador barato entre as ondas e o juiz no fim. Procure na figura onde cada laço pode trocar o modelo da tarefa (nota abaixo de 6 em 10 no verificador; reprovação do juiz) e onde ele só marca o resultado sem trocar nada (segunda reprovação do mesmo texto).
Os 12 estados de uma saída e as 21 setas entre eles
A pílula cinza é o estado inicial, uma saída com sucesso de transporte; a pílula azul é o único estado final, e as três caixas ao lado dele são os desfechos possíveis. Setas roxas tracejadas voltam a um estado anterior: são os laços de retentativa, escalada e re-execução, cada um com limite escrito na condição.
Saída produzida para Gate heurístico: sempre (verificação de código antes, se o tipo é code). pipeline.py:1973-1979
Gate heurístico para Aceita na onda: passou no gate do tipo. pipeline.py:1981-1990
Gate heurístico para Próximo da fila: reprovou: evento com nota zero no histórico, sem punir o modelo. pipeline.py:1994-2019
Próximo da fila para Saída produzida: outro modelo usável devolveu texto. pipeline.py:1909-1937
Próximo da fila para Aceita na onda: fila esgotada: a melhor saída guardada é entregue. pipeline.py:2046-2063
Aceita na onda para Cascata entre ondas: modelo econômico, 80 caracteres ou mais, com dependentes na onda seguinte, menos de 3 escalações no run. pipeline.py:1416-1427
Aceita na onda para Juiz ou painel: última onda concluída ou parada antecipada sem veto. orchestrator.py:691-717
Cascata entre ondas para Aceita na onda: nota 6,0 ou mais. pipeline.py:1448-1450
Cascata entre ondas para Escalada: nota abaixo de 6,0 e existe alvo não econômico usável. pipeline.py:1451-1468
Cascata entre ondas para Degradada: verificador indisponível ou sem alvo de escalada. pipeline.py:1438-1460
Escalada para Aceita na onda: re-pontuação 6,0 ou mais: a nova saída substitui. pipeline.py:1529-1538
Escalada para Degradada: segunda reprovação: fica a melhor das duas, sem nova escalada; ou a escalada falhou. pipeline.py:1469-1528
Degradada para Juiz ou painel: última onda concluída. orchestrator.py:691
Juiz ou painel para Juiz ou painel: falha técnica: uma repetição em outra família. quality_judge.py:314
Juiz ou painel para Amostra estratificada: há resultados fora do cache para julgar. orchestrator.py:770-820
Juiz ou painel para Cache, sinal e código de saída: sem amostra: o consolidado decide. orchestrator.py:903-917
Amostra estratificada para Agregação: sempre; tarefas com falha técnica do juiz não votam. orchestrator.py:1374-1395
Agregação para Re-execução dirigida: veredito REPROVADO e re-execução ainda não usada. orchestrator.py:868-877
Agregação para Cache, sinal e código de saída: APROVADO ou APROVADO_COM_RESSALVAS. orchestrator.py:903
Re-execução dirigida para Amostra estratificada: alguma tarefa foi substituída: o consolidado fica velho e a amostra re-julgada decide sozinha. orchestrator.py:892-896
Re-execução dirigida para Cache, sinal e código de saída: nenhuma substituição, sub-orçamento esgotado ou sem degrau acima; nunca há segunda rodada. orchestrator.py:1480-1517
O que cada estado significa
Saída produzida:
Um modelo devolveu texto com sucesso de transporte.
Gate heurístico:
Verificação barata e local por tipo de tarefa: tamanho mínimo, seções vazias, chaves de código, TODO, citação de fonte.
Próximo da fila:
A saída reprovada fica guardada como melhor até agora e outro modelo tenta.
Aceita na onda:
A saída entra nos resultados da onda.
Cascata entre ondas:
Um verificador de outra família dá nota de 0 a 10 a saídas de modelos econômicos que alimentam a onda seguinte.
Escalada:
Um modelo não econômico refaz a tarefa uma única vez e o mesmo verificador re-pontua.
Degradada:
A saída segue, com aviso que sobrevive à sumarização, e fica fora do cache.
Juiz ou painel:
Rubrica de cinco dimensões sobre o consolidado. Painel 2 de 3 nos tipos premium; juiz único nos demais.
Amostra estratificada:
Até 6 tarefas julgadas uma a uma: 2 piores da cascata, 3 premium, 1 aleatória por semente.
Agregação:
O veredito do run é o pior entre o consolidado e a amostra.
Re-execução dirigida:
As 2 piores tarefas sobem um degrau com as críticas sanitizadas no prompt; substituem só se a nota melhorar.
Cache, sinal e código de saída:
Validade do cache pelo veredito; sinal de qualidade no relatório; código 0 ou 3.
O que acontece quando um provedor fica sem saldo?
O provedor sai da rota por 30 minutos e volta sozinho na primeira resposta boa. A primeira chamada que recebe um erro de crédito ou de autenticação marca a queda (queda: período em que o provedor não responde ou não tem saldo), e a partir daí todos os modelos daquela família contam como indisponíveis.
Imagine a pesquisa do exemplo caindo na Perplexity sem saldo. A fila de reservas do tipo pesquisa já pula os modelos da família e a chamada segue para o próximo provedor sem esperar. A escolha do juiz e a escalação do verificador consultam a mesma marca, então nenhum deles manda trabalho para quem acabou de falhar. O disjuntor (disjuntor: trava que desliga um provedor após falhas seguidas) fica intocado, porque saldo zerado é problema de conta, e não de transporte.
O prazo de 30 minutos erra de propósito para o lado curto: quem recarrega a conta quer o provedor de volta na rota sem reiniciar nada.
O que acontece quando um provedor demora ou devolve erro 5xx?
O sistema tenta uma segunda vez com o prazo esticado em 1,5 vez e, se falha de novo, passa à reserva; três falhas seguidas na mesma família abrem o disjuntor por 90 segundos, e as tarefas seguintes pulam o provedor em milissegundos em vez de esperar o prazo inteiro.
A regra distingue esperar de desistir. Um erro 429 (limite de requisições) merece espera: o sistema recua 2, 4 e 8 segundos, respeitando o prazo que o provedor pedir, em até três tentativas. Um erro 500 a 504 ou um estouro de tempo merece uma única tentativa curta, porque uma queda sustentada não melhora esperando e a fila de reservas está ali para isso. Um erro 4xx de outro tipo (payload, autenticação) nem conta para o disjuntor, para que um defeito nosso não derrube um provedor saudável.
Passados os 90 segundos, o disjuntor entra em meio-aberto: um sucesso fecha, uma falha reabre. A tarefa que sobrevive pela reserva conta como salva pela fila, e o registro alimenta a auditoria de quem derrubou a execução na semana.
Relatório de planejamento
sempre ativo, sem flag
Entre a decomposição e o roteamento, o sistema imprime e grava o plano: faixa da demanda, ondas em ordem e, por tarefa, o modelo, o id dele e a origem da decisão. Durante a execução, cada chamada abre e fecha com uma linha própria. Os comandos de plano e de simulação imprimem o mesmo bloco sem executar nada.
Roteador-sombra
só registro, política versionada
Uma heurística sem modelo calcula quatro sinais por tarefa (dificuldade, se precisa de juiz, se exige evidência, se depende de dado ao vivo), consulta uma tabela de 24 células e grava a decisão ao lado da rota real. Nada executa com base nela; a comparação entre as duas colunas é o que diz se a política merece entrar em produção.
Nível de esforço por tipo de tarefa
modelos com raciocínio por padrão
Nos modelos que raciocinam antes de responder, o raciocínio divide o teto de tokens com a resposta, e o padrão da API é o nível mais alto. Uma tabela por tipo corrige na origem: alto em arquitetura, revisão crítica e redação; médio em análise e revisão; baixo em classificação, resumo e monitoramento. Modelos sem o parâmetro não o recebem.
Doutrina editorial no prompt
módulo por perfil
A doutrina editorial entra no prompt de sistema de cada tarefa conforme o perfil: completa para peça com arco de leitura, núcleo para texto sem arco, só idioma para saída estruturada e nenhuma para código. Regra que fica só no repositório não chega ao modelo.
Resolução por código antes do modelo
tabela de despacho por palavra-chave
Contar palavras, extrair URLs, validar JSON, detectar idioma e calcular expressões são resolvidos por código, com custo zero e resultado marcado como concluído antes do roteamento. Fusão de textos vale para o tipo de processamento de dados quando a descrição pede juntar ou consolidar.
Refinador de demanda
HALO · arXiv 2505.13516
Três passos sem modelo (ler, enriquecer, ajustar) extraem intenção, idioma, entidades e uma estimativa de complexidade de 1 a 10 antes da decomposição. O relatório e o juiz veem a demanda original; só a decomposição recebe a versão enriquecida.
Cache semântico
AFlow · arXiv 2410.10762
Descrições do mesmo tipo de tarefa são comparadas por cosseno sobre TF-IDF; acima de 0,85 a resposta guardada é reaproveitada sem chamada. Redação e pesquisa só aceitam igualdade exata. O prazo de validade segue a nota do juiz na escrita, nunca na leitura.
Classificador de demanda
CASTER · arXiv 2601.19793
Soma pontos por palavras, número de tarefas, domínios distintos e sinal de raciocínio premium: até 2 é simples, até 5 moderada, acima complexa. A faixa define quantos modelos participam e liga o piso de diversidade nos planos complexos.
Replanejamento de subárvore
HALO · arXiv 2505.13516
Quando uma tarefa esgota a fila de reservas e tem dependentes pendentes, um decompositor adaptativo propõe uma substituta sob o mesmo id, uma vez por execução. A substituta que dá certo sai marcada como degradada; a que falha devolve o erro original e a lacuna declarada.
Juiz de qualidade
Judging the Judges · arXiv 2604.23178
Rubrica de cinco dimensões, 0 a 10 cada; abaixo de 60% reprova. O juiz nunca pertence ao provedor que mais produziu a saída. Em redação, SEO, arquitetura e revisão crítica, o veredito vem de um painel de três juízes de famílias distintas, por mediana; com menos de dois votos válidos, cai ao juiz único.
Verificador em cascata
Cluster-Route-Escalate · arXiv 2606.27457
Entre ondas, um verificador barato de outra família dá nota de 0 a 10 às saídas dos modelos econômicos que alimentam a onda seguinte. Abaixo de 6, a tarefa refaz num modelo acima e é pontuada de novo pela mesma régua; se reprova outra vez, fica o melhor dos dois, marcado. Teto de três escalações por execução.
Piso de diversidade
MoA · Wang 2024 / DAAO 2509.11079 / AdaptOrch 2602.16873
Em planos complexos com cinco ou mais tarefas, o roteador exige ao menos quatro famílias distintas (ou o tamanho do plano, se menor), promovendo uma tarefa por família ausente. A soma dos tetos menos qualquer provedor fica acima de 1,40, então todo plano fecha mesmo com uma família inteira fora do ar.
Três perguntas, no máximo, separam a tarefa do modelo: o tipo de tarefa, a complexidade e quem está usável na família. Procure na figura as respostas escritas nas setas e a folha em que cada caminho termina; a folha de borda roxa é o GPT-6 Astra, o modelo de topo de outra família. A árvore descreve a primeira tentativa de cada tarefa. O relatório de planejamento e a prévia de cada onda usam outra rotina, de quatro degraus (router.py:1019-1073): rota adaptativa por evidência, o menos usado entre os dois primeiros da fila de reservas, o par padrão e reserva da tabela e, por último, qualquer modelo disponível.
A árvore de roteamento: tipo, complexidade e disponibilidade
Três perguntas no máximo separam a tarefa do modelo. A primeira é o tipo de tarefa; escolha um ramo para ver as outras duas. Cada folha verde é um modelo; a folha de borda roxa é o GPT-6 Astra, o frontier de outra família, que entra em três caminhos.
Para architecture, o caminho da raiz à folha se lê como frase: a lista abaixo escreve cada um, com a regra e a fonte.
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable 5.1 usável. Modelo: Claude Fable 5.1. A faixa frontier fica com architecture em complexidade high. Se a fila trouxe o Opus 5 e o Fable está usável, a escada sobe para o Fable. router.py:751-754, :838-863
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable fora, Opus 5 usável. Modelo: Claude Opus 5. O Opus 5 é a segunda vaga da fila e a reserva imediata em recusa do classificador de segurança, sem sair da família. router.py:838-863; config.py:1121-1125
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable e Opus fora. Modelo: GPT-6 Astra. Terceira vaga da fila de architecture: o frontier de outra família entra quando a família Anthropic inteira está indisponível (queda, disjuntor aberto ou teto de participação). A escada OpenAI mantém o Astra porque o perfil é high. router.py:763-789; config.py:1105
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? medium. Modelo: Claude Sonnet 5. A escada Claude rebaixa architecture de complexidade medium ao Sonnet 5, se usável; senão mantém o modelo da fila. router.py:897-909
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? low. Modelo: Claude Haiku 4.5. Architecture de complexidade low desce ao Haiku, se usável. Em demanda COMPLEX o piso de qualidade devolve ao Sonnet 5. router.py:897-909; smart_router.py:566-576
Os 3 caminhos em que o GPT-6 Astra entra
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable e Opus fora. Modelo: GPT-6 Astra. Terceira vaga da fila de architecture: o frontier de outra família entra quando a família Anthropic inteira está indisponível (queda, disjuntor aberto ou teto de participação). A escada OpenAI mantém o Astra porque o perfil é high.
Qual é o tipo de tarefa? critical_review. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable e Opus fora. Modelo: GPT-6 Astra. Terceira vaga da fila de critical_review: o frontier de outra família entra quando a família Anthropic inteira está indisponível (queda, disjuntor aberto ou teto de participação). A escada OpenAI mantém o Astra porque o perfil é high.
Qual é o tipo de tarefa? code ou code_generation. Qual é a complexidade da tarefa? high. O GPT-6 Astra está usável? sim. Modelo: GPT-6 Astra. Degrau Sol para Astra: em code de complexidade high, a escada OpenAI promove o Sol ao Astra antes da chamada.
Os 35 caminhos da árvore inteira, em texto
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable 5.1 usável. Modelo: Claude Fable 5.1.
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable fora, Opus 5 usável. Modelo: Claude Opus 5.
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable e Opus fora. Modelo: GPT-6 Astra.
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? medium. Modelo: Claude Sonnet 5.
Qual é o tipo de tarefa? architecture. Qual é a complexidade da tarefa? low. Modelo: Claude Haiku 4.5.
Qual é o tipo de tarefa? critical_review. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable 5.1 usável. Modelo: Claude Fable 5.1.
Qual é o tipo de tarefa? critical_review. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable fora, Opus 5 usável. Modelo: Claude Opus 5.
Qual é o tipo de tarefa? critical_review. Qual é a complexidade da tarefa? high. Quem está usável na família Anthropic? Fable e Opus fora. Modelo: GPT-6 Astra.
Qual é o tipo de tarefa? critical_review. Qual é a complexidade da tarefa? low ou medium. Modelo: Claude Sonnet 5.
Qual é o tipo de tarefa? code ou code_generation. Qual é a complexidade da tarefa? high. O GPT-6 Astra está usável? sim. Modelo: GPT-6 Astra.
Qual é o tipo de tarefa? code ou code_generation. Qual é a complexidade da tarefa? high. O GPT-6 Astra está usável? não. Modelo: GPT-5.6 Sol.
Qual é o tipo de tarefa? code ou code_generation. Qual é a complexidade da tarefa? low ou medium. Modelo: GPT-5.6 Sol.
Qual é o tipo de tarefa? writing, copywriting ou seo. O GPT-5.5 está usável? sim. Modelo: GPT-5.5.
Qual é o tipo de tarefa? writing, copywriting ou seo. O GPT-5.5 está usável? não. Qual é a complexidade da tarefa? high ou medium. Modelo: Claude Sonnet 5 (Opus 5 se o Sonnet estiver fora).
Qual é o tipo de tarefa? writing, copywriting ou seo. O GPT-5.5 está usável? não. Qual é a complexidade da tarefa? low. Modelo: Claude Haiku 4.5 (Sonnet 5 em demanda COMPLEX).
Qual é o tipo de tarefa? review ou code_review. O Sonnet 5 está usável? sim. Modelo: Claude Sonnet 5.
Qual é o tipo de tarefa? review ou code_review. O Sonnet 5 está usável? não. Modelo: Gemini Flash (review) ou GPT-5.5 (code_review).
Qual é o tipo de tarefa? research ou fact_check. A Perplexity está usável? sim. Modelo: Perplexity Agent API (preset high).
Qual é o tipo de tarefa? research ou fact_check. A Perplexity está usável? não. Modelo: Gemini 3.1 Pro, depois Opus 5 (research) ou GPT-5.5 (fact_check).
Qual é o tipo de tarefa? analysis ou long_context_synthesis. O Gemini 3.1 Pro está usável? sim. Modelo: Gemini 3.1 Pro.
Qual é o tipo de tarefa? analysis ou long_context_synthesis. O Gemini 3.1 Pro está usável? não. Modelo: GPT-5.5, depois GPT-5.6 Sol.
Qual é o tipo de tarefa? classification, extraction ou data_processing. O Gemini 3.8 Flash está usável? sim. Modelo: Gemini 3.8 Flash.
Qual é o tipo de tarefa? classification, extraction ou data_processing. O Gemini 3.8 Flash está usável? não. Modelo: GPT-5.6 Luna, depois Groq gpt-oss-120b, depois Haiku 4.5.
Qual é o tipo de tarefa? summarization. O Gemini 3.8 Flash está usável? sim. Modelo: Gemini 3.8 Flash.
Qual é o tipo de tarefa? summarization. O Gemini 3.8 Flash está usável? não. Modelo: Claude Haiku 4.5, depois Groq gpt-oss-120b.
Qual é o tipo de tarefa? translation. O GPT-5.5 está usável? sim. Modelo: GPT-5.5.
Qual é o tipo de tarefa? translation. O GPT-5.5 está usável? não. Modelo: Gemini 3.8 Flash, depois Haiku 4.5.
Qual é o tipo de tarefa? realtime_search ou current_events. A Perplexity está usável? sim. Modelo: Perplexity Agent API (preset low).
Qual é o tipo de tarefa? realtime_search ou current_events. A Perplexity está usável? não. Modelo: Grok 4.6, depois Groq Compound.
Qual é o tipo de tarefa? social_listening ou brand_monitoring. O xAI está usável? sim. Modelo: Grok 4.6.
Qual é o tipo de tarefa? social_listening ou brand_monitoring. O xAI está usável? não. Modelo: Perplexity Agent API (preset low), depois Groq Compound.
Qual é o tipo de tarefa? decomposition (como tarefa do plano). O Sonnet 5 está usável? sim. Modelo: Claude Sonnet 5.
Qual é o tipo de tarefa? decomposition (como tarefa do plano). O Sonnet 5 está usável? não. Modelo: Gemini 3.1 Pro, depois GPT-5.5.
Qual é o tipo de tarefa? multi_perspective_decomposition. O xAI está usável? sim. Modelo: Grok 4.20 Reasoning.
Qual é o tipo de tarefa? multi_perspective_decomposition. O xAI está usável? não. Modelo: Claude Sonnet 5, depois Gemini 3.1 Pro.
Regras que valem antes e depois da árvore
Regras transversais do roteador, com a fonte de cada uma
Regra
O que faz
Fonte
Pré-alocação primeiro
Na primeira tentativa de cada tarefa, o modelo pré-alocado no planejamento é honrado se estiver usável; só então a árvore acima vale.
router.py:1109-1116
Teto de concentração por modelo
Com 5 ou mais tarefas na sessão, nenhum modelo recebe mais de 90% delas; a próxima vaga usável abaixo do teto assume. Sem alternativa, o teto é ignorado com aviso: é um teto brando.
router.py:103-109, :726, :911-946
Escada Claude
Só age quando o modelo escolhido é Opus 5 ou Fable 5.1. Fable fica apenas em architecture e critical_review high; fora de architecture, review e critical_review, o Opus desce ao Sonnet (Haiku em low); review nunca desce ao Haiku. Toda troca exige destino usável.
router.py:803-909
Escada OpenAI
Só age quando o modelo escolhido é Sol ou Astra. Astra fica em code, code_generation, architecture e critical_review high; fora disso desce ao Sol. Sol sobe ao Astra apenas em code e code_generation high. Architecture e critical_review aceitam o Astra pela fila, mas não promovem a partir do Sol.
router.py:763-800
Piso de qualidade em demanda COMPLEX
Depois das duas escadas, se a demanda é COMPLEX e o resultado é o Haiku, o Sonnet 5 assume, se usável. Só eleva, nunca rebaixa.
smart_router.py:566-576
Disjuntor de qualidade reordena a fila
Um apelido com 3 amostras fortes seguidas abaixo de 0,4 para aquele tipo vai para o fim da fila por 6 horas, nunca é removido: se só ele estiver vivo, executa.
router.py:496-549, :707-711
Retentativa não passa pela árvore
A partir da segunda tentativa da mesma tarefa, o próximo usável da fila é chamado sem teto, sem escadas e sem novo registro de uso.
router.py:1136
Nota da árvore: a escada Claude roda na primeira tentativa e no planejamento, e fica parada nas retentativas
Na primeira tentativa de uma tarefa, o roteador aplica as escadas ao primeiro usável da fila (router.py:1118); no planejamento pelo roteador inteligente, a mesma escada roda depois da escolha (smart_router.py:554). A partir da segunda tentativa, o roteador pega o próximo usável da fila de reservas sem teto, sem escadas e sem novo registro de uso (router.py:1136). Uma tarefa de copy cujo GPT-5.5 estava usável e falhou na chamada chega ao Opus 5, segunda vaga da fila, e ele fica; se o GPT-5.5 já estava fora antes da chamada, a escada desce o Opus 5 ao Sonnet 5 na primeira tentativa. A árvore acima descreve a primeira tentativa.
Para quem integra o orquestrador, os códigos de saída são o contrato: 0 entregou sem ressalva, 3 entregou marcado pelo juiz, 1 teve tarefa falha ou estourou o orçamento, 4 não conseguiu montar o plano e não gastou. Para quem avalia, a fase que mais vale conferir é a decomposição, porque um plano ruim atravessa todas as fases seguintes sem que nenhuma o conserte.
O que roda ao mesmo tempo, o que espera e quando o sistema para antes do fim?
Tarefas sem dependência pendente rodam juntas na mesma onda (onda: lote de tarefas que rodam ao mesmo tempo), e uma tarefa espera só pelo que consome. O sistema para antes do fim quando as saídas já cobrem mais de 80% das palavras-chave da demanda, restam mais de duas tarefas e nenhuma pendente consome resultado pronto.
Imagine oito tarefas de dois minutos cada: quatro pesquisas independentes, duas análises que consomem duas pesquisas cada, uma redação que consome as análises e uma revisão da redação. Em série, 16 minutos. Em ondas, quatro: as pesquisas juntas, as análises juntas, a redação, a revisão, ou seja, 8 minutos. O ganho vem da largura das primeiras ondas, e um plano em fila indiana, cada tarefa dependendo da anterior, não ganha nada.
Dentro de uma onda, as tarefas da Google rodam em série, com o intervalo mínimo do limitador de requisições entre elas, para que o lote inteiro da família não saia de uma vez; as demais disparam juntas. Antes de cada onda o sistema grava um ponto de retomada (ponto de retomada: arquivo com o plano e o que já ficou pronto), então uma execução interrompida recomeça da onda em que parou, sem repetir chamada paga.
A figura mostra um plano hipotético dividido em ondas. Procure as setas que cruzam de uma onda para a seguinte: cada uma é uma dependência, e a tarefa na ponta só começa quando todas as setas que chegam nela saem de tarefa concluída. Se o plano tem um ciclo ou uma dependência que aponta para tarefa inexistente, o que sobrou vai para uma última onda e falha com aviso, em vez de travar a execução.
O mesmo plano de sete tarefas em três cenários
Plano hipotético: duas pesquisas, uma análise que consome as duas, uma classificação, a redação que consome análise e classificação, e uma checagem e uma revisão que consomem a redação. As setas são dependências; a tarefa na ponta só começa quando todas as setas que chegam nela saem de tarefa concluída. O modelo em cada nó é a rota prevista do tipo.
C1: caminho feliz
Bifurcação: Escolha do modelo na fila. É a primeira tentativa desta tarefa? router.py:1088-1136, :726, :911-946
C6: parada antecipada vetada
t3: consome t1 e t2: veto
t4: consome t2: veto
Bifurcação: Veto à parada antecipada. Alguma tarefa pendente depende de uma tarefa já concluída com sucesso? pipeline.py:464-493, :535
C7: replanejamento após falha
t3: fila esgotada: substituta
t5: degradada ou lacuna
t6: herda o aviso
t7: herda o aviso
Bifurcação: Replanejamento de subárvore. A tarefa esgotou a fila, o replanejamento ainda não foi usado neste run, e há tarefas pendentes que dependem dela? pipeline.py:1748-1869, :815-833; config.py:940
Os oito cenários, um a um
Quando cada bifurcação responde do lado esperado, o run atravessa planejamento, ondas e juiz sem nenhuma reserva acionada, e termina aprovado com código de saída 0 e cache válido por 48 horas.
Refinador de prompt, sem modelosim Demanda em português refinada em três etapas, sem custo.
Decomposição: falha de transportenão O Gemini 3.1 Pro responde na primeira chamada.
Decomposição: plano legívelsim Plano com tarefas tipadas e dependências aceito.
Classe da demanda: SIMPLEnão A demanda tem várias tarefas e domínios.
Classe da demanda: MODERATE ou COMPLEXnão COMPLEX: até 5 modelos e garantia de diversidade.
Gate code-first: resolve sem modelonão Nenhuma tarefa resolve por código.
Deduplicaçãonão Nenhuma duplicata.
Equilíbrio de famíliasnão As quatro famílias base já têm tarefa.
Pré-alocação com teto de participaçãonão Ninguém passou do teto de participação.
Garantia de diversidadenão Quatro famílias distintas: diversidade OK.
Relatório de planejamentonão O relatório sai mesmo sem modo detalhado.
Cache semânticonão Nada parecido no cache.
Cache exatonão Nada idêntico no cache: todas as tarefas vão executar.
Anel 1: orçamento por runnão Estimativa abaixo de US$ 25.
Anel 2: teto diário globalnão Dia com folga no teto global.
Sobrou tarefa para executar?sim Pipeline construído.
Ondas por dependêncianão Ondas por dependência, em paralelo.
Escolha do modelo na filasim Cada tarefa vai ao modelo pré-alocado.
Anel 3: teto do provedor por chamadanão Nenhum provedor perto do teto diário.
A chamada devolveu texto?sim [OK] em todas as tarefas.
Gate heurístico por tiposim Todas as saídas passam no gate do tipo.
Cascata entre ondas: elegível?sim As saídas econômicas com dependentes são pontuadas.
Cascata: nota mínimasim Notas de 6,0 ou mais: nada escala.
Veto à parada antecipadasim A redação final depende das anteriores: o run segue até a última onda.
Juiz único ou painelsim Há writing no plano: painel 2 de 3 de famílias distintas.
Falha técnica do juiznão JSON da rubrica legível.
Veredito consolidadosim APROVADO.
Amostra estratificada de tarefassim Até 6 tarefas julgadas uma a uma.
Agregação do veredito do runnão Nenhuma reprovada: o consolidado vale.
Re-execução dirigidanão Sem re-execução.
O que vai ao cachesim Cache de 48 horas.
Código de saída: tarefa falhanão Nenhuma tarefa falhou.
Código de saída: sinal de qualidadenão Código 0; o vigia de gasto roda.
Código de saída
0
Sinal de qualidade
sem sinal
Cache
48 horas nos dois caches
Custo relativo
o custo base do plano: uma chamada por tarefa, mais decomposição, verificadores da cascata, painel e amostra
O que este cenário destaca: As três camadas de decisão (plano, fila, chamada) e os dois gates entre ondas.
01
Fatia máxima por família
Antes da primeira onda, o sistema pré-aloca as tarefas respeitando o teto de cada família: Anthropic 45%, OpenAI 50%, Google 60%, Perplexity 50%, xAI 35% e Groq 35% do plano. Quem passa do teto cede a tarefa de menor complexidade para a próxima família da fila; arquitetura e revisão crítica ficam presas ao modelo previsto e nunca são movidas primeiro.
6 famílias · piso de 4 em plano complexo
02
Ondas por dependência
O grafo de dependências vira níveis, e as tarefas do mesmo nível rodam juntas. A razão entre a soma das durações e o tempo de relógio é gravada como indicador por execução, e a tela mostra a composição de cada onda antes de dispará-la e uma linha de fechamento por tarefa.
indicador de paralelismo por execução
03
Verificação entre ondas e juiz no fim
Saídas de modelos econômicos que alimentam a onda seguinte recebem nota de um verificador de outra família antes de propagar. No fim, o juiz nunca pertence ao provedor dominante da saída; a nota dele define o prazo do cache e pode disparar a re-execução das duas piores tarefas.
indicador de aprovação do juiz
Quando o sistema para antes de rodar todas as tarefas?
Só quando três condições valem juntas: as saídas já cobrem mais de 80% das palavras-chave da demanda, restam mais de duas tarefas, e nenhuma tarefa pendente consome saída já concluída. Com duas ou menos restantes, o sistema termina tudo, porque parar economizaria pouco.
A terceira condição é um veto e roda antes das outras. Imagine que, depois da primeira onda, as quatro pesquisas do exemplo já citam quase todas as palavras da demanda. A cobertura passou de 80%, mas a redação final depende das quatro; o veto força o contador de restantes a zero, e a parada antecipada nem é consultada. Se as quatro tarefas restantes fossem independentes, sem consumir nada pronto, a execução pararia ali.
Cobertura de palavras mede se a demanda foi tocada, e consolidação é outra medida. O veto existe para separar as duas.
Quando uma tarefa falha, o que as próximas recebem?
Uma lacuna declarada no lugar do texto que faltou. Se a tarefa esgotou a fila de reservas (os modelos que assumem, em ordem, quando o principal falha) e tem dependentes pendentes, o sistema tenta uma vez replanejá-la: um decompositor adaptativo propõe uma substituta sob o mesmo id, que roda pelo caminho normal, com fila de reservas, gates e teto de custo.
Se a substituta dá certo, a saída sai marcada como degradada de qualquer jeito, e o aviso é escrito antes do resumo de contexto para sobreviver ao resumo. Se a substituta falha, o erro original volta ao relatório e a onda seguinte recebe um bloco que diz que aquela tarefa não existe e que o modelo deve declarar a lacuna em vez de preencher.
O contador de replanejamentos sobe antes da chamada, então uma execução nunca replaneja duas vezes, nem quando a substituta também falha.
Para quem escreve a demanda, a forma do plano é o que muda o tempo: pedidos com várias frentes independentes ganham mais com as ondas. Para quem avalia a saída, a marca de degradado e o bloco de lacuna dizem onde uma tarefa foi substituída ou faltou, e nenhum dos dois é apagado pelo resumo de contexto.
Como o roteador escolhe o modelo de cada tarefa, e quando ele muda de ideia?
O tipo da tarefa aponta um modelo padrão e uma fila de reservas (os modelos que assumem, em ordem, quando o principal falha); o roteador segue a fila na ordem, pula quem está indisponível e só troca a ordem quando a evidência de qualidade manda, com três guardas contra oscilação.
A fila de reservas de um tipo é montada em cinco camadas: o modelo padrão do tipo, a reserva declarada, a cadeia (cadeia: modelos chamados um depois do outro) configurada para o tipo, os modelos da faixa de complexidade da tarefa (faixa: modelos de custo e capacidade parecidos) e, como rede de segurança, qualquer modelo configurado. Um modelo conta como indisponível quando falta chave, quando a família está em queda (queda: provedor sem saldo ou fora do ar), quando o disjuntor (a trava que desliga um provedor após falhas seguidas) está aberto ou quando um limite local de 120 segundos ainda vale.
Na primeira tentativa de cada tarefa, três ajustes passam por cima da escolha. O teto de concentração impede que um único modelo fique com mais de 90% das tarefas de uma sessão a partir da quinta. A escada de complexidade desce o modelo mais caro de cada família quando o tipo não pede: o Claude de topo só fica em arquitetura e revisão crítica de complexidade alta, cai para o Opus nos outros casos, e o Opus cai para o Sonnet fora de arquitetura, revisão e revisão crítica; o GPT-6 Astra só fica em código, arquitetura e revisão crítica de complexidade alta e cai para o Sol nos demais. Um piso vale na direção oposta: em demanda complexa, o Haiku sobe para o Sonnet.
Nas retentativas da mesma tarefa, nada disso roda: o próximo da fila é chamado como está, sem teto nem escada, porque a tarefa já foi contada uma vez.
Redação só roda em modelos premium, regra fixa desde a Sprint 12. Redação, copywriting e SEO seguem a fila gpt-5.5, depois claude-opus-5, depois gemini-3.1-pro, depois perplexity, com Flash, Haiku, Luna, Groq e Astra vetados em qualquer posição da fila, e a suíte testa o veto. A fila é o que a regra fixa; a escada de complexidade é outra rotina, e ela ainda age na primeira tentativa: se o GPT-5.5 já está fora antes da chamada, a vaga do Opus 5 desce ao Sonnet 5, ou ao Haiku em complexidade baixa (router.py:1118). Nas retentativas a escada não roda, e o Opus 5 fica (router.py:1136). O precedente que fixou a regra: um curso publicado em 14 de maio de 2026 com centenas de acentos faltando, depois de um rebaixamento automático de faixa.
Como a frota inteira se comporta quando as tarefas chegam em sequência?
Os 16 modelos ficam numa tela só e as tarefas entram uma a uma, em ciclo pelos 23 tipos. Procure o ponto que sai do roteador: ele vai ao modelo previsto para o tipo. Desligue uma família nos interruptores e veja o mesmo ponto descer a fila de reservas até outro modelo, com o desvio em tracejado. É a mesma regra que vale para um provedor sem saldo ou com o disjuntor aberto, só que aqui você é quem derruba a família.
0 tarefas distribuídas
Aperte “Rodar a frota” para ver as tarefas entrarem e serem distribuídas.
A frota inteira numa tela: cada tarefa que sai da demanda é de um dos 23 tipos e segue para o modelo previsto pelo tipo; desligue uma família nos interruptores e a tarefa desce a fila de reservas até um modelo usável, com o desvio marcado em tracejado. A cor de cada ponto é a da família do modelo escolhido; o contador de cada modelo soma as tarefas recebidas.
config.py TASK_TYPES e FALLBACK_CHAINS (fila por tipo); router.py:952 _is_usable (família fora da rota); router.py:1088 get_next_in_chain (primeira posição usável)
Anthropic: Fable 5.1, 0 tarefas recebidas
Anthropic: Opus 5, 0 tarefas recebidas
Anthropic: Sonnet 5, 0 tarefas recebidas
Anthropic: Haiku 4.5, 0 tarefas recebidas
OpenAI: GPT-6 Astra, 0 tarefas recebidas
OpenAI: GPT-5.5, 0 tarefas recebidas
OpenAI: GPT-5.6 Sol, 0 tarefas recebidas
OpenAI: GPT-5.6 Luna, 0 tarefas recebidas
Google: Gemini Pro, 0 tarefas recebidas
Google: Gemini Flash, 0 tarefas recebidas
Perplexity: Agent high, 0 tarefas recebidas
Perplexity: Agent low, 0 tarefas recebidas
xAI: Grok 4.6, 0 tarefas recebidas
xAI: Grok Reason, 0 tarefas recebidas
Groq: gpt-oss-120b, 0 tarefas recebidas
Groq: Compound, 0 tarefas recebidas
O simulador aplica as regras desta aba a um tipo de tarefa e uma complexidade que você escolhe. Procure a linha de motivo: ela diz qual regra decidiu (tabela do tipo, escada de complexidade, teto ou piso), e é o mesmo motivo que o relatório de planejamento imprime.
Rodar simulação: qual modelo a primeira tentativa escolhe
Escolha o tipo de tarefa, a complexidade, a classe da demanda e quais provedores estão usáveis (um provedor fora cobre queda por crédito, disjuntor aberto ou chave ausente, as verificações de usável do roteador). O resultado aplica as regras da primeira tentativa e mostra o motivo em uma frase.
Nenhuma simulação ainda. Ajuste os controles e clique em Rodar simulação para ver o modelo escolhido, a fila de reservas e o motivo.
O que a simulação aplica e o que deixa de fora
Aplica, nesta ordem, as regras da primeira tentativa: fila de reservas do tipo, filtro de usável, escada Claude, escada OpenAI e piso de qualidade em demanda COMPLEX. O teto de concentração de 90% por modelo só vale com 5 ou mais tarefas na sessão e por isso fica de fora de uma simulação de tarefa única.
As 7 verificações de usável do roteador, que aqui viram um único interruptor por provedor: apelido existe; chave de api presente; marca de limite de requisições; queda do provedor por crédito ou autenticação; degradação local de sessão; disjuntor do provedor; disjuntor de qualidade: reordena a fila sem bloquear.
Regras da primeira tentativa, com fonte: Pré-alocação primeiro (router.py:1109-1116); Teto de concentração por modelo (router.py:103-109, :726, :911-946); Escada Claude (router.py:803-909); Escada OpenAI (router.py:763-800); Piso de qualidade em demanda COMPLEX (smart_router.py:566-576); Disjuntor de qualidade reordena a fila (router.py:496-549, :707-711); Retentativa não passa pela árvore (router.py:1136).
Cada modelo entra onde a evidência de bench mostra vantagem e sai de onde não mostra. Procure nos cartões o tipo de tarefa em que cada um é padrão: o Claude Fable 5.1 na faixa de topo de arquitetura e revisão crítica, o GPT-5.6 Sol em código, o Gemini 3.1 Pro em análise, a Perplexity em pesquisa com citações, o Grok 4.6 na linha do tempo do X e o Groq no degrau barato do trabalho curto em volume.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Faixa frontier (a de maior custo e capacidade), reservada a architecture e critical_review em complexidade high: fora desse perfil a escada da família rebaixa a tarefa para o Opus 5. Sucessor do Fable 5 na mesma faixa e preço (GA 01/09/2026). Raciocínio sempre ligado. Quando o classificador de segurança recusa a resposta, a reserva imediata é o Opus 5, sem sair da família. Leitura de cache a 0,025x do preço de entrada, única da família.
Leitura de cache a 0,025x do preço de entrada, única da família; escrita de cache a 1,25x ou 2,0x.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Faixa premium da Anthropic, degrau imediato abaixo do Fable 5.1: assume architecture e critical_review quando o frontier recusa ou fica indisponível, e ocupa a segunda vaga da fila de copy (writing, copywriting, seo). Raciocínio adaptativo ligado por padrão, e o teto de saída é dobrado em 2,5x pelo pipeline porque o raciocínio divide o limite de tokens com a resposta.
Raciocínio adaptativo ligado por padrão; o pipeline dobra o teto de saída em 2,5x porque o raciocínio divide o limite com a resposta.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Primário de review e code_review, e a rota alternativa da decomposição: quando a primeira chamada ao Gemini Pro falha ou devolve plano ilegível, a tentativa única de repetição vai ao Sonnet 5. Também é o piso de review: nessa família, review nunca desce ao Haiku. Preço de US$ 2/10 definitivo pela nota oficial de 07/09/2026.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Faixa econômica da Anthropic, acionada quando a escada da família rebaixa uma tarefa de complexidade low. Degrau 4 do bulk curto, atrás de Flash, Luna e Groq, e segunda vaga de summarization porque contexto longo é a fraqueza documentada do Luna. Em demanda COMPLEX o piso de qualidade o troca pelo Sonnet 5.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Frontier de outra família desde 07/09/2026 (lançado em 03/09). Entra em code só em complexidade high, por degrau condicional a partir do Sol, e na terceira vaga de architecture e critical_review, alcançada quando Fable e Opus não estão usáveis. Nunca em copy nem como juiz primário. Responses API com reasoning.effort.
Nível de esforço enviado só a este modelo na Responses API. Entra só em code high e na terceira vaga de architecture e critical_review.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Modelo padrão de copy (writing, copywriting e seo, sob a regra COPY PREMIUM ONLY desde maio de 2026) e primário de translation, pela qualidade de português. Cedeu code ao GPT-5.6 Sol em julho de 2026 e seguiu na escrita. Acima de 272 mil tokens no prompt, a entrada custa o dobro e a saída 1,5 vez.
Acima de 272 mil fragmentos no prompt, a entrada custa o dobro e a saída 1,5 vez (multiplicador de contexto longo).
Preço somado, entrada mais saída, em relação ao mais caro do parque
Primário de code em complexidade low e medium e reforço de outra família em analysis, code_review, critical_review e architecture. Em code de complexidade high o roteador o promove ao Astra antes da chamada, se o Astra estiver usável. Fora de copy.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Faixa econômica da família GPT-5.6: segunda vaga de classification, extraction e data_processing, e terceiro nome na lista de preferência dos juízes. Nunca em contexto longo nem em copy.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Decompositor padrão: é o modelo que quebra a demanda em tarefas tipadas, com repetição única no Sonnet 5 se a chamada falhar. Primário de analysis e de long_context_synthesis, com 1 milhão de tokens de contexto e preço fixo de tabela em qualquer tamanho de prompt. Em erro 503 o cliente tenta o 3.8 Flash dentro da mesma família antes de avançar na fila de reservas.
Preço fixo de tabela em qualquer tamanho de prompt. Em erro 503 o cliente tenta o Flash na mesma família.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Cavalo de carga do bulk (classification, summarization, extraction e data_processing) e primeiro nome na lista de preferência dos juízes, com a regra de que o juiz nunca é da mesma família que produziu o texto. Flash padrão desde 07/09/2026 (GA de 02/09), sempre pelo preço de tabela; a promoção até 31/12/2026 fica fora do catálogo. Raciocina por padrão, com o raciocínio cobrado como saída.
Preço de tabela; a promoção vigente até 31/12/2026 não entra no catálogo. O raciocínio é cobrado como saída.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Pesquisador profundo pela Agent API (preset high) desde a Sprint 30, com citações. O custo real vem no campo usage.cost da resposta e prevalece sobre a tabela; há taxa por requisição e US$ 0,005 por busca fora do preço por token. Pesquisas profundas rodam em série, uma por vez, e uma chamada que estoura o tempo não ganha segunda tentativa. O Sonar legado sai do ar em 27/09/2026.
O custo real vem no campo usage.cost da resposta e prevalece sobre a tabela; há taxa por requisição e por busca.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Monitor da web viva pela Agent API (preset low): primário de realtime_search e current_events, com citações. Reserva de social_listening e brand_monitoring, cobrindo a web geral quando o xAI cai.
O custo real vem no campo usage.cost da resposta e prevalece sobre a tabela.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Único do parque com busca viva na linha do tempo do X, pela Agent Tools API: primário de social_listening e brand_monitoring, segunda vaga de realtime_search e current_events e reforço em analysis. O custo vem faturado pela própria API em unidades de dez bilionésimos de dólar. Com busca viva ligada, o volume de entrada por chamada pode crescer muito, e um teto para essa busca é item aberto da Sprint 31.
Custo faturado pela própria API em unidades de dez bilionésimos de dólar; com busca viva, a entrada por chamada pode crescer muito.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Primário de multi_perspective_decomposition: raciocínio estendido de um agente só para produzir vários pontos de vista. A reserva Sonnet 5 cobre queda do xAI. Baixa frequência de uso.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Modelo aberto servido pelo GroqCloud, de volta ao parque em 07/09/2026 depois de sair na Sprint 16. Degrau 3 de classification, extraction, data_processing e summarization, e âncora do redirecionamento para o modelo mais barato quando um provedor bate 95% do teto diário (custo de partida US$ 0,0008 por chamada, dado com folga de propósito). Proibido em copy, como primário de code e em julgamento.
Preço somado, entrada mais saída, em relação ao mais caro do parque
Sistema agêntico com busca web embutida (US$ 0,005 por busca, contadas no cliente pelas ferramentas executadas) e execução de código, saída máxima de 8.192 tokens. Terceira vaga de realtime_search, current_events, social_listening e brand_monitoring: a rota de web viva que resta quando Perplexity e xAI estão fora.
Mais US$ 0,005 por busca executada pelo Groq Compound.
Preços de tabela do catálogo v5.0, por milhão de fragmentos de texto (a unidade que o provedor cobra), entrada e saída. Contexto é o tamanho máximo de entrada, em fragmentos.
A figura mostra a escada de complexidade das duas famílias de topo. Procure os degraus que só sobem com tarefa de arquitetura ou revisão crítica em complexidade alta (e código, no caso da OpenAI): fora deles, o modelo mais caro desce um degrau antes de a chamada sair, e a descida só acontece se o degrau de baixo está disponível.
As faixas das duas famílias com escada
A largura de cada faixa não codifica quantidade: a pirâmide só ordena os degraus, do mais caro e capaz no topo ao mais barato na base. Os preços são de tabela, por milhão de fragmentos de texto (a unidade que o provedor cobra), entrada e saída, lidos do catálogo v5.0; o custo de uma chamada depende do tamanho do texto.
Quando a escada Anthropic sobe ou desce um degrau
sobeOpus 5 para Fable 5.1 quando architecture ou critical_review em complexidade high, com o Fable usável. router.py:838-863
desceFable 5.1 para Opus 5 quando qualquer outro tipo ou complexidade abaixo de high, ou Fable fora do ar. router.py:838-863
desceOpus 5 para Sonnet 5 quando tipo fora de architecture, review e critical_review em medium ou high; review e critical_review em low ou medium; architecture em medium. router.py:867-909
desceOpus 5 para Haiku 4.5 quando complexidade low fora de review e critical_review (architecture incluída). router.py:867-909
sobeHaiku 4.5 para Sonnet 5 quando demanda COMPLEX, com o Sonnet usável; o piso só eleva. smart_router.py:566-576
Quando a escada OpenAI sobe ou desce um degrau
sobeGPT-5.6 Sol para GPT-6 Astra quando code ou code_generation em complexidade high, com o Astra usável. router.py:790-800
desceGPT-6 Astra para GPT-5.6 Sol quando fora de code, code_generation, architecture e critical_review em high, com o Sol usável. router.py:779-789
ficaGPT-5.5 e GPT-5.6 Luna para o mesmo degrau quando sempre: copy, translation e bulk ficam fora da escada OpenAI, que só age sobre Sol e Astra. router.py:774
As regras da escada, na forma em que o roteador as aplica
Escada Claude: Só age quando o modelo escolhido é Opus 5 ou Fable 5.1. Fable fica apenas em architecture e critical_review high; fora de architecture, review e critical_review, o Opus desce ao Sonnet (Haiku em low); review nunca desce ao Haiku. Toda troca exige destino usável. router.py:803-909
Escada OpenAI: Só age quando o modelo escolhido é Sol ou Astra. Astra fica em code, code_generation, architecture e critical_review high; fora disso desce ao Sol. Sol sobe ao Astra apenas em code e code_generation high. Architecture e critical_review aceitam o Astra pela fila, mas não promovem a partir do Sol. router.py:763-800
Piso de qualidade em demanda COMPLEX: Depois das duas escadas, se a demanda é COMPLEX e o resultado é o Haiku, o Sonnet 5 assume, se usável. Só eleva, nunca rebaixa. smart_router.py:566-576
Toda troca exige destino usável; sem destino, o modelo da fila fica. A escada só age no modelo escolhido para a primeira tentativa e na pré-alocação; nas retentativas pela fila de reservas ela não roda.
O que acontece quando o modelo recusa a tarefa?
A recusa vira falha de tentativa, e a fila de reservas avança sem trocar de família. Na Anthropic, uma resposta com motivo de parada igual a recusa passa primeiro por uma reserva interna do próprio provedor; persistindo, a tarefa cai para a próxima posição da fila.
Imagine uma revisão crítica de complexidade alta no Claude Fable 5.1. A segunda posição da fila desse tipo é o Opus da mesma família, de propósito: uma recusa do classificador de segurança do modelo de topo não deveria custar a qualidade de raciocínio, e a troca de família só começa na terceira posição, onde entra o GPT-6 Astra.
Resposta vazia e resposta cortada pelo teto de tokens sem texto recebem o mesmo tratamento em todos os provedores: contam como falha e passam a vez, em vez de virar entrega vazia com status de sucesso.
Como a nota do juiz muda as escolhas seguintes?
Devagar e com guardas. O juiz (o modelo de outra família que dá nota) alimenta uma janela de 50 amostras por tipo e modelo, com dois sinais separados: transporte (a chamada respondeu?) e qualidade (a resposta foi boa?). Sem nota de qualidade suficiente, a pontuação é 0,6 de sucesso, 0,2 de custo e 0,2 de latência; com três ou mais notas fortes, passa a 0,40 de transporte, 0,30 de qualidade, 0,20 de custo e 0,10 de latência.
Para uma reserva passar na frente do padrão, três guardas precisam valer ao mesmo tempo: dez amostras de cada lado, três notas fortes de cada lado (juiz, verificador ou verificador de código; a nota difusa de execução pesa 0,25) e vantagem média acima de 0,15. Em demanda complexa, a exigência dobra para vinte amostras.
Um disjuntor de qualidade separado manda para o fim da fila, por seis horas, o modelo cujas três últimas notas fortes ficaram abaixo de 0,4 num tipo; uma nota posterior de 0,6 ou mais o reabilita antes do prazo. Ele nunca remove o modelo: se for o único vivo, executa.
A tabela lista, por tipo de tarefa, o modelo padrão e a ordem das reservas. Procure os tipos em que a segunda posição é da mesma família da primeira: essa ordem existe para cobrir recusa sem trocar de família, e a diversidade entre provedores começa na terceira posição.
Tabela de rotas: 23 tipos de tarefa, primário, reserva e terceiro
Primário é o modelo previsto para o tipo; reserva é quem assume quando o primário falha ou está fora; terceiro é a vaga seguinte da fila. Faixa de esforço é quanto raciocínio o modelo gasta, quando ele aceita esse ajuste. A marca de mesma família na reserva indica ordem feita para cobrir recusa sem trocar de família.
Rota por tipo de tarefa: categoria, primário, reserva, terceiro, resto da fila e faixa de esforço
Haiku 4.5, GPT-5.5, Agent low, Sonnet 5, Gemini Pro
baixo
translation
Volume
GPT-5.5OpenAI
Gemini FlashGoogle
Haiku 4.5Anthropic
Sonnet 5, Gemini Pro, Agent low
baixo
summarization
Volume
Gemini FlashGoogle
Haiku 4.5Anthropic
gpt-oss-120bGroq
GPT-5.5, Gemini Pro, Agent low, Sonnet 5
baixo
realtime_search
Pesquisa
Agent lowPerplexity
Grok 4.6xAI
CompoundGroq
Gemini Flash, GPT-5.6 Luna, GPT-5.5, Haiku 4.5, Agent high
baixo
social_listening
Pesquisa
Grok 4.6xAI
Agent lowPerplexity
CompoundGroq
GPT-5.6 Luna, GPT-5.5, Gemini Flash, Haiku 4.5, Agent high
baixo
current_events
Pesquisa
Agent lowPerplexity
Grok 4.6xAI
CompoundGroq
Gemini Flash, GPT-5.6 Luna, GPT-5.5, Haiku 4.5, Agent high
baixo
brand_monitoring
Pesquisa
Grok 4.6xAI
Agent lowPerplexity
CompoundGroq
GPT-5.6 Luna, GPT-5.5, Gemini Flash, Haiku 4.5, Agent high
baixo
multi_perspective_decomposition
Produção
Grok ReasonxAI
Sonnet 5Anthropic
Gemini ProGoogle
GPT-5.5, Agent high, Gemini Flash
médio
long_context_synthesis
Produção
Gemini ProGoogle
GPT-5.5OpenAI
GPT-5.6 SolOpenAI
Opus 5, Sonnet 5, GPT-6 Astra, Agent high, Gemini Flash
médio
As duas primeiras vagas de cada fila são exatamente o par primário e reserva da tabela de tipos (invariante testado na suíte); as demais vagas alternam famílias para que uma queda inteira de provedor não esgote a fila. Fonte: config.py:TASK_TYPES e config.py:1105 (FALLBACK_CHAINS).
Para quem usa o orquestrador, isso significa que a rota de uma tarefa é previsível pela tabela do tipo e só muda com evidência acumulada de dez amostras ou mais. Para quem quer mudar uma rota, o lugar é o catálogo e a tabela de tipos, e a suíte de testes acusa quando um modelo vetado entra numa fila de redação.
O que já está no sistema, o que a última rodada corrigiu e o que vem a seguir?
Estão no sistema 30 sprints e 2 marcos; a rodada de 8 de setembro de 2026 corrigiu três regras que só a rede real expôs, e o backlog da Sprint 31 abre com um registro de gasto que conta cada chamada duas vezes.
As 24 primeiras sprints viraram duas entradas de era, porque o que elas construíram já é infraestrutura e o detalhe segue no repositório. As entradas das Sprints 25 a 30 e dos marcos abrem com detalhe completo, que é onde está o comportamento novo. A PR #24, mesclada em 8 de setembro, mudou três regras descritas nas outras abas: a parada antecipada passou a ser vetada quando uma tarefa pendente consome saída concluída; o juiz ganhou teto de 4.000 tokens e um resgate que lê o JSON cortado; e a leitura de cache do Fable 5.1 passou a ser cobrada a 0,025 do preço de entrada, como na tabela.
O achado aberto para a Sprint 31 é de contabilidade: o registro de gasto grava cada chamada de tarefa duas vezes, uma no cliente e outra no pipeline, o que infla o gasto do dia e consome os tetos diários em dobro. Até a correção, o teto por provedor chega na metade do gasto real, e quem lê o painel de custo deve dividir por dois o que veio de tarefas.
Evidência de campo: o que uma medição de um dia mostrou
Em 08/09/2026, com saldo nas seis contas, o doctor --live respondeu 6 de 6 provedores e o canário 16 de 16 aliases em 37 s.
O E2E real com os seis provedores concluiu 4 de 8 tarefas em 215 s, com US$ 1,04 no relatório de execução e US$ 2,13 no registro do FinOps.
Fonte: wiki do repositório, página Verificacao-com-Credito-08-09-2026. A diferença entre as duas cifras é o registro duplo descrito acima, somado a juízes e re-execuções que o relatório não soma.
Timeline · 30 sprints lançadas e 2 marcos
As 2 primeiras fases (Sprints 1-13 e Sprints 14-24) aparecem como entradas únicas; da Sprint 25 em diante cada sprint tem entrada própria. A Sprint 30, de 7 de setembro de 2026, fecha a numeração, e o marco de 8 de setembro de 2026 encerra a linha. Cada entrada abre com o detalhe técnico: itens entregues, justificativa, métricas e arquivos tocados.
MARCOVerificação08 set 2026MAIS RECENTE
Marco de 08/09: verificação do parque v5.0 com crédito nas seis APIs
A lacuna declarada no fechamento da Sprint 30 foi fechada com rede real: as três contas sem saldo foram recarregadas e os seis provedores responderam.
Destaques
doctor --live 6 de 6 e models --verify sem deriva de catálogo
Canário de 16 em 16 aliases em 37 s, uma chamada real por alias
Banca de 5 LLMs sobre o diff do parque: cinco pareceres em 61 s, US$ 0,34
E2E real com os seis provedores: 4 de 8 tarefas, 215 s, US$ 1,04 no relatório e US$ 2,13 no FinOps
Três defeitos que só a rede real mostrou, corrigidos na PR #24, mesclada em 08/09 às 18:49
Refatoração 5.1 no mesmo dia: doctor em src/doctor.py e ruff no CI; master 3c88f10 com 850 testes
01O que a rede real mostrou que o mock não alcançava
A demanda de quatro partes foi decomposta pelo Gemini 3.1 Pro em 8 tarefas e 3 ondas. A pesquisa rodou na Agent API preset high em 184 s por US$ 0,387, contra 220 s e US$ 0,689 do Sonar legado no run de controle da manhã. A revisão crítica passou pelo Sonnet 5 e foi re-executada no Fable 5.1, que sustentou 9.619 tokens de saída em 136 s. O custo escondido apareceu no FinOps: a re-execução da busca em tempo real caiu no Grok com busca viva, 287.214 tokens de entrada numa única chamada e US$ 0,903, sem aparecer no relatório de execução.
Por que esta decisão
Três defeitos vieram desse run. O early stop encerrou depois da onda 1 com a redação final e três revisões ainda pendentes, sem registrar falha. O juiz truncava o JSON da rubrica em 1.600 tokens e o run saía reprovado sem veredito. E o cache read do Fable 5.1 era faturado a 0,10x do input em vez de 0,025x, quatro vezes acima do real. Os três estão na PR #24, mesclada em 08/09 às 18:49, com 16 testes novos. A refatoração 5.1 seguiu no mesmo dia (doctor em src/doctor.py, ruff no CI) e o master 3c88f10 fechou com 850 testes. Um achado ficou aberto para a Sprint 31: o FinOps grava cada chamada de tarefa duas vezes, em llm_client.py e em pipeline.py, o que infla o gasto registrado e consome os tetos diários em dobro.
Canário: Fable 5.1 4,2 s · Astra 3,0 s · Gemini Pro 5,2 s · Groq 0,8 s
Fable 5.1 na revisão crítica: 6.306 in / 9.619 out, 136 s, US$ 0,552
Master 3c88f10 depois da PR #24 e da refatoração 5.1: 850 testes
tests/test_fable51_cache_read.py
tests/test_pos_sprint30_e2e_com_credito.py
src/pipeline.py:_has_pending_consumers
src/quality_judge.py:_rescue_truncated
30
SPRINTParque07 set 2026
Sprint 30: parque v5.0 com GPT-6 Astra, Claude Fable 5.1, Gemini 3.8 Flash e Groq de volta
Reforma em cinco waves contra as APIs vivas: quatro trocas de modelo, preços corrigidos pela tabela oficial, três adaptadores novos e um sexto provedor.
Destaques
16 aliases em 6 provedores: gpt_astra, groq e groq_web entram; Fable 5.1 e Gemini 3.8 Flash assumem os aliases da família
Preços pela tabela oficial de 07/09/2026: gpt-5.5 US$ 5/30, Sol US$ 4/20, Luna US$ 0,20/1,20, Sonnet 5 US$ 2/10
OpenAI pela Responses API, com reasoning.effort só no Astra; Perplexity pela Agent API por padrão; Groq pela rota compatível com OpenAI
Astra no slot 3 de architecture e critical_review e degrau Sol para Astra em code de complexidade high
Bulk curto em Flash, Luna, Groq e Haiku; monitoramento com três rotas de web viva de famílias distintas
models --verify compara o catálogo com os endpoints /models vivos sem custo; doctor --live ganha catalog_live_drift
823 testes verde; três runs reais só em Google, xAI e Groq porque Anthropic, OpenAI e Perplexity estavam sem saldo
01Quatro trocas de modelo e um provedor de volta, todos pela mesma régua
O GPT-6 Astra, lançado em 03/09/2026, entra como frontier de outra família: Coding Agent Index 67, igual ao Fable 5 por menos da metade do custo, e um terço dos tokens do Sol em agentes de código. Fica no slot 3 de architecture e critical_review e sobe do Sol em code apenas em complexidade high; nunca em copy nem como primário de julgamento. O Claude Fable 5.1 (GA 01/09) lidera o AA Intelligence Index com 66 e assume o alias do Fable 5 no mesmo preço. O Gemini 3.8 Flash (GA 02/09) assume o alias gemini_flash pelo preço de tabela. E o Groq volta com o gpt-oss-120b a US$ 0,15/0,60 e 500 tok/s como degrau 3 do bulk curto, mais o Groq Compound como terceira rota de web viva.
Por que esta decisão
A regra é a mesma desde a era de consolidação: entra onde o bench prova vantagem, e a validação é contra a conta. O consenso da banca de cinco LLMs em 08/09 foi manter o Astra como fallback frontier, nunca primário, até haver medição comparativa própria.
Astra: Coding Agent Index 67, FrontierMath T4 97,6%, GPQA 96% (Artificial Analysis e guia oficial, lidos em 07/09/2026)
Fable 5.1: AA Intelligence Index 66 em 07/09/2026
gpt-oss-120b no Groq: 500 tok/s, US$ 0,15/0,60 por Mtok
catalog/model_catalog.yaml
src/config.py
src/llm_client.py
src/catalog_verify.py
02O catálogo errava o preço de quatro modelos, nos dois sentidos
Lidas as tabelas oficiais de OpenAI, Anthropic, Google, Perplexity e Groq em 07/09/2026: o Sol custa US$ 4/20 (o catálogo tinha 5/30), o Luna US$ 0,20/1,20 (tinha 1/6, cinco vezes a mais), o GPT-5.5 US$ 5/30 na saída (tinha 15) e o Sonnet 5 US$ 2/10 como preço definitivo (tinha 3/15; o aumento previsto para 01/09 foi cancelado pela nota oficial). Com os números certos, a âncora do redirecionamento por custo passa a cair em Groq e Luna, e não mais no Gemini Flash nem no Haiku.
Por que esta decisão
O catálogo subestimava o Sol em 33% na saída, superestimava o Luna em 400% e o Sonnet 5 em 50%. Estimativa errada distorce o roteamento por custo antes de distorcer a fatura. Preço de tabela, nunca promoção: o 3.8 Flash tem desconto até 31/12/2026 e o catálogo o ignora.
Tetos diários v5.0: Anthropic 100, OpenAI 70, Google 60, Perplexity 40, xAI 40, Groq 15; global 300
Caps de share: 0,45 / 0,50 / 0,60 / 0,50 / 0,35 / 0,35; pior caso de outage 2,15, acima do piso de 1,40
03Três adaptadores novos e um sunset com data
A OpenAI passa a ser chamada pela Responses API, com reasoning.effort enviado só ao Astra. A Anthropic concatena todos os blocos de texto da resposta e ganha fallback server-side opcional na recusa, desligado até probe real. A Perplexity vai pela Agent API por padrão: o alias perplexity vira preset high e o perplexity_fast vira preset low, com o custo real vindo em usage.cost; o Sonar Chat Completions sai do ar em 27/09/2026. O Groq entra pela rota compatível com OpenAI. A xAI passa a usar o custo faturado em cost_in_usd_ticks.
Por que esta decisão
Cada gate tem variável de ambiente (GEO_OPENAI_RESPONSES, GEO_PPLX_AGENT_API, GEO_ANTHROPIC_SERVER_FALLBACK) para voltar à rota anterior sem deploy, porque troca de adaptador sem chave de retorno vira incidente no primeiro erro de contrato.
823 passed, 1 skipped, 1 xfailed em 07/09/2026
Manifest regenerado: version 5.0, sprint 30, 24.683 LOC em 49 arquivos
src/llm_client.py
src/provider_liveness.py
docs/audits/SPRINT30_VERIFICACAO_20260907.md
29
SPRINTResiliência27 ago 2026
Sprint 29: Perplexity confiável, com série, sem retry de timeout, custo completo, locks por loop e âncora de data
Cinco defeitos com prova e cinco correções depois da rodada do menu Redes sociais, em que o Perplexity reprovava o tempo todo e caía em timeout.
Destaques
ReadTimeout aos 25 minutos era aritmética do retry: 600 s de banda mais 900 s de retry esticado; modelo que raciocina não ganha retry de timeout
Deep-research em série por semáforo por loop (GEO_PPLX_DEEP_CONCURRENCY=1); sonar-pro segue paralelo
Locks recriados quando o event loop muda: 9 de 9 pesquisas caíam sem busca live quando o SDK síncrono rodava em ThreadPool
Ledger subcontava a Perplexity (US$ 14 contra US$ 33 no painel): tarifa por requisição, citation tokens, buscas e raciocínio entram na soma
Âncora temporal injetada nas superfícies dinâmicas: o juiz chamava 14 de 14 números de 2026 de futuro
Suíte em 734 verdes, com 14 testes em test_sprint29
01Cinco defeitos silenciosos na rota de pesquisa, cada um com prova
A banda de research de 600 s somada ao retry esticado em 1,5x explicava o timeout de 25 minutos; deep-research que não respondeu em 10 minutos está preso na fila do provider, e a segunda tentativa só dobrava o prejuízo. Cinco chamadas em paralelo davam 429 e abriam o breaker, porque o rate limiter controla RPM e não chamadas de 5 a 10 minutos em voo. Os locks do token bucket e do pool nasciam no primeiro event loop e quebravam no seguinte. O ledger não somava tarifa por requisição, citation tokens, buscas a US$ 5 por mil e raciocínio a US$ 3 por milhão. E o juiz, sem data de referência, tratava o presente como futuro.
Por que esta decisão
Nenhum dos cinco aparecia em teste unitário, porque cada um dependia de tempo real, de dinheiro real ou de mais de um event loop. A suíte passou a isolar o saldo real dos providers: com OpenAI e Perplexity sem crédito, sete testes de roteamento falhavam no master limpo.
14 testes novos; suíte de 727 para 734 verdes
Painel de 27/08: US$ 33 no mês contra US$ 14 no ledger antes da correção
Demandas de research voltavam sem entregável com HTTP 200: o raciocínio do deep-research consumia o teto inteiro de tokens e o cliente aceitava resposta vazia como sucesso.
Destaques
max_tokens é teto TOTAL no sonar-deep-research: com 1.200, o raciocínio gastou 39.503 tokens e a resposta veio vazia, HTTP 200
Piso de max_tokens de 32.000 para modelos que raciocinam (GEO_PPLX_REASONING_MIN_MAX_TOKENS)
Guard de resposta vazia: texto vazio vira RuntimeError e cai para a fallback chain
finish_reason=length com texto passa a emitir WARNING de truncamento
Custo passa a ser o usage.cost.total_cost devolvido pela API: a estimativa por token subestimava cerca de 4x
Catálogo v4.6: sonar-deep-research de 8.192 para 32.000 tokens de saída
01Teto de tokens que engolia a resposta inteira
Medido na rota legada de chat completions em 23/08/2026: com max_tokens 1.200, o modelo gastou 39.503 tokens de raciocínio, zero de resposta e devolveu HTTP 200 com finish_reason=length; com 8.192, o teto antigo do catálogo, o texto vinha cortado no meio; com 32.000 ou sem teto, a resposta fechava em stop com 12 a 19 mil tokens, 110 a 140 segundos e US$ 0,23 a 0,32 por chamada. reasoning_effort low não contém o raciocínio. A correção fica em um único ponto, o cliente da Perplexity, por onde passam pipeline, board e SDK.
Por que esta decisão
O defeito era intermitente porque dependia de quanto o modelo resolvia raciocinar, e invisível porque o cliente tratava texto vazio como sucesso. Um guard e um piso eliminam a classe do problema em vez de remendar cada chamada.
Piso de 32.000 tokens em modelos que raciocinam; sonar-pro intocado
FinOps mostrava US$ 0,02 com gasto real perto de US$ 1 por chamada antes do usage.cost
src/llm_client.py:_call_perplexity
catalog/model_catalog.yaml
tests/test_sprint28.py
MARCOResiliência19 ago 2026
Marco de 19/08: TLS pelo cert store do sistema operacional
O parque inteiro estava caindo no desktop de trabalho por causa do antivírus, e o diagnóstico honesto foi 0 de 13 modelos respondendo.
Destaques
truststore.inject_into_ssl() no import de src/: cobre CLI, MCP server, SDK e scripts de uma vez
Antes 0 de 13 modelos no status --ping; depois 13 de 13, medido no mesmo desktop
Kill-switch GEO_ORCHESTRATOR_NO_TRUSTSTORE=1 e degradação limpa para certifi se o pacote faltar
CI Linux intocado: o defeito é de máquina com antivírus MITM, não do produto
01Verificação de certificado delegada ao sistema operacional
Em Windows com antivírus que faz MITM, a cadeia TLS chega assinada por uma raiz própria do antivírus, que o bundle do certifi não conhece, e todas as 13 chamadas de modelo morrem em CERTIFICATE_VERIFY_FAILED antes de sair da máquina. O Python 3.13 agrava o quadro: com VERIFY_X509_STRICT ligado por padrão, essa raiz é reprovada por Basic Constraints, então nem apontar SSL_CERT_FILE para um bundle com a raiz anexada resolve. A correção injeta o truststore no import do pacote e passa a verificação para o verificador nativo do sistema.
Por que esta decisão
Consertar isso por variável de ambiente em cada shell seria um remendo que some no próximo terminal, e desligar a verificação seria trocar um erro visível por um risco invisível. Delegar ao cert store do sistema é o caminho que já é verdade para todo o resto do software da máquina, e cobre os quatro pontos de entrada do orquestrador com uma linha no bootstrap.
Medição de 19/08 neste desktop: 0/13 antes, 13/13 depois
PR #19, 50 linhas somadas em 2 arquivos
Suíte do ambiente puro: 566 passed
src/__init__.py
pyproject.toml
27
SPRINTParque14 ago 2026
Sprint 27: parque v4.5, Gemini 3.7 Flash como Flash padrão
O Flash trocou de geração no dia seguinte ao GA, sem mexer em alias, chain ou preço de tabela, e os candidatos ao tier economy ficaram para depois da validação de qualidade.
Destaques
gemini-3.7-flash assume o alias gemini_flash: GA de 13/08/2026 no changelog oficial da Gemini API
Upgrade drop-in: mesmo contexto de 1M de entrada e 65K de saída, mesmos métodos, mesmo preço de tabela
Sondagem viva de 14/08: raciocina por padrão, com o thinking cobrado como output e somado pelo cliente desde a v4.3
Preço registrado é o de tabela (US$ 1,50/US$ 7,50), não o promocional que dobra em 01/01/2027
Candidatos grok-4.3 e gemini-3.1-flash-lite avaliados e adiados: sem validação de qualidade, o parque não cresce
Suíte em 689 testes verde, com 6 testes novos em test_sprint27
01O Flash padrão trocou de geração no dia seguinte ao GA
O gemini-3.7-flash entrou em GA em 13 de agosto de 2026, pelo changelog oficial da Gemini API, e assumiu o alias gemini_flash em 14. A troca é drop-in: mesmo contexto de 1M de entrada e 65K de saída, mesmos métodos e mesmo preço de tabela. A sondagem viva de 14 de agosto confirmou que o modelo raciocina por padrão, com thoughtsTokenCount presente já em resposta de uma palavra; a Google cobra esse raciocínio como output, e o cliente soma esses tokens desde a v4.3, então a contabilidade nasceu correta. Em 07/09/2026 o alias trocou de novo, para o 3.8 Flash, pelo mesmo protocolo.
Por que esta decisão
Upgrade de mesma família com preço e contrato idênticos dispensa período de convivência: o risco de regressão fica coberto pela suíte e pelos números do anúncio, que mostram salto real de capacidade em código. O alias, as chains e os caps ficaram intocados, que é o mesmo protocolo das trocas de geração anteriores.
FrontierCode 43,6% contra 34,4% do 3.6 (anúncio Google)
340 tok/s medidos pela Artificial Analysis
Contexto mantido: 1M de entrada, 65K de saída
catalog/model_catalog.yaml
src/config.py
02Preço de tabela registrado, promocional recusado
A Google oferece o 3.7 Flash a US$ 0,75 e US$ 3,75 por milhão de tokens até 31 de dezembro de 2026, valor que dobra em 1º de janeiro de 2027. O catálogo registrou o preço de tabela, US$ 1,50 e US$ 7,50, exatamente o que o 3.6 já custava.
Por que esta decisão
Regra da casa, a mesma aplicada ao Sonnet 5: FinOps projeta custo com o preço que vai existir depois da promoção, porque estimativa calibrada em desconto temporário vira estouro de budget na virada do ano. O desconto aparece na fatura como folga, nunca no planejamento como base.
Tabela registrada: US$ 1,50 / US$ 7,50 por Mtok
Promocional vigente: US$ 0,75 / US$ 3,75 até 31/12/2026
03Dois candidatos ao tier economy ficaram de fora, por enquanto
O grok-4.3 e o gemini-3.1-flash-lite foram avaliados como reforço do tier economy e adiados. Nenhum dos dois passou por validação de qualidade contra as rotas que ocupariam, e a régua do parque segue a mesma desde a era de consolidação: entra onde o bench prova vantagem, e catálogo de vendor não é bench.
Por que esta decisão
Inflar o parque com modelo barato sem medição repete o defeito que a correção de preço do Flash expôs em agosto: número bonito no papel e conta diferente na prática. O parque fechou a sprint com os mesmos 13 modelos em 5 providers.
Sprint 26: DAAO em shadow e effort dial ao vivo (fase 2)
O roteador novo decide em paralelo e grava a decisão sem executá-la, enquanto o effort dial dos Claude 5 entra em produção de verdade.
Destaques
Tupla DAAO em shadow mode, 100% log-only: zero enforcement, zero chamada de API
24 células explícitas em política versionada, não as ~160 que a banca apontou como risco
Effort dial ao vivo nos Claude 5: high em architecture e copy, low no bulk
classify_demand passou a considerar tokens de contexto e só rebaixa o tier, nunca eleva
Quatro dívidas técnicas fechadas por derivação
TTL do cache semântico proporcional à nota do judge, pela régua mais restritiva
01O roteador novo mede antes de decidir
A tupla de decisão é dificuldade, necessidade de juiz, exigência de evidência e uso de dado em tempo real, o que fecha 24 células explícitas numa política declarativa e versionada. O número de subtarefas ficou fora da célula e virou campo de trace. A função que calcula a tupla é heurística pura, sem LLM e sem rede. Nesta sprint não há enforcement nenhum: o trace grava a decisão-sombra ao lado do alias realmente planejado, e um script agrega por célula.
Por que esta decisão
A banca de cinco LLMs cobrou duas coisas que viraram requisito de projeto: espaço combinatório pequeno o bastante para cada célula ter tráfego, e shadow traffic antes de produção. A primeira leitura real deu razão ao método. Em 66 entradas, a célula de dificuldade média sem juiz divergiu em 21 de 21, porque o mapa de faixa para apelido ignora que as rotas previstas por tipo de tarefa já escolhem por especialidade. Corrigir a política antes de qualquer enforcement é exatamente para isso que o shadow existe.
Política versionada em shadow-1, com as 24 células travadas por teste de completude
Primeira leitura: 66 entradas em 4 das 24 células
Divergência de 21 em 21 na célula de maior tráfego
src/config.py:DAAO_POLICY
src/daao.py:compute_daao_tuple
scripts/daao_shadow_report.py
02Effort dial: pagar raciocínio só onde ele compra qualidade
A tabela de effort por task type chega ao cliente da Anthropic como parâmetro de saída, e apenas para os modelos com thinking ativo por padrão, porque enviar o campo para a geração 4.x devolve erro 400. São high em architecture, critical_review e nas três rotas de copy; medium no miolo de análise e review; low no bulk e no monitoramento.
Por que esta decisão
Nos Claude 5 o thinking é sempre ativo e consome o mesmo teto da resposta, e o default da API é high quando o campo é omitido. Deixar o default correndo em tarefa de classificação é gastar raciocínio caro para produzir uma linha. O pipeline também passou a injetar o task type nos três pontos que constroem o cliente, sem o que o dial nunca dispararia em run real.
high em 5 task types, medium em 8, low em 9
Gate GEO_CLAUDE5_EFFORT
683 testes verde
src/config.py:EFFORT_BY_TASK_TYPE
src/llm_client.py:_call_anthropic
03Quatro dívidas fechadas eliminando a classe do defeito
O KPI de distribuição passou a ser derivado das configurações por provider, o que devolveu Sol, Luna, Grok e Sonar Pro à base. A validação de balanceamento passou a derivar das rotas previstas por tipo de tarefa, em vez de uma tabela literal que ainda mandava código para o Claude. O conjunto de modelos com thinking por padrão foi unificado, e o teste de paridade virou teste de identidade. E o TTL do cache semântico passou a acompanhar a nota do judge: sete dias acima de 0,9, um dia entre 0,7 e 0,9, uma hora abaixo disso.
Por que esta decisão
Corrigir o caso deixa a classe viva. Cada uma dessas quatro dívidas era uma cópia manual do que o sistema já sabia em outro lugar, então a correção foi apontar para a fonte, não reescrever a cópia.
Quebra de série do KPI datada no docstring
Régua mais restritiva entre cache e judge
src/kpi_history.py
src/orchestrator.py:_validate_balance
src/semantic_cache.py
25
SPRINTObservabilidade12 ago 2026
Sprint 25: observabilidade total no terminal
Os três caminhos que ainda executavam em silêncio passaram a narrar cada chamada, e o parque recebeu o Grok 4.6.
Destaques
SDK call_llm emite [CALL] com alias, modelo, tipo, chain e tentativa, mais [CALL-OK] ou [CALL-FAIL]
plan e run --dry-run imprimem o mesmo planning report do run real, sem executar tarefa nenhuma
board narra o planejamento por persona e emite [EXEC] e [OK] por expert
Grok 4.6 entra no lugar do 4.5 pelo mesmo preço, com id literal fixado
Piso de max_tokens de 4.096 nos Claude 5, onde o thinking divide o teto com a resposta
Adapter da Agent API da Perplexity pronto e desligado por padrão
Dupla contabilidade FinOps do SDK eliminada: o gasto era registrado duas vezes
01Toda chamada de LLM se anuncia, em qualquer caminho de código
O SDK avulso era 100% silencioso no caminho feliz. Agora emite em stderr o alias, o model id, o tipo da tarefa, a chain e o número da tentativa, com resultado explícito ao fim. Os comandos plan e run --dry-run passaram a imprimir o mesmo planning report do run real via preview_assignments(), então ver quem executaria o quê custa apenas a decomposição. O board ganhou bloco de planejamento por persona e eventos por expert.
Por que esta decisão
A ordem foi direta: sempre que o orquestrador for acionado no terminal, ele reporta como cada LLM está sendo usado. Observabilidade que depende de flag some justamente no dia em que a run quebra, então nada disso tem chave para ligar.
3 caminhos silenciosos fechados: SDK, plan/dry-run e board
Opt-out por GEO_CALL_REPORT, nunca opt-in
624 testes verde na entrega
src/geo_orchestrator_sdk.py
cli.py:plan
src/orchestrator.py:preview_assignments
02Usar o próprio board como banca expôs cinco defeitos reais
O run de US$ 0,089 que serviu de dogfooding derrubou cinco problemas medidos: o Opus 5 abortava com teto de 2.000 tokens porque o thinking divide o max_tokens com a resposta; o GPT-5.5 faturava 2.000 tokens de saída vazia; o sonar-deep-research devolvia zero tokens no slot; havia truncamento no teto; e as respostas pagas eram persistidas cortadas em cerca de 250 caracteres.
Por que esta decisão
Conteúdo pago jogado fora é o pior tipo de defeito silencioso, porque a fatura chega inteira e o material não. O preview de wave também imprimia t1->? desde 19 de maio, com o AttributeError engolido por um except genérico.
Run de dogfooding: US$ 0,089
5 defeitos do próprio board corrigidos
src/board.py
src/llm_client.py
03Grok 4.6 e o cuidado com alias instável
A sondagem viva de 12 de agosto mostrou o id literal servido, resposta 200 em 1,85s e preço idêntico ao do 4.5, com cached input a US$ 0,50 por Mtok e contexto de 500K. O modelo raciocina por padrão, com reasoning_tokens faturados como output. O papel não mudou: segue aditivo em social e marca, fora de código e de copy premium.
Por que esta decisão
O apelido grok-latest aponta para o grok-4.3, uma geração atrás. Fixar o id literal evita que um upgrade silencioso do vendor rebaixe o parque sem ninguém perceber.
Grok 4.6 a US$ 2/US$ 6 por Mtok
Contexto de 500K
Grok 4.5 movido para DEPRECATED_MODELS
catalog/model_catalog.yaml
src/config.py
14-24
FASEPark & Qualityjun a jul 2026
Parque e qualidade: Sprints 14 a 24 (jun-jul/2026)
Onze sprints montaram o parque por evidência de bench e fecharam os loops de qualidade: o pipeline deixou de ser feed-forward.
Destaques
Tier frontier: o Claude Fable 5 assume architecture e critical_review em complexity high
Parque consolidado por evidência: Groq sai na Sprint 16, xAI volta com busca live na timeline do X
GPT-5.6 Sol entra em code por liderar o AA Coding Agent Index; Luna reforça as chains de volume
Verificador em cascata entre waves e painel de 3 juízes de famílias distintas nos gates premium
Router vivo: janela de 50 amostras por (task_type, alias) domina o score
Timeout por requisição, escrita atômica dos state files e SDK call-level com call_llm()
Sprint 24: judge com consequência, code verifier que executa o código e replan com abort
01O parque foi montado por bench independente, nunca por completude de família
Cada entrada e cada saída de modelo teve origem em medição externa validada contra a API viva. O Fable 5 abriu o tier frontier por distância em SWE-Bench Pro; o Groq saiu por ser bulk substituível a custo neutro; a xAI saiu quando perdeu a busca na timeline do X e voltou um dia depois, quando o próprio vendor devolveu o recurso pela Agent Tools API; o GPT-5.6 Sol entrou em code por liderar o AA Coding Agent Index, e o irmão Terra ficou de fora por estar dominado na fronteira de Pareto.
Por que esta decisão
Inserir modelo por catálogo de vendor produz parque caro e indefensável. A régua que sobreviveu foi outra: entra onde o bench prova vantagem, sai de onde não prova, e a validação é contra a conta, não contra o material de marketing. Foi essa mesma régua que trouxe o Groq de volta na Sprint 30, quando o preço de tabela do gpt-oss-120b o tornou a âncora barata do bulk.
6 providers viraram 4 e voltaram a 5 no período; o sexto, Groq, voltou em 07/09/2026
13 modelos configurados ao fim do período
37 sentinelas de teste blindam o parque contra regressão por drift
02Qualidade sem consequência é só telemetria
As Sprints 17, 18 e 24 fecharam os loops do pipeline. O verificador em cascata pontua output do tier economy antes de ele alimentar a wave seguinte e escala a task quando o score fica abaixo de 6,0. O router passou a aprender com uma janela de 50 amostras recentes em vez da média histórica. E a reprovação do judge ganhou efeito: re-executa as duas piores tarefas, re-julga e entrega marcada com quality_flag mais exit code próprio.
Por que esta decisão
Dois mecanismos estavam implementados e nunca eram chamados, então o router aprendia cego para qualidade e um run reprovado era entregue igual a um aprovado. As Sprints 17 e 18 foram especificadas pelo próprio orquestrador, num run de 13 tarefas em 7 waves que custou US$ 0,4638.
Smoke real da Sprint 24: US$ 0,24 e 7 de 7 tarefas com o Google inteiramente fora do ar
Suíte chegou a 531 testes verde no fim do período
1-13
FASEFoundationabr a mai 2026
Fundação: Sprints 1 a 13 (abr-mai/2026)
Seis semanas construíram o que hoje é infraestrutura invisível: waves paralelas, roteamento por task type, cache em dois níveis, governança de custo e resiliência a outage.
Destaques
Pipeline em waves paralelas: o DAG de dependências vira níveis executados com asyncio.gather()
Roteamento por task type com fallback chains cross-provider
Cache exato somado a cache semântico por similaridade sobre a descrição da task
FinOps com limite diário por provider, auto-calibração de custo e rollback
Circuit breaker por provider: 3 falhas abrem o circuito por 90s
COPY PREMIUM ONLY e Perplexity prioritária em research, as duas diretrizes que sobrevivem intactas
01O que a fase de fundação deixou pronto
As Sprints 1 a 13 levaram o projeto de um CLI que ignorava o roteador a um pipeline com waves topológicas, roteamento adaptativo, dois níveis de cache, governança de custo e resiliência a outage. A Sprint 12 fixou as duas diretrizes editoriais que seguem valendo, COPY PREMIUM ONLY e prioridade da Perplexity em research; a Sprint 13 validou o conjunto numa bateria E2E que fechou 6 gaps de roteamento.
Por que esta decisão
Cartão a cartão, essa fase empurrava para baixo o que mudou nas últimas semanas. O histórico completo segue no repositório; aqui fica o que ela entregou.
Suíte saiu de 51 para 223 testes verde no período
Sprint 13: 6 gaps de roteamento fechados na bateria E2E
Backlog priorizado · 14 itens, 6 com sprint alvo
Cada item nasce de um paper de 2025-2026 (AdaptOrch, DAAO, FrugalGPT, RCR-Router, Mixture of Agents) ou de um achado de revisão crítica sobre o parque em produção, e entra com critério de aceite escrito. Itens já entregues saíram da lista: a reintegração do xAI na Sprint 19, o SDK call-level na 22, a inserção do GPT-5.6 na 23 e o fechamento de loops na 24. Os achados de FinOps e KPI abaixo seguem abertos.
P0 · Bloqueia produção · 3P1 · Degrada qualidade · 8P2 · Evolutivo · 3medido em produção · 5
P0 · Bloqueia produção(3 itens)
Prioridade P0Sprint alvo: Sprint 31Esforço: 0,5 dia
FinOps registra cada chamada de tarefa duas vezes
Toda chamada feita pelo pipeline passa por dois pontos de registro de custo: o cliente de LLM grava com o id sintético _llmclient_<apelido> e o pipeline grava de novo com o id real da tarefa.
Toda chamada feita pelo pipeline passa por dois pontos de registro de custo: o cliente de LLM grava com o id sintético _llmclient_<apelido> e o pipeline grava de novo com o id real da tarefa. Não há deduplicação, então o gasto diário por provedor e a lista de custos por tarefa saem inflados. Chamadas fora do pipeline (juiz, canário, sumarizador) são registradas uma vez só.
Justificativa
O gasto registrado alimenta os três anéis de orçamento. Com o registro em dobro, o teto diário por provedor e o teto global de US$ 300 são consumidos duas vezes mais rápido do que a fatura real, e o redirecionamento para o modelo mais barato dispara antes da hora.
Critérios de aceitação
Um único ponto de registro por chamada de tarefa, com o id real da tarefa
Teste que reproduz uma chamada de pipeline e confere um registro só no FinOps
Relatório de sessão igual à soma das chamadas feitas
Origem: Mapa do algoritmo no master 3c88f10 (finops.py:394; llm_client.py:826; pipeline.py:2178)
Prioridade P0Sprint alvo: Sprint 31Esforço: 0,5 diamedido em produção
Teto para a busca viva do Grok em re-execução de qualidade
Em dois runs reais (07/09 e 08/09) a re-execução de qualidade escolheu o Grok 4.6 com busca viva como melhoria de uma realtime_search e gastou 297 mil e 287 mil tokens de entrada numa única chamada: US$ 0,67 e US$ 0,90 por tarefa, sem que o resultado substituísse o original.
Em dois runs reais (07/09 e 08/09) a re-execução de qualidade escolheu o Grok 4.6 com busca viva como melhoria de uma realtime_search e gastou 297 mil e 287 mil tokens de entrada numa única chamada: US$ 0,67 e US$ 0,90 por tarefa, sem que o resultado substituísse o original. Falta limite de resultados ou de tokens de entrada na busca e um seed de custo realista para o alias.
Justificativa
É a rota mais cara do parque quando a re-execução a escolhe, e o custo não aparece no relatório de execução nem no cost-report, só no FinOps. Sem teto, cada reprovação de juiz numa tarefa de web viva pode custar mais do que o run inteiro.
Critérios de aceitação
Limite de tokens de entrada ou de resultados na busca viva do Grok, configurável por variável de ambiente
Seed de custo do alias grok calibrado pelo faturado em cost_in_usd_ticks dos dois runs
Run de regressão com a mesma demanda de 08/09 abaixo de US$ 0,20 na re-execução
Origem: E2E real de 08/09/2026 (output/.finops/task_costs.json)
Prioridade P0Sprint alvo: Sprint 31Esforço: 1 diamedido em produção
Relatório de execução com o custo inteiro da sessão
O execution_*.json soma só o custo do resultado final de cada tarefa.
O execution_*.json soma só o custo do resultado final de cada tarefa. Na sessão de verificação de 08/09 ele mostrou menos da metade do que o FinOps registrou em 16 chamadas: decomposição, cinco chamadas de juiz, painel e duas re-execuções ficaram fora. O drift_detector acusa subestimativa de 4,28x na média dos últimos runs pelo mesmo motivo.
Justificativa
Relatório que diverge do FinOps em 2x deixa de servir como instrumento de decisão. O custo de juízes e re-execuções é parte do preço da qualidade e precisa aparecer onde o operador olha.
Critérios de aceitação
Total do relatório igual ao total do FinOps para a mesma sessão, com quebra por decomposição, execução, juízes, painel e re-execuções
cost-report lê a mesma fonte
Teste que reproduz a sessão de 08/09 com as 16 chamadas
Origem: Divergência medida em 08/09/2026, registrada no bloco Evidência de campo da aba Visão geral
P1 · Degrada qualidade(8 itens)
Prioridade P1Sprint alvo: Sprint 31Esforço: 0,5 diamedido em produção
Piso de complexidade para critical_review e architecture
O decompositor rotulou a critical_review como medium em 08/09 (e como low no run de controle), então a escada da família Claude mandou a tarefa ao Sonnet 5 na primeira passada; o Fable 5.1 só entrou porque o loop de qualidade re-executou a pior tarefa no degrau acima.
O decompositor rotulou a critical_review como medium em 08/09 (e como low no run de controle), então a escada da família Claude mandou a tarefa ao Sonnet 5 na primeira passada; o Fable 5.1 só entrou porque o loop de qualidade re-executou a pior tarefa no degrau acima. O degrau frontier existe, mas nunca dispara na primeira passada com as etiquetas que o decompositor produz.
Justificativa
Pagar frontier pela re-execução custa duas chamadas em vez de uma e só acontece quando o juiz reprova. Se a demanda pede alta complexidade, critical_review e architecture não deveriam começar abaixo de high.
Critérios de aceitação
Piso por tipo aplicado depois da decomposição e antes do roteamento, com registro no planning report
Run de 08/09 reproduzido com o Fable 5.1 na primeira passada da critical_review
Teste de contrato em tests/test_sprint31_*.py
Origem: Defeito 3 da verificação com crédito de 08/09/2026
Prioridade P1Sprint alvo: Sprint 31Esforço: 0,25 diamedido em produção
Piso de max_tokens em code sugerido pelo decompositor
O GPT-5.6 Sol devolveu o script Python com testes incompleto em 08/09 porque o max_output_tokens de 4.000 veio do max_tokens sugerido pelo decompositor.
O GPT-5.6 Sol devolveu o script Python com testes incompleto em 08/09 porque o max_output_tokens de 4.000 veio do max_tokens sugerido pelo decompositor. Um script com testes não cabe em 4.000 tokens, e o cliente aceitou o corte.
Justificativa
É o mesmo defeito que a Sprint 28 corrigiu para o deep-research da Perplexity, agora em code: o teto sugerido por outro modelo vira truncamento silencioso de saída paga.
Critérios de aceitação
Piso de max_tokens por tipo para code e code_generation, acima da sugestão do decompositor
finish_reason=length em code emite WARNING de truncamento
Tarefa t3 de 08/09 reproduzida sem corte
Origem: Tarefa t3 do E2E real de 08/09/2026
Prioridade P1Sprint alvo: Sprint 31Esforço: 0,25 diamedido em produção
Recarga automática nas três contas ou doctor --live diário com alerta
Anthropic, OpenAI e Perplexity estavam com saldo negativo ou zero em 07/09 e foram recarregadas à mão em 08/09; a recarga automática segue desligada nas três.
Anthropic, OpenAI e Perplexity estavam com saldo negativo ou zero em 07/09 e foram recarregadas à mão em 08/09; a recarga automática segue desligada nas três. Nos 30 dias anteriores a Perplexity consumiu US$ 206 e a xAI US$ 184, então o saldo cobre cerca de duas semanas nesse ritmo.
Justificativa
Provider sem saldo sai da rota por GEO_OUTAGE_TTL, e o run segue com o parque reduzido sem que ninguém perceba até olhar o doctor. Descobrir o crédito zerado pelo run reprovado é o modo mais caro de descobrir.
Critérios de aceitação
Recarga automática ligada nas três contas, ou
doctor --live agendado diariamente com alerta quando qualquer provider sai de OK
Registro do saldo por provider no histórico de KPIs
Origem: Seção 1 da verificação com crédito de 08/09/2026
Prioridade P1Sprint alvo: A decidirEsforço: 1 dia
Corrigir o mapa de tier para alias da política DAAO antes de qualquer enforcement
A primeira leitura do shadow (66 entradas em 4 das 24 células) mostrou a célula de dificuldade média sem juiz divergindo em 21 de 21, e a de evidência exigida em 20 de 20.
A primeira leitura do shadow (66 entradas em 4 das 24 células) mostrou a célula de dificuldade média sem juiz divergindo em 21 de 21, e a de evidência exigida em 20 de 20. A sombra escolhe pelo tier e cai no gpt4o; a rota real escolhe por especialidade e vai para o Gemini em analysis e para a Perplexity em research. A política segue em shadow-1 em 08/09/2026.
Justificativa
É o resultado que o shadow existe para produzir, e ligar enforcement agora trocaria roteamento por especialidade por roteamento por tier genérico, que é pior. Cada mudança na tabela exige bump da versão da política, porque o trace grava a versão por linha e agregados de versões diferentes não podem se misturar em silêncio.
Critérios de aceitação
Política shadow-2 leva a rota prevista do tipo de tarefa em conta antes da faixa
Concordância acima de 80% nas células com tráfego, medida pelo report de shadow
Ablação de uma dimensão por vez documentada antes de propor enforcement
Origem: Leitura do shadow da Sprint 26 (output/.daao_shadow.jsonl)
Prioridade P1Sprint alvo: A decidirEsforço: 3 dias
Decidir a topologia (paralela, sequencial, hierárquica ou híbrida) antes de escolher o modelo.
Decidir a topologia (paralela, sequencial, hierárquica ou híbrida) antes de escolher o modelo. Hoje o pipeline decide modelo tarefa a tarefa e a topologia emerge do DAG implícito.
Justificativa
O paper reporta ganho de 12% a 23% sobre as baselines. Ficou explicitamente atrás do DAAO na fila: decidir topologia com a mesma heurística que ainda não sabemos calibrar seria empilhar aposta sobre aposta. A ordem correta é ler o shadow primeiro.
Critérios de aceitação
src/topology_router.py classifica a demanda entre as quatro topologias
Decomposer recebe a dica de topologia e gera plano alinhado
5 demandas de exemplo cobrindo cada topologia, mais run real comparativo
KPI topology_match_rate no histórico
Origem: Paper AdaptOrch 2602.16873 · adiado com justificativa na Sprint 26
Prioridade P1Sprint alvo: A decidirEsforço: 1 dia
Bateria E2E real automatizada em CI, contra os 6 providers
A bateria contra APIs reais valida os contratos que o mock não alcança, e em 08/09/2026 ainda roda a mão: foi assim que os três defeitos da PR #24 apareceram.
A bateria contra APIs reais valida os contratos que o mock não alcança, e em 08/09/2026 ainda roda a mão: foi assim que os três defeitos da PR #24 apareceram. Falta virar workflow semanal, protegido por variável de ambiente e com relatório anexado como artifact.
Justificativa
Regressão silenciosa de provider passa despercebida entre baterias manuais, e foi assim que o timeout congelado do pool sobreviveu semanas. O custo por run é baixo o bastante para caber num agendamento semanal.
Critérios de aceitação
Marker que pula sem GEO_E2E_REAL=1
Demanda mínima de cerca de 6 tarefas com budget de US$ 1
Os 6 provedores configurados cobertos numa única run
Workflow semanal separado, com relatório anexado
Origem: Bateria E2E manual da Sprint 13, repetida à mão em 07 e 08/09/2026
Prioridade P1Sprint alvo: A decidirEsforço: 2 dias
Cache semântico por embeddings, se a similaridade por palavras ficar aquém
Trocar a similaridade por palavras (TF-IDF com cosseno) por embeddings reais no cache semântico.
Trocar a similaridade por palavras (TF-IDF com cosseno) por embeddings reais no cache semântico. Adiado na Sprint 26: o TTL proporcional à nota do judge, que entrou na mesma sprint, captura a maior parte do ganho sem nenhuma chamada de rede nova.
Justificativa
A banca questionou o custo por lookup, e ele é real: cada consulta ao cache passaria a custar uma chamada de embedding. A decisão depende de dado que ainda não temos, a taxa de acerto da similaridade por palavras em produção.
Critérios de aceitação
Taxa de acerto do cache semântico medida em produção por pelo menos duas semanas
Custo por lookup do embedding comparado ao custo do miss evitado
Decisão registrada mesmo se for não implementar
Origem: Adiado com justificativa na Sprint 26
Prioridade P1Sprint alvo: A decidirEsforço: 0,5 dia
Publicar o dashboard HTML em alexandrecaramaschi.com
O comando que gera o dashboard auto-contido já existe, mas o HTML vive apenas na máquina local.
O comando que gera o dashboard auto-contido já existe, mas o HTML vive apenas na máquina local. Falta o pipeline diário que gera e publica.
Justificativa
Publicar troca o print estático pelo estado vivo do sistema, que é o que a página de descrição deveria mostrar. Enquanto isso não existe, todo número operacional da página depende de manifest ou de texto escrito à mão.
Critérios de aceitação
Action diária roda cli.py dashboard --html
HTML publicado em rota estável do site
Link a partir da página /geo-orchestrator
Origem: Dashboard HTML existente desde a Sprint 7
P2 · Evolutivo(3 itens)
Prioridade P2Sprint alvo: A decidirEsforço: 1 dia
Endpoint /metrics em formato Prometheus
Servir as métricas em formato de exposição compatível com scraping do Prometheus, a partir do histórico de KPIs que já existe em jsonl.
Servir as métricas em formato de exposição compatível com scraping do Prometheus, a partir do histórico de KPIs que já existe em jsonl.
Justificativa
Quem adota o orquestrador em escala precisa plugar na stack de observabilidade que já roda. O custo é baixo porque os KPIs já existem; falta só o formato.
Critérios de aceitação
Conversão do histórico de KPIs para o formato de exposição
Tipos corretos: counter, gauge e histogram
Labels por provider e por alias
Configuração de scrape documentada
Origem: Roadmap empresarial
Prioridade P2Sprint alvo: A decidirEsforço: 1 dia
Webhook de alerta em drift e em estouro de budget
Disparar POST com payload estruturado quando o drift dispara ou quando um provider passa de 95% do limite diário.
Disparar POST com payload estruturado quando o drift dispara ou quando um provider passa de 95% do limite diário.
Justificativa
Hoje o alerta vive no log e no doctor sob demanda, o que só funciona para quem está olhando. Um webhook genérico atende Slack, Discord, Teams e PagerDuty sem integração dedicada.
Critérios de aceitação
Função de envio com retry
Configuração por variável de ambiente
Templates para drift, budget e falha de calibração
Janela de deduplicação para não inundar o canal
Origem: Roadmap empresarial
Prioridade P2Sprint alvo: A decidirEsforço: 3 dias
Multi-tenant com namespace de KPIs por cliente
Prefixar output, histórico de KPIs e calibração de custo por tenant, com limites FinOps próprios.
Prefixar output, histórico de KPIs e calibração de custo por tenant, com limites FinOps próprios.
Justificativa
Isolar dados por cliente é pré-requisito para empacotar o orquestrador como produto. Sem isso, qualquer operação multi-cliente mistura custo e qualidade de contas diferentes no mesmo arquivo.
Critérios de aceitação
Variável de ambiente define a raiz de saída por tenant
Limites FinOps por tenant
doctor e dashboard aceitam a flag de tenant
Retro-compatibilidade com o tenant padrão
Origem: Roadmap comercial
Para quem acompanha o projeto, a linha do tempo diz em que sprint cada regra desta página nasceu, e o backlog diz qual regra ainda pode mudar. Para quem lê o custo hoje, o número do registro de gasto vale dobrado nas tarefas até a Sprint 31 fechar o registro duplo.
Quanto o orquestrador deixa gastar, e o que ele faz quando o teto chega?
Três anéis limitam o gasto: 25 dólares por execução, 300 por dia somando os provedores e um teto diário por provedor. Os dois primeiros abortam antes de executar; o terceiro, a 95% do teto diário de um provedor, desvia a chamada para o modelo mais barato disponível e só a dá por falha quando nenhum modelo cabe.
O primeiro anel roda antes do plano executar: se a estimativa das tarefas passa de 25 dólares, o processo sai com código 1, e a opção de forçar ignora esse anel. O segundo roda antes do pipeline, com a mesma estimativa contra o teto por execução e contra o teto diário total de 300 dólares; a opção de forçar não ignora este. O terceiro roda a cada chamada: a 80% do teto diário do provedor sai um alerta, a 95% a chamada é desviada para o modelo mais barato que ainda cabe. Os tetos diários por provedor são 100 dólares na Anthropic, 70 na OpenAI, 60 na Google, 40 na Perplexity, 40 na xAI e 15 na Groq; a soma passa de 300 de propósito, para que o teto total freie o conjunto antes de cada provedor bater o seu.
Imagine a redação do exemplo caindo na Anthropic com o dia a 96% do teto. A chamada é desviada para o modelo mais barato disponível, hoje o Groq, filtrado pelo teto de participação da família (a fatia máxima do plano que uma família recebe); se o modelo mais barato também estouraria o teto de participação, o sistema procura na fila de reservas do tipo alguém que caiba nos dois e, se ninguém cabe, mantém o mais barato e grava um aviso explícito. Orçamento é limite duro; participação é limite mole, e a violação da mole nunca é silenciosa.
O sistema mantém duas réguas de custo, e elas medem coisas diferentes. Procure na figura o que cada uma soma: o relatório de execução conta só o resultado final de cada tarefa; o registro de gasto conta toda chamada, incluindo decomposição, juízes, verificadores e re-execuções. O número que vale para os tetos é o do registro de gasto.
Onde cada chamada é registrada, e por que o registro de gasto conta dobrado
A seta vermelha tracejada é o defeito conhecido: toda chamada de tarefa entra no registro de gasto duas vezes, uma pelo cliente de modelos (llm_client.py:826) e outra pelo pipeline (pipeline.py:2178), com ids de tarefa diferentes e sem deduplicação, o que infla o gasto do dia e consome os tetos em dobro. Chamadas fora do pipeline (juiz, canário, sumarizador) entram uma vez. Correção aberta para a Sprint 31 (finops.py:394).
Registro de gasto: a régua dos tetos
Incremento atômico em SQLite por dia e provedor, com cópia em JSON; falha do banco degrada para memória sem derrubar a chamada. É o número que os três anéis e os alertas de 80% leem, e por isso o registro duplo aperta os tetos antes da hora.
Relatório de execução: a régua do entregável
Guarda o custo do resultado final de cada tarefa, o plano e o veredito. Não soma decomposição, juízes, verificadores, tentativas falhas nem re-execuções descartadas; por isso fica sempre abaixo do registro de gasto, mesmo sem o defeito.
O laço de governança recalibra a tabela de custo médio por modelo sozinho. Procure na figura o ponto em que uma calibração é rejeitada por sair da banda: um candidato só entra com três ou mais amostras nas últimas 30 execuções e dentro de 0,2 a 5 vezes o valor atual, para que uma execução anômala não contamine a tabela. Se as três últimas execuções erram a estimativa fora da faixa de 0,7 a 1,5, o desvio dispara a recalibração e o resultado é anexado ao resumo da execução.
Três anéis param o gasto em três pontos
Anel 1: Por run, antes do pipeline, depois do cache
Condição: A soma dos custos médios calibrados das tarefas que restaram passa do limite por run.
Limiar: US$ 25 (BUDGET_LIMIT, GEO_BUDGET_LIMIT)
Efeito: Aborta com código de saída 1 antes de qualquer chamada de execução. A opção de forçar ignora este anel.
orchestrator.py:634-648; config.py:1339
Anel 2: Por dia, global, na entrada do pipeline, antes da primeira onda
Condição: O estimado passa de US$ 25, ou o gasto do dia mais o estimado passa do teto global diário.
Limiar: US$ 300 por dia (FINOPS_DAILY_GLOBAL), abaixo da soma dos tetos por provedor (US$ 325) de propósito: freio agregado
Efeito: Aborta o pipeline. A opção de forçar não vale. A opção de forçar não vale aqui.
Anel 3: Por provedor, por chamada, em cada chamada de modelo
Condição: O provedor escolhido está em 95% do seu teto diário (Anthropic 100, OpenAI 70, Google 60, Perplexity 40, xAI 40, Groq 15), ou o global em 95% de 300.
Limiar: 0,95 do teto diário
Efeito: Redireciona para o modelo mais barato disponível (âncora: Groq), filtrado pelo teto de participação quando dá; se ninguém satisfaz os dois, o mais barato vence e a violação do teto de participação é registrada em aviso. Se o alvo também estourou, a tarefa recebe resultado falho e a fila avança. A opção de forçar não vale aqui.
O anel de fora é o dia inteiro; dentro dele cabem as execuções, e dentro de cada execução as chamadas. O tracejado âmbar em cada anel marca os 80%, onde o registro de gasto passa a avisar sem bloquear. Orçamento é restrição dura; teto de participação é brando. Quando os dois conflitam no redirecionamento por chamada, o orçamento vence e a violação do teto de participação nunca é silenciosa.
Alertas do registro de gasto: nome, limiar, efeito e fonte
Alerta
Limiar
Efeito
Fonte
Alerta de 80%
0,80 do teto diário por provedor ou global
Aviso no log a cada verificação e a cada registro de custo, sem bloquear.
finops.py:44-45, :320, :453
Custo real 2x acima do estimado
custo corrente maior que 2 vezes o estimado
Só aviso no log ao fim do run; nada aborta.
orchestrator.py:972-978
Deriva de estimativa
os 3 últimos runs com precisão de estimativa fora de 0,7 a 1,5
Recalibração automática dos custos médios sobre os 30 últimos runs, com banda de rejeição (5x acima ou 0,2x abaixo do valor atual é descartado) e cópia de segurança para reverter.
gasto do dia acima de 4 vezes a mediana dos 14 dias anteriores e delta de ao menos US$ 1
Aviso pós-run; exige ao menos 5 dias de base.
spend_watch.py:60-68, :128
Quando a tabela de custo médio se recalibra sozinha
A estimativa de cada execução usa um custo médio por modelo. Se os três últimos runs erram a estimativa fora da faixa de 0,7 a 1,5, o desvio dispara a recalibração sobre os 30 últimos relatórios; um candidato só entra com três ou mais amostras e dentro de 0,2 a 5 vezes o valor atual, para que uma execução anômala não contamine a tabela. O arquivo anterior vira cópia de segurança, e um comando reverte.
Como o orquestrador entra num pipeline de automação
Por três pontos e um contrato de códigos de saída. O comando doctor no modo estrito devolve 1 em qualquer verificação crítica e serve de portão; o modo ao vivo faz uma chamada real por provedor, classifica quem está sem saldo ou sem chave e grava um retrato que o roteador usa por 24 horas para pular provedor caído sem pagar a ida e volta. O servidor de saúde expõe um endereço de vida e um de métricas para sondas, com token opcional. O painel em HTML sai como arquivo único para qualquer servidor estático.
Os códigos de saída de uma execução: 0 entregou sem ressalva; 3 entregou marcado pelo juiz; 1 teve tarefa falha ou estourou um teto de custo; 4 não conseguiu montar o plano e não gastou. Um agendador que trata 3 como sucesso com revisão e 4 como falha barata cobre os quatro casos.
Perguntas frequentes
As respostas descrevem regras e limiares do algoritmo no parque v5.0, de setembro de 2026, sem dado de uma execução específica.
Como eu vejo qual modelo vai executar cada tarefa antes de gastar?
Rodando o comando de plano ou a execução em modo de simulação: os dois imprimem a faixa da demanda, as ondas em ordem e, por tarefa, o modelo, o id dele e a origem da decisão, e param ali, com a decomposição como única chamada paga. Na execução real o mesmo bloco sai antes da primeira tarefa, e cada tarefa abre e fecha com uma linha própria, mostrando a fila de reservas quando precisa cair para a próxima posição. Nada disso depende de opção ligada, porque a observabilidade que precisa ser ligada some no dia em que a execução quebra.
O que é o roteador-sombra e por que ele ainda não decide nada?
Uma heurística sem modelo calcula quatro sinais por tarefa (dificuldade, se precisa de juiz, se exige evidência e se depende de dado ao vivo), consulta uma tabela de 24 células e grava a decisão ao lado do modelo que o roteador real escolheu. A execução ignora a decisão-sombra. A tabela só entra em produção quando as duas colunas concordam na maioria dos casos, e a primeira leitura mostrou que a política de faixa genérica escolhe pior do que a rota por tipo de tarefa, que já escolhe por especialidade.
O que o nível de esforço muda no custo e na qualidade?
Nos modelos que raciocinam antes de responder, o raciocínio consome o mesmo teto de tokens que a resposta, e o padrão da API é o nível mais alto. Deixar esse padrão numa classificação é pagar raciocínio caro para produzir uma linha. A tabela por tipo de tarefa define alto em arquitetura, revisão crítica e nas três rotas de redação; médio em análise, pesquisa e revisão; baixo em classificação, extração, resumo, tradução e monitoramento. O parâmetro só vai aos modelos que o aceitam.
Quando a execução usa cache em vez de chamar um modelo?
Quando encontra a mesma tarefa guardada e ainda válida. A consulta é por semelhança primeiro (cosseno acima de 0,85 entre descrições do mesmo tipo de tarefa) e por igualdade exata depois, com 24 horas de validade. Redação e pesquisa só aceitam igualdade exata. Na escrita, o prazo segue a nota do juiz: 48 horas com 80% ou mais, 24 horas com 60% ou mais, nada abaixo disso; uma tarefa reprovada, degradada ou construída sobre lacuna nunca entra no cache, mesmo em execução aprovada.
O que acontece quando o juiz reprova a entrega?
A entrega sai marcada, e o sistema tenta melhorar antes. Com nota abaixo de 60%, o juiz avalia uma amostra de até seis tarefas (as duas piores do verificador entre ondas, até três premium e uma sorteada com semente fixa), confirma a reprovação se uma premium reprovou ou metade da amostra reprovou, e refaz as duas piores num modelo um degrau acima, com as críticas do juiz no prompt. A nova versão só substitui a antiga se a nota subir. Se a execução continua reprovada, a entrega sai com a marca, o cache fica vazio e o processo devolve código 3. A entrega nunca é segurada.
Por que redação só roda em modelos premium e pesquisa prioriza a Perplexity?
Redação, copywriting e SEO seguem a fila gpt-5.5, Opus 5, Gemini Pro e Perplexity, com Flash, Haiku, Luna, Groq e Astra vetados em qualquer posição: voz densa em português exige raciocínio nativo, e o rebaixamento automático de faixa já custou um curso publicado com centenas de acentos faltando, em 14 de maio de 2026. Em pesquisa, citação verificável vence velocidade e custo: a fila começa na Agent API da Perplexity com citações e recência de um ano, e a saída sem fonte, link ou referência reprova no gate heurístico e passa a vez para a próxima posição.
xAI Grok (com K) é a mesma coisa que Groq (com Q)?
Não. A xAI (Grok com K) é a empresa de Elon Musk, dona dos modelos grok e da busca ao vivo na linha do tempo do X. A Groq Inc (com Q) fabrica chips de inferência e serve modelos abertos em alta velocidade. Os dois estão no parque desde a Sprint 30, de 7 de setembro de 2026: o Grok 4.6 em escuta social, monitoramento de marca e como segunda rota de web viva; o Groq como degrau barato do trabalho curto em volume, âncora do desvio por custo e terceira rota de web viva. Nenhum dos dois entra em redação.
Como o teto por família e o piso de diversidade evitam concentração?
O teto soma os modelos de cada família (Anthropic 45%, OpenAI 50%, Google 60%, Perplexity 50%, xAI 35% e Groq 35% do plano) e a pré-alocação move a tarefa de menor complexidade de quem passou do teto para a próxima família da fila; arquitetura e revisão crítica nunca são movidas primeiro. Em planos complexos com cinco ou mais tarefas, o piso exige ao menos quatro famílias distintas, promovendo uma tarefa por família ausente. A soma dos tetos menos qualquer provedor fica acima de 1,40, então todo plano fecha mesmo com uma família inteira fora do ar. Quando nenhum movimento respeita o teto, a distribuição fica como está e o aviso vai para o log.
Como o disjuntor por provedor funciona?
Um disjuntor por família: três falhas seguidas de transporte (erro 5xx, estouro de tempo ou limite de requisições) abrem o circuito por 90 segundos, e as tarefas seguintes caem para a próxima posição da fila de reservas em milissegundos, sem esperar o prazo. Depois vem o meio-aberto: um sucesso fecha, uma falha reabre. Erros de saldo e de autenticação não tocam o disjuntor; eles marcam a família como em queda por 30 minutos, e a primeira resposta boa limpa a marca.
Por que o Opus não é padrão de código nem de revisão?
Porque cada ponto extra de qualidade precisa pagar o prêmio. Código assentou no GPT-5.6 Sol, com o GPT-6 Astra só em complexidade alta, e revisão no Sonnet 5, com piso no Sonnet (revisão nunca cai ao Haiku). O Opus 5 segue onde o prêmio se paga: arquitetura e revisão crítica abaixo da faixa de topo, segunda posição da fila do Fable 5.1 para cobrir recusa sem trocar de família, e segunda posição da fila de redação.
Posso usar o orquestrador em produção sem temer gasto descontrolado nem provedor fora do ar?
Sim, com uma ressalva de contabilidade. Três anéis limitam o gasto: 25 dólares por execução e 300 por dia no total abortam antes de executar; a 95% do teto diário de um provedor, a chamada é desviada para o modelo mais barato e só falha quando nenhum cabe. Em queda de provedor, o disjuntor e a fila de reservas seguram o pipeline, e o piso de diversidade garante que nenhum plano depende de uma família só. A ressalva: até a Sprint 31, o registro de gasto conta cada chamada de tarefa duas vezes, então os tetos diários chegam na metade do gasto real, e o relatório de execução soma só o resultado final de cada tarefa. O número que vale é o do registro de gasto, dividido por dois nas tarefas.
Como integro em CI/CD?
Três pontos nativos e um contrato de saída: o doctor no modo estrito devolve 1 em qualquer verificação crítica e serve de portão; o servidor de saúde expõe um endereço de vida (200 ou 503) e um de métricas para sondas, com token opcional; o painel em HTML sai como arquivo único. Os códigos de saída da execução são 0 (entregou), 3 (entregou marcado pelo juiz), 1 (tarefa falha ou teto de custo) e 4 (não montou o plano e não gastou).
O que está no backlog imediato?
O registro duplo de gasto abre a Sprint 31: cada chamada de tarefa é gravada no cliente e no pipeline, o que infla o gasto do dia e consome os tetos em dobro. Seguem um teto para a busca ao vivo do Grok em re-execução de qualidade, um relatório de execução que some juízes e re-execuções, um piso de complexidade para revisão crítica e arquitetura, um piso de tokens em código, a correção da política do roteador-sombra, o roteamento por topologia (AdaptOrch, arXiv 2602.16873), a bateria ponta a ponta contra os seis provedores em CI e a publicação do painel HTML.
Para quem paga a conta, o teto por execução é o número a ajustar primeiro, e o registro de gasto é a régua a ler, dividida por dois nas tarefas até a Sprint 31. Para quem integra, o código de saída 3 é o único que pede decisão humana: a entrega existe, e o juiz achou que ela precisa de olhos.
Rode o plano sobre uma demanda sua
O código, os 850 testes e o histórico de decisões estão no repositório. O comando de plano imprime a rota de cada tarefa com o motivo e para ali, pagando só a decomposição; é o jeito mais barato de avaliar se as regras desta página servem ao seu caso. Código aberto sob licença MIT.
por Alexandre Caramaschi, Chief Strategy Officer da Nuvini (Nasdaq: NVNI), Founder da Brasil GEO, cofundador da NAIA, ex-CMO da Semantix (Nasdaq), cofundador da AI Brasil
Dúvidas frequentes
Perguntas frequentes sobre o geo-orchestrator
O que é o geo-orchestrator?+
É um orquestrador multi-LLM em Python, de código aberto sob licença MIT. Ele recebe uma demanda em linguagem natural, divide em tarefas com dependências, agrupa as tarefas em ondas paralelas e escolhe um modelo por tarefa entre 16 configurados em 6 provedores. Cada tipo de tarefa tem um modelo padrão e uma fila de reservas em outras famílias, um juiz de outra família dá a nota final e três tetos limitam o gasto por execução, por dia e por provedor.
Preciso de chave de API de todos os provedores para usar?+
Não. O roteador usa os provedores com chave configurada e monta a fila de reservas só com eles; um provedor sem chave conta como indisponível e é pulado em toda posição da fila. Com um único provedor o orquestrador funciona, mas perde o piso de diversidade dos planos complexos e a proteção do disjuntor, que tira da rota por 90 segundos a família que falhou três vezes seguidas e manda a tarefa para outra.
O que acontece quando um modelo falha no meio da execução?+
A tarefa passa para a próxima posição da fila de reservas do tipo dela, sem parar a onda. Um erro de limite de requisições espera 2, 4 e 8 segundos; um erro 5xx ou um estouro de tempo ganha uma tentativa curta; um erro de saldo tira a família inteira da rota por meia hora. Se a fila se esgota e a tarefa tem dependentes, o sistema replaneja uma vez; se ainda falha, as tarefas seguintes recebem uma lacuna declarada.
Qual é a relação entre o geo-orchestrator e Generative Engine Optimization?+
O orquestrador nasceu para operar a medição de GEO em escala: rodar o mesmo conjunto de prompts em vários LLMs, comparar respostas, detectar citação de marca e produzir relatórios reproduzíveis. A arquitetura é genérica, então o mesmo motor serve para produção de conteúdo, auditoria e qualquer fluxo que precise de vários modelos com reserva entre eles.
Como acompanhar a evolução do projeto?+
O repositório público no GitHub concentra código, testes e histórico de versões, e esta página explica as regras do algoritmo com a data da última revisão. Mudanças de comportamento, como um novo modelo padrão para um tipo de tarefa ou um limiar novo, aparecem primeiro no repositório, depois na aba Roadmap desta página e, na revisão seguinte, nas abas que descrevem a regra.
Todas as perguntas do site, com a página de origem de cada uma, estão em /faq.