Ejecuta Claude Code Gratis Con Modelos Locales de Ollama

Ejecuta Claude Code Gratis Con Modelos Locales de Ollama

Mi suscripción a Claude Pro llegó a $20 otra vez el mes pasado. Miré la factura por un segundo, no porque veinte dólares sea mucho — no lo es — sino porque había estado leyendo sobre la nueva capa de compatibilidad con la API de Anthropic de Ollama, y una pregunta me venía rondando durante semanas: ¿y si pudiera ejecutar todo el framework agéntico de Claude Code contra un modelo local en mi propia GPU, y nunca enviar un solo token a los servidores de Anthropic?

Así que lo probé. Tres modelos diferentes. Dos semanas de trabajo real en proyectos. Y los resultados genuinamente me sorprendieron — aunque no de la forma que esperarías.

La versión corta: sí, puedes ejecutar Claude Code completamente gratis con modelos locales a través de Ollama, y para una categoría específica de trabajo de desarrollo, es sorprendentemente capaz. Para otra categoría, falla estrepitosamente. La parte interesante es descubrir exactamente dónde está esa línea, porque no está donde la mayoría asume. Te mostraré el límite exacto que encontré — y las tareas específicas donde los modelos locales realmente superaron mis expectativas — una vez que pasemos la configuración.

Pero primero, algo de contexto sobre por qué esto importa más allá de ahorrar veinte dólares al mes.

Por Qué Ejecutar Claude Code Localmente Cambia el Juego

Claude Code es, en mi experiencia, el mejor agente de programación con IA disponible ahora mismo. Corre dentro de tu terminal. Lee tu base de código, edita archivos, ejecuta tests, gestiona git, y ejecuta flujos de trabajo de desarrollo de múltiples pasos con un nivel de autonomía que todavía me sorprende a veces. He construido sistemas de agentes completos con él, entregado proyectos de clientes, automatizado pipelines de contenido en cuatro sitios web.

El problema siempre ha sido el muro de pago. Necesitas una suscripción a Claude Pro o créditos de API directos para usarlo. Esa es una barrera dura para estudiantes, hackers independientes, contribuidores de código abierto, y cualquiera que simplemente quiera experimentar sin comprometerse financieramente.

Ollama cambió la ecuación. Si no lo has usado, Ollama es esencialmente Docker para modelos de lenguaje — descargas modelos de la misma forma que descargas imágenes de contenedores, y se ejecutan localmente en tu hardware. La reciente adición de compatibilidad con la API de Anthropic significa que Ollama ahora puede hacerse pasar por el endpoint de la API de Anthropic. Claude Code no nota la diferencia. Envía peticiones a lo que cree que es el servidor de Anthropic, y Ollama las intercepta, las enruta al modelo local que hayas cargado, y devuelve respuestas en el formato que Claude Code espera.

Ese es el truco. Toda la infraestructura de herramientas de Claude Code — edición de archivos, búsqueda de código, comandos de terminal, sub-agentes, prompts programados — todo funciona a través de esta capa de compatibilidad. El modelo que alimenta la inteligencia cambia. El framework permanece idéntico.

Pero aquí está lo que nadie te dice: el modelo que eliges importa enormemente, y la relación entre tamaño del modelo, requisitos de VRAM y rendimiento real de programación no es lineal. Probé tres configuraciones y obtuve resultados radicalmente diferentes de cada una. Llegaremos a esos benchmarks después de la configuración — y uno de ellos genuinamente cambió cómo pienso sobre el desarrollo local con IA.

Lo Que Necesitas Antes de Empezar

Permíteme ser directo sobre los requisitos de hardware, porque aquí es donde muchos tutoriales se vuelven deshonestos. Te muestran una configuración corriendo en alguna bestia de estación de trabajo y casualmente olvidan mencionar que no funcionará en tu MacBook Air.

Estoy corriendo con una NVIDIA GeForce RTX 4090 con 24GB de VRAM. Esa es una GPU seria. Para los modelos de 3B parámetros, absolutamente no necesitas eso — una tarjeta con 6-8GB de VRAM los maneja bien. Pero cuando llegamos a los modelos de 32B parámetros que realmente producen código de calidad, necesitas mínimo 24GB. Los MacBooks M-series con 32GB+ de memoria unificada también pueden manejar esto, pero espera velocidades de inferencia más lentas comparadas con una tarjeta NVIDIA dedicada.

El umbral crítico es la longitud de contexto. Para que las funcionalidades agénticas de Claude Code funcionen correctamente — especialmente la ejecución paralela de sub-agentes y la edición de múltiples archivos — necesitas al menos 32K tokens de contexto. Ventanas de contexto más pequeñas causan que el agente pierda el rastro del contenido de archivos a mitad de la edición, olvide instrucciones anteriores, y produzca cambios fragmentados que rompen tu base de código. Aprendí esto viendo a un modelo de 3B con un contexto de 8K intentar refactorizar una clase de servicio. Editó la primera mitad hermosamente y luego olvidó completamente que la segunda mitad existía.

Aquí está la configuración mínima:

• GPU: 8GB+ VRAM para modelos pequeños (3B-7B), 24GB+ para trabajo serio (32B+)
• RAM: 16GB de memoria del sistema mínimo, 32GB recomendado
• Almacenamiento: 5-30GB por modelo dependiendo del tamaño
• SO: macOS, Linux, o Windows (WSL2 recomendado en Windows)
• Software: Node.js 18+, npm, Ollama, Claude Code CLI

Hay sitios web — yo uso sitios como ollama.com/search y varias calculadoras de VRAM — que te permiten coincidir tu GPU exacta con modelos compatibles. Verifica antes de descargar un modelo de 20GB que tu tarjeta no puede ejecutar.

Ahora la parte para la que realmente viniste.

La Configuración Completa: De Cero a Funcionando en 10 Minutos

Voy a guiarte primero en macOS/Linux, luego cubriré las diferencias de Windows. Todo el proceso toma unos diez minutos, asumiendo que tienes internet decente para la descarga del modelo.

Paso 1: Instala Ollama

Ve a ollama.com y descarga el instalador para tu plataforma. En macOS, es un .dmg estándar. En Linux, hay un comando de una línea:

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

Después de la instalación, verifica que está corriendo:

ollama --version
# Debería mostrar algo como: ollama version 0.6.x

Ollama corre como un servicio en segundo plano. En macOS se inicia automáticamente. En Linux, podrías necesitar iniciarlo manualmente:

# Iniciar servicio de Ollama (Linux)
systemctl start ollama

# O ejecutar directamente
ollama serve

El servidor escucha en http://localhost:11434 por defecto. Esa URL importa — es a donde Claude Code se conectará.

Paso 2: Descarga Tu Primer Modelo

Aquí es donde se pone interesante. Estás eligiendo el cerebro que alimentará tu agente de programación. Probé tres, y te doy la recomendación de entrada: empieza con qwen2.5-coder:3b para tu primera ejecución. Es rápido, ligero, y lo suficientemente bueno para probar el concepto antes de invertir tiempo descargando modelos más grandes.

# Rápido y ligero — genial para probar la configuración
ollama pull qwen2.5-coder:3b

# Más capaz — necesita 16GB+ VRAM
ollama pull qwen2.5-coder:14b

# El de verdad — necesita 24GB+ VRAM pero genuinamente impresionante
ollama pull qwen2.5:32b

Los tamaños de descarga son aproximadamente 2GB, 9GB y 20GB respectivamente. Mientras descarga, preparemos Claude Code.

Paso 3: Instala Claude Code

Si aún no tienes Claude Code instalado, es una instalación npm directa:

npm install -g @anthropic-ai/claude-code

Verifica la instalación:

claude --version

También puedes usar la app de escritorio de Claude Code si prefieres — el enfoque de variables de entorno funciona con ambos.

Paso 4: Apunta Claude Code a Ollama

Este es el paso crítico. Necesitas decirle a Claude Code que deje de buscar la API cloud de Anthropic y en su lugar hable con tu servidor local de Ollama. Dos variables de entorno hacen que esto suceda.

En macOS/Linux:

export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama

En Windows (Command Prompt):

set ANTHROPIC_BASE_URL=http://localhost:11434
set ANTHROPIC_API_KEY=ollama

En Windows (PowerShell):

$env:ANTHROPIC_BASE_URL = "http://localhost:11434"
$env:ANTHROPIC_API_KEY = "ollama"

La clave API puede ser literalmente cualquier cosa — Ollama no la verifica. Yo uso "ollama" porque queda obvio en mi historial de shell que estoy corriendo localmente, no quemando créditos reales de API.

Para hacerlo permanente, agrega esas líneas de export a tu .bashrc, .zshrc, o perfil de shell. Yo mantengo las mías en un script separado que cargo cuando quiero modo local:

# ~/scripts/claude-local.sh
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama
echo "Claude Code pointed at local Ollama"

Luego simplemente ejecuto source ~/scripts/claude-local.sh cuando quiero cambiar. Cuando necesito el Claude real, elimino esas variables o abro una terminal nueva con mi clave real de Anthropic.

Paso 5: Lanza Claude Code Con Tu Modelo Local

Ahora el momento de la verdad:

claude --model qwen2.5-coder:3b

Si todo está bien conectado, Claude Code arranca viéndose exactamente como siempre — misma interfaz, mismos comandos, mismas capacidades de herramientas. La única diferencia es la inteligencia detrás. Tus prompts van a localhost en vez de los servidores de Anthropic. Tus tokens nunca salen de tu máquina.

Prueba algo simple primero:

> Create a Python function that reads a CSV file and returns the top 5 rows sorted by a specified column

Si ves al modelo pensando, generando código, y ofreciendo escribirlo en un archivo — felicidades. Estás ejecutando Claude Code gratis en tu propio hardware.

Aquí es donde la mayoría de los tutoriales terminan. Pero la historia interesante es lo que pasa cuando realmente intentas usar esto para trabajo real.

Tres Modelos, Dos Semanas, Una Evaluación Honesta

Me comprometí a usar esta configuración local durante dos semanas de trabajo de desarrollo real. No proyectos de juguete — trabajo real de clientes, plazos reales, bases de código reales. Roté entre tres modelos y rastreé qué manejaba bien cada uno y dónde fallaba.

Qwen 2.5 Coder 3B: El Velocista

Este pequeño modelo corre ultra rápido incluso en hardware modesto. Los tiempos de respuesta fueron menores a 2 segundos para la mayoría de los prompts. Lo usé para:

• Generar endpoints CRUD boilerplate en Laravel
• Escribir esqueletos de tests unitarios
• Crear interfaces TypeScript a partir de ejemplos JSON
• Scaffolding simple de archivos e inicialización de proyectos
• Generación de mensajes de commit de git

Para estas tareas, rindió al 70-75% de la calidad de Claude Sonnet. El código compilaba. La lógica era correcta. Las convenciones de nombres eran razonables. Para scaffolding especialmente — generar el esqueleto de una nueva clase de servicio, una nueva ruta de API, un nuevo componente React — era sorprendentemente capaz.

Donde falló: cualquier cosa que requiriera conciencia de múltiples archivos. Le pedí que refactorizara un servicio de autenticación que tocaba cuatro archivos diferentes. Manejó el primer archivo perfectamente, hizo cambios razonables en el segundo, y para el tercer archivo había perdido el rastro de los cambios que ya había hecho. El cuarto archivo fue esencialmente alucinado — referenciando funciones que creía haber escrito pero no lo había hecho.

El modelo 3B piensa un archivo a la vez. Eso está bien para tareas aisladas. Es un factor decisivo para trabajo arquitectónico.

Qwen 2.5 32B: La Sorpresa

Esperaba mejora incremental. Obtuve un cambio cualitativo. El modelo 32B no solo cometió menos errores — demostró razonamiento genuino de múltiples pasos que el modelo 3B no podía ni tocar.

Le di la misma refactorización de autenticación. Planificó los cambios en los cuatro archivos antes de escribir una sola línea. Identificó una dependencia circular que yo no había notado. Sugirió extraer una interfaz compartida para prevenir el tipo de desviación que típicamente ocurre cuando modificas servicios relacionados de forma independiente.

¿Fue tan bueno como Claude Sonnet? No. La estructura del código fue aproximadamente 85% tan limpia, y ocasionalmente usó patrones que eran técnicamente correctos pero no idiomáticos para el framework que estaba usando. Pero hizo algo que el modelo 3B no podía hacer en absoluto: razonó sobre las relaciones entre archivos en vez de tratar cada uno de forma aislada.

El trade-off es la velocidad. Donde el modelo 3B respondía en 2 segundos, el modelo 32B tardaba 8-15 segundos por respuesta, y operaciones complejas de múltiples archivos podían tardar más de 30 segundos. En mi RTX 4090 con 24GB de VRAM, usaba casi todo lo disponible. Si tienes menos VRAM, espera overhead de cuantización e inferencia aún más lenta.

La funcionalidad de sub-agentes paralelos me sorprendió más aquí. Configuré dos sub-agentes — uno investigando la API de un paquete npm y otro escribiendo el código de integración. Ambos corrieron simultáneamente a través del modelo local. La coordinación no fue perfecta (el agente de investigación a veces producía resúmenes que el agente de programación malinterpretaba), pero el hecho de que funcionara en absoluto con un modelo local corriendo en hardware de consumo genuinamente me impresionó.

El Claude Sonnet Real: Todavía el Referente

Después de dos semanas con modelos locales, volví al Claude Sonnet real por un día. La diferencia fue inmediatamente aparente en tres áreas:

Cadenas de razonamiento complejas. Una tarea que requería entender lógica de negocio, mapearla a cambios de esquema de base de datos, generar migraciones, actualizar relaciones de modelos, y modificar respuestas de API — Claude Sonnet manejó esto como un solo pensamiento coherente. Los modelos locales necesitaban guía constante a través de cada paso.

Matices de calidad de código. Claude Sonnet no solo escribe código funcional. Escribe código que sigue las convenciones del proyecto específico que está viendo. Capta patrones en tu base de código existente y los replica. Los modelos locales escribieron código genéricamente correcto que a menudo parecía venir de un proyecto diferente.

Recuperación de errores. Cuando algo no funcionaba, Claude Sonnet analizaba el error, lo rastreaba hasta la causa raíz, y lo arreglaba — a menudo anticipando problemas secundarios. Los modelos locales tendían a arreglar el síntoma superficial y crear un nuevo problema aguas abajo.

Dicho esto — y esta es la parte que me mantuvo pensando — para probablemente el 40-50% de mis tareas diarias de programación, el modelo local de 32B era suficientemente bueno. No perfecto. No un reemplazo. Pero suficientemente bueno como para no perder tiempo ni calidad en la salida.

Aquí está la verdadera pregunta que esto plantea, y es una que todavía estoy procesando.

Los Trade-Offs Honestos Que Nadie Quiere Discutir

He visto una docena de posts afirmando que puedes "reemplazar tu suscripción a Claude completamente" con modelos locales. Eso es deshonesto o escrito por alguien que no usa Claude Code para trabajo serio. Permíteme ser directo sobre las limitaciones.

La calidad del uso de herramientas varía enormemente. El poder de Claude Code viene de su capacidad de usar herramientas — leer archivos, ejecutar comandos, buscar en bases de código, editar múltiples archivos atómicamente. Los modelos oficiales de Claude fueron específicamente entrenados y afinados para este comportamiento de llamada a herramientas. Los modelos locales soportan el formato API para llamadas a herramientas, pero su uso real de herramientas es menos confiable. Vi al modelo 3B intentar editar un archivo que no existía aproximadamente una vez por sesión. El modelo 32B fue mejor pero todavía ocasionalmente llamaba herramientas con argumentos malformados.

El trabajo sensible a la seguridad es un no rotundo. Hago consultoría de ciberseguridad. Revisión de código para vulnerabilidades, automatización de pruebas de penetración, generación de informes de auditoría de seguridad — nunca confiaría en un modelo open-source de 3B para este trabajo. Los modos de fallo son demasiado peligrosos. Un vector de SQL injection pasado por alto o una evaluación alucinada de "este código es seguro" podría causar daño real. Para trabajo de seguridad, uso el Claude Sonnet real sin excepción.

La gestión de la ventana de contexto se siente diferente. Incluso con 32K de contexto, los modelos locales parecen "olvidar" el contexto anterior más agresivamente que los modelos oficiales de Claude. Sospecho que es una combinación de diferencias en el mecanismo de atención y artefactos de cuantización. El impacto práctico: necesitas re-declarar restricciones importantes más frecuentemente, y las sesiones largas se degradan más rápido.

Las actualizaciones de modelos son tu responsabilidad. Cuando Anthropic mejora Claude, cada usuario recibe la actualización instantáneamente. Con modelos locales, necesitas rastrear lanzamientos, descargar nuevas versiones, probarlas contra tus flujos de trabajo, y lidiar con regresiones ocasionales. Me han quemado con una actualización de modelo que rompió la compatibilidad de llamada a herramientas por dos días antes de que se lanzara una corrección.

Aquí está mi evaluación honesta, y desearía que alguien me hubiera dicho esto antes de empezar: esta configuración es un complemento, no un reemplazo. Uso modelos locales para el 40-50% inferior de tareas — scaffolding, boilerplate, automatización simple, generación de tests, borradores de documentación. Uso el Claude real para el 50-60% superior — decisiones de arquitectura, refactorización compleja, trabajo sensible a la seguridad, cualquier cosa donde las diferencias sutiles de calidad se acumulan en problemas reales.

Esa división ha reducido mi uso de la API de Claude en casi la mitad. Lo que significa que aunque sigo pagando por Pro, obtengo más valor de cada dólar porque solo envío los problemas difíciles al mejor modelo.

Ese es el cambio de mentalidad. No pienses "reemplazo gratuito." Piensa "enrutamiento inteligente."

Configuración Avanzada: Sacando el Máximo de Tu Setup

Una vez que la configuración básica funciona, hay algunas optimizaciones que hicieron una diferencia significativa en mi flujo de trabajo.

Configuración Persistente del Modelo

En vez de especificar el modelo en cada lanzamiento, puedes establecerlo como predeterminado:

# Agrega a tu .bashrc o .zshrc
export CLAUDE_MODEL=qwen2.5-coder:3b

# Luego simplemente lanza con
claude

De hecho mantengo dos alias:

# En .zshrc
alias claude-local='source ~/scripts/claude-local.sh && claude --model qwen2.5:32b'
alias claude-fast='source ~/scripts/claude-local.sh && claude --model qwen2.5-coder:3b'
alias claude-pro='unset ANTHROPIC_BASE_URL && claude'

Tres comandos. Tres niveles. Local rápido para tareas rápidas, local pesado para trabajo sustancial, y Pro para lo de verdad. Alterno entre ellos múltiples veces al día dependiendo de lo que esté haciendo.

Optimización de Longitud de Contexto

Por defecto, Ollama podría no exponer la ventana de contexto completa que tu modelo soporta. Puedes configurar esto en el Modelfile o en tiempo de ejecución:

# Verifica la configuración actual de tu modelo
ollama show qwen2.5-coder:3b

# Crea un Modelfile personalizado con contexto extendido
cat << 'EOF' > Modelfile
FROM qwen2.5-coder:3b
PARAMETER num_ctx 32768
PARAMETER temperature 0.1
EOF

ollama create qwen-code-extended -f Modelfile

Establecer la temperatura a 0.1 (en vez del valor por defecto) hace la generación de código más determinista y menos creativa. Para tareas de programación, quieres consistencia sobre creatividad. La subí a 0.4 solo cuando generaba documentación o mensajes de commit donde algo de variedad ayuda.

Monitoreo del Uso de GPU

Mantén un ojo en el uso de tu VRAM, especialmente con modelos más grandes:

# GPUs NVIDIA
watch -n 1 nvidia-smi

# macOS con Apple Silicon
sudo powermetrics --samplers gpu_power -i 1000

Si tu GPU se queda sin VRAM, Ollama silenciosamente recurre a inferencia por CPU, y los tiempos de respuesta pasan de segundos a minutos. He tenido sesiones donde no me di cuenta de que esto pasó porque las respuestas seguían llegando — solo que dolorosamente lentas. Revisa la utilización de tu GPU si las cosas se sienten repentinamente lentas.

Usando Diferentes Modelos para Diferentes Sub-Tareas

Esto es experimental, pero el sistema de sub-agentes de Claude Code teóricamente permite que diferentes agentes usen diferentes modelos. En la práctica, todos se enrutan a través del mismo endpoint de Ollama, pero puedes ejecutar múltiples instancias de Ollama en diferentes puertos con diferentes modelos cargados:

# Terminal 1: Modelo pesado para el agente principal
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# Terminal 2: Modelo ligero para sub-agentes
OLLAMA_HOST=0.0.0.0:11435 ollama serve

Aún no he encontrado una forma limpia de hacer que Claude Code enrute sub-agentes a un puerto diferente, pero este es el tipo de optimización que la comunidad probablemente resolverá en los próximos meses. La arquitectura lo soporta en teoría.

Qué Mejoró Realmente en Mi Flujo de Trabajo

Después de dos semanas de uso híbrido — modelos locales para trabajo rutinario, Claude real para tareas complejas — tres cosas medibles cambiaron.

Los costos de tokens bajaron aproximadamente 45%. Mi panel de Anthropic mostró la disminución claramente. Todas las tareas simples que antes quemaban tokens reales — scaffolding de archivos, generación de esqueletos de tests, endpoints de API boilerplate, operaciones de git — ahora corrían en computación local. Enviaba menos peticiones a Anthropic, y las que sí enviaba eran tareas de mayor complejidad que realmente necesitaban la capacidad de razonamiento de Claude.

La velocidad de iteración aumentó para tareas rápidas. Sin latencia de red. Sin limitación de tasa. Sin esperar a los servidores de Anthropic durante horas pico. El modelo local de 3B respondía más rápido que cualquier API en la nube podría, y para tareas simples, la velocidad importa más que la brillantez. ¿Generar una interfaz TypeScript desde un payload JSON? No necesito inteligencia nivel Sonnet para eso. Necesito que esté hecho en menos de 2 segundos.

Me volví más intencional sobre la selección de modelos. Este fue el beneficio inesperado. Antes de este experimento, cada tarea iba al mismo modelo al mismo costo. Ahora pienso activamente sobre qué nivel de inteligencia requiere una tarea antes de empezarla. Ese marco mental — "¿es esta una tarea de 3B, una de 32B, o una de Sonnet?" — me hizo un desarrollador más eficiente independientemente de las herramientas. Empecé a agrupar tareas de complejidad similar. Mejoré en descomponer trabajo complejo en sub-tareas simples que podían manejarse localmente.

Los resultados no son dramáticos — no estoy afirmando una mejora de productividad de 10x. El número honesto es quizás una mejora del 15-20% en el rendimiento diario, principalmente por eliminar latencia en tareas rutinarias y ser más reflexivo sobre cuándo invoco computación costosa.

Para una configuración que no cuesta nada más allá del hardware que ya tienes, es un buen retorno.

Los Modelos Que Vale la Pena Probar Ahora Mismo

Referencia rápida de qué es realmente bueno para tareas de programación a principios de 2026:

Qwen 2.5 Coder Series — Mi recomendación actual. Las variantes específicas para código están fine-tuned en código y superan sustancialmente a los modelos Qwen de propósito general para tareas de desarrollo. El de 3B es genial para velocidad, el de 14B es un buen punto medio, y el de 32B es genuinamente impresionante.

DeepSeek Coder V2 — Alternativa fuerte, especialmente para trabajo pesado en Python. El soporte de llamada a herramientas es bueno. El manejo de contexto es competitivo con Qwen.

GLM 4 — Vale la pena probar si tus tareas involucran manipulación de datos estructurados o integración de API. Maneja bien JSON y su implementación de llamada a funciones es limpia.

Variantes de CodeLlama — Quedándose atrás de las opciones Qwen y DeepSeek para la mayoría de tareas, pero todavía viables si estás en hardware limitado y necesitas algo que corra bien a 7B parámetros.

Verifica la compatibilidad del modelo con tu hardware antes de comprometerte con una descarga. Un modelo que no cabe en tu VRAM y recurre a inferencia por CPU no te está ahorrando nada — te está costando tiempo.

Tu Desafío de 24 Horas

Esto es lo que quiero que hagas antes de mañana a esta hora. No la próxima semana. No "cuando tengas tiempo." Hoy.

Instala Ollama. Descarga qwen2.5-coder:3b. Configura las dos variables de entorno. Lanza Claude Code con --model qwen2.5-coder:3b. Luego dale una tarea real de tu proyecto actual — no un ejercicio de hello-world, sino algo que realmente necesites hecho. Una función utilitaria. Un archivo de tests. Una migración de configuración.

Observa qué pasa. Nota dónde acierta y dónde tropieza. Esa experiencia de primera mano te dirá más sobre si esta configuración encaja en tu flujo de trabajo que cualquier blog post — incluyendo este.

Si el modelo 3B te impresiona (y para tareas simples, probablemente lo hará), descarga el de 32B después e intenta la misma tarea. El salto de calidad te hará reconsiderar qué significa "suficientemente bueno" para IA local.

Sigo ejecutando tanto local como cloud. Sospecho que lo haré por mucho tiempo. Pero la opción de bajar a computación local gratuita para la mitad de mis tareas diarias mientras mantengo el modelo premium para el trabajo que lo demanda — eso no es un compromiso. Es simplemente asignación inteligente de recursos.

¿Y honestamente? La mejor parte no es el dinero ahorrado. Es la velocidad. Sin viaje de ida y vuelta por la red. Sin límites de tasa. Sin mensajes de "Anthropic está experimentando alta demanda" a las 2 PM cuando todos están enviando prompts. Solo IA de programación instantánea, local, privada — en tus términos, en tu hardware, cuando quieras.

Tu turno.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io