El espejismo del Agentic Coding local: ¿hardware, pasarelas o suscripción?

Quien trabaje a diario en la terminal con herramientas como Claude Code o Google Antigravity habrá vivido la misma escena: estás en mitad de una refactorización compleja, el agente lleva un ritmo perfecto ejecutando comandos y aplicando cambios, y de repente la sesión se corta. Has agotado el límite de uso de tu cuota diaria.

El cambio de paradigma de la autocompletación sencilla al desarrollo agéntico autónomo trae consigo un consumo masivo de recursos. Cuando un agente lee directorios enteros, prueba errores en la terminal y corrige parches de código en bucle, la cuota de una tarifa plana estándar vuela en un par de horas.

Ante este bloqueo, la reacción técnica habitual pasa por explorar dos vías: montar una pasarela intermedia para diversificar API o comprar una GPU potente para ejecutar todo en local. Hemos hecho los números.

1. El espejismo de los AI Gateways (OmniRoute, OpenRouter y modelos alternativos)

La primera idea para evitar el bloqueo consiste en interponer un AI Gateway o proxy de IA (como OmniRoute u OpenRouter). La teoría suena bien: conectar el agente a un endpoint unificado y derivar las peticiones a modelos gratuitos, pools alternativos o proveedores de inferencia ultrarrápida (Groq, Cerebras, DeepSeek API, Hugging Face).

Sin embargo, al aplicar esto a un flujo de trabajo agéntico real en la terminal, la estrategia choca con dos muros técnicos:

1. El coste del pago por uso (pay-as-you-go): Los agentes de terminal no envían solo la última línea tecleada. Reenvían en cada interacción la estructura del proyecto, los parches diff, los logs de error y el historial completo. Una tarde de refactorización genera fácilmente millones de tokens de contexto. Pasar este volumen por API comerciales a precio por token resulta sustancialmente más caro que cualquier tarifa plana mensual.
2. Rotura de herramientas (Tool Calling): Las CLI avanzadas inyectan instrucciones de sistema complejas y esperan llamadas a funciones estrictas para manipular el sistema de archivos de Linux. Al pasar por pasarelas que recortan tokens (compresión RTK) o al derivar las consultas a modelos secundarios que no dominan el tool calling, el agente entra en bucles de error o pierde la capacidad de editar archivos.

Las pasarelas son útiles para autocompletado en editor o scripts aislados, pero no resuelven la continuidad de un agente de desarrollo completo.

2. La IA como herramienta profesional: trasladar el coste al cliente

Antes de evaluar la compra de componentes, conviene revisar la ecuación económica del desarrollo. Si facturamos por software, la infraestructura de inteligencia artificial no representa un gasto a evitar, sino un coste operativo directo (OpEx) que se amortiza en la entrega del proyecto.

El desarrollo agéntico altera la lógica habitual de las horas facturables:

• Reducción drástica de tiempo: Una tarea de arquitectura o debugging multi-módulo que antes requería 10 horas de trabajo manual se resuelve en 2 horas asistidas.
• Transferencia del valor: El cliente no paga por ver teclear al programador durante días; paga por un entregable funcional, probado y a tiempo.
• Absorción del coste: La bajada general en el total de horas cobradas al cliente absorbe de sobra los 90 € o 100 € mensuales de un plan de alta cuota (tipo Claude Max o equivalentes). La herramienta se paga sola en la primera entrega del mes.

3. El análisis de partida: caso real en Debian

Para comprobar si podemos construir una alternativa 100% local, tomamos como modelo de pruebas una estación de trabajo habitual sobre Debian Linux:

• Procesador: 12 hilos.
• Memoria RAM: 32 GB DDR4 @ 3200 MT/s.
• GPU / VRAM: NVIDIA RTX 4060 Ti (8 GB VRAM).
• Almacenamiento: NVMe PCIe 4.0.

Capacidad real en local

Con 8 GB de VRAM, el límite de la GPU permite cargar únicamente modelos de tamaño pequeño (7B a 8B en precisión Q8/FP16), como qwen2.5-coder:7b. El rendimiento en VRAM es excelente (~70 tokens/segundo), ideal para escribir funciones aisladas o generar tests.

Sin embargo, para aguantar la carga de un agente autónomo se necesitan modelos de 32B parámetros (como Qwen 2.5 Coder 32B o DeepSeek R1 32B). En un equipo con 8 GB de VRAM, mover un modelo de 32B exige desplazar más de 12 GB de capas a la memoria RAM del sistema. Al depender del bus DDR4, la velocidad cae a 2-5 tokens/segundo, una latencia inviable para trabajar en tiempo real.

4. ¿Invertir en una GPU de 24 GB de VRAM?

Para ejecutar modelos de 32B en local sin cuellos de botella se necesita una GPU con al menos 24 GB de VRAM. Aquí es donde el mercado impone la realidad del hardware:

• El mercado de segunda mano: En foros y redes se habla de adquirir tarjetas usadas como la RTX 3090 por unos 1.200 €. No obstante, la oferta de estos componentes es escasa, volátil y conlleva un riesgo elevado al carecer de garantía en productos sometidos a alto desgaste.
• El mercado nuevo con garantía: Si se busca estabilidad profesional y factura deducible, una GPU nueva de 24 GB VRAM se sitúa en una horquilla de 1.900 € a 2.000 €.

5. Comparativa financiera y operativa: Hardware vs. Nube

Poniendo los datos en una balanza:

Invertir 2.000 € en una GPU resuelve la disponibilidad, pero congela el capital en un hardware que se deprecia rápido, mientras que los modelos en la nube evolucionan de versión continuamente sin coste de infraestructura para el usuario.

🚀 Conclusión: La arquitectura híbrida

No existe una solución única universal. La decisión depende de las prioridades operativas de cada entorno:

1. Vía Nube Profesional: Ideal para quien priorice la máxima capacidad de razonamiento agéntico y la tasa de acierto al primer intento. Se asume el coste de la tarifa plana superior trasladándolo al valor del proyecto.
2. Vía Hardware Dedicado: Ideal para entornos con restricciones estrictas de privacidad de datos, proyectos offline o donde el bloqueo por cuotas sea inaceptable independientemente del desembolso inicial.
3. Vía Híbrida (La más eficiente): Utilizar la GPU que ya tenemos en local con modelos de 7B/8B para autocompletado, consultas de sintaxis y edición de archivos cortos a coste cero. Reservar la CLI agéntica de nube exclusivamente para refactorizaciones complejas de arquitectura y debugging multi-módulo.

Al final, la herramienta debe adaptarse al margen del proyecto, no al revés.