Prueba un modelo de pesos abiertos en tu tarea de codificación en curso

La tarea en curso es el banco de pruebas

Tienes una tarea de Claude Code o Codex en curso y estás sopesando un cambio de suscripción. La prueba más limpia es la tarea que ya estás ejecutando: una función a medio construir, una prueba que falla o un refactor con un estado final conocido. Esa tarea se convierte en el banco de pruebas. Tiene contexto, casos límite y un costo que puedes comparar.

Cline Desktop está en beta en macOS y Windows, y Saoud Rizwan, fundador de Cline, lanzó la versión de escritorio independiente el 14 de septiembre. Lo útil para esta prueba es la ruta de importación, no la interfaz.

No empieces desde un chat en blanco. Un chat en blanco mide el entusiasmo del modelo, no su capacidad para heredar tu estado en curso. Importa la sesión y luego cambia el motor que hay debajo.

La prueba, en orden:

• Captura la salida original, las pruebas, los pasos de plan y acción, y el costo.
• Importa la misma tarea en curso en un agente con capacidad de importación.
• Reejecútala en un modelo local o de pesos abiertos.
• Compara el código, los resultados de pruebas, el comportamiento de plan y acción, y el costo por tarea.
• Registra los fallos de importación y decide.

Importa la sesión y luego cambia el modelo

Captura la tarea original antes de tocar nada. Haz commit del árbol de trabajo, guarda la salida de las pruebas, exporta la transcripción y anota el costo hasta el momento. Guarda una etiqueta de git, un informe de pruebas, un archivo de sesión y una nota de costo a la que puedas hacer referencia más adelante.

Importa la misma tarea en curso en un agente con capacidad de importación. Cline Desktop puede importar una conversación existente de Claude Code, Codex u otro agente compatible y luego reanudar el trabajo. La transcripción debe ser visible, el contexto de archivos debe estar presente y la siguiente instrucción debe ser aceptada sin tener que reexplicar todo el problema.

Configura el modelo objetivo antes de reejecutar. Después de una importación, Cline Desktop continúa la sesión con el proveedor y el modelo seleccionados en Cline, no con los de la herramienta original. Puedes conectar una clave API existente a más de 50 proveedores, usar el propio proveedor de Cline, ClinePass, o ejecutar modelos locales. Cline fijó la suscripción de ClinePass en $9.99 al mes cuando se introdujo en junio. El nombre del modelo debe ser visible, el proveedor debe estar autenticado y no debe ser posible ningún cambio oculto al modelo anterior.

La trampa es suponer que importar significa continuidad. No es así. La transcripción puede llegar, pero el plan, las llamadas a herramientas, las suposiciones de archivos y el estado de costo pueden no llegar. Registra los fallos de importación y luego verifica el historial importado, la lista de archivos y la autenticación del proveedor antes de pedirle al modelo que continúe. La página de lanzamientos de GitHub de Cline mostraba la versión 0.0.27 el 14 de septiembre, tras varias compilaciones de septiembre; sus notas recientes describen correcciones que abarcan el historial importado, las sesiones programadas, el inicio de sesión del proveedor, el comportamiento relacionado con Windows y la búsqueda web.

Compara el trabajo, no las sensaciones

Reejecuta la tarea con el mismo prompt, los mismos archivos, la misma suite de pruebas y la misma definición de terminado. Conserva cualquier plan original, paso de acción o prueba que falle; si una prueba está fallando, déjala fallando hasta que el modelo la corrija. La segunda transcripción debe comenzar desde el estado importado y terminar con un nuevo conjunto de cambios.

Compara el diff de código contra el diff original. Busca ediciones faltantes, ediciones de más y ediciones que pasan las pruebas pero cambian el comportamiento de una forma que el original no hacía. Ejecuta las mismas pruebas. Si la tarea original no tenía pruebas, añade la prueba más pequeña que demuestre que la función funciona y luego ejecútala en ambas salidas. Guarda un diff lado a lado, un resultado de pruebas y una nota sobre qué salida se acerca más al comportamiento previsto.

Compara el comportamiento de plan y acción. Anota si el modelo pidió aclaraciones o supuso, ejecutó los comandos correctos o los inventó, y si se detuvo cuando la tarea estaba terminada o siguió editando. Estas son las señales que importan cuando decides si confiar un modelo de pesos abiertos con una tarea en vivo.

Compara el costo por tarea, no el costo por token. Un modelo barato que necesita reintentos extra no es barato. Un modelo local que termina sin reintentos puede ser la mejor opción, aunque el costo del hardware sea real. Registra el tiempo, el número de pasos, el número de pruebas fallidas y el dinero gastado. Termina con un veredicto: más barato, igual o más caro, con el motivo adjunto.

Usa los benchmarks publicados como una verificación de sentido común, no como sustituto. Las puntuaciones pass@1 de Terminal-Bench 2.0 de Cline muestran a Kimi K3 con 82.02% bajo el harness de Cline, 71.9% bajo Hermes y 76.4% bajo OpenCode. Esas cifras te dicen que el harness importa. No te dicen si el modelo puede terminar tu función a medio construir sin romper la compilación.

Haz el cambio solo cuando la tarea importada pase tu propio diff. Si falla, conserva el agente original para esa tarea y prueba el modelo de pesos abiertos en un fragmento más pequeño. Si pasa, guarda la captura, el diff y la nota de costo. Ese registro te permite cambiar de agentes de codificación sin perder la sesión, y te da un motivo para la siguiente tarea, no solo una esperanza.