LLM Market 0.2.18: A Biblioteca Python que Roteia Prompts para o Modelo Certo Automaticamente e Reduz Custos com IA

O Problema que o LLM Market Resolve: Parar de Pagar Caro para Tudo

Quem trabalha com aplicações que consomem modelos de linguagem grande (LLMs) conhece bem o dilema: usar sempre o modelo mais poderoso garante qualidade, mas o custo por token explode rapidamente. Usar sempre o mais barato economiza dinheiro, mas a qualidade das respostas cai em tarefas complexas. A versão 0.2.18 do llm-market, publicada no PyPI, propõe uma terceira via: um roteador sequencial e inteligente que escolhe automaticamente qual modelo usar em cada momento, baseado em evidências reais de desempenho anterior.

A premissa é direta: nem todo prompt precisa do modelo mais caro. Uma pergunta simples de lookup não merece o mesmo orçamento que uma tarefa de arquitetura de software com múltiplas etapas. O llm-market tenta quantificar essa diferença e agir sobre ela de forma programática.

O que é o LLM Market e Como Funciona o Roteamento

O llm-market se descreve como um open clearinghouse — uma câmara de compensação aberta — para lances de modelos, conselhos multi-modelo e roteamento baseado em evidências. Na prática, a biblioteca intercepta cada requisição antes de enviá-la a um provedor e decide qual caminho seguir.

O Motor JEPA por Trás das Decisões

O núcleo do sistema de roteamento automático é um componente chamado StructuredStateJEPA — uma implementação de Joint Embedding Predictive Architecture aplicada ao contexto de roteamento de LLMs. Esse modelo consome até seis estados anteriores da conversa mais uma ação candidata, prediz o próximo estado latente e aplica cabeças de consequência aprendidas para estimar qualidade esperada, probabilidade de sucesso, progresso da tarefa, necessidade de resgate, risco de continuação desnecessária, latência e custo.

O checkpoint incluído na versão atual é descrito como um modelo real de contexto-6 e horizonte-2, treinado com 13.090 transições distribuídas em 240 bases semânticas agrupadas. Os mantenedores são claros sobre o que isso significa: é uma política inicial útil, não uma evidência definitiva sobre a qualidade dos modelos em produção. O pacote só é publicado se o preditor latente e todos os sete alvos de consequência superarem suas linhas de base no conjunto de validação.

As Oito Ações Possíveis do Controlador

O controlador determinístico não escolhe um modelo para a tarefa inteira. Ele escolhe a próxima ação delimitada e reavalia a cada evento significativo do ciclo de vida. As ações disponíveis são:

• accept_current: aceitar a resposta atual e encerrar
• answer_fast: delegar para Luna Medium, o modelo mais leve, para respostas rápidas
• execute_standard: usar Terra High para codificação, revisão de PRs e testes
• plan_important: acionar Sol High para planejamento e arquitetura
• review_or_repair: Sol High revisa uma falha anterior
• rescue_max: Sol Max entra em falhas repetidas
• council: painel de leitura com Terra e Sol High, síntese pelo Sol Max
• continue_native: deixar o Codex nativo continuar sem interferência

A lógica de desempate é econômica: quando duas ações têm qualidade prevista dentro de uma margem de 0,03, a mais barata vence. Há portões mais rígidos para acionar Sol Max e conselhos, evitando escalada desnecessária.

Integração com Codex, Cursor e OpenRouter

Uma das características mais interessantes do llm-market 0.2.18 é o suporte a múltiplos provedores locais além do OpenRouter clássico.

Roteamento Automático no Codex

Para quem usa o Codex CLI da OpenAI como ambiente de desenvolvimento assistido, o llm-market oferece uma integração via hooks que opera de forma completamente transparente. Após a instalação, oito entradas de hook são registradas no Codex. O usuário faz uma pergunta normalmente; os hooks disparam um controlador local em background que decide a próxima ação sem que o usuário precise especificar modelo, esforço ou qualquer parâmetro adicional.

Os IDs de modelo para o Codex seguem o padrão codex com slug e esforço de raciocínio, como luna em esforço medium ou sol em esforço max. Os valores de esforço suportados vão de low até ultra.

Suporte ao Cursor Agent

O Cursor também ganhou um adaptador dedicado. Os IDs de modelo seguem o padrão cursor com o slug do modelo, como gemini-3.1-pro ou claude-opus-high. Um detalhe importante: os cartões de modelo para Cursor usam pesos de roteamento relativos em vez de preços por token, porque o Cursor não expõe preços estáveis por chamada via CLI. Os cartões iniciais incluem um overhead de tokens para compensar o overhead oculto de workspace que o Cursor Agent frequentemente reporta.

Mistura de Provedores Locais

O modo multi-provider permite que uma única execução misture Codex, Cursor e OpenRouter. O multiplexador despacha por prefixo de ID: modelos com prefixo codex vão para o Codex CLI, com prefixo cursor vão para o Cursor Agent, e qualquer outro ID no estilo OpenRouter vai para o OpenRouter. A chave de API do OpenRouter só é exigida se um modelo OpenRouter for de fato chamado.

Cartões de Modelo e Evidências: A Base do Roteamento Inteligente

O sistema de roteamento é alimentado por dois tipos de dados: cartões de modelo e registros de evidência.

Os cartões de modelo são arquivos JSON que descrevem crenças atuais sobre custo por milhão de tokens, latência, confiabilidade, tamanho de contexto e capacidades por dimensão como codificação, raciocínio e escrita. São crenças editáveis — o sistema espera que você os mantenha atualizados com os preços reais dos provedores.

Já os registros de evidência capturam o que funcionou em prompts anteriores. Histórico exato ou fortemente similar ao prompt atual tem peso maior do que médias amplas por família de tarefa. Um único modelo precisa de margem suficiente antes de poder suprimir o roteamento para um conselho.

Privacidade e Limites do Sistema

Os mantenedores dedicam atenção explícita aos limites de privacidade. O controlador local armazena apenas embeddings da lista de permissões, hashes, contadores, decisões e sinais de resultado — nunca texto de prompt ou resposta. O pacote wheel contém apenas ativos de inferência sanitizados: checkpoint, embedder local, cabeças de consequência, escaladores, schema, limiares e proveniência.

Os episódios de rota exportados são locais e privados por padrão. O llm-market não faz upload, sincronização, telemetria ou compartilhamento automático de nenhum dado. A documentação recomenda explicitamente que futuros modelos globais de roteamento sejam treinados apenas a partir de artefatos públicos ou com opt-in explícito.

Interface de Linha de Comando: Principais Comandos

A CLI do llm-market cobre os casos de uso mais comuns de forma clara:

• llm-market plan: explica a rota sem fazer chamadas reais a modelos
• llm-market run --mock --trace: executa com modelos simulados para inspecionar mecânica de roteamento
• llm-market live-eval: avalia com provedores reais e compara contra baselines
• llm-market evidence-ingest: converte artefatos de avaliação em evidências para roteamento futuro
• llm-market next-action: inspeciona o controlador automático sem expor texto de conversa
• llm-market codex-doctor --smoke: verifica a integração com o Codex

Os presets fast, balanced e max ajustam a postura geral do roteador sem exigir edição manual dos cartões de modelo.

Relação com OpenRouter Fusion e Posicionamento no Ecossistema

Os próprios mantenedores reconhecem a dívida conceitual com o OpenRouter Fusion, que popularizou o primitivo de conselho: enviar o mesmo prompt para múltiplos modelos, ter um juiz comparando as respostas e produzir uma resposta final. O llm-market mantém esse primitivo aberto e acrescenta a política de roteamento ao redor dele — quando vale a pena pagar por um conselho, quando um modelo barato é suficiente, quando evidências históricas devem promover um modelo específico.

Atualmente classificado como Development Status: Alpha no PyPI e exigindo Python 3.11 ou superior, o projeto está em evolução rápida. Para quem constrói pipelines de IA que precisam equilibrar custo e qualidade de forma dinâmica, vale acompanhar de perto.