A ideia central

O README chama o projeto de “AI Router & Token Saver”, mas essa descrição fica pequena quando se olha o código. O 9Router recebe chamadas de Claude Code, Codex, Cursor, OpenCode, Cline, Copilot e clientes OpenAI; escolhe uma conta e um provedor; traduz o formato; executa a chamada; atualiza tokens e quotas; e devolve uma resposta compatível.

O ponto arquitetural é este: o modelo pedido pelo cliente não precisa ser o endpoint real. Um alias ou combo pode significar uma sequência de provedores, contas e estratégias. O cliente continua apontando para http://localhost:20128/v1; a inteligência operacional fica no gateway.

O caminho de uma requisição

  1. O cliente envia Chat Completions, Messages ou Responses.
  2. O gateway identifica o formato e resolve o modelo, alias ou combo.
  3. Seleciona uma conexão ativa, respeitando prioridade, cooldown, quota e estratégia.
  4. Traduz OpenAI, Claude, Gemini, Cursor, Kiro, Vertex e outros formatos.
  5. Aplica, se habilitado, RTK, Headroom, Caveman, Ponytail e PXPIPE.
  6. O executor específico chama o provedor, atualiza credenciais e tenta refresh em 401/403.
  7. A resposta é normalizada, transmitida por SSE e registrada no uso e na observabilidade.

Isso explica por que o repositório contém tantos executors: Antigravity, Codex, Cursor, GitHub/Copilot, Kiro, Gemini, OpenCode, Grok, Ollama, Vertex, Windsurf e vários outros. Não é uma camada fina de HTTP. É uma coleção de adaptadores para serviços que frequentemente não são verdadeiramente equivalentes.

O que há de especialmente forte

Compatibilidade como produto: a tradução fica antes e depois do executor, com passthrough nativo quando possível. Isso reduz a necessidade de configurar cada ferramenta com um formato diferente. A presença de rotas para chat, messages, responses, modelos, embeddings, áudio, imagens, vídeo, busca e web fetch mostra que o projeto quer ser uma superfície de integração ampla.

Fallback com memória operacional: combos podem usar fallback, round-robin ou fusion. Dentro de um provedor, várias contas podem alternar; erros e limites colocam uma conta em cooldown; uma credencial renovada é persistida. A capacidade também participa da decisão: uma requisição com visão pode encontrar um modelo-adaptador quando o modelo original não suporta a modalidade.

Economia de contexto: o RTK comprime resultados de ferramentas como git diff, grep, ls e tree antes da tradução. Headroom é opcional e falha aberto; Caveman e Ponytail tentam reduzir tokens de saída por injeção de instruções. É uma escolha poderosa, mas não neutra: um roteador que modifica o prompt passa a participar do comportamento do agente, não apenas do transporte.

Operação local pragmática: a aplicação usa SQLite com uma cadeia de adaptadores — better-sqlite3, node:sqlite ou sql.js — e guarda conexões, aliases, combos, chaves, uso e configurações no diretório de dados. O Docker inclui o Headroom como serviço separado. Para um laboratório pessoal, isso é simples de operar e fácil de arquivar.

O que o 9Router realmente sabe

As conexões armazenam accessToken, refreshToken, expiração, API key, dados específicos do provedor e, em alguns casos, identificadores de conta e projeto. O OAuth cobre fluxos PKCE, device code e integrações muito específicas, como Kiro via AWS SSO OIDC. O gateway também registra custos estimados e quotas; esses custos são telemetria de referência, não a fatura real dos provedores.

Essa é a fronteira conceitual mais importante: o 9Router é um credential broker local. Ele não apenas escolhe um modelo; ele guarda e renova as autorizações que permitem acessar esse modelo. Isso aumenta bastante seu valor e, na mesma proporção, o impacto de uma instalação exposta ou de um backup mal protegido.

Segurança: há bons guardrails, mas o operador continua responsável

O dashboardGuard distingue acesso local, token de CLI, JWT e API key. Rotas de execução local, túnel, MCP, OAuth de autoimportação e MITM têm restrições próprias. O servidor customizado remove cabeçalhos de IP falsificáveis e carimba a origem do peer. Há limiter de login, cookie httpOnly e suporte a OIDC/SAML.

Mas o envelope seguro precisa ser configurado. O código ainda prevê a senha inicial padrão 123456 quando não há senha persistida nem INITIAL_PASSWORD; o exemplo de ambiente usa segredos ilustrativos; e o modo local pode aceitar chamadas sem API key quando essa opção é desligada. O CORS amplo e o binding em 0.0.0.0 do Docker tornam perigoso tratar “é local” como sinônimo de “é privado”.

Existe ainda uma superfície de alto privilégio: o MITM gera uma CA raiz, instala confiança no sistema quando autorizado, altera DNS/hosts e intercepta endpoints de ferramentas. Isso pode resolver integrações difíceis, mas deve ser considerado uma operação de segurança de máquina, não um botão cosmético do dashboard.

Uma descoberta documental

O código atual usa DATA_DIR/db/data.sqlite, enquanto partes da documentação de arquitetura ainda descrevem db.json e módulos de sincronização que não aparecem neste clone. O README continua apresentando Cloud Sync, BASE_URL e CLOUD_URL, e há hooks de dashboard para nuvem, mas não encontrei neste snapshot uma implementação local completa das rotas/scheduler de sincronização.

Minha interpretação é que a capacidade de nuvem é parcialmente externa ou ficou à frente da publicação do código. Portanto, eu não prometeria “sync seguro” apenas com base no README. Antes de habilitar, seria necessário localizar o serviço remoto, entender exatamente quais credenciais são enviadas e testar o caminho com dados sintéticos.

Depois do OpenBot: as duas peças não competem

A diferença ficou nítida depois da pesquisa anterior. O OpenBot governa o que o agente faz: browser, arquivos, shell, MCP, grants, política e auditoria. O 9Router governa por onde o pedido de inteligência passa: formato, modelo, conta, quota, fallback, compressão e provedor.

Uma composição possível seria:

Hermes / Codex / OpenCode
        ↓ intenção e tarefa
OpenBot — execução governada
        ↓ chamada de modelo
9Router — tradução, credenciais e fallback
        ↓
Claude / Codex / Gemini / Ollama / outros provedores

O OpenBot é a fronteira de ação; o 9Router é a fronteira de inferência. Juntos, poderiam formar um agente que sabe agir com política e também sobreviver à heterogeneidade dos modelos. Separados, continuam úteis: um não substitui o outro.

Meu veredito para o Rabelus Lab

Eu colocaria o 9Router na categoria candidato forte para laboratório, ainda não componente de confiança cega. O encaixe com Hermes, Codex e OpenCode é direto: uma URL compatível centraliza provedores, reduz configuração repetida e cria um lugar observável para quotas e falhas.

As condições seriam claras: rodar localmente ou atrás de uma rede privada; definir senha forte e segredos novos; manter API keys obrigatórias; desabilitar Cloud Sync até auditar o destino; tratar tokens OAuth e exports de banco como material sensível; fazer backup verificável; e testar cada provider com contas de baixo impacto. A maior virtude do projeto — concentrar credenciais e decisões — é também seu maior risco.

O OpenBot coloca o agente diante do mundo com uma fronteira de ação. O 9Router coloca uma fronteira entre o agente e os modelos. Um governa a mão; o outro governa a estrada por onde o pensamento viaja.