El momento de los agentes de programación open source no llegó porque los desarrolladores hayan redescubierto de pronto la terminal. Llegó porque las herramientas cerradas cambiaron la factura.

El anuncio de GitHub de abril lo dejó claro: desde el 1 de junio de 2026, el uso de Copilot consume GitHub AI Credits calculados por consumo de tokens, incluidos tokens de entrada, salida y caché. Los precios base siguen siendo familiares, pero las sesiones largas y de varios pasos con agentes tienen otra economía. En la discusión oficial de GitHub Community hay cientos de comentarios y respuestas. La pelea no es por un retoque de precios; es por si la próxima capa de herramientas de programación será una función del IDE, una carga cloud medida por uso o infraestructura que el equipo pueda ejecutar y presupuestar.

Por eso OpenCode está recibiendo tanta atención. El proyecto se presenta como un AI coding agent open source para terminal, IDE y escritorio. Su sitio anuncia LSP, varias sesiones, enlaces compartibles, más de 75 proveedores de modelos, modelos locales y login con GitHub Copilot y ChatGPT Plus/Pro. La API de GitHub redirige sst/opencode a anomalyco/opencode; el repositorio mostraba unas 186.000 estrellas, 23.000 forks, licencia MIT, miles de issues y la release v1.18.1 del 14 de julio de 2026. Hacker News ya lo sometió a la prueba habitual: un hilo con más de mil puntos y cientos de comentarios comparándolo con Claude Code, Aider, Cline y flujos de trabajo reales.

Agente de programación open source ejecutándose en un sandbox con modelo local y controles de presupuesto

El titular fácil sería “OpenCode es la alternativa a Copilot”. Es demasiado estrecho. La lectura más útil es que los agentes open source se están convirtiendo en infraestructura para desarrolladores. Reducen lock-in, permiten usar claves propias o modelos locales y hacen inspeccionable el agent harness. Pero también trasladan responsabilidad al equipo: costes, seguridad, permisos, ritmo de actualizaciones y radio de impacto.

Por qué la facturación de Copilot empujó a mirar alternativas

La explicación de GitHub es comprensible. Copilot ya no es solo autocompletado. GitHub lo describe como una plataforma agéntica capaz de ejecutar sesiones largas, trabajar entre repositorios y consumir más cómputo de modelos que las sugerencias inline. Si una herramienta empieza a parecerse a un trabajador cloud, una tarifa plana resulta más difícil para el proveedor.

Para desarrolladores y responsables técnicos, la facturación por tokens cambia la psicología diaria. Una suscripción predecible se convierte en gestión de presupuesto. Importan los tokens de entrada, salida y caché. Importa el modelo. Una petición como “refactoriza este servicio” puede convertirse en lecturas de repositorio, llamadas a herramientas, reescrituras y tests. Eso hace útiles a los agentes, y también hace menos predecible la factura.

Copilot no se volvió malo de la noche a la mañana. Sigue teniendo pulido, integración con Microsoft/GitHub, controles de administración y compra empresarial sencilla. Muchos equipos seguirán pagando por eso. Pero el cambio de precios da una razón práctica para preguntar: ¿y si el runner del agente no fuera el producto alquilado, sino una capa bajo control del equipo?

Qué ofrece OpenCode

OpenCode no atrae por una sola función, sino por combinar una interfaz de agente reconocible con una historia de modelos menos cerrada. El sitio oficial habla de terminal, IDE y desktop; soporte LSP; varias sesiones; sesiones compartibles; y uso de cualquier modelo mediante más de 75 proveedores. También apunta al uso de modelos locales, importante para equipos con Ollama, vLLM, llama.cpp o endpoints privados.

Su lenguaje de “privacy first” afirma que el servicio no almacena código ni datos de contexto. Conviene tratarlo como una afirmación del proyecto, no como sustituto de una auditoría. Aun así, marca el criterio: OpenCode quiere competir en control, transparencia y posibilidad de cambiar de proveedor.

Las métricas del repositorio explican por qué no es un juguete de fin de semana. La ruta canónica resuelve a anomalyco/opencode; la captura de la API mostró licencia MIT, cifras muy altas de estrellas y forks, actualizaciones recientes y v1.18.1. La release era un pequeño arreglo de escritorio, casi más revelador que un gran lanzamiento: las herramientas maduras viven de arreglar paneles, plataformas, dependencias y flujos de autenticación.

Qué arregla el open source y qué no

El open source arregla la inspeccionabilidad. Puedes leer el código, fijar una versión, abrir un issue, parchear un comportamiento, hacer fork o ejecutar el agente contra tu propio proveedor. Si un agente envía contexto a un destino inesperado o cambia permisos, hay una vía para verlo.

Pero open source no equivale a seguro. La mayoría de desarrolladores no audita cada dependencia. La mayoría de equipos no leerá cada línea de un agente que puede leer el repo, ejecutar shell y editar archivos. El código abierto da derecho a auditar; no hace la auditoría por ti.

El debate en Hacker News sobre OpenCode refleja esa tensión. Algunos lo usan como sustituto práctico de Claude Code o Aider. Otros hablan de telemetría, comportamiento cloud por defecto, permisos, bugs de Windows y Wayland, uso de recursos y ritmo de releases. Son preguntas normales para una herramienta privilegiada de desarrollo.

La división útil no es abierto contra cerrado. Es auditado contra no auditado, aislado contra confiado, presupuestado contra sorpresa en la factura.

El nuevo stack: modelo, harness, permisos y presupuesto

Antes bastaba con instalar una extensión y aceptar o rechazar sugerencias. Los agentes rompen esa simplicidad.

Primero está el modelo: API de un proveedor, login de Copilot, plan de ChatGPT, modelo local o endpoint privado. Cada opción cambia latencia, coste, exposición del código y calidad.

Luego está el harness. OpenCode, Aider, Continue, Cline, Roo Code y Tabby deciden cómo seleccionar contexto, editar archivos, ejecutar herramientas, mostrar diffs, guardar sesiones y cuánta autonomía recibe el modelo.

Después vienen los permisos. ¿Puede el agente ejecutar shell? ¿Escribir fuera del worktree? ¿Acceder a la red? ¿Ver .env? ¿Leer SSH config? ¿Abrir navegador o llamar herramientas MCP? Cuanto más potente sea, más importante es la frontera.

Por último está el presupuesto: límites de gasto, claves por proyecto, routing de modelos, logs y una respuesta clara a “¿cuánto costó esta tarea?”.

Dónde tiene sentido OpenCode primero

OpenCode merece una prueba si ya trabajas en terminal y quieres elegir modelos. Para un desarrollador individual, las primeras tareas buenas son acotadas: añadir tests, refactorizar un módulo pequeño, explicar un archivo legacy, conectar una opción de CLI o limpiar documentación.

Los equipos pequeños deberían tratarlo como piloto, no como instalación libre para todos. Empieza con repositorios no sensibles, claves separadas, sin secretos de producción, un worktree limpio y revisión normal de cada diff. Si funciona, escribe la política antes de ampliarlo: modelos permitidos, comandos permitidos, repositorios permitidos, límites de gasto y versiones fijadas.

Para equipos sensibles a seguridad, la pregunta no es “¿OpenCode es open source?”, sino “¿qué puede leer, ejecutar y exfiltrar este agente?”. Si la respuesta se parece a “lo mismo que el portátil de un senior engineer”, necesitas controles equivalentes: contenedores o VMs, no-egress cuando sea posible, escaneo de secretos, audit logs, tokens estrechos y acciones reproducibles.

Dónde encajan Aider, Continue, Cline, Roo Code y Tabby

OpenCode no está solo. Aider es fuerte como pair programmer de terminal cerca de Git y shell. Continue encaja mejor como asistente de IDE para equipos que quieren integración con editor y un proyecto Apache-2.0 inspeccionable. Cline y Roo Code llevan workflows agénticos a entornos tipo VS Code, con aprobaciones más visibles, pero requieren permisos bien pensados. Tabby se centra en asistencia self-hosted; para organizaciones que no pueden enviar código a proveedores externos, puede ser el primer paso aceptable.

La mejor comparación no es por estrellas. Haz un bake-off con tres tareas reales: tests, refactor y bug investigation. Ejecuta las mismas tareas con OpenCode, Aider y un agente de IDE. Mide calidad del diff, tests, dolor de configuración, gasto de tokens, errores de contexto e intervenciones humanas.

Checklist de seguridad

No instales un coding agent en tu entorno principal y le entregues las llaves el primer día. Usa un worktree nuevo o un clon desechable. Si hay secretos, scripts de despliegue o acceso a producción, empieza en contenedor o VM. Quita .env y credenciales. Usa una clave API separada con límite duro de gasto.

Revisa el comportamiento de red. Aunque un proyecto diga que no almacena código o contexto, el proveedor del modelo recibe prompts salvo que uses modelo local o endpoint privado. Si la política dice que el código no puede salir de la red, una API pública no es un atajo.

Inspecciona comandos y escrituras antes de ejecutarlos. Bloquea comandos destructivos salvo que sean parte explícita de la tarea. No dejes que el agente ejecute scripts de paquetes de un repo no confiable sin aislamiento. Revisa el diff como revisarías el primer PR de un junior en una base de código delicada: permisos ampliados, dependencias tocadas, config generada, llamadas de red ocultas y cambios fuera de alcance.

Checklist de costes

Los agentes open source no hacen barato el AI coding automáticamente. Hacen más visible y configurable el coste. El uso directo de API también puede subir si el agente envía mucho contexto, pide razonamiento largo, reintenta ediciones o usa modelos caros para tareas rutinarias. Los modelos locales reducen facturas de proveedor, pero añaden hardware, mantenimiento y compromisos de calidad.

Rastrea tokens de entrada, salida y caché. Usa modelos pequeños para limpieza de docs, cambios mecánicos, scaffolding de tests o búsqueda. Reserva modelos fuertes para debugging difícil y diseño entre módulos. La métrica correcta no es “software gratis contra servicio pagado”, sino coste por cambio aceptado, revisado y funcionando.

Qué mirar después

Mira las partes aburridas. ¿El proyecto documenta telemetría? ¿Hace claros los destinos de red? ¿Soporta sandboxing o lo recomienda honestamente? ¿Permite fijar modelos y proveedores? ¿Expone logs de coste? ¿Funciona en Windows, escritorios Linux y desarrollo remoto sin hacks frágiles? ¿Explica permisos riesgosos en lenguaje simple?

La gobernanza también importa. OpenCode es MIT. Aider, Continue, Cline y Roo Code mostraban Apache-2.0 en las capturas de API. Tabby mostró un campo de licencia no estándar en la API, así que conviene leer la licencia directamente en el repo. Si una herramienta se vuelve crítica, licencia, bus factor, proceso de releases y ecosistema de plugins importan tanto como la demo.

Juggler y otros GUI agents muestran la siguiente competencia: no será “agente o no agente”, sino qué interfaz hace comprensible la agencia. Las buenas herramientas mostrarán qué leyeron, qué cambiarán, qué ejecutaron, cuánto gastaron y qué debe verificar el humano.

Veredicto: pruébalos, pero no como extensiones corrientes

Los open-source coding agents ya merecen prueba. OpenCode destaca porque junta elección de modelos, soporte de modelos locales, terminal/IDE workflows, comunidad grande y una respuesta directa al lock-in de herramientas cerradas.

Pero la libertad no es gratis. Pasar de Copilot o Claude Code a OpenCode, Aider, Continue, Cline o Roo Code no elimina la gobernanza; la acerca a tu equipo. Eso puede ser bueno si hay sandboxing, límites de presupuesto, revisión de telemetría y plan de rollback.

Para un desarrollador curioso, prueba OpenCode en un repo no crítico. Para un equipo, haz un piloto controlado: tres herramientas, tres tareas reales, claves separadas, límites de gasto, sandboxing, versiones fijadas y revisión normal. La ola open source no es solo reacción a Copilot billing. Es una señal de que AI coding se está convirtiendo en infraestructura. Y la infraestructura debe ser inspeccionable, reemplazable, presupuestada y bloqueada antes de editar código de producción.