Cambiando el motor: Claude Code en silicio local, coste cero

Imagen: cultofmac.com

El poder real de Claude Code no es el modelo de Anthropic que hay detrás, es lo agéntico: el acceso al sistema de archivos, el uso de herramientas, la forma de encadenar tareas sin que tengas que vigilar cada paso. Me di cuenta por la vía cara. El mes pasado pasé un lote de scripts de parseo de logs por la API para un proyecto de cliente y me topé con una factura de 400 £ en una semana. Cuatrocientas libras, casi todas en tokens de Sonnet masticando pattern-matching repetitivo que no necesitaba inteligencia frontera.

Ahí empezó mi búsqueda en serio de cómo ejecutarlo todo en local. Y la respuesta, resulta, es bastante sencilla: cambias el motor de la nube por un modelo local vía Ollama o LM Studio, mantienes la CLI de Claude Code como interfaz y obtienes la misma potencia de flujo de trabajo por un coste marginal cero. Hace un tiempo escribí sobre recortar el gasto en tokens de Claude Code con Converly-LM, pero esto va más allá. Se trata de desacoplar del todo de la API para el trabajo pesado y recurrir a Sonnet solo cuando de verdad lo necesitas.

---

Piénsalo como un cambio de motor. El coche (la CLI de Claude Code, su bucle agéntico, su capacidad de leer y escribir tus archivos) sigue exactamente igual. Solo estás montando un motor distinto, uno que corre en tu propio silicio en lugar de en los servidores de Anthropic.

Navegación rápida: El impuesto de la API frente a tu estrategia de silicio | Preparando tu entorno: la pila local | El cambio de motor: mapeando Claude Code a localhost | La limpieza del 'Big Log': una auditoría de marketing real | Cuándo usar modelos locales frente a motores de fábrica | Más allá del bot: mantener la independencia

El impuesto de la API frente a tu estrategia de silicio

Anthropic está ahora en una tasa de ingresos de 5.000 millones de dólares, alimentada por 300.000 clientes empresariales que pagan más de 100.000 dólares al año. Es economía de fiebre del oro, edición API. Si eres un marketer técnico que ejecuta flujos agénticos a través de Claude Code, estás en la cola con todo el mundo, pagando por token por un trabajo que podría no necesitar un modelo frontera en absoluto.

Llamémoslo el impuesto de la API (mi hijo se ríe con esto por el meme del impuesto del queso). Es la prima que pagas cuando envías tareas rutinarias, repetitivas o de procesamiento masivo a Sonnet porque es lo que Claude Code usa por defecto. ¿Parsear un gigabyte de logs de servidor en busca de patrones 404? ¿Escribir un script para auditar enlaces internos en 10.000 páginas? ¿Generar esquemas Zod para un pipeline de datos? Nada de esto requiere la profundidad de razonamiento de un modelo frontera. Pero si llegas al endpoint de Anthropic, pagas precios frontera.

Ya he escrito sobre recortar tu uso de tokens de Claude Code con Converly-LM, y el principio central no ha cambiado: casa el modelo con la tarea. Ahora mismo, gran parte de la conversación de desarrolladores va de vibe coding, de lograr que Claude construya apps enteras de un golpe, y eso está bien para presumir en Twitter. La cuestión es que, si construyes automatización de marketing repetible que se ejecuta a diario o semanalmente, los costes de tokens se acumulan rápido. Una sola sesión de análisis de logs que devora cientos de miles de tokens puede costar más que el hosting del propio proyecto.

La computación local es la única forma de escalar infraestructura agéntica sin sangrar dinero. Tu propio silicio, tu propia VRAM, coste cero por token tras la inversión en hardware. El cambio de motor que describí arriba hace esto posible sin renunciar a las herramientas de Claude Code, a su acceso a archivos, a su bucle agéntico. Mantienes el coche, solo dejas de llenarlo con combustible premium para cada viaje a comprar el pan.

Preparando tu entorno: la pila local

Bien, antes de meternos, necesitas tener esto instalado:

curl -fsSL https://ollama.com/install.sh | sh

Eso es Ollama. Una línea. Luego descarga tu modelo:

ollama run qwen2.5-coder:32b

¿Te falta VRAM? Con menos de 24 GB, baja a la variante de 7b. Sigue siendo capaz para la mayoría de trabajos de scripting y parseo.

¿Por qué Qwen 2.5 Coder frente a Llama 3.1? Qwen sigue instrucciones de varios pasos de forma más fiable, sobre todo para tareas de E/S de archivos o transformación de datos donde necesitas que se mantenga en el camino. Llama 3.1 se despista. Qwen se mantiene en la tarea. Para el trabajo diario de automatización de marketing, esa diferencia importa más que las puntuaciones brutas de los benchmarks.

Una vez descargado, tienes un modelo local corriendo en tu propio silicio, listo para atender peticiones del bucle agéntico de Claude Code. Sin clave de API, sin facturación por token.

El cambio de motor: mapeando Claude Code a localhost

Bien, ya tienes un modelo corriendo en local en tu propia máquina. Ahora necesitas cablear la CLI de Claude Code para que hable con él en lugar de llamar a casa a los servidores de Anthropic. Esta es la parte donde la mayoría de guías pasan por alto los detalles engorrosos.

Claude Code es, en su núcleo, un framework agéntico. Lee tus archivos, ejecuta comandos shell, gestiona tareas de varios pasos. La inteligencia detrás de esas decisiones puede venir de la API de Anthropic o de cualquier cosa que hable el mismo protocolo en localhost. Ese es el truco entero: mantienes el framework (que es genuinamente excelente) y cambias dónde ocurre el pensamiento.

Primero, comprueba que Ollama está sirviendo en el puerto correcto. Por defecto escucha en 11434, pero he visto configuraciones donde otra cosa se ha adueñado de ese puerto. Comprobación rápida:

curl http://127.0.0.1:11434/v1/models

Deberías recibir una respuesta JSON listando lo que hayas descargado. Si obtienes un error de conexión rechazada, Ollama no se está ejecutando o algo ocupa ese puerto. lsof -i :11434 te dirá qué es.

Ahora, apunta Claude Code a tu endpoint local. Necesitas dos variables de entorno:

export ANTHROPIC_BASE_URL=http://127.0.0.1:11434/v1
export ANTHROPIC_MODEL=qwen2.5-coder:32b

Ponlas en tu .bashrc o .zshrc si quieres que sean persistentes. Yo guardo las mías en un script de shell aparte porque cambio entre local y nube según la tarea, un hábito que cogí tras dejar Claude Code corriendo toda la noche en refactors grandes y despertar para hacer una mueca al ver el recuento de tokens.

Si quieres comprobar que de verdad estás llegando a localhost y no filtrando peticiones a Anthropic, ejecuta un curl rápido contra el endpoint de chat completions:

curl http://127.0.0.1:11434/v1/chat/completions \
 -H "Content-Type: application/json" \
 -d '{"model":"qwen2.5-coder:32b","messages":[{"role":"user","content":"ping"}]}'

Si eso devuelve una respuesta, estás en local. Si agota el tiempo o da error, revisa la configuración del firewall.

El dolor de cabeza del paso intermedio del que nadie te avisa: si ejecutas Ollama dentro de Docker o WSL, probablemente te topes con errores de CORS o timeouts de conexión porque la API no está correctamente expuesta a la red del host. En Docker, necesitas ,network=host o un mapeo de puertos explícito. En WSL2, localhost no siempre resuelve limpiamente a la instancia de WSL; puede que necesites la IP real de WSL desde hostname -I. Me costó unos cuarenta minutos la primera vez.

Así que, según lo que de verdad he probado, esto es lo que yo usaría para hardware y concurrencia:

La cuestión es que la concurrencia es la trampa. El bucle agéntico de Claude Code puede disparar un montón de peticiones en rápida sucesión cuando planifica y ejecuta pasos. En la nube, eso está bien porque la infra de Anthropic lo gestiona. En local, si ejecutas un modelo de 32B en una sola GPU, necesitas OLLAMA_NUM_PARALLEL=1 o verás cómo las peticiones se encolan y todo se atasca. Para el modelo de 7B en un Mac M3 o una RTX 3060, puedes empujar las peticiones paralelas un poco más, pero vigila ollama ps para ver qué hay realmente cargado.

Algo que vale la pena saber: el handshake inicial entre Claude Code y el endpoint local puede ser lento, a veces 8-10 segundos en un arranque en frío mientras el modelo se carga en VRAM. Tras esa primera petición, las llamadas siguientes son rápidas (el ajuste OLLAMA_KEEP_ALIVE gestiona esto). Pero si eres impaciente y matas el proceso pensando que se ha colgado, solo reiniciarás todo el ciclo de carga. Dale un minuto.

La limpieza del 'Big Log': una auditoría de marketing real

Imagen: reddit.com

Así que tengo la pila local funcionando y necesitaba algo real que lanzarle. No un ejemplo de juguete, sino el tipo de tarea tediosa y de alto volumen que quema silenciosamente créditos de API si no estás pendiente.

Así que el escenario: un sitio de cliente con dieciocho meses de logs de servidor. Exportación en bruto de poco más de 1 GB de texto; ahí dentro hay patrones de errores 404 que están dañando la eficiencia del rastreo. Enlaces internos rotos, URLs de campañas antiguas que nunca se redirigieron, el desastre habitual. Lo que necesitaba era un script capaz de parsear, desduplicar y agrupar esos 404 por patrón para entregarle al equipo de desarrollo una hoja de cálculo limpia y decirles «arreglad estas 340 URLs».

¿Ejecutar esto por la API de Sonnet con Claude Code haciendo todo el trabajo? Un volumen serio de tokens. Un gigabyte de logs, incluso troceado de forma sensata, significa cientos de miles de tokens de entrada por pasada. Estimé el coste en algún punto por encima de 80 $ para una sola ejecución de análisis, y eso antes de que inevitablemente refines el script y lo vuelvas a ejecutar. Dos veces. Tal vez tres. Potencialmente más de 200 $ en lo que, francamente, es un trabajo aburrido de parseo de datos.

¿En hardware local? Cero. El silicio ya está pagado; está sobre mi mesa.

Pero hay un problema, y no es pequeño. Los modelos locales no gestionan ventanas de contexto masivas como lo hace la API alojada. No puedes simplemente pasar un archivo de 1 GB a qwen2.5-coder y esperar que razone sobre el conjunto. Se ahogará o, peor, truncará en silencio y te dará resultados basados en el fragmento que haya conseguido cargar. Mi primer intento volvió «limpio», pero en realidad solo había procesado los primeros 12 MB de logs.

La solución es el troceado manual. Escribí un script rápido en bash para dividir el archivo de log en fragmentos de 50 MB y luego apunté a Claude Code a cada uno de forma secuencial: extrajo los patrones 404 de cada fragmento y añadió los resultados a un único archivo de salida. No es elegante. Es pura fontanería. Pero funciona, y el acceso agéntico al sistema de archivos que te da Claude Code, incluso apuntando a un modelo local, hace que la orquestación sea sencilla.

El modelo local de 32B tardó unos 45 minutos en masticar el gigabyte completo en fragmentos. No es rápido. Pero lo lancé, me preparé un café y volví a un CSV de patrones 404 agrupados listo para revisar. El pattern matching era lo suficientemente bueno para el trabajo, y ese es el listón que de verdad importa aquí. Cazó lo obvio: rutas viejas de /blog/2023/, imágenes de producto que faltaban, URLs de paginación rotas, y las agrupó de forma sensata.

El enfoque por fragmentos de hecho sacó a la luz patrones que un análisis de una sola pasada habría pasado por alto, algo que no esperaba de un modelo local. Como cada fragmento recibe su propia pasada de análisis, acabas con recuentos de frecuencia que se agregan de forma natural, y los duplicados entre fragmentos se convierten en señales obvias. Si la misma URL rota aparece en quince segmentos de log distintos, ahí tienes tu lista de prioridades escribiéndose sola.

He escrito más sobre recortar tu uso de tokens de Claude Code con Converly-LM si quieres el detalle de gestionar costes para este tipo de trabajo. La versión corta: usa local para el medio caótico, el parseo, la fontanería y la iteración, y luego reserva tu presupuesto de API para las partes donde de verdad necesitas el razonamiento de Sonnet.

Cuándo usar modelos locales frente a motores de fábrica

Imagen: xda-developers.com

La decisión no es teórica. Necesitas una regla de clasificación para qué tareas se quedan en local y cuáles se mandan a la API.

Si la tarea es mecánica, el tipo de trabajo donde escribes boilerplate, limpias logs, haces extracción con regex, reformateas datos entre esquemas, manténla en local. Si implica razonamiento arquitectónico de verdad, donde el modelo necesita sostener un sistema complejo en la cabeza y tomar decisiones sobre la estructura, entonces la mandas a Sonnet.

Yo lo llamaría el umbral del 30 %. Si la tarea es el 30 % o menos de tu lógica central, es decir, es fontanería y parseo en lugar de toma de decisiones real sobre cómo debe funcionar tu sistema, ejecútala en tu configuración local de Qwen y ahorra presupuesto de API. En el momento en que le pides al modelo que razone sobre trade-offs entre enfoques, o que refactorice algo donde una decisión errónea se propaga en cascada por cinco o seis archivos, ahí es donde los modelos locales empiezan a tambalearse. Para eso quieres el razonamiento más fuerte de la nube.

Así que así se comparan los dos en lo que de verdad importa:

Esa última fila se subestima. Cuando iterar es gratis, acabas trabajando de otra forma. Pruebas cosas tontas. Le lanzas prompts a medio formar al modelo y refinas según lo que vuelve. Ese bucle experimental es de donde salen muchos scripts de automatización sólidos, simplemente trasteando con la inferencia local hasta que algo encaja y luego apretándolo con Sonnet después.

El ángulo de seguridad también importa, sobre todo para trabajo de clientes donde los datos no deberían salir del edificio. Si estás parseando logs de servidor o datos de rastreo que contienen URLs internas, rutas de clientes, cualquier cosa que pueda considerarse sensible, mantenerlo en hardware local gana a pasarlo por una API externa. No es que el tratamiento de datos de Anthropic sea sospechoso, pero algunos clientes tienen políticas sobre esto y poder decir «nada salió de mi máquina» facilita la conversación.

Donde el local se desmorona es en lo matizado. Construir un pipeline de puntuación de contenido que necesitaba evaluar la autoridad temática en un clúster de páginas, sopesar patrones de enlazado interno y devolver una lista de acciones priorizada; Qwen me dio algo que parecía plausible pero que pasaba por alto dependencias sutiles entre los criterios de puntuación. Sonnet lo clavó al segundo intento porque podía sostener la forma entera del sistema en el contexto a la vez.

El flujo de trabajo híbrido: local para el medio caótico (y siempre hay más medio caótico del que crees), API para las partes donde la calidad del razonamiento afecta directamente a la salida. La mayoría de tareas de automatización de marketing, probablemente el 70 % de lo que se construye, no necesita tocar la API en absoluto.

Más allá del bot: mantener la independencia

Empieza con tus scripts de limpieza, tus parsers de logs, lo aburrido que ejecutas cada semana. Apúntalos a localhost hoy. Si tienes un Mac con Apple Silicon o incluso una GPU de gama media, ya tienes el hardware para esto. El ahorro cubre una mejora de hardware en un mes. He montado converly-lm para facilitar el ruteo. El modelo que elijas importa menos que la infraestructura que construyes a su alrededor, y esa infraestructura debería ser tuya.

---

Artículos relacionados