@model dá ao loop agent/coder o poder de se rotear sozinho: inspecionar os modelos de todos os providers configurados — enriquecidos com tier derivado do preço, custo por 1M de tokens, context window e capabilities — e decidir qual modelo deve servir a tarefa em questão. Ela pode trocar o restante da tarefa para outro modelo (o provider troca junto), ou delegar uma sub-tarefa autocontida a um modelo mais barato sem tocar no loop principal.
É a contraparte in-loop do roteamento por chamada que a superfície do MCP Server expõe a clientes externos (params
provider/model + list_providers): o mesmo poder, agora disponível para a própria IA enquanto trabalha. Sub-tarefas que não precisam de um modelo frontier param de pagar preço de frontier.Como funciona
model: de frontmatter de skills — com três garantias:
- Escopo de tarefa. O override é limpo no início de toda execução do agente. A decisão de roteamento da IA nunca sobrevive silenciosamente à tarefa para a qual foi tomada.
- Não invasivo. Nunca muta o provider/modelo/client da própria sessão — fora da tarefa,
/modele/switchcontinuam mandando. - Contabilizado. O cost tracking atribui cada turno ao modelo que de fato o serviu — o
/costmostra exatamente o que cada modelo roteado consumiu.
@model use da IA vence o hint model: de frontmatter de skill — uma decisão explícita tomada dentro da tarefa supera uma preferência estática.
Subcomandos
O que o list retorna
Tiers de preço
Para o modelo raciocinar sobre um rótulo em vez de preços brutos, olist deriva um tier das mesmas tabelas de preço que o cost tracking usa:
A própria descrição da tool ensina ao agente a política de roteamento: delegue sub-tarefas mecânicas a um modelo
fast-cheap; use use apenas em uma mudança clara de fase, nunca por chamada — trocas de modelo invalidam o prompt cache do provider, e o vai-e-vem frequente custa mais do que economiza.
Handles qualificados: PROVIDER:model
Com 15 providers suportados, o mesmo id de modelo pode existir em vários deles (claude-* no CLAUDEAI, no Bedrock e no OpenRouter; deepseek no Ollama e no GitHub Models). A forma canônica e determinística é o handle qualificado exatamente como o list imprime:
model: de skills — provider ativo primeiro, depois catálogo, depois heurística de família (sonnet→CLAUDEAI, gpt-*→OPENAI, glm-*→ZAI, …). O resultado da tool sempre informa qual provider foi escolhido, então o agente nunca opera às cegas.
Tags do Ollama são seguras. A forma qualificada só divide quando o prefixo nomeia um provider real —
qwen2.5:14b não é dividido (o prefixo não é um provider), e OLLAMA:qwen2.5:14b mantém o dois-pontos da tag dentro da parte do modelo.delegate: a maior economia de tokens
O use move o loop inteiro — histórico incluído — para outro modelo. O delegate faz algo mais barato: roda um prompt no modelo alvo, sem nenhum histórico da sessão, e devolve a resposta ao loop principal como resultado de tool.
- O prompt cache do provider do loop principal fica intacto (nada no histórico dele muda).
- O histórico gordo do agente nunca viaja ao modelo barato — a chamada delegada paga apenas pelo prompt entregue.
- O uso delegado é registrado no cost tracking sob o modelo delegado.
delegate para fast-cheap. Mudança de fase sustentada (ex.: uma migração mecânica longa depois do design fechado) → use.
Segurança e governança
- Kill switch:
CHATCLI_AGENT_MODEL_TOOL=falsedesregistra a tool por completo — a IA não consegue rotear modelos sozinha. Exposto no/configem agent → token efficiency. - Guarda de capability: quando o catálogo sabe que o modelo alvo não tem suporte nativo a tools, o
useavisa que o loop cairá no protocolo textual para tool calls. - Modelo de permissões:
list/statussão read-only;use/resetmutam o roteamento do loop edelegategasta tokens — declarados como tal ao sistema de permissões.use/resettambém são serializados (nunca rodam dentro de um batch paralelo de tools). - Isolamento do MoA: participantes do Mixture-of-Agents rodam sob uma whitelist estritamente read-only —
@modelé inalcançável de turnos de painel.
Configuração
Exemplo de uso
Veja também
- Cost Tracking — atribuição por modelo de cada turno roteado
- Token Efficiency — as outras alavancas que o agente usa para gastar menos
- MCP Server — o mesmo poder de roteamento para clientes MCP externos
- Modelos Suportados — o catálogo por trás dos tiers e capabilities
- Variáveis de Ambiente → Roteamento de modelo