LLM Router (roteamento inteligente de modelos)

Um único model=auto entrega ao gateway a decisão de “qual modelo usar”.

O roteamento inteligente (LLM Router) seleciona em tempo real, dentre as centenas de modelos da plataforma, o mais adequado de acordo com o conteúdo da requisição. Basta definir model como auto — sem escolher modelo, sem comparar preços, sem acompanhar as iterações de modelos.

A cobrança é feita pelo modelo realmente usado, sem taxa adicional e com zero alteração no código do cliente. Qual modelo foi usado fica registrado no cabeçalho e no corpo da resposta (veja Como confirmar o modelo realmente usado), totalmente rastreável.

Casos de uso

Distribuição automática por contexto: atribui automaticamente o modelo mais adequado conforme o contexto atual do usuário — especialmente útil para agents / apps que chamam modelos muitas vezes e não conseguem fixar de antemão a escolha do modelo em cada etapa.
Otimização de custo: deixe que tarefas simples caiam automaticamente em modelos mais baratos e mais rápidos (auto é, por padrão, custo prioritário).
Otimização de qualidade: garanta que requisições complexas sejam roteadas para modelos mais capazes (auto:quality_first).
Cenários de baixa latência: loops de agent multironda, chat interativo em tempo real e outros cenários sensíveis à latência preferem o modelo de resposta mais rápida (auto:latency_critical).
Entrada unificada, sem seleção manual: requisições de tipos diferentes são distribuídas automaticamente para o modelo ideal de cada uma — sem precisar manter uma tabela de mapeamento “tarefa → modelo”, nem acompanhar continuamente as iterações de modelos ou comparar preços e trocar nomes manualmente.

Início rápido

Defina model como auto; o restante do corpo da requisição é exatamente igual a uma chamada normal. Use https://aihubmix.com/v1 como base_url.

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }'

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

resp = client.chat.completions.create(
    model="auto",  # deixa o gateway selecionar o modelo automaticamente
    messages=[
        {"role": "user", "content": "What is the meaning of life?"},
    ],
)

print(resp.choices[0].message.content)
print("Modelo realmente usado:", resp.model)  # não é "auto", e sim o nome real do modelo

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "<AIHUBMIX_API_KEY>",
  baseURL: "https://aihubmix.com/v1",
});

const resp = await client.chat.completions.create({
  model: "auto", // deixa o gateway selecionar o modelo automaticamente
  messages: [
    { role: "user", content: "What is the meaning of life?" },
  ],
});

console.log(resp.choices[0].message.content);
console.log("Modelo realmente usado:", resp.model); // nome real do modelo

O roteamento inteligente conclui a análise antes de a requisição chegar ao upstream e trata requisições em streaming (stream: true) e não-streaming da mesma forma, sem parâmetros adicionais; toda a decisão adiciona apenas cerca de 1ms de overhead, praticamente imperceptível na latência ponta a ponta.

Como confirmar o modelo realmente usado

Esta é a âncora de confiança do roteamento inteligente: você sempre sabe qual modelo foi finalmente usado nesta requisição. Método 1 · Console da AIHubMix “Logs”: em console.aihubmix.com/logs, cada requisição mostra diretamente o nome real do modelo efetivamente acertado e cobrado — sem código, verificável a olho nu. Método 2 · Campos da resposta (prático para leitura programática):

O campo model do corpo da resposta é preenchido com o modelo realmente usado (por exemplo, mimo-v2.5-pro), e não auto.
Os cabeçalhos da resposta trazem as informações completas da decisão:

Cabeçalho da resposta	Significado	Valor de exemplo
`X-Aihubmix-Router-Resolved-Model`	Modelo realmente usado e cobrado com base nele	`xiaomi-mimo-v2.5-pro`
`X-Aihubmix-Router-Policy`	Política usada nesta requisição	`cost_optimized`
`X-Aihubmix-Router-Dimension`	Dimensão de tarefa identificada	`text.overall`
`X-Aihubmix-Router-Decision-Id`	ID único desta decisão, útil para depuração	`05dbad09-33c5-42de-…`
`X-Aihubmix-Router-Reason`	Resumo da decisão (política / dimensão / maior pontuação / nº de candidatos)	`policy=cost_optimized dim=text.overall top=0.182 survivors=20/33`
`X-Aihubmix-Router-Fallback`	Aparece apenas quando é acionado o fallback por ausência de candidatos	`true`

Cabeçalhos HTTP são insensíveis a maiúsculas/minúsculas: a tabela acima usa inicial maiúscula por convenção, mas a resposta HTTP/2 real vem em minúsculas como x-aihubmix-router-*; ambos são equivalentes.

Ler a decisão de roteamento (curl mostra os cabeçalhos da resposta; com o SDK use o objeto de resposta bruta para obter o header):

curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }' | grep -i "^x-aihubmix-router"

# reutiliza o client criado acima; with_raw_response permite obter os cabeçalhos da resposta
raw = client.chat.completions.with_raw_response.create(
    model="auto",
    messages=[
        {"role": "user", "content": "What is the meaning of life?"},
    ],
)

print("Modelo usado:", raw.headers.get("x-aihubmix-router-resolved-model"))
print("Política:", raw.headers.get("x-aihubmix-router-policy"))
print("Dimensão:", raw.headers.get("x-aihubmix-router-dimension"))

completion = raw.parse()  # converte para um objeto completion normal
print("body.model:", completion.model)

// reutiliza o client criado acima; .withResponse() permite obter os cabeçalhos brutos da resposta
const { data: completion, response } = await client.chat.completions
  .create({
    model: "auto",
    messages: [
      { role: "user", content: "What is the meaning of life?" },
    ],
  })
  .withResponse();

console.log("Modelo usado:", response.headers.get("x-aihubmix-router-resolved-model"));
console.log("Política:", response.headers.get("x-aihubmix-router-policy"));
console.log("Dimensão:", response.headers.get("x-aihubmix-router-dimension"));
console.log("body.model:", completion.model);

Saída real do curl (ambiente de produção; o modelo usado varia conforme o catalog online):

x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c
x-aihubmix-router-dimension: text.overall
x-aihubmix-router-policy: cost_optimized
x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33
x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro

Como ler o reason: survivors=20/33 indica que, dos 33 candidatos, 20 passaram pelo filtro rígido e entraram na pontuação; top=0.182 é a pontuação composta normalizada do modelo vencedor dentro do pool de candidatos (capacidade / custo / latência ponderados pela política).

O Resolved-Model do exemplo depende dos candidatos e preços atuais do catalog online e muda conforme os modelos da plataforma entram e saem — e é exatamente esse o valor do roteamento inteligente: você não precisa acompanhar essas mudanças. Para que a decisão seja auditável, baseie-se sempre no nome real do modelo no cabeçalho / corpo da resposta, e não na suposição de que ele é fixo.

Políticas de roteamento

O auto sem sufixo usa a política padrão cost_optimized. Você pode usar auto:<política> para indicar explicitamente a ênfase:

Forma de escrita	Ênfase	Caso de uso
`auto` (= `auto:cost_optimized`)	Custo prioritário: dentre os que atendem à capacidade, escolhe o mais barato	Tarefas em lote, sensíveis a custo
`auto:balanced`	Equilibrado: pondera capacidade / custo / latência	Genérico, escolha segura quando há incerteza
`auto:quality_first`	Qualidade prioritária: prioriza o mais capaz	Raciocínio complexo, saídas críticas
`auto:latency_critical`	Baixa latência prioritária: prioriza o mais rápido	Loops de agent, chat interativo em tempo real

Uma política não é uma “lista fixa de modelos”, mas uma ponderação diferente de capacidade / custo / latência. O auto primeiro delimita a dimensão da tarefa pelo conteúdo da sua requisição e então escolhe em tempo real o melhor modelo do conjunto de candidatos de centenas de modelos na plataforma conforme a política escolhida — então a mesma política acerta modelos diferentes conforme o conteúdo. A tabela “mesma requisição, políticas diferentes → resultados diferentes” abaixo ilustra exatamente isso; qual modelo vence a cada vez é determinado pelo nome real do modelo nos cabeçalhos de resposta / nos logs do console. Os modelos atualmente no pool e as pontuações por dimensão podem ser consultados pelo endpoint Escopo de Modelos da Estratégia LLM Router. Para especificar a política, basta adicionar o sufixo ao model:

# qualidade prioritária + tarefa de código
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto:quality_first",
    "messages": [
      { "role": "user", "content": "Write a Python function to reverse a linked list." }
    ]
  }' | grep -i "^x-aihubmix-router"

raw = client.chat.completions.with_raw_response.create(
    model="auto:quality_first",  # qualidade prioritária
    messages=[
        {"role": "user", "content": "Write a Python function to reverse a linked list."},
    ],
)

print(raw.headers.get("x-aihubmix-router-resolved-model"))
print(raw.headers.get("x-aihubmix-router-dimension"))

const { response } = await client.chat.completions
  .create({
    model: "auto:quality_first", // qualidade prioritária
    messages: [
      { role: "user", content: "Write a Python function to reverse a linked list." },
    ],
  })
  .withResponse();

console.log(response.headers.get("x-aihubmix-router-resolved-model"));
console.log(response.headers.get("x-aihubmix-router-dimension"));

Mesma requisição, políticas diferentes → modelos usados diferentes (medição real em produção, com a mesma frase What is the meaning of life?, todas caindo na dimensão text.overall):

Política	Modelo usado	Pontuação top
`auto` (= `cost_optimized`)	`xiaomi-mimo-v2.5-pro`	0.182
`auto:balanced`	`claude-opus-4-6-think`	0.488
`auto:latency_critical`	`claude-opus-4-6`	0.646
`auto:quality_first`	`claude-opus-4-6-think`	0.758

O latency_critical escolheu a versão sem -think — variantes de thinking têm latência de raciocínio maior, e a política de baixa latência as evita ativamente. Vê-se que os pesos da política atuam de fato no trade-off entre “capacidade / custo / latência”, e não apenas na capacidade.

O conteúdo também muda o resultado: aplicar o mesmo auto:quality_first em uma tarefa de código (a requisição do exemplo acima) faz a dimensão mudar de text.overall para text.coding, com modelo usado medido claude-opus-4-6-think — política e conteúdo da requisição determinam juntos o modelo final.

Sufixos de política desconhecidos (como auto:fast) voltam à política padrão cost_optimized, sem gerar erro.

Como funciona

Ao receber model=auto, o gateway transforma a “intenção” em “modelo concreto” em três passos:

Extrair características da requisição

Analisa as modalidades de entrada / saída desta requisição (texto, imagem, arquivo), a intenção do conteúdo (código, matemática, OCR, gráfico, idioma, se há busca na internet etc.) e a escala da requisição (tokens de entrada / saída estimados), normalizando tudo em uma dimensão de tarefa. Por exemplo: uma pergunta com código → text.coding; com imagem e pedido de OCR → vision.ocr; texto comum → text.overall.

Filtro rígido de candidatos

Exclui diretamente os modelos que não atendem às restrições rígidas: não suportam as modalidades de entrada / saída exigidas, a janela de contexto não comporta, foram removidos pelo circuit breaker (veja Confiabilidade e tolerância a falhas) ou não estão no conjunto de modelos disponíveis para a sua Key.

Pontuação ponderada pela política

Para os candidatos que passam pelo filtro, com base na pontuação de capacidade dos modelos segundo benchmarks reconhecidos do setor, somando preço em tempo real e dados de desempenho, faz uma pontuação ponderada tridimensional de “capacidade / custo / latência” conforme a política escolhida e seleciona o de maior pontuação. O nome do modelo final é gravado de volta na requisição e nos cabeçalhos da resposta.

Exemplo real de pontuação (sob a política quality_first, top 3 do mesmo conjunto de candidatos; dados de exemplo baseados em logs históricos de decisão de produção):

Modelo candidato	Pontuação de capacidade	Custo relativo	Latência	Pontuação composta
`claude-opus-4-6-think`	1504	220	1963ms	0.758
`claude-opus-4-6`	1498	220	822ms	0.721
`claude-fable-5`	1510	484	11130ms	0.600

Note que o claude-fable-5 tem a maior pontuação de capacidade (1510), mas, por ter custo mais alto e latência maior, foi rebaixado para terceiro na pontuação composta. É exatamente esse o sentido da pontuação ponderada: não é “só capacidade”, e sim ponderar capacidade / custo / latência conforme a política.

O claude-fable-5 foi um modelo-base de prévia em fases (staged preview baseline) e agora está descontinuado (deprecated) e não é mais oferecido; sua pontuação histórica é mantida aqui apenas para ilustrar o mecanismo de pontuação ponderada — requisições reais não o acertarão mais.

A identificação da dimensão é automática — o roteamento inteligente traz embutidas mais de 30 dimensões de tarefa detalhadas (código / matemática / OCR / gráfico / textos longos / chinês / busca na internet…), muito mais finas do que “distribuir grosso por família de modelo”. Mesmo preenchendo auto, conteúdos diferentes são roteados para dimensões diferentes:

Sua requisição	Dimensão identificada
Pergunta de texto comum	`text.overall`
Com código, pedindo para escrever / depurar programa	`text.coding`
Prova / resolução matemática	`text.math`
Pergunta muito longa (cerca de 500+ tokens)	`text.longer_query`
Pergunta em chinês	`text.language.chinese`
Entrada de imagem + “What is in this image?”	`vision.overall`
Entrada de imagem + “OCR…” / “reconhecer texto”	`vision.ocr`
Entrada de imagem + gráfico / fluxograma	`vision.diagram`
Busca na internet ativada	`search.overall`
Geração de imagem (`/v1/images/generations`)	`text_to_image.overall`
Edição de imagem (`/v1/images/edits`, imagem de entrada → imagem de saída)	`image_edit.single_image`

Esses nomes de dimensão vêm de leaderboards autorizados do setor que detalham as capacidades específicas dos modelos; o auto envia cada tipo de requisição ao modelo mais forte naquela capacidade. Domínios comuns, por exemplo:

Texto: text.coding = escrever / depurar código, text.math = resolução matemática, text.longer_query = texto longo, text.language.chinese = chinês, text.occupational.legal / text.occupational.medicine = cenários profissionais jurídicos / médicos.
Visão: vision.ocr = reconhecer texto em imagens, vision.diagram = entender gráficos / fluxogramas, vision.overall = compreensão geral de imagens.

A identificação da dimensão usa correspondência conservadora (alta precisão, baixo falso positivo): requisições de cauda longa ou ambíguas caem em dimensões mais genéricas (como text.overall / vision.overall) em vez de serem classificadas à força, evitando roteamento incorreto.

A entrada de imagem também passa pelo roteamento inteligente: ao enviar imagem em /v1/chat/completions, a requisição é roteada para modelos com forte capacidade visual conforme a tarefa de imagem. Medição real em produção — «OCR this image» → vision.ocr, modelo usado qwen3.5-397b-a17b; visão genérica «What is in this image?» → vision.overall, modelo usado gpt-5.4-mini. (Aqui refere-se a compreensão de imagem; a geração de imagem /v1/images/* também suporta auto, veja FAQ.)

Ranking de Pontuações e Pool de Modelos

O ranking de pontuações de modelos por dimensão e o pool de modelos atual podem ser consultados interativamente na página do LLM Router, ou obtidos diretamente pelos endpoints abertos sem login: Escopo de Modelos da Estratégia LLM Router e Ícones de Fornecedores de Modelos. O ranking exibe o mesmo conjunto que os candidatos de roteamento: apenas modelos atualmente roteáveis aparecem, as pontuações são normalizadas de 0 a 100 dentro de cada dimensão e o ranking é atualizado continuamente com o pool de modelos.

Confiabilidade e tolerância a falhas

O roteamento inteligente traz embutidas múltiplas camadas de tolerância a falhas, garantindo que o caminho auto nunca falhe sem motivo:

Circuit breaker: remoção automática de modelos com falha

O gateway mantém, para cada modelo, uma estatística de taxa de falha em janela deslizante. Quando um modelo acumula falhas suficientes na janela e a taxa de falha ultrapassa o limiar, ele é temporariamente removido do pool de candidatos e, após um período de resfriamento, é restaurado automaticamente — evitando continuar enviando requisições para um modelo que está instável. O sinal de falha vem do erro que o upstream retorna para aquela requisição; o “nenhum canal disponível” do próprio gateway não conta (isso não é problema do modelo em si).

Fallback por ausência de candidatos: nunca retorna 400 no auto

Caso o filtro rígido exclua todos os candidatos (por exemplo, alguma combinação de modalidades sem modelo disponível no momento), o gateway não retorna erro: ele atribui um modelo de fallback conforme o tipo de saída para garantir uma resposta e adiciona o cabeçalho X-Aihubmix-Router-Fallback: true para você saber.

Linha de defesa contra excesso de permissão: Key restrita não é contornada pelo fallback

Se a sua Key limita o conjunto de modelos disponíveis, o modelo escolhido pelo roteamento inteligente (incluindo o fallback) está sempre dentro desse conjunto. Se realmente não houver nenhum modelo no conjunto capaz de atender a esta requisição, será retornado explicitamente 403, em vez de usar silenciosamente um modelo fora do conjunto (possivelmente mais caro).

Sobre a cobrança

A cobrança é feita pelo preço original do modelo realmente usado; o roteamento inteligente em si não cobra nenhuma taxa adicional. Qual modelo finalmente responder é o que vale para calcular preço, capacidade e limite de contexto — esse modelo é o valor presente no cabeçalho X-Aihubmix-Router-Resolved-Model e no campo model do corpo da resposta. Em outras palavras, o roteamento inteligente não vai “usar um modelo caro às escondidas”: cada modelo usado fica registrado na resposta e pode ser conciliado item a item.

Limitações

O roteamento inteligente é atualmente voltado para a interface de chat completion /v1/chat/completions e para as interfaces de geração / edição de imagem /v1/images/* (veja FAQ: quais interfaces são suportadas).

?router=off ou o cabeçalho X-Router-Off faz o model=auto retornar diretamente 400 — é uma recusa explícita ao uso ambíguo de “querer auto e ao mesmo tempo desligar o roteamento”, e não uma ignorância silenciosa:

curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'
# → HTTP/1.1 400 Bad Request
# {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}}

O conjunto de candidatos muda dinamicamente conforme o catalog da plataforma: o mesmo auto pode usar modelos diferentes em momentos diferentes (isso é por design e pode ser auditado pelos cabeçalhos da resposta). O escopo atual de candidatos pode ser consultado pelo endpoint Escopo de Modelos da Estratégia LLM Router.

Diferenças em relação ao OpenRouter / LiteLLM

“Seleção automática de modelo” não é exclusividade da AIHubMix; OpenRouter e LiteLLM oferecem capacidades semelhantes. As diferenças estão principalmente no custo de integração e no modo de hospedagem:

Ponto de diferença	OpenRouter	LiteLLM	AIHubMix
Seleção automática de modelo conforme o conteúdo	✅	✅	✅
Zero configuração, pronto para uso (sem escrever regras de roteamento / utterances)	✅	❌	✅
Hospedado pela plataforma, sem precisar montar / implantar proxy próprio	✅	❌	✅
Múltiplas políticas de custo / qualidade / latência, alternadas por um único parâmetro	❌	❌	✅
Decisão de uso rastreável (cabeçalho com dimension / policy / reason)	❌	❌	✅
Cobrança pelo modelo finalmente usado	✅	❌	✅

Perguntas frequentes FAQ

P: Quais interfaces o roteamento inteligente suporta? R: Atualmente model=auto suporta a interface de chat completion compatível com OpenAI /v1/chat/completions, bem como as interfaces de geração / edição de imagem (/v1/images/generations, /v1/images/edits). Áudio, /v1/embeddings, /v1/rerank e outras interfaces ainda não suportam auto; indique o modelo específico diretamente. P: O roteamento inteligente suporta entrada de imagem? R: Suporta. Perguntar com imagem (image_url) em /v1/chat/completions é compreensão de imagem e é roteado para modelos com forte capacidade visual conforme a tarefa de imagem (vision.ocr = reconhecer texto em imagens, vision.diagram = entender gráficos / fluxogramas, vision.overall = compreensão geral de imagens, etc.). A geração de imagem também suporta auto: defina model como auto nas interfaces /v1/images/* e a requisição é roteada pelas dimensões de geração de imagem (por exemplo, text_to_image.overall). P: Como sei qual modelo foi de fato usado nesta requisição? R: Veja o cabeçalho X-Aihubmix-Router-Resolved-Model ou o campo model do corpo da resposta — ambos são preenchidos com o nome real do modelo. Veja Como confirmar o modelo realmente usado. P: O roteamento inteligente usa modelos caros às escondidas? R: Não. A política padrão cost_optimized é custo prioritário; além disso, cada modelo usado fica registrado na resposta e é cobrado pelo seu preço original, podendo ser conciliado item a item. Veja Sobre a cobrança. P: Como controlar / estimar o custo? R: Três recursos combinados — ① o auto padrão (cost_optimized) já é custo prioritário; ② use o conjunto de modelos disponíveis da Key para travar os candidatos na faixa de preço que você aceita, o que equivale a definir um teto de custo; ③ cada modelo usado é cobrado pelo preço original do modelo do cabeçalho Resolved-Model, podendo ser conciliado item a item. Quando precisar de mais capacidade, use explicitamente auto:quality_first. P: Qual a diferença entre auto e “mapeamento de modelos / fallback”? R: O mapeamento de modelos / fallback é alias fixo em nível de Key + fallback ordenado em caso de falha (sempre o mesmo destino); o roteamento inteligente é seleção dinâmica de modelo conforme o conteúdo de cada requisição. O primeiro resolve “o cliente só reconhece um certo nome / o modelo principal caiu e troca pelo backup”, o segundo resolve “não me importa qual seja, me dê o mais adequado”. P: É possível limitar o roteamento inteligente a escolher apenas entre alguns modelos? R: Sim — por meio do conjunto de modelos disponíveis da Key: o roteamento inteligente só escolhe entre os modelos permitidos para aquela Key, e modelos fora do conjunto não serão usados. P: Requisições em streaming são suportadas? R: Suportadas. O roteamento é concluído antes de a requisição chegar ao upstream e trata streaming / não-streaming da mesma forma. P: Por que duas chamadas com a mesma frase usaram modelos diferentes? R: O conjunto de candidatos e os preços mudam dinamicamente conforme o catalog da plataforma; isso é por design. Use o Decision-Id e o Resolved-Model dos cabeçalhos para auditar cada decisão. O escopo atual de candidatos pode ser consultado pelo endpoint Escopo de Modelos da Estratégia LLM Router. P: Como fazer a requisição usar de forma estável sempre o mesmo modelo (por exemplo, para reaproveitar o cache de prompt)? R: O auto seleciona o modelo dinamicamente conforme o catalog atual e não garante determinismo. Se você precisa usar de forma estável o mesmo modelo (por exemplo, dependendo do cache de prompt do upstream ou para reprodução estrita), indique diretamente o nome do modelo específico ou use a Key para limitar o conjunto disponível a um único modelo — nessas duas formas o modelo usado é determinístico.

Recursos relacionados

Mapeamento de modelos e fallback: alias fixo em nível de Key + fallback em caso de falha, complementar ao roteamento inteligente.
Parâmetros de inferência unificados: parâmetros de requisição consistentes entre modelos.
Página de modelos da AIHubMix: consulte nome do modelo, preço e Input Modalities.
Escopo de Modelos da Estratégia LLM Router: acesso sem login ao subconjunto público de 23 subdimensões (das 30+ dimensões de roteamento) e ao pool de modelos roteáveis.

Começar

Recursos de gateway

Capacidades do modelo

Referência de protocolo

Gestão de plataforma

Privacidade e termos

LLM Router (roteamento inteligente de modelos)

Casos de uso

Início rápido

Como confirmar o modelo realmente usado

Políticas de roteamento

Como funciona

Ranking de Pontuações e Pool de Modelos

Confiabilidade e tolerância a falhas

Sobre a cobrança

Limitações

Diferenças em relação ao OpenRouter / LiteLLM

Perguntas frequentes FAQ

Recursos relacionados

​Casos de uso

​Início rápido

​Como confirmar o modelo realmente usado

​Políticas de roteamento

​Como funciona

​Ranking de Pontuações e Pool de Modelos

​Confiabilidade e tolerância a falhas

​Sobre a cobrança

​Limitações

​Diferenças em relação ao OpenRouter / LiteLLM

​Perguntas frequentes FAQ

​Recursos relacionados

Casos de uso

Início rápido

Como confirmar o modelo realmente usado

Políticas de roteamento

Como funciona

Ranking de Pontuações e Pool de Modelos

Confiabilidade e tolerância a falhas

Sobre a cobrança

Limitações

Diferenças em relação ao OpenRouter / LiteLLM

Perguntas frequentes FAQ

Recursos relacionados