Caso de uso
Roteamento de modelos
Escolha um modelo barato ou caro a partir da tarefa, não de uma lista fixada no código.
O problema
Mandar todo prompt para o maior modelo queima orçamento em consultas.
O que seu código faz com a resposta
Envie tarefas `small` para um modelo rápido e escale apenas as `large`.
Como é a requisição de roteamento
O state é a própria tarefa — o ticket, a query, o prompt — e duas perguntas: difficulty (choice entre small, medium e large, com descrições ligadas ao que cada tier lida bem) e needs_tools (sim/não: responder exige execução de código ou retrieval?). Ambas as respostas vêm com probabilidades, então tarefas de fronteira aparecem como confiança dividida em vez de uma rota errada silenciosa. A chamada é tipicamente 1 crédito; a economia é não pagar a tarifa do tier grande em consultas e reescritas.
Escalonamento é uma segunda requisição, não uma reconstrução
Roteie pela difficulty. Tarefas pontuadas como small vão direto para o modelo rápido. Tudo acima da sua linha de confiança — difficulty dividida entre tiers, necessidades de ferramenta incertas — escala para o caminho caro com o mesmo state que você já montou, então nada de re-plumbagem. Registre rota, confiança e latência por chamada, e reajuste as descrições dos tiers conforme o tráfego muda.
Pitfalls específicos de roteamento
Tiers descritos por vibe em vez de comportamento ("barato / mais caro / caríssimo") convidam a chamadas inconsistentes; descreva como a tarefa se parece. Não esconda o caminho de escalonamento — meça onde o tráfego real aterrissaria, e se a maioria das tarefas pontua para o tier large, ou o seu tiering está errado ou as suas descrições de criteria são tímidas demais. E roteie pela tarefa, não pelo usuário: o typo de um power user merece o tier small.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Write a SQL query that returns the top 5 customers by revenue in 2025 from tables orders(customer_id, total, created_at) and customers(id, name).",
"questions": {
"difficulty": {
"type": "choice",
"instructions": "Which model tier is enough to answer this well?",
"criteria": {
"small": "Simple lookup or rewrite a small model handles",
"medium": "Routine reasoning or code",
"large": "Multi-step reasoning, ambiguity or long context"
}
},
"needs_tools": {
"type": "noul",
"instructions": "Does answering require running code or fetching data?"
}
}
}'FAQ sobre este caso de uso
- O roteador deve conhecer os meus custos?
- Mantenha-o comportamental: os criteria descrevem o que cada tier lida. O preço mora na sua política — uma tarefa pontuada como small que volta com confiança baixa é candidata ao escalonamento, e é o número de confiança que faz essa regra funcionar.
- Quantos tiers devo declarar?
- Três é o ponto ideal, escritos em termos comportamentais: consulta e reescrita, raciocínio ou código de rotina, ambiguidade de vários passos ou contexto longo. Dois tiers perdem nuance; cinco começam a se embaralhar.
- Isso funciona para tarefas fora do inglês?
- Sim — o state pode carregar a tarefa no idioma dela. Mantenha os nomes dos tiers nos criteria como identificadores sobre os quais o seu código comuta.