Un solo modelo en el cliente: el gateway crea los niveles automáticamente
Saque la elección de modelo de la interfaz: el cliente expone un único nombre de modelo, la planificación se ejecuta en el modelo potente y la ejecución recae en el rentable, con niveles creados en el salto que la solicitud ya estaba haciendo.
De qué se queja realmente la comunidad
"Cada persona tiene un modelo distinto en sus ajustes y el mismo prompt sale diferente para dos personas", "la pregunta más habitual en la primera semana de alguien es qué modelo debo elegir", "retirar un modelo significa editar variables de entorno en cada máquina de desarrollo". La elección de modelo se ha entregado a las personas con menos información para tomarla: no ven su propio gasto y no tienen forma de saber si esta solicitud concreta merece el modelo potente.
Si en cambio baja a todos a un modelo barato, el trabajo se degrada: confíe la planificación y el criterio arquitectónico a un modelo pequeño y el retrabajo cuesta más que el ahorro. La división que realmente importa es qué está haciendo esta solicitud, planificar o ejecutar, y el cliente nunca se lo ha dicho al gateway.
Cómo lo hace GateLLM
El cliente conserva un único nombre de modelo; un mapeo comodín (desde "*") en el gateway normaliza el nombre que pida el cliente, así que editar los ajustes personales ya no cambia dónde recae la solicitud. Ya no queda nada que explicar sobre qué modelo elegir.
La señal de los niveles ya está en la conversación: el modo de planificación de Claude Code inyecta Plan mode is active al entrar y Exited Plan Mode al salir. Un script de ranura before recorre los mensajes hacia atrás, toma el último marcador visto para determinar el estado actual y luego llama a context.useModel() para cambiar el enrutamiento. La decisión es una comparación de posiciones de cadena: sin llamada de clasificación aparte ni salto de red adicional.
Los niveles tienen que vivir en la ranura before: la ranura after ve el cuerpo traducido del upstream y no puede leer los marcadores inyectados por el cliente; además, useModel en la ranura after solo cambia dentro del mismo protocolo, mientras que pasar de planificación a ejecución es un cambio de ruta entre modelos. Las reglas request_payload (prompt_cache_key y similares) deben configurarse en ambos modelos: el modelo de entrada conserva la suya mientras planifica y la del modelo destino se aplica una vez ocurre el cambio.
5 palancas que realmente funcionan
- Un solo nombre de entrada: el cliente expone un único nombre de modelo y un mapeo comodín desde "*" normaliza todos los nombres solicitados a un único modelo de destino
- Niveles automáticos: un script de ranura before toma el último marcador recorriendo hacia atrás; el marcador de entrada permanece en el historial para siempre, así que una comprobación de "contiene" leería el estado como modo de planificación de forma permanente
- Protección de protocolo: el script comprueba primero context.sourceProtocol y vuelve antes de tiempo para el tráfico que no es de Anthropic, así que un modelo de entrada que sirve a varios clientes nunca se enruta mal
- Observable: una etiqueta SW en la columna de modelo del log marca un cambio por script y MM marca un mapeo por identidad; las estadísticas y la facturación atribuyen al nombre del modelo final, así que cada decisión de nivel es auditable
- Cero despliegue en clientes: los cambios de configuración no necesitan ediciones por máquina y los mapeos se recargan en caliente (la única excepción es el límite de heap de los scripts, SCRIPT_MEMORY_LIMIT_MB, que requiere reiniciar)