Caso de uso
Enrutamiento de modelos
Elige un modelo barato o caro a partir de la tarea, no de una lista hardcodeada.
El problema
Mandar cada prompt al modelo más grande quema presupuesto en consultas simples.
Qué hace tu código con la respuesta
Envía las tareas `small` a un modelo rápido y escala solo las `large`.
Cómo es la solicitud de enrutamiento
El estado es la tarea misma — el ticket, la consulta, el prompt — y dos preguntas: difficulty (choice entre small, medium y large, con descripciones ligadas a lo que cada nivel maneja bien) y needs_tools (sí/no: ¿responder requiere ejecutar código o hacer retrieval?). Ambas respuestas vienen con probabilidades, así que las tareas en la frontera aparecen como confianza repartida en lugar de un enrutado silenciosamente erróneo. La llamada suele ser 1 crédito; el ahorro es no pagar la tarifa del nivel grande en consultas y reescrituras.
El escalado es una segunda solicitud, no una reconstrucción
Enruta por difficulty. Las tareas puntuadas small van directas al modelo rápido. Todo lo que esté por encima de tu línea de confianza — difficulty repartida entre niveles, necesidades de herramientas inciertas — escala a la vía cara con el mismo estado que ya construiste, así que no hay que recablear nada. Registra ruta, confianza y latencia por llamada, y reajusta las descripciones de los niveles a medida que cambia el tráfico.
Riesgos propios del enrutamiento
Niveles descritos por impresión más que por comportamiento («barato / más caro / carísimo») invitan a llamadas inconsistentes; describe cómo se ve la tarea en su lugar. No escondas el camino de escalado — mide adonde aterrizaría el tráfico real, y si la mayoría de las tareas puntúan hacia el nivel grande, o tu estratificación está mal o tus descripciones de criteria son demasiado cautas. Y enruta por la tarea, no por el usuario: el error tipográfico de un usuario avanzado merece el nivel small.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave 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?"
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Debería el enrutador conocer mis costes?
- Mantenlo conductual: las criteria describen qué maneja cada nivel. Los precios viven en tu política — una tarea puntuada small que vuelve con baja confianza es candidata al escalado, y el número de confianza es lo que hace funcionar esa regla.
- ¿Cuántos niveles debería declarar?
- Tres es el punto dulce, escritos en términos conductuales: consulta y reescritura, razonamiento o código rutinario, ambigüedad de varios pasos o contexto largo. Dos niveles pierden matiz; cinco empiezan a difuminarse.
- ¿Funciona esto con tareas no inglesas?
- Sí — el estado puede llevar la tarea en su propio idioma. Mantén los nombres de los niveles en las criteria como identificadores sobre los que conmuta tu código.