Claude Code con GLM-5.3 y Qwen: cinco trampas al sustituir el modelo mediante LiteLLM

Sustituir el modelo bajo Claude Code es facilísimo: ANTHROPIC_BASE_URL, un token, y el agente envía solicitudes mediante el protocolo Anthropic Messages a donde sea. Los problemas empiezan el segundo día. El equipo de la pasarela bielorrusa ZuBrIQ, donde Claude Code oficialmente no funciona y no hay forma de pagar a Anthropic, describió cinco trampas en las que cayó por sí mismo.

El esquema y la regla principal

Entre los clientes (Claude Code, Codex, OpenCode, Zed, Cursor) y los modelos hay un LiteLLM en dos pods. Los clientes solo conocen nombres estables: zubr, zubr-flash, zubr-coder. Detrás de cada uno hay una lista de rutas con orden y respaldo: GLM-5.3 de un proveedor, DeepSeek V4 Pro como alternativa y un Qwen3.8-27B propio sobre cuatro V100. Si cambian los pesos o cae el proveedor, las integraciones no lo notan. Es cómodo, pero justo ahí se esconden las averías silenciosas.

Tres averías silenciosas

Primera: el desvío discreto al respaldo. GLM-5.3 se configuró como un backend openai/ normal. El chat funcionaba, pero Claude Code y Codex recibían respuestas del modelo de respaldo. LiteLLM traduce /v1/messages y /v1/responses a la Responses API, el proveedor responde 404 y el enrutador sigue de largo en silencio. En los logs no hay error; lo delata solo la cabecera x-litellm-attempted-fallbacks: 1. Se soluciona con el proveedor nativo de LiteLLM para ese fabricante, que traduce todo a chat/completions.

Segunda: gasto cero. Con el proveedor nativo, LiteLLM no toma el precio de model_info, el gasto (spend) es cero, los presupuestos de las claves no se activan y el informe de margen miente. Hay que duplicar los precios directamente en litellm_params: input_cost_per_token, output_cost_per_token, cache_read_input_token_cost. Otro matiz: un cambio mediante PATCH /model/{id}/update tarda uno o dos minutos en llegar al segundo pod, así que no se apresure a pensar que no funcionó.

Tercera: las imágenes. GLM-5.3 es fuerte en código, pero no acepta imágenes.

El endpoint de chat del proveedor responde 400, mientras que el endpoint compatible con Anthropic descarta la imagen en silencio y el modelo adivina con seguridad a partir del texto. El usuario envía una captura de un error y recibe razonamientos sobre algo que el modelo no vio. En ZubrCode lo resolvieron así: si en el catálogo el modelo no tiene visión, la imagen se sustituye por una descripción textual de GLM-5.

3 Flash, y el resultado se guarda en caché según el sha256 de la imagen, porque el agente reproduce todo el historial en cada turno. Hubo además un error aparte en el catálogo: supports_vision: null se trataba como false, y desapareció la visión de un modelo que sí ve.

Configuración de Claude Code y GPU propias

Claude Code envía por sí mismo subtareas de servicio (títulos, compresión de contexto, subagentes) a modelos de las clases Haiku, Sonnet y Opus. Si se sustituye solo ANTHROPIC_MODEL, esas solicitudes fallarán con 403 en pleno trabajo. Hay que definir ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL y ANTHROPIC_DEFAULT_HAIKU_MODEL. Escriba ANTHROPIC_BASE_URL sin /v1, o terminará con /v1/v1/messages. El sufijo [1m] indica una ventana de 1M y se elimina antes del envío; para modelos sin él, la ventana la fija CLAUDE_CODE_MAX_CONTEXT_TOKENS.

Un modelo propio en tarjetas de 2017 es otra historia. Las V100 no tienen bf16 ni FP8, por lo que se usa AWQ INT4 con cálculos en FP16, vLLM con paralelismo tensorial en 4 tarjetas y un fork con soporte para SM70. El fork no resta los pesos al calcular el presupuesto de la caché KV, por eso --kv-cache-memory-bytes se define de forma explícita.

No se pueden arrancar dos instancias a la vez: el pico de inicialización supera los 16 GB, el worker sufre un OOM y el proceso principal se cuelga en el NCCL watchdog, aunque systemd muestre active. Ahora la segunda unidad espera al health de la primera. El 27B denso en lugar del MoE 35B-A3B es más inteligente y ve imágenes por sí mismo, pero el primer token llega en ~1,3 s en vez de ~0,6 s, por lo que se reserva para tareas en segundo plano y datos cerrados.

Qué hacer

Las limitaciones son evidentes: es la experiencia de un solo equipo, los precios de los ejemplos son ilustrativos y el comportamiento de LiteLLM puede cambiar entre versiones. Pero el principio es general. Si coloca una pasarela entre el agente y los modelos, monitoree las cabeceras de fallback, concilie el gasto con las facturas reales del proveedor, compruebe qué ocurre con la imagen en cada ruta y defina los tres espacios: Haiku, Sonnet y Opus.

Los errores más caros aquí no se caen con un error: responden con seguridad, pero no con las palabras correctas. La pasarela forma parte de la plataforma comercial de los autores, así que el artículo es en parte publicitario, pero los detalles técnicos son fáciles de comprobar en su propio banco de pruebas.