Cómo ejecutar agentes GPT-6.1 Sol en Sharkly

OpenAI lanzó GPT-6.1 Sol durante el DevDay del 29 de septiembre con el mismo precio oficial que GPT-6 Sol: 2 $ por millón de tokens de entrada y 10 $ por millón de salida, con el coste de entrada en caché reducido a la mitad (0,10 $). Sin embargo, el detalle que más importa a un equipo que ejecuta varios agentes de Codex pasa más desapercibido. La pantalla de bienvenida en la documentación de la CLI de Codex ahora indica gpt-6.1-sol medium. En cualquier Computer que no tenga fijado un modelo, los Agents cambiarán de modelo cuando alguien actualice Codex en esa máquina, no cuando el equipo decida que deban hacerlo.

Sharkly no reflejará ese cambio. El Agent adopta el modelo predeterminado del Runtime y no muestra ningún nombre de modelo, por lo que a partir de esta semana dos Agents con instrucciones idénticas pueden ejecutar modelos distintos en dos Computers mientras sus Tasks se ven exactamente iguales en el panel. Saber qué agente utiliza cada modelo y de cuál proviene cada resultado pasa a ser una incógnita que depende de la memoria. Esta guía cubre únicamente las diferencias respecto a nuestra guía de GPT-6 Sol: de dónde proviene el nuevo valor predeterminado, cuándo fijarlo, los dos ajustes que han cambiado y cómo debería un Crew distribuir el trabajo ahora que el nivel intermedio se acerca tanto a la gama alta.

TL;DR

GPT-6.1 Sol llega a Sharkly a través del Codex Runtime en un Computer, y nada cambia dentro de Sharkly al hacerlo. Comprueba qué compilación de Codex ejecuta cada Computer y si su archivo ~/.codex/config.toml tiene un modelo fijado. Los Computers sin modelo fijado adoptan el predeterminado de la CLI, que según la documentación ahora es gpt-6.1-sol con esfuerzo medio. Los Computers configurados según nuestra guía anterior permanecerán en gpt-6-sol hasta que alguien edite una línea. Cambia cualquier nivel de esfuerzo none por low, ten en cuenta que la rebaja a la mitad en la caché solo se reflejará en los Computers facturados con API key (no en los inicios de sesión por suscripción), y toma la tabla de enrutamiento que figura más abajo como una pauta a probar con tus propias Tasks, no como un veredicto definitivo.

Qué ha cambiado en el Codex Runtime

La documentación de Agents explica por qué este artículo se centra en los Computers y no en los Agents: «El Agent adopta el modelo predeterminado del Runtime. No garantiza ni muestra un nombre de modelo específico. Cambia los modelos en la configuración de herramientas del Runtime o del Computer, no en el Agent». La actualización es un evento del Runtime. Estas son las diferencias tangibles para un Crew:

La renovada CLI de Codex también ha añadido voz, una vista /agents, edición de prompts, reanudación y worktrees en todos los planes. Vale la pena utilizarlos siempre que manejes Codex de forma manual desde un terminal. No obstante, una vez que el trabajo pasa a manos del equipo, la Task se convierte en el registro compartido. En modo Temporary, Sharkly asigna a cada Task su propio directorio y, para el trabajo con repositorios, puede preparar un worktree limpio; asimismo, el estado de la ejecución, el registro, las preguntas y el resultado regresan a la Task, donde la siguiente persona podrá consultarlos.

Fijar el modelo o dejar que cada Computer siga el valor predeterminado

Comienza con un inventario, ya que la respuesta puede ser distinta para cada Computer. sharkly computer list muestra los Computers registrados en tu organización, y sharkly computer show <computer-id> devuelve la información de un Computer con sus Runtimes. En el propio Computer, iniciar codex muestra la compilación y el modelo. El registro de cambios de Codex detalla que la versión 0.159.1 (29 de septiembre) convirtió a GPT-6.1 Sol en el modelo predeterminado, y la sesión de ejemplo de la documentación indica model: gpt-6.1-sol medium.

Presta atención a dos aspectos. En primer lugar, qué binario se ejecuta. En macOS, un Computer sin un Codex independiente puede registrar como Runtime la CLI de Codex integrada en la aplicación de escritorio de ChatGPT; la documentación de Sharkly recomienda en su lugar un Codex instalado por ti e incorporado al PATH. En segundo lugar, qué capa de configuración define el modelo. La guía de conceptos básicos de configuración de Codex sitúa las preferencias personales en ~/.codex/config.toml, permite que un repositorio las anule mediante su propio archivo .codex/config.toml (cargado únicamente en proyectos de confianza) y prioriza los parámetros -m o --model de la línea de comandos por encima de ambos.

Dos alternativas a considerar: deja que un Computer siga el valor predeterminado si lo gestiona una sola persona, ejecuta un puñado de Tasks a la semana y prefiere alinearse con el modelo recomendado por OpenAI antes que mantener una línea de configuración. Fija el modelo cuando varias personas asignen trabajo a Agents en ese Computer, cuando un Crew abarque más de un Computer o en mitad de un Sprint, donde un cambio inadvertido haría que el resultado del martes y el del jueves parezcan iguales en la Task sin serlo en absoluto.

Para fijarlo, edita la configuración de usuario en el Computer que ejecuta el Codex Runtime:

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

Ambas claves figuran en la documentación de configuración de Codex con estos valores. Si seguiste nuestra guía sobre GPT-6 Sol, ese archivo ya indicará model = "gpt-6-sol", por lo que ese Computer no cambiará de versión al actualizarse. Modifica esa línea cuando estés preparado para el cambio, no antes.

Actualiza Codex con el instalador que la documentación emplea tanto para instalar como para actualizar, o bien solicita a Sharkly que gestione la actualización de la CLI para un Runtime específico:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
# or, from anywhere with the Sharkly CLI:
sharkly computer update <computer-id> <runtime-id>

A continuación, ejecuta el reescaneo o la prueba de conexión en el detalle del Computer y confirma que el Codex Runtime figure como Available. Por último, anota el modelo fijado en la descripción del Agent. Quien revise un diff no debería tener que abrir una shell en algún Computer solo para averiguar qué modelo generó el código.

Los dos ajustes modificados: esfuerzo y caché

El nivel none ha desaparecido. GPT-6.1 Sol admite low, medium, high, xhigh y max, y excluye tanto none como minimal. Un Computer cuya configuración pida none —una elección natural para una vía rápida en GPT-6 Sol— requerirá low antes de la migración, y conviene revisar los resultados con detenimiento, ya que low sigue aplicando razonamiento. Si una ejecución falla con el ajuste antiguo, el registro de ejecución conservará el título y la respuesta original del servicio del modelo; la guía de resolución de problemas de Sharkly ante una opción no compatible aconseja verificar las opciones del modelo y de la petición en lugar de reintentar a ciegas.

La caché es la mejora más discreta pero ventajosa. OpenAI factura la entrada en caché a 0,10 $ por millón, «un 95 % menos que el precio estándar de entrada y un 50 % menos que el precio de entrada en caché de GPT-6 Sol». Esto se aprecia sobre todo en Agents de larga duración. Una ejecución que trabaja durante una hora en un mismo repositorio reenvía continuamente buena parte del mismo contexto, y los miembros de un Crew que parten de la misma estructura de repositorio, reglas y comandos de prueba reutilizan el mismo prefijo a lo largo de toda la jornada.

Conviene tener presentes tres salvedades. El ahorro por token solo se manifiesta en un Computer donde Codex facture mediante una API key; un Computer con sesión iniciada a través de un plan de ChatGPT consumirá el uso asignado a dicho plan, aspecto que abordamos en el artículo complementario sobre cómo ejecutar GPT-6.1 Sol sin API key. El precio oficial no ha variado, de modo que el trabajo sin caché cuesta lo mismo que la semana pasada. Y los contextos extensos conllevan un recargo: OpenAI tarifa cualquier prompt superior a 272K tokens de entrada al doble en las tasas de entrada y caché, y al 1,5x en salida para toda la solicitud; por tanto, un Agent que arrastre un contexto masivo en cada interacción debería contar con un prefijo estable y más reducido antes de recibir un presupuesto mayor.

Distribución para el Crew: Astra, 6.1 Sol, Luna o un Runtime de Claude

La propuesta de OpenAI para 6.1 Sol promete resultados cercanos a Astra por una fracción de su coste, y todas las cifras que la respaldan proceden de las evaluaciones internas de OpenAI. En DeepSWE v1.1, OpenAI señala que 6.1 Sol iguala a Astra con aproximadamente una quinta parte del coste y supera la mejor puntuación de GPT-6 Sol en 6,4 puntos con un nivel de esfuerzo menor. En OSWorld 2.0, una prueba de rendimiento de uso del ordenador, se queda a 2,1 puntos de Astra con esfuerzo máximo por cerca de una séptima parte del coste por tarea. OpenAI también es explícita respecto a sus límites: Astra sigue obteniendo la puntuación más alta en Terminal-Bench Science, con un 68,1 %, y OpenAI recomienda recurrir a Astra para las tareas científicas más exigentes.

La guía de selección de modelos de OpenAI clasifica a los modelos de la familia según este mismo criterio: Astra para problemas ambiguos, 6.1 Sol para tareas complejas donde el tiempo y el coste son prioritarios, y Luna para tareas acotadas y clasificación inicial, describiendo sus propias directrices como un punto de partida. Dado que el modelo se define en la configuración del Runtime, una regla de enrutamiento en Sharkly es una regla sobre los Computers: un Agent vinculado a un Computer cuyo Codex utilice Astra por defecto ejecutará Astra. Una regla inicial de referencia para probar:

La última fila plasma una postura formal de neutralidad frente a proveedores, no una afirmación basada en comparativas. Claude Sonnet 5.5 se lanzó un día antes que 6.1 Sol con los mismos precios de 2 $ y 10 $, y la publicación de OpenAI compara 6.1 Sol con Opus 5.5 y Fable 5.1, nunca con Sonnet 5.5. Ningún proveedor ha publicado esa comparativa directa, por lo que la única evaluación decisiva es la que ejecutes con tus propias Tasks. La fundamentación completa a favor de establecer una regla documentada con escalado manual se detalla en nuestra guía sobre enrutamiento de modelos para Crews.

Nada de esto cambia el eslabón final del proceso. Una vía más económica hacia resultados casi a nivel de Astra se traduce en más ejecuciones completadas al día, pero todas ellas siguen concluyendo ante una persona que revisa el diff. Los Agents investigan, ejecutan, prueban e informan. Las personas marcan el rumbo, conceden permisos y validan el resultado. La labor productiva de esta semana consiste en asegurarse de que el panel permita saber qué Computer ejecutó qué modelo, qué concluyó con éxito, qué falló por un ajuste de esfuerzo obsoleto y qué está esperando revisión. Si todavía alternas terminales de Codex manualmente, la guía sobre cómo gestionar múltiples agentes de Codex repasa primero el procedimiento manual.

Puedes implementar este flujo manualmente con worktrees o utilizar Sharkly para gestionar el proceso.