En los últimos meses se ha extendido una idea tentadora entre desarrolladores: mantener la experiencia de Claude Code —el asistente de programación en terminal/IDE— pero sustituyendo el modelo de Anthropic por uno local (vía Ollama u otros servidores). En redes suele presentarse como “usar Claude Code gratis”, aunque la realidad es más matizada: no se obtiene Claude (el modelo) sin coste, sino que se intenta usar el cliente de Claude Code como interfaz para hablar con otro modelo que corre en local o en una infraestructura propia.
La clave de por qué esto es siquiera posible está en que Claude Code admite proveedores de terceros y, además, contempla un “LLM gateway”: una capa intermedia a la que el cliente se conecta y que puede redirigir las peticiones a distintos backends. Dicho gateway se configura con variables de entorno (por ejemplo, una URL base y credenciales) y está pensado para escenarios corporativos o de control de red, donde interesa centralizar políticas, trazabilidad y seguridad.
El matiz importante: Claude Code no “habla” Ollama de forma nativa
El gran choque con muchos tutoriales virales es el siguiente: Ollama expone su propia API (por defecto en localhost:11434) con endpoints como /api/generate y /api/chat.
Claude Code, en cambio, cuando se integra con un gateway, espera que ese gateway presente una interfaz compatible con Anthropic (por ejemplo, el Messages API) o con determinados proveedores/formatos soportados por el propio producto.
Eso significa que, si alguien apunta “a pelo” la base URL de Claude Code a http://localhost:11434, lo más probable es que no funcione salvo que exista un proxy que traduzca entre protocolos (por ejemplo, de Anthropic Messages → API de Ollama, o mediante una pasarela que “hable” el dialecto esperado por Claude Code). La idea general se sostiene; el “atajo” de copiar tres variables de entorno, no siempre.
Entonces, ¿qué es lo que sí encaja técnicamente?
El patrón que están explorando muchos equipos se parece a esto:
- Cliente: Claude Code (terminal o IDE).
- Gateway/Proxy: un servicio intermedio que expone la interfaz que Claude Code entiende y aplica políticas.
- Backend: un modelo local o autoalojado (Ollama, vLLM u otro servidor).
Claude Code documenta precisamente la existencia de ese gateway y su configuración por variables de entorno, incluyendo ANTHROPIC_BASE_URL y mecanismos de autenticación hacia el gateway (token/clave), además de opciones de cabeceras adicionales.
Por la parte local, Ollama encaja bien como motor porque es sencillo de desplegar y ofrece una API local estándar para generar y chatear con modelos, además de un catálogo amplio que incluye familias como Qwen, Gemma o DeepSeek, entre otras.
Por qué a los sysadmins les interesa (más allá del “gratis”)
El atractivo real no es tanto el ahorro “a cero”, sino cambiar el modelo de riesgo:
- Soberanía del código: parte del flujo puede quedarse en local o en un entorno controlado.
- Reducción de exposición: se limita qué sale de la máquina (útil en repos privados o sectores regulados).
- Coste predecible: se intercambia factura por uso por coste de hardware/energía/operación.
- Gobernanza: el gateway permite imponer reglas (por ejemplo, auditar peticiones, bloquear herramientas, aplicar listas de allow/deny).
Claude Code, además, se vende como herramienta lista para integrarse en flujos de trabajo y admite entornos corporativos con control centralizado mediante ese enfoque de gateway.
Lo que se suele omitir: “gratis” no significa “sin coste”
Incluso si se consigue que Claude Code funcione contra un modelo local, hay tres “peajes” inevitables:
- Compute: un modelo útil para programación exige CPU/GPU y memoria. La latencia y el rendimiento pasan a ser tu problema.
- Calidad: un modelo local puede rendir muy bien en tareas concretas, pero no equivale automáticamente a Claude Opus o similares.
- Mantenimiento: actualizar modelos, vigilar logs, asegurar el gateway/proxy, rotar credenciales y evitar fugas.
Dicho de otra forma: se cambia un coste variable (API) por un coste fijo y operativo (infraestructura). Para muchos equipos —sobre todo los que ya operan clústeres o tienen política estricta de datos— ese intercambio merece la pena.
Seguridad: lo que sí conviene afirmar con “barandillas” duras
En redes se repite una promesa: “el agente no puede ver tus claves, no puede tocar carpetas no compartidas, no puede enviar emails sin confirmar”. Ese resultado es posible, pero no sale gratis por defecto: depende de cómo se diseñen las capas.
- El cliente (Claude Code) debe ejecutar con permisos limitados.
- El gateway debe validar identidad, registrar acciones y aplicar políticas.
- El backend local debe estar aislado (contenedor/VM) si se teme que una integración exponga demasiado.
La parte importante para un medio técnico no es el truco, sino el principio: si el LLM no tiene ruta hacia secretos ni herramientas, no puede “inventárselas”. Eso es ingeniería de permisos, no prompting.
Preguntas frecuentes
¿Esto permite usar Claude (Opus/Sonnet) gratis?
No. Lo que se intenta es usar Claude Code como interfaz, pero hablando con otro modelo (normalmente local). Para usar modelos de Anthropic, se necesita una vía legítima (suscripción, cuenta o proveedor compatible).
¿Por qué no funciona siempre apuntar Claude Code directamente a localhost:11434?
Porque Ollama expone endpoints propios (/api/chat, /api/generate) y Claude Code, en modo gateway, espera una interfaz compatible con Anthropic o con proveedores soportados. Suele hacer falta un proxy que traduzca protocolos.
¿Qué aporta un “LLM gateway” en un entorno de empresa?
Centraliza control: autenticación, auditoría, políticas de red, límites de uso y, en general, gobernanza del acceso a modelos y herramientas.
¿Es una buena idea para equipos de sysadmin y dev con repositorios sensibles?
Puede serlo si el objetivo es reducir exposición de código y tener trazabilidad. Pero exige asumir operación (infraestructura, actualizaciones y hardening) y validar que el modelo local alcanza la calidad necesaria para el tipo de trabajo.
