Haz esta prueba de 3 tareas antes de hacer de OpenCode 2.0 tu arnés diario

OpenCode 2.0 centraliza sus clientes de terminal, web y escritorio en un único servicio en segundo plano iniciado localmente. Si estás valorándolo como arnés diario, empieza donde está el dolor: el contexto que se infla, las sesiones que mueren al cambiar de máquina y las tareas largas que bloquean la terminal. La ruta de actualización es una decisión. OpenCode v1.19.0, publicado el 11 de octubre, dejó de instalar actualizaciones automáticamente. Así que la decisión es tuya, y debería probarse antes de trasladar tu trabajo.

Comparar arneses tiene menos que ver con la inteligencia del modelo que con el envoltorio que mantiene el trabajo vivo. El envoltorio decide qué ve el modelo, qué se ejecuta en segundo plano y qué sobrevive a un reinicio. Esas son las partes que puedes probar sin comprar un modelo nuevo ni reescribir tu flujo de trabajo.

Crea una tarea fija que exponga el envoltorio

La prueba de contexto necesita un prompt fijo, no un prompt vago de «probar lo nuevo». Elige una tarea que involucre varios servidores MCP y un cambio de archivo local. OpenCode 2.0 incluye @opencode/codemode, que expone servidores MCP y endpoints OpenAPI como funciones invocables. Cada servidor MCP está habilitado para Code Mode de forma predeterminada en OpenCode 2.0. El equipo de Anomaly afirma que Code Mode permite añadir muchos servidores MCP manteniendo la hinchazón del contexto baja. Tu trabajo es comprobar si esa afirmación resiste tu repositorio, tu prompt y tu modelo.

Mantén la tarea lo suficientemente pequeña para que puedas ver la traza completa. OpenCode ofrece herramientas de worktree integradas llamadas worktree_create, worktree_list y worktree_remove para usar en Code Mode. Pide a la agente que cree un worktree, lo liste y lo elimine. Si la nueva versión puede invocar esas herramientas sin problemas, el comportamiento de la versión antigua se convierte en tu línea base. Si no puede, ya has encontrado un bloqueador de migración.

No hagas el prompt ingenioso. Un prompt ingenioso oculta el arnés. La hinchazón del contexto aparece cuando el modelo tiene que elegir una herramienta, esperar un resultado y luego usar ese resultado. El envoltorio o mantiene el esquema de la herramienta fuera del camino o entierra la respuesta bajo un muro de instrucciones.

Ejecuta las tres comprobaciones antes de trasladar el trabajo diario

La lista de verificación siguiente es toda la prueba. Cada elemento es una comprobación rápida, no un benchmark. Ejecútala primero en el arnés antiguo y luego en el nuevo, usando el mismo repositorio y el mismo prompt. Anota lo que ves, no lo que esperas ver.

• Compara el contexto del prompt multi-MCP fijo en ambas versiones y anota la primera llamada de herramienta, el tamaño del contexto y el error.
• Abre una segunda máquina, inicia la sesión /pair si el arnés la expone y confirma que la primera máquina ve la misma conversación.
• Entrega un comando largo a una subagente en segundo plano, cierra la terminal y comprueba si la tarea sobrevive y reporta de vuelta.

Las tres comprobaciones corresponden a los tres modos de fallo: contexto, cambio de máquina y trabajo largo. Un acierto en contexto no rescata una sesión /pair rota, y una sesión /pair limpia no rescata una tarea en segundo plano que muere al cerrar la terminal. Si la nueva versión gana en todas las comprobaciones, merece una prueba. Si pierde una comprobación, mantén el arnés antiguo para esa tarea.

No promedies los resultados. Un arnés puede ser excelente en contexto y terrible en trabajo en segundo plano. Tu uso diario es una mezcla, así que la mezcla es el veredicto. Pondera las comprobaciones según tu trabajo real: las ediciones cortas favorecen la prueba de contexto, las compilaciones largas favorecen la prueba en segundo plano y el cambio frecuente de máquina favorece /pair.

Juzga el resultado con un registro, no con una intuición

Registra algunos números: llamadas de herramienta antes de una edición útil, líneas de contexto visibles antes de la respuesta y reintentos tras un fallo. No necesitas una métrica perfecta. Necesitas un número que te permita decir que la nueva versión fue más rápida, más lenta o igual. Si el número está cerca, prefiere el arnés que falla de forma más silenciosa.

También registra la forma del fallo: los errores limpios, los errores útiles de herramientas y las tareas en segundo plano que indican que están en ejecución son más fáciles de convivir que los cuelgues silenciosos, los largos bloques de salida estructurada y las tareas que desaparecen al cerrar la terminal.

No dejes que un acierto decida el cambio. Un arnés que maneja bien una demo puede seguir siendo un mal conductor diario. La prueba está hecha cuando puedes decir qué tarea aún necesita el arnés antiguo.