Cómo recorté mi factura de tokens de Claude Code con Converly LM

Converly LM es un servidor MCP que permite a Claude Code delegar el trabajo rutinario (stubs de test, mensajes de commit, revisiones de código, conversiones de formato) a un modelo barato o local, mientras Claude conserva la planificación, la orquestación multi-archivo y el QA; cada respuesta muestra un contador de tokens que te habrías gastado si hubiera hecho el trabajo él mismo. Dejé Claude Code corriendo toda la noche con un refactor hace unos meses, entré en la cocina a la mañana siguiente con un café y vi el contador de tokens pasar a una cifra que prefiero no poner por escrito. El trabajo en sí había salido bastante limpio. El problema era la factura. La mayor parte del gasto, al repasar el registro de la sesión, se había ido en el tipo de trabajo que cualquier modelo de código competente maneja bien: stubs de test, mensajes de commit, repasos de una función que no había visto antes, conversiones de formato, revisión de código en archivos que nunca iban a empujar la arquitectura en una dirección útil.

La pregunta interesante no era «¿debería dejar de usar Claude?», sino «¿qué puedo quitarle del plato a Claude sin perder aquello por lo que pago?». El razonamiento de Claude. La orquestación multi-archivo. La capacidad de llamar a herramientas, planificar un cambio en seis archivos, ejecutar las pruebas y decirme cuáles fallaron y por qué. Esa parte vale cada token. La parte de «redáctame veinte stubs de test», no.

Así que construí Converly LM. Es un servidor MCP que permite a Claude delegar el trabajo aburrido a un modelo barato o local, mantiene la planificación y el QA en Claude y te muestra el recuento acumulado de tokens que te habrías gastado si Claude lo hubiera hecho él mismo. Llevo varios meses usándolo a diario en mi propio equipo y descargo entre 20.000 y 50.000 tokens en un día cargado. Aquí explico cómo lo uso, qué recomendaría para endpoints en 2026 y dónde falla.

Por qué lo construí

Hay todo un género de YouTube para desarrolladores ahora mismo diciéndote que abandones Claude por completo y ejecutes Qwen Coder o Gemma en tu propia máquina. Algunos de esos vídeos tienen cifras de visualizaciones enormes, y no están técnicamente equivocados: puedes sacar código de un modelo local de 20 mil millones de parámetros. La trampa aparece cuando los propios casos de prueba del revisor empiezan a fallar. El mismo vídeo que demuestra un modelo de 120B escribiendo Python limpio suele mostrar a la versión de 20B de la misma familia cascándolo. Puedes sustituir Claude por un modelo local. Lo que no puedes hacer es sustituir Claude por un modelo local sin perder el razonamiento que hace que Claude Code merezca la pena pagar.

Quería el alivio de coste sin el precipicio. El esquema de arquitecto/redactor/QA es lo que salió de ahí. Claude se queda en el asiento de la planificación y la revisión. El modelo barato hace el tecleo. El tecleo, resulta, es a donde se va la mayor parte del uso de tokens.

Llevo unos seis meses ejecutando Qwen Coder Next en una máquina local (llamada hopper, vive en el armario bajo las escaleras). Es un modelo mixture-of-experts de 80 mil millones de parámetros, con una ventana de contexto decente y absolutamente brillante en trabajo acotado. Pídele que razone entre tres archivos a la vez y las ruedas se salen. Pídele que escriba tests para una función, que redacte un mensaje de commit a partir de un diff o que explique qué hace un trozo de código heredado, y es más rápido que yo tecleando.

Converly LM es el puente. Claude Code (o Claude Desktop) habla con él vía MCP. Habla cualquier endpoint compatible con OpenAI: LM Studio en tu red local, OpenRouter para acceso en la nube a más de 300 modelos, DeepSeek, Groq y Cerebras para inferencia barata y rápida, vLLM si te autoalojas. La arquitectura es la misma independientemente de a dónde lo apuntes.

El arquitecto, el redactor y el QA

El modelo mental que mantengo son tres roles, un flujo de trabajo.

Claude es el arquitecto. Lee el encargo, planifica el trabajo, decide qué archivos hay que cambiar, llama a las herramientas, ejecuta las pruebas y juzga si el resultado es correcto. Mantengo el razonamiento en el modelo frontera porque para eso es el modelo frontera.

El modelo barato o local es el redactor. Toma una tarea acotada con todo el contexto empaquetado en un único mensaje —«aquí tienes una función, escríbeme tests para ella», «aquí tienes un diff, redacta un mensaje de commit»— y devuelve la salida. No ve el sistema de archivos, la conversación anterior ni nada excepto lo que Claude envía en el mensaje. Ese aislamiento fue una decisión de diseño deliberada por mi parte: en parte porque mantiene la arquitectura realmente simple, y en parte porque no me hacía mucha gracia darle a un modelo cualquiera rienda suelta sobre mi sistema de archivos.

Claude es el QA. Lee el borrador de vuelta, decide si publicarlo, pedir una revisión o reescribir la sección él mismo. Una salida equivocada del redactor no me cuesta nada en el trayecto: Claude la detecta, envía un prompt más afilado y sigue adelante. El pase de QA es lo que hace que la arquitectura sea segura para usarla en trabajo real y no solo en demos.

La prueba que ejecuto al decidir si delegar: ¿confiaría esta tarea a un desarrollador junior competente que trabajara a partir de una especificación clara, conmigo revisando la salida antes de que se publique? Si la respuesta es sí, se delega. Si la tarea es «decidir si partir este archivo de 600 líneas en tres o cuatro módulos», no: en esa quiero el cerebro del arquitecto, no el del redactor.

Qué hay dentro

Mantuve Converly LM intencionadamente pequeño. Hay ocho herramientas MCP y un recurso MCP. Toda la superficie cabe en una pantalla.

• chat: envía una única tarea y recibe una respuesta. Mi caballo de batalla. Soporta un parámetro model opcional si quieres fijar un id de modelo específico solo para esta llamada (útil en OpenRouter, donde 343 modelos se reportan como «loaded» y el router, de lo contrario, elige prácticamente al azar).
• custom_prompt: prompt estructurado en tres partes: mensaje de sistema, contexto e instrucción. Supera a chat en cualquier caso en el que te importe que el modelo se mantenga centrado en un tipo específico de tarea. Lo probé bien un fin de semana: cogí el mismo lote de tareas de revisión y las ejecuté de ambas formas, una como un único muro de texto y otra dividida en sistema/contexto/instrucción. La estructura de tres partes ganó todas las rondas. En el modelo Qwen de 14B la diferencia fue casi cómica: le di un mensaje largo y desestructurado y empezó a revisar una función completamente distinta de la que yo había preguntado.
• code_task: específico para código. Prompt de sistema preconfigurado, temperatura y restricciones de salida por familia. Qwen Coder corre aquí a 0.1, GLM con un ajuste ligeramente distinto, etc.
• code_task_files: lee archivos del lado del servidor en lugar de a través de la ventana de contexto del cliente MCP. Le pasas paths, el servidor los concatena y los procesa. Hay un estimador de tokens de pre-vuelo que rechaza de entrada las entradas que claramente se pasan del presupuesto usando una regresión por mínimos cuadrados ordinarios sobre la tasa de prefill medida del modelo, en lugar de dejar que se queden colgados en silencio dos minutos antes de un timeout.
• embed: /v1/embeddings compatible con OpenAI para RAG. Usa el modelo de embeddings que exponga tu endpoint.
• discover: comprobación de salud más velocidad medida. Muestra el TTFT (tiempo hasta el primer token) y los tok/s del modelo activo, promediados a lo largo de la sesión y del tiempo de vida de la estación de trabajo. La primera llamada medida de cada modelo emite un benchmark de una línea: sin calentamiento sintético, cifras reales de tareas.
• list_models: el catálogo completo con enriquecimiento de metadatos de HuggingFace.
• stats: un volcado compacto en markdown de los totales de sesión y de tiempo de vida, el rendimiento por modelo y la sobrecarga de tokens de razonamiento. Barato de llamar repetidamente para ver cómo sube el contador de ahorro.

El recurso MCP es converly://metrics/session, que expone los mismos números que stats en JSON para cualquier cliente que quiera mostrarlos en su propia interfaz.

La pieza que quiero señalar específicamente es el contador de ahorro. Cada respuesta de herramienta incluye una línea al pie que dice 💰 Claude quota saved - this session: X tokens / Y calls · lifetime: Z tokens / W calls. El número de tiempo de vida persiste entre sesiones en una base de datos SQLite en ~/.converly-lm/model-cache.db en mi estación de trabajo. Es lo más parecido que tengo a una contabilidad honesta de lo que todo esto hace por mí.

Los endpoints que recomendaría en 2026

Converly LM habla cualquier endpoint compatible con OpenAI, así que la pregunta es contra cuáles ejecutarlo. Mis recomendaciones se han asentado en los últimos meses.

LM Studio es lo que recomiendo si tienes hardware local. Bien testeado, bien comportado, mi objetivo de desarrollo por defecto para el propio MCP. Si tienes una máquina con GPU en tu red con un modelo cargado, apunta Converly LM hacia ella y empieza a delegar. He escrito una guía aparte para configurar LM Studio si no lo has hecho antes.

OpenRouter es la recomendación principal si no tienes hardware local (o si quieres alcance en la nube además). Una clave de API, más de 300 modelos, enrutamiento automático. Converly LM detecta OpenRouter por la URL y cambia de comportamiento: las cabeceras de atribución salen en cada petición, el flag de exclusión de razonamiento se dispara correctamente en modelos con «thinking» y el reintento con backoff ante 429/5xx entra automáticamente. No tienes que configurar nada de eso: apúntalo a https://openrouter.ai/api/v1, pon la clave y funciona.

DeepSeek, Groq, Cerebras, Fireworks, vLLM: todos funcionan a través de la ruta genérica compatible con OpenAI. Elige la combinación de precio y velocidad que se ajuste a tu carga de trabajo. Cerebras a 3.000 tokens por segundo es ridículo para tareas acotadas: lo he visto devolver una revisión de código de 400 tokens antes de que la barra de estado de mi terminal terminara de redibujarse. DeepSeek V3.2 es el modelo de código competente más barato que he usado en el momento de escribir esto.

Ollama es compatible, pero no lo recomiendo. Converly LM funciona con Ollama (v2.12.0 corrigió tres bugs específicos de Ollama para llegar ahí: la captura de delta.reasoning en el campo correcto, la detección de thinking de Qwen3 que la plantilla Jinja de Ollama hardcodea a on, y un campo model autoinyectado porque Ollama devuelve HTTP 400 sin él, mientras que LM Studio acepta el valor por defecto). Funciona. Simplemente es, en la práctica, consistentemente más frágil que LM Studio. Si puedes ejecutar LM Studio en su lugar, y en Windows, macOS y Linux puedes, ejecuta LM Studio. El SERP de «local model» está lleno de tutoriales de Ollama y entiendo por qué la recomendación se propaga, pero los meses que he pasado depurando casos límite específicos de Ollama no han cambiado mi postura al respecto.

Qué delego (y qué me guardo en Claude)

Mi matriz de delegación se ha asentado en algo simple. La prueba que ejecuto es si la tarea tiene una entrada claramente acotada y una salida claramente acotada, y si puedo hacer el QA del borrador en unos segundos cuando Claude me lo lee de vuelta.

Lo que envío a Converly LM:

• Stubs de test a partir de una firma de función
• Mensajes de commit a partir de un diff
• Revisiones de código de un archivo o un conjunto pequeño de archivos (paso el código fuente completo vía code_task_files, no fragmentos: el modelo barato casca las revisiones de archivos a medias)
• Repasos de «¿qué hace esta función?» de código heredado que acabo de abrir por primera vez
• Conversión de formato: de JSON a YAML, de snake_case a camelCase, tipos a partir de un JSON schema
• Salida JSON estructurada donde el modelo es la única fuente sensata (paso un parámetro json_schema y obtengo una salida restringida por gramática que valida al primer intento)
• Brainstorming: redactar unos cuantos nombres candidatos, variantes de copy candidatas, enfoques candidatos
• Embeddings de texto para indexación RAG

Se queda en Claude:

• Cualquier cosa que necesite llamar a otras herramientas (leer archivos, escribir archivos, ejecutar la suite de tests, parsear el fallo)
• Planes de refactorización multi-archivo: el modelo barato los casca
• Decisiones arquitectónicas en las que perderse un caso límite arruina todo el diseño
• Cualquier cosa en la que el criterio de éxito sea «¿se puso verde la suite de tests después?»: Claude puede ejecutar las pruebas, el modelo local no
• Cualquier cosa en la que el borrador sea difícil de QA en unos segundos (prosa larga donde no tienes una verdad clara contra la que comprobar)

El enfoque que se me ha quedado es que Claude hace el trabajo que requiere leer la mente de otros (la intención del usuario, el veredicto de la suite de tests, los contratos de los otros archivos), y Converly LM hace el trabajo que requiere producir una salida bien formada a partir de una especificación limpia.

Las cifras en mi propio equipo

El hardware importa aquí porque fija un suelo sobre lo que es honesto afirmar. Yo ejecuto una RTX 4500 Ada con 256 GB de RAM de sistema en un chasis Threadripper PRO 5995WX. Qwen Coder Next carga con cuantización Q6 repartido por la VRAM disponible. La ventana de contexto de 256K es generosa para el tipo de trabajo de delegación que hace Converly LM, y el recuento de parámetros activos significa que la inferencia es lo bastante rápida para que la ida y vuelta no sea un problema de usabilidad.

En un día cargado típico, el contador de ahorro se ve más o menos así:

💰 Claude quota saved - this session: 4,283 tokens / 7 calls · lifetime: 147,432 tokens / 213 calls

Eso no es un benchmark, es lo que lee mi salida real de stats la mañana en que escribí esta sección. El pie por llamada es más informativo cuando estás ajustando:

Model: qwen/qwen3-coder-next | 279→303 tokens (12 reasoning / 291 visible) | TTFT: 485ms, 58.0 tok/s, 5.2s

La cifra de TTFT (tiempo hasta el primer token) es la que vigilo. Está dominada por el coste de prefill —el modelo leyendo el prompt antes de empezar a generar— y en entradas largas puede empequeñecer el tiempo de generación. Converly LM la sigue por modelo y usa una regresión por mínimos cuadrados ordinarios sobre muestras (prompt_tokens, TTFT_ms) para predecir el coste de prefill de nuevas entradas. En mis datos medidos, Qwen Coder Next se ajusta a α=668ms, β=1,49ms/token, R²=0,999, lo que equivale a decir que el modelo tiene 668 ms de sobrecarga fija por petición y añade 1,49 ms por token de entrada. Eso permite al estimador de pre-vuelo rechazar de entrada una entrada de 7.000 tokens con un honesto «esto tardará 11,1 segundos, quizá quieras pensártelo» en lugar de empezar y quedarse colgado.

La otra razón por la que las cifras importan es que son la respuesta al inicio. La mueca ante el recuento de tokens desapareció porque el contador de la máquina local estaba subiendo en su lugar. No todo: Claude sigue haciendo la arquitectura, la orquestación y los pases de QA, pero lo bastante para que la factura de Anthropic volviera a algo que no me importa mirar.

Si no tienes hardware local, los endpoints baratos en la nube (DeepSeek, Groq, Cerebras) replicarán la arquitectura por una pequeña fracción del coste por token de Anthropic. Las matemáticas siguen favoreciendo la descarga. La diferencia es que con hardware local el coste marginal es la electricidad y, con la nube, es por token a un proveedor más barato.

He escrito una guía completa para elegir hardware para IA local si estás decidiendo qué construir o comprar.

Para empezar

Un comando, si tienes Claude Code instalado:

claude mcp add converly-lm -- npx -y @converly/lm

Si tienes LM Studio corriendo en localhost:1234 (el valor por defecto) con un modelo cargado, Claude puede empezar a delegar de inmediato. Sin variables de entorno, sin archivo de configuración, nada que tocar.

¿Ejecutas el LLM en otra máquina? Apunta Converly LM a la IP:

claude mcp add converly-lm -e CONVERLY_LM_ENDPOINT_URL=http://192.168.1.50:1234 -- npx -y @converly/lm

El espacio de nombres de variables de entorno es CONVERLY_LM_* a partir de v2.13. El conjunto completo:

• CONVERLY_LM_ENDPOINT_URL: la URL del endpoint (por defecto http://localhost:1234)
• CONVERLY_LM_API_KEY: autenticación bearer para endpoints remotos
• CONVERLY_LM_MODEL: fija un id de modelo específico, anula el enrutamiento
• CONVERLY_LM_PROVIDER: fuerza la detección de proveedor (rara vez necesario; la detección por URL suele funcionar)
• CONVERLY_LM_CONTEXT_WINDOW: anulación manual de la ventana de contexto

Los nombres heredados LM_STUDIO_* siguen funcionando indefinidamente. Si tienes una configuración existente de una versión anterior, no necesitas migrarla.

Para OpenRouter:

claude mcp add converly-lm \
  -e CONVERLY_LM_ENDPOINT_URL=https://openrouter.ai/api/v1 \
  -e CONVERLY_LM_API_KEY=sk-or-... \
  -e CONVERLY_LM_MODEL=qwen/qwen3-coder-next \
  -- npx -y @converly/lm

Para Claude Desktop, las mismas variables de entorno van en el bloque claude_desktop_config.json. La guía de instalación de servidores MCP para Claude Desktop cubre la estructura del JSON.

¿Nuevo en Claude Code? Puedes registrarte aquí para una semana gratis de Claude Code y probar toda esta arquitectura sin comprometerte con una suscripción.

Dónde falla

La lista honesta.

La delegación concurrente se encola en el endpoint. La mayoría de servidores LLM procesan una petición cada vez. Si Claude dispara tres llamadas de delegación en paralelo, y lo hará, especialmente en sesiones largas donde ha descubierto que delegar es barato, se serializan en el endpoint y los timeouts se acumulan. Converly LM tiene un semáforo por proveedor que limita los backends locales a single-flight (de modo que la cola es honesta), mientras que los proveedores remotos como OpenRouter saltan el bloqueo porque tienen capacidad paralela nativa. Las descripciones de las herramientas advierten a Claude del compromiso; en la práctica se comporta la mayor parte del tiempo.

El timeout de 60 segundos de las peticiones del cliente MCP. El SDK de MCP del lado del cliente abandona una única petición después de unos 60 segundos. Un prompt grande + un modelo frío + un prefill lento solía significar que desaparecían respuestas perfectamente válidas. Converly LM se defiende de esto en tres sitios: un latido de progreso previo a la obtención empieza a dispararse en el momento en que se reconoce una llamada a herramienta, un keep-alive de 10 segundos se ejecuta mientras se esperan las cabeceras de respuesta del upstream y las notificaciones de progreso continúan durante la generación en streaming. Los clientes que respetan resetTimeoutOnProgress (Claude Desktop lo hace) ahora sobreviven a prefill de varios minutos de forma limpia. Los que no, seguirás viendo de vez en cuando un timeout con una entrada grande.

El modelo local nunca toca tu sistema de archivos. Es una decisión de diseño deliberada, no un bug, pero merece la pena señalarlo porque condiciona cómo delegas. El redactor solo ve lo que Claude envía en el mensaje. No puede leer tu proyecto, navegar por tu configuración ni mirar el archivo junto al que estás preguntando. La arquitectura resulta absurdamente simple como consecuencia, y no me pone nervioso que un modelo con acceso al sistema de archivos haga algo que no pretendo, pero significa que Claude tiene que empaquetar el contexto relevante en cada llamada de delegación. En revisiones de código grandes esto se vuelve verboso. code_task_files mitiga lo peor leyendo del lado del servidor, de modo que el código fuente en sí nunca pasa por la ventana de contexto del cliente MCP, pero sigues pagando tokens del lado de Claude para escribir las rutas.

La calidad de salida del modelo local escala con el modelo. Ejecutar Qwen Coder Next en 104 GB de VRAM es una experiencia distinta de apretar un modelo de 7B en 16 GB en una GPU vieja. La brecha de calidad es real y el nivel que te puedas permitir va a limitar qué tareas salen limpias. En los niveles más bajos, sé más conservador con lo que delegas. Los stubs de test y los mensajes de commit siguen funcionando bien. Las revisiones de código multi-archivo, no.

La disciplina de prompt importa más que con Claude. Los modelos locales y los de nube barata necesitan instrucciones más claras que los modelos frontera. He metido guía en las descripciones de las herramientas del MCP («envía código completo, nunca trunques», «sé explícito sobre el formato de salida», «define una persona concreta») y Claude recoge la mayor parte, pero si obtienes una salida mediocre, nueve de cada diez veces es la forma del prompt y no el modelo.

Por dónde seguir

Si tienes Claude Code instalado, estás a unos diez segundos de recortar tu gasto de tokens en trabajo acotado:

claude mcp add converly-lm -- npx -y @converly/lm

El paquete está en npm como @converly/lm. El código fuente está en GitHub si quieres leer cómo funciona el enrutamiento. Piezas complementarias:

• La guía de configuración de LM Studio si estás configurando el endpoint local recomendado.
• La guía de instalación de servidores MCP para Claude Desktop si lo estás conectando a Desktop en lugar de a Code.
• La guía de hardware para IA local si estás decidiendo en qué tipo de máquina poner el modelo.
• La guía para principiantes de Claude si eres nuevo en Claude Code o Desktop y quieres un panorama general.

Apúntalo a lo que tengas corriendo —Qwen en la máquina del armario, DeepSeek por cable, Cerebras si quieres una velocidad absurda— y deja que el contador de ahorro corra una semana. El número al que llega es la respuesta a la mueca que puse en la encimera de la cocina hace seis meses.

Artículos relacionados