OpenCode publicó el 13 de noviembre de 2026 la versión 2.3.0, sin marcarla como preliminar en GitHub. Su cambio principal para quienes usan agentes de programación es el trabajo de los subagentes en segundo plano: encargar una tarea devuelve inmediatamente un identificador de sesión y permite continuar la conversación principal. El resultado llega después, mediante informes.
Ya recogimos el lanzamiento en el resumen del 13 de noviembre. Aquí desarrollamos la diferencia práctica entre lanzar un trabajo y disponer de una respuesta revisada. No hemos ejecutado una evaluación de OpenCode 2.3 ni atribuimos al cambio mejoras medidas de calidad, tiempo o coste.
Un identificador no es un resultado
La actualización elimina la elección de ejecución en primer plano o en segundo plano de la herramienta de subagentes. Cada llamada devuelve un sessionID, el identificador con el que se reconoce la sesión secundaria. La sesión principal recibe informes cuando el subagente queda inactivo, en lugar de esperar una respuesta final dentro de esa llamada.
Para una integración que antes esperaba el resultado en línea, la distinción es relevante: recibir ese identificador confirma el encargo, no la corrección del trabajo. Tampoco permite tratar cualquier informe como una aprobación humana. El cambio técnico se fusionó el 11 de noviembre; su incorporación a la versión publicada corresponde al día 13.
La interfaz de terminal también agrupa herramientas y razonamiento en filas desplegables. El detalle se puede recuperar con los niveles de verbosidad medium o high; las notas indican que se conserva una preferencia existente. Una vista más breve no significa que se hayan ejecutado menos acciones.
Escape no detiene el trabajo de los subagentes
Según la implementación enlazada desde las notas de la versión, pulsar Escape en la sesión principal ya no cancela a sus subagentes activos. Estos pueden continuar y comunicar resultados después; sigue existiendo la interrupción individual.
Por eso, al revisar una sesión conviene comprobar qué trabajos siguen activos y qué acción los detiene. Es una recomendación de operación: el paralelismo no demuestra aislamiento entre cambios ni sustituye la revisión de permisos. Nuestro antecedente sobre OpenCode 2.2.3 explica otros cambios de integración y permisos de esa familia.
Un encargo acotado antes de integrar cambios
Como ejemplo hipotético, no ejecutado, un equipo podría pedir a un subagente que analice las pruebas y a otro que revise la documentación mientras la sesión principal prepara una propuesta. Delimitaría qué puede modificar cada uno y evitaría encargos que escriban simultáneamente en los mismos archivos sin coordinación.
Después reuniría los informes, contrastaría los cambios propuestos y ejecutaría las pruebas pertinentes antes de integrarlos. Que lleguen dos informes no demuestra que ambos trabajos sean compatibles ni que el resultado sea mejor. Para medir una ventaja haría falta comparar tareas equivalentes, sus errores, el consumo y el tiempo total, incluidos los reintentos.