programa
Fundamentos del negocio de la IA
12 h
OpenCode está pensado para llevar a cabo una tarea. Es un agente de código abierto que conecta un modelo de IA con tu repositorio, tu terminal y tus herramientas de desarrollo. Pídele que arregle un bug y podrá localizar los archivos relevantes, proponer un plan, editar el código, ejecutar pruebas y responder a los errores. Un autocompletado, por sí solo, no llega a tanto.
Ese papel más amplio ha llamado la atención. En el momento de escribir estas líneas, el repositorio activo de OpenCode rondaba las 189.000 estrellas en GitHub. No tomaría las estrellas como prueba de calidad del código, pero sí muestran el interés que ha despertado el proyecto.
La realidad es menos ordenada. OpenCode te ofrece elegir modelos y luego te pide que gestiones esa elección. Un cambio de política de un proveedor en enero de 2026 mostró lo rápido que pueden moverse esas opciones. Veré eso junto a cómo funciona OpenCode y cuál es su encaje.
Antes de seguir, una nota rápida sobre el nombre: si buscas OpenCode, quizá encuentres el repositorio archivado en Go opencode-ai/opencode. Ese proyecto dejó de mantenerse en septiembre de 2025. Aquí nos centraremos en el proyecto activo en github.com/anomalyco/opencode, creado por el equipo detrás del framework Serverless Stack (SST).
¿Qué es OpenCode?
OpenCode es un agente de codificación de IA de código abierto con licencia MIT. Es agnóstico al modelo, es decir, no está atado a un único proveedor. Los usuarios pueden leer el código fuente y modificarlo. También pueden autoalojar la herramienta. El software es gratuito. La facturación del modelo va aparte, como veremos en la sección de funciones.
OpenCode no es un modelo de lenguaje grande (LLM). El modelo elegido lee prompts y genera respuestas. OpenCode aporta las herramientas de archivos, acceso al shell, historial de sesión, reglas de permisos y la interfaz alrededor de ese modelo. Esta distinción es útil porque cambiar el modelo no exige cambiar el resto de la herramienta.
Lo desarrolla Anomaly, antes SST, y se ejecuta principalmente con TypeScript y Bun.
Repositorios archivado y actual de OpenCode, comparados. Imagen del autor.
OpenCode no está ligado a una sola familia de modelos. A través del registro Models.dev, se conecta con más de 75 proveedores, incluidos Anthropic, OpenAI, Google, DeepSeek, Groq y modelos locales mediante Ollama. También es posible conectar cuentas de suscripción existentes, como veremos en la sección de funciones.
Sesión de terminal de OpenCode mostrando cambios en archivos. Imagen del autor.
Aunque OpenCode nació en el terminal, hoy se distribuye como interfaz de terminal (TUI), app de escritorio beta para macOS, Windows y Linux, y extensiones para editores como VS Code. La versión estable más reciente al cierre de este artículo es la v1.18.8.
Por qué se creó OpenCode
Como comenté antes, OpenCode admite modelos de muchos proveedores. Se diseñó así porque la calidad y los precios de los modelos cambian, y una herramienta atada a un solo proveedor deja menos margen al usuario.
La documentación afirma que OpenCode no está acoplado a ningún proveedor. El registro Models.dev mencionado arriba aporta los detalles y precios de modelos que usa OpenCode.
Esta decisión afecta a más que a la facturación. Los modelos difieren en límites de contexto, formatos de llamadas a herramientas y tipos de entrada. OpenCode usa una única interfaz para esas diferencias. Un desarrollador puede cambiar de modelo en el mismo proyecto sin migrar la sesión a otra herramienta.
El equipo también apuesta por herramientas con mentalidad terminal-first que el usuario pueda inspeccionar. Las instrucciones del proyecto viven en un archivo de texto llamado AGENTS.md. Más adelante explicaré cómo crea y utiliza OpenCode este archivo.
El proyecto oficial señala tres decisiones de diseño. La primera es el soporte de proveedores ya comentado. La segunda mantiene los controles principales en el terminal. La tercera separa el cliente del servidor. Esa división viene ahora.
En enero de 2026, Anthropic bloqueó que herramientas de terceros usaran suscripciones de consumo de Claude a través de canales no oficiales. OpenCode añadió entonces otras opciones de suscripción y usó su propia pasarela. Los usuarios siguieron pudiendo conectar a través de otros proveedores.
Ese episodio explica por qué la elección de proveedor tiene tanto peso en OpenCode. Para ver qué hacen los usuarios con esa elección, el siguiente paso es observar una sesión.
Cómo funciona OpenCode
OpenCode se ejecuta como un cliente y un servidor local. La TUI, la app de escritorio, las extensiones del IDE y el SDK hablan con ese servidor por HTTP. El mismo servidor admite la conexión remota con opencode attach <url> y el uso sin interfaz con opencode serve.
Dentro de una sesión, el agente lee archivos relevantes, puede redactar un plan, edita código y ejecuta comandos cuando es necesario. Su integración con el Language Server Protocol (LSP) devuelve diagnósticos del compilador y el linter al modelo para que responda a errores de tipos y sintaxis.
Por ejemplo, una tarea puede empezar con glob o grep para localizar archivos. El agente puede usar read para inspeccionarlos y edit para cambiar líneas seleccionadas. Después puede usar bash para ejecutar un comando de test o build. La salida pasa a formar parte de la siguiente solicitud al modelo.
Entiendo la separación entre Build y Plan como un interruptor de permisos. Build es el modo por defecto y puede leer, escribir y ejecutar comandos. Plan pide confirmación antes de editar archivos o ejecutar comandos bash. Pulsar Tab cambia entre ambos.
Los controles de permisos se aplican cuando se invoca una herramienta. Un proyecto puede permitirla, bloquearla o preguntar cada vez. Las reglas también pueden variar por patrón de comando. Un equipo podría permitir tests rutinarios pero pedir confirmación para otros comandos de shell.
Las sesiones se guardan localmente en disco en el directorio de datos de OpenCode. OpenCode compacta de forma automática las conversaciones largas. Los comandos /undo y /redo se mueven por instantáneas de archivos basadas en Git.
Funciones clave de OpenCode
OpenCode agrupa sus funciones principales en acceso a modelos, contexto del proyecto, ejecución de tareas y uso local. A continuación explico qué cambia cada grupo durante una sesión de codificación.
Compatibilidad con múltiples modelos
Como ya vimos, OpenCode obtiene su lista de proveedores a través de Models.dev. En la práctica, puedes conectar un servicio alojado, una plataforma cloud o un endpoint compatible con OpenAI. GitHub Copilot y los inicios de sesión de ChatGPT Plus/Pro ofrecen alternativas a gestionar una API key aparte.
Elegir proveedor no significa que todos los modelos se comporten igual. El uso de herramientas, los límites de contexto, el tiempo de respuesta y el precio siguen dependiendo del modelo y del proveedor seleccionados. Las llamadas a modelos alojados también envían el contexto de código requerido a ese proveedor bajo sus propias reglas de datos.
OpenCode también ofrece dos vías opcionales para acceder a modelos. OpenCode Zen es una pasarela de pago por uso con una lista seleccionada de modelos. OpenCode Go es una suscripción que cuesta 5 $ el primer mes y luego 10 $ al mes, para modelos open-weight seleccionados. Los usuarios pueden seguir usando sus propias API keys. Los precios pueden cambiar.
Esto es lo molesto: una herramienta gratuita puede acabar generando una factura del proveedor.
Trabajar con el contexto del repositorio
Ejecuta /init y OpenCode genera un AGENTS.md con el resumen de la estructura y las convenciones del proyecto. Los equipos pueden comitear ese archivo para que las sesiones empiecen con instrucciones compartidas.
El archivo puede incluir comandos de test, nombres de carpetas, reglas de nomenclatura y notas del proyecto. Un AGENTS.md global puede recoger instrucciones comunes a varios proyectos. El archivo del proyecto guarda las reglas de un repositorio en concreto.
Las comprobaciones LSP descritas antes se ejecutan tras las ediciones. El contexto del repositorio también incluye referencias de archivo: el símbolo @ inserta un archivo seleccionado en el prompt.
Ejecución de tareas de codificación
Además de los agentes Build y Plan explicados antes, OpenCode incluye subagentes para búsquedas multietapa, escaneo de bases de código y documentación externa. Los agentes personalizados pueden tener su propio modelo, prompt y permisos de herramientas.
Cada subagente trabaja en una sesión hija, por lo que sus mensajes no llenan la sesión principal del mismo modo. Un agente personalizado puede limitarse a leer archivos, asignarse a un modelo más económico o recibir instrucciones para un tipo de tarea concreto.
Model Context Protocol (MCP) añade servicios externos. Se definen en opencode.json, y las comprobaciones de permisos comentadas antes también se aplican a las herramientas que incorporan.
Pasar de la planificación a los cambios de código. Vídeo del autor.
Desarrollo con prioridad local (y sus límites)
El término "local-first" necesita matices. No lo tomaría como una promesa de que nada sale nunca de la máquina. Como se indicó en la sección de proveedores, OpenCode puede conectar con Ollama. Esa configuración mantiene el código y los prompts en infraestructura local. Los modelos alojados, /share y OpenCode Zen envían datos fuera de la máquina local.
El uso local sigue dependiendo del modelo. Los modelos pequeños pueden devolver llamadas de herramientas inválidas o perder relaciones entre archivos. Un servidor local también necesita suficiente memoria para el modelo elegido y suficiente espacio de contexto para los archivos que se envían en cada solicitud.
Su sistema de permisos es una salvaguarda del flujo de trabajo, no un sandbox de seguridad. En modo servidor con red debería usarse OPENCODE_SERVER_PASSWORD y enlazar a localhost. Un problema anterior de exposición sin autenticación se parcheó, pero el modo servidor no debería exponerse públicamente sin autenticación.
Arquitectura de OpenCode
Como mencioné, OpenCode separa sus clientes de su servidor local. Esa división afecta a la configuración y al estado almacenado. La API añade otra forma de usar el servidor.
Si solo piensas usar la TUI, puedes saltarte los detalles de la API. El párrafo de configuración del final es el que usarás.
El servidor en TypeScript y Bun habla con los proveedores de modelos y ejecuta herramientas. También gestiona el estado. Su especificación OpenAPI 3.1 genera el paquete oficial @opencode-ai/sdk. Scripts y clientes personalizados pueden usar esta API documentada.
La API incluye sesiones, mensajes, archivos, proveedores, herramientas, agentes y configuración. Es el mismo servidor que usan los clientes de OpenCode. Un script puede crear una sesión o enviar un mensaje sin intentar controlar la TUI.
Clientes de OpenCode conectándose a un único servidor. Imagen del autor.
Las interfaces citadas actúan como clientes: la TUI, la app de escritorio, la extensión del IDE y opencode web. Todas hablan con el mismo proceso de servidor. Otro dispositivo puede adjuntarse a una sesión existente a través de ese proceso.
Ejecutar opencode serve inicia el servidor sin la TUI normal. Ejecutar opencode web añade un cliente en el navegador. Ambos comandos requieren autenticación si el servidor es accesible desde otro dispositivo.
La configuración vive en opencode.json o opencode.jsonc a nivel de proyecto, con un fallback global en ~/.config/opencode/opencode.json. Controla los modelos, permisos, servidores MCP y agentes personalizados. Como se indicó en la sección de flujo de trabajo, el historial de sesiones y los registros de herramientas permanecen en archivos locales salvo que el usuario los comparta.
Flujos de trabajo habituales en OpenCode
Las mismas piezas de OpenCode pueden usarse para varias tareas comunes de software. Los ejemplos siguientes muestran dónde sigue siendo clave la revisión humana en cada caso.
Crear nuevas funcionalidades
Con el proceso de Plan a Build descrito, un desarrollador puede pedir una funcionalidad y revisar los pasos propuestos antes de cualquier edición. Pulsar Tab pasa la tarea a modo Build para cambios de código y pruebas.
El plan se puede ajustar antes de tocar archivos. Yo aprovecharía esa revisión para acotar el alcance, señalar archivos que no deben cambiarse o añadir requisitos de test.
Refactorizar código existente
El mismo proceso de Plan a Build sirve para refactorizar. El modo Plan puede identificar dependencias y puntos de llamada antes de que el modo Build aplique las ediciones. Si el resultado no es correcto, /undo restaura la instantánea anterior. Aun así, hay que revisar el diff, porque que pasen los tests no garantiza que todas las interfaces públicas sigan igual.
Depurar aplicaciones
Para depurar, OpenCode puede combinar un stack trace con la información de tipos del servidor de lenguaje. Puede proponer un cambio, repetir los pasos que causaron el error y comprobar el resultado. Sin pasos de reproducción claros, puede limitarse a confirmar que el código compila o que pasan los tests existentes.
Escribir pruebas
Como vimos, el modo Build puede editar archivos y ejecutar comandos. Para escribir pruebas, eso significa que puede crear un test, leer el resultado y hacer otro cambio. Una batería de pruebas completa le da más feedback, pero tarda más.
La calidad de las pruebas sigue necesitando revisión humana. Un test generado puede repetir la implementación en lugar de comprobar el comportamiento del que dependen los usuarios.
Entender bases de código grandes
La sección del repositorio explicó cómo /init crea notas del proyecto. Tras ese paso, una pregunta como "¿Cómo funciona la autenticación aquí?" puede guiar la búsqueda. El subagente @general puede buscar en varias partes del repositorio.
Las preguntas concretas suelen dar resultados más claros que pedir una explicación de todo el repositorio. Las referencias de archivo con @ pueden acotar aún más la búsqueda.
OpenCode frente a otros agentes de codificación con IA
Estas herramientas difieren en licencia, soporte de modelos, interfaz y facturación. Las comparo en esos puntos en lugar de tratar una como la opción por defecto.
OpenCode vs. Claude Code
Tenemos un artículo aparte comparando OpenCode y Claude Code con más detalle. Claude Code es propietario y usa el modelo y el sistema de cuentas de Anthropic. OpenCode usa licencia MIT y te pide que elijas proveedor. También da acceso a su código fuente y configuración. Como se indicó en la sección de historia, las suscripciones de consumo de Claude ya no funcionan a través de OpenCode, por lo que el uso de Claude requiere una API de Anthropic con facturación por uso.
Ambas herramientas pueden leer archivos, hacer cambios, ejecutar comandos y usar servidores MCP. El acceso a modelos es la gran diferencia: Claude Code se ciñe al esquema de Anthropic descrito arriba, mientras que OpenCode puede conectar otros proveedores o un endpoint local.
OpenCode vs. Cursor
Cursor es un IDE basado en VS Code que también ofrece agentes por CLI y en la nube. Su flujo principal mantiene sugerencias, cambios de archivos y acciones del agente dentro del editor. OpenCode usa las interfaces de terminal, escritorio y editor ya citadas. Cursor funciona con planes de suscripción de pago. El software de OpenCode es gratuito, pero quizá tengas que pagar al proveedor del modelo por los tokens. Las diferencias principales son la interfaz de trabajo, la elección de modelo y el método de facturación.
Cursor también incluye autocompletado inline mientras escribes. OpenCode se centra en tareas encomendadas a un agente y no sustituye esa forma de autocompletado. Algunos desarrolladores pueden usar ambos tipos de herramienta para trabajos distintos.
OpenCode vs. Cline
Cline es, en su núcleo, un agente open source con BYOK y con interfaces para VS Code y CLI. También tiene un cliente para JetBrains, aunque en el momento de escribir esto no es open source. Tanto Cline como OpenCode admiten MCP y permiten fijar reglas de aprobación. Cline sitúa sus controles de editor en una barra lateral. OpenCode usa sesiones de terminal que pueden ejecutarse aparte del editor. La elección depende sobre todo de dónde prefieres revisar y aprobar cambios.
Cline usa licencia Apache 2.0. OpenCode usa la licencia MIT mencionada. Ambos permiten revisar y cambiar el código fuente, pero sus interfaces y archivos de proyecto difieren.
Aider y Codex CLI también son agentes de codificación basados en terminal. OpenCode cubre terminal, escritorio e IDE en el mismo proyecto y admite modelos de varios proveedores.
Instalación y primeros pasos con OpenCode
El script oficial de instalación funciona en la mayoría de sistemas tipo Unix. Ofrece una forma de instalar la herramienta de línea de comandos:
El comando descarga el binario de OpenCode y lo añade al entorno del usuario. Un gestor de paquetes puede encajar mejor si las actualizaciones se gestionan junto con el resto del sistema.
curl -fsSL https://opencode.ai/install | bashEntre las opciones de gestor de paquetes están npm i -g opencode-ai@latest, brew install anomalyco/tap/opencode en macOS y Linux, y scoop install opencode o choco install opencode en Windows. Hay una app de escritorio para macOS, Windows y Linux. En Windows, la documentación de OpenCode recomienda WSL porque ciertas funciones de sistema de archivos y shell funcionan mejor ahí.
La instalación no incluye acceso a modelos. La primera sesión sigue necesitando uno de los métodos de acceso vistos en la sección de múltiples modelos.
Instalar OpenCode antes de crear las instrucciones del proyecto. Vídeo del autor.