Na semana passada eu escrevi sobre NeMoCo, um sistema auto-supervisionado que aprende a categorizar estruturas neurais da mesma forma que o cérebro categoriza o mundo — a partir de experiência bruta, não rotulada, sem que lhe digam quais são as categorias. Eu voltei repetidamente à mesma linha: labels são um atalho, a estrutura é o que importa.

Esta semana eu construi a outra metade dessa ideia, no domínio em que realmente trabalho. Eu executo um assistente de IA pessoal — Aura — que gerencia memória, roteia tarefas e tenta ser genuinamente útil entre sessões. Ele roda em uma frota de modelos: Claude para codificação de produção, alguns modelos de nuvem para pesquisa e design, e um modelo local que não consome nada. O problema é o mesmo que o NeMoCo resolve, apenas invertido. O NeMoCo aprende estrutura a partir de dados brutos. Eu tinha a estrutura — uma lista de agentes, cada um com uma função — e eu precisava que o sistema decidisse qual modelo deve executar qual tarefa, em tempo real, sob um orçamento que se esgota.

Esse mecanismo de decisão é o que eu construi nesta semana. Ele tem três partes: um classifier que lê uma tarefa e decide que tipo de trabalho é, um router que mapeia isso para a melhor cadeia de modelos dado o quota em tempo real, e um dashboard que renderiza tudo isso como um cérebro vivo e pulsante. Este é o writeup técnico — o que cada peça faz, por que ela tem essa forma e as falhas que forçaram o projeto.

O Problema: Uma Lista Não É Um Roteador

A configuração ingênua é uma tabela estática: este agente executa este modelo, aquele agente executa aquele modelo. É simples, e está errado, por três razões.

Primeiro, o orçamento se esgota. Claude opera com uma cota semanal e uma cota de sessão contínua, e eles se movem independentemente. Em um dia, a cota semanal estava em 15% enquanto a de sessão estava em 71% — e, como o antigo roteador apenas monitorava o número semanal, ele informou "Claude disponível, modo NORMAL" e direcionou o trabalho de codificação diretamente para um muro. A CLI recusou cada chamada por três horas com "Você atingiu seu limite de sessão" enquanto o painel continuava dizendo que tudo estava bem. Um roteador que não lê o limite que realmente está vinculando não é um roteador, é um palpite.

Segundo, a qualidade não é um número. Um modelo que escreve bom código não é necessariamente bom em recuperação de longo contexto ou geração de UI. Pontuar cada modelo com uma única pontuação de "qualidade" é inútil — não pode dizer qual modelo deve liderar o codificador versus o pesquisador. Cada agente precisa ser pontuado em seu próprio eixo.

Terceiro, o revisor não deve herdar os pontos cegos do escritor. Eu intencionalmente pareio um escritor e um revisor — o codificador escreve, o diagnóstico revisa — e eles precisam executar diferentes famílias de modelos, caso contrário o revisor apenas repete os mesmos erros. A primeira versão do roteador manteve pousando ambas as cabeças no mesmo modelo porque desempatava pela latência. Isso derrotou todo o projeto.

Então a tabela estática teve que ser removida. O que a substituiu é um mecanismo de decisão que lê o estado ao vivo e calcula, por tarefa, a melhor cadeia de modelos.

O Classificador: Lendo a Tarefa

A primeira peça é um classificador que lê uma tarefa e decide que tipo de trabalho ela é. A entrada é uma frase — "o endpoint de pagamento está retornando 500 em produção desde o deploy" — e a saída é um veredicto: tipo, nível e prioridade.

Primeira versão era puro regex. Funcionou, e era frágil exatamente das maneiras que o regex sempre é. "Log parser" foi encaminhado incorretamente para ops (é um componente de código, não uma tarefa de ops). "Checkout está cobrando os clientes duas vezes" não tinha nenhum vocabulário de erro, então foi classificado como unknown e caiu através para o agente principal — em um incidente de produção. "Throwing 500s" não correspondeu ao padrão de código de status porque o 's' final quebrou o limite de palavra. Cada um desses foi um encaminhamento incorreto real que eu corrigi um de cada vez, e cada correção foi uma nova regra de regex. Esse é o indicativo de que você está lutando contra a ferramenta errada.

Agora o classificador tenta primeiro um modelo barato — `deepseek-v4-flash:cloud` lê a tarefa e retorna um veredicto JSON. Se o modelo estiver indisponível, ele recorre ao classificador de regex. O modelo é o caminho principal; o regex é a rede de segurança. Essa é a mesma lição do NeMoCo: não rotule manualmente cada caso, aprenda a estrutura e deixe que ela se transfira.

O classificador também recebe a cota ao vivo do seu chamador, assim nunca pode se desviar do roteador. O chamador lê o estado da cota e a passa; o classificador não lê o arquivo de cota diretamente. A regra chave: o trabalho de produção nunca é rebaixado para um modelo fraco, por mais apertado que seja o orçamento. Um incidente de produção é classificado como `prod` mesmo quando o Claude está esgotado — ele não é redirecionado silenciosamente para um agente leve e relatado como concluído. Ele bloqueia, e o protocolo de handoff é acionado. O risco de qualidade é pior que o risco de cota, e o design nunca esquece qual é qual.

O Roteador: O Mecanismo de Decisão

O roteador é onde acontece o verdadeiro raciocínio. Ele recebe o veredicto do classificador e o estado ao vivo do provedor, e calcula uma cadeia de modelos por nível de tarefa.

O núcleo é pontuação baseada em eixos. Cada agente é pontuado em seu próprio eixo de habilidade — programador na geração de código, diagnosticador no raciocínio de depuração, pesquisador na recuperação de fatos, criativo na geração de interface do usuário, operações na chamada de ferramentas, principal na orquestração. A qualidade efetiva de um modelo é sua pontuação de benchmark sintético vezes sua confiabilidade observada em sessões reais. Um modelo que se sai bem no benchmark mas comete erros em produção é rebaixado. Esta é a camada "aprender com o desempenho real": o benchmark é a capacidade sintética, os dados de confiabilidade são o que realmente se manteve.

A fórmula de pontuação é a matriz de pesos de Bander: `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. Custo é um nível relativo de 0 a 1, não dólares reais — porque a nuvem ollama não tem preço por chamada e Claude é uma assinatura, você não pode escaloná-los honestamente usando min-max. E há um piso rígido de qualidade: um candidato que pontua abaixo dele em seu próprio eixo é eliminado antes do ranking, de modo que um modelo barato e burro nunca pode vencer apenas pelo preço.

O roteador também lida com o decorrelation problem — forçando as cabeças do programador e do diagnosticador para famílias de modelos diferentes, de modo que o avaliador não herde os pontos cegos do redator. E ele lida com subagent economics: um subagente executa uma fatia do trabalho do seu pai, e uma delegação pode se ramificar até 20×, de modo que as cadeias de subagentes ponderam o custo muito acima de qualquer nível padrão. É isso que mantém o Claude fora das cadeias de subagentes sem uma exclusão rígida — com um peso de custo de 0,45 ele simplesmente não pode vencer.

O Painel: O Cérebro Robótico

O painel é a parte mais difícil de capturar em texto. Ele renderiza todo o sistema como um cérebro vivo.

Existe uma visualização 3D do cérebro — uma estrutura neural renderizada por WebGL onde cada agente é uma região, e você pode orbitar, dar zoom e clicar em uma região para aprofundar-se na cadeia de modelo, estatísticas e seletor de sobrescrita. E há um "peça central do cérebro eletrônico" na visualização em grade: uma placa de circuito SVG onde os agentes são nós de fluxo conectados por rastros de sinal animados, com tudo pulsando mais rápido ou mais lento com base na atividade ao vivo.

O cérebro não é apenas decoração. É telemetria tornada visível. O painel deriva a atividade por agente do crescimento do arquivo de sessão entre pesquisas — o sinal mais forte de que um agente está realmente trabalhando — e a representa como pulsos de sinal viajando pelos rastros do circuito. Quando o sistema está ocioso, o cérebro desacelera até quase parar. Quando está ocupado, os rastros aceleram. Você pode ver o cérebro pensando.

Também há um seletor de nível — seis botões (Nível 1–4, um escudo "Local" e um redefinir "Baseline") que permitem forçar toda a frota a um determinado nível de qualidade. E as substituições de modelo por agente, persistidas em um arquivo, permitem fixar um modelo específico a um agente específico quando a escolha do roteador ao vivo não for o desejado. O painel é a superfície de controle do cérebro.

As Falhas Que o Moldaram

Cada decisão de design aqui é uma cicatriz de uma falha real, e elas valem a pena ser listadas porque são o conteúdo real da semana:

• O ponto cego do limite de sessão. O roteador aplicava gate apenas na cota semanal e ignorava a cota de sessão que era realmente vinculativa. A correção: ler ambas e deixar que o mais apertado prevaleça.
• O bug do envelope do benchmark. O benchmark rev1 escreveu seu arquivo em um envelope `{value:[...]}` em vez de um array simples, então cada linha faltava o campo `.model` e o roteador recebeu silenciosamente um mapa vazio. Os dados do benchmark nunca chegaram ao roteador e nada reclamou. A correção: desembalar o formato legado para que arquivos antigos ainda carreguem.
• A inversão do eixo-rubrica. A rubrica do eixo deu ao opus 0.50 em raciocínio de depuração — abaixo de um modelo que nunca deveria revisar código de produção. Permitir que ela reordenasse os níveis de produção teria feito o revisor se tornar o escritor. A correção: os níveis de produção não são reclassificados pela rubrica. Uma rubrica de palavra-chave não é evidência forte o suficiente para anular uma decisão de projeto declarada.
• A espiral da morte da janela de contexto. Colocar um modelo de contexto de 131k na cabeça da camada de orquestração estourou a janela e acionou a espiral da morte da compactação. A correção: todo candidato à orquestração deve ter uma janela confortavelmente acima do orçamento de contexto mais a reserva.
• A operação nula de confiabilidade. Os logs de sessão armazenam o nome nu do modelo enquanto os candidatos carregam um prefixo de provedor, então a camada de confiabilidade corresponde silenciosamente a nada. A correção: remover o prefixo antes da correspondência.

O que estou levando embora

O post do NeMoCo terminou com: labels são um atalho, a estrutura é o que importa, e você pode aprender a estrutura a partir da experiência bruta. Esta semana foi a versão de engenharia disso. Eu não escrevi à mão uma regra para cada tarefa — eu construi um classificador que lê a tarefa e um roteador que lê o estado ao vivo, e deixei que a estrutura do trabalho decidisse a ferramenta. O classificador de regex foi a abordagem "labels", e ele quebrou exatamente onde as labels sempre quebram: nas bordas, nos casos que você não antecipou. O classificador auxiliado por modelo é a abordagem "estrutura": aprenda o padrão, transfira-o, recua com elegância.

O painel do cérebro é a parte que faz parecer real. Quando você pode observar os pulsos de sinal correrem junto aos trilhos do circuito enquanto os agentes realmente trabalham, e ver tudo desacelerar até engatar quando está ocioso, você não está mais olhando para um arquivo de configuração. Está olhando para um sistema que tem um pulso.

O roteador é de código aberto em espírito — é um conjunto de scripts no meu espaço de trabalho, `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — e ele roda em uma mistura de Claude, modelos ollama na nuvem e um modelo local que não consome nada. Não é um sistema corporativo fechado. É um mecanismo de decisão que você poderia construir por conta própria, e as falhas que o moldaram são a parte útil.

Esta é a lição. Uma lista de escala é uma lista. Um roteador é uma decisão. E um cérebro é o que você obtém quando a decisão é tomada ao vivo, sob um orçamento que se esgota, por um sistema que aprende com seus próprios erros.