Mira lo que produjo tu equipo la semana pasada. Una pequeña parte fue la funcionalidad de la que se habló en el standup. La mayor parte fue el entorno: triaje de bugs, etiquetas, un changelog, comentarios de primera pasada en once pull requests, andamiaje de tests para un módulo que nadie quiere asumir, actualizaciones de dependencias, una página de documentación que quedó obsoleta cuando cambió la forma de una respuesta. Alto volumen, poca gloria y, hasta esta semana, costaba lo mismo por token que el trabajo interesante, porque se ejecutaba en el mismo runtime.
OpenAI lanzó GPT-6 Luna el 22 de septiembre a $0,10 por millón de tokens de entrada y $0,50 por millón de salida, con id de API gpt-6-luna y una ventana de contexto de 1M. Ese es el nivel al que pertenece el aburrido 80 por ciento. La pregunta útil no es si Luna es bueno, sino qué trabajos bajan a ese nivel, cuáles no deben hacerlo y cómo escribir una Task que un runtime barato pueda completar.
TL;DR
Enruta el trabajo al nivel barato según su verificabilidad, no su dificultad. Si un resultado se puede verificar sin rehacerlo, y una respuesta incorrecta le cuesta a quien revisa un minuto en lugar de una tarde, pertenece a Luna. Reserva para el runtime caro los juicios de valor, todo aquello sobre lo que el tablero automatice y cualquier cosa que nadie vaya a revisar. Escribe criterios de aceptación que una máquina pueda evaluar, mantén el esfuerzo moderado para trabajos cortos y haz que cada resultado vuelva a la Task donde una persona lo acepta.
A qué precio está Luna y contra qué se compara
Las comparativas de Luna que publica OpenAI son de coste por tarea en lugar de posiciones en rankings, que es el marco correcto para este trabajo.
| Resultado publicado | Luna | Comparado con |
|---|---|---|
| DeepSWE 1.1 | 66,6% con esfuerzo máximo | Comparable a Claude Opus 5 y Fable 5 en esfuerzo medio, con un 93% menos de coste por tarea que Opus 5 y un 96% menos que Fable 5 |
| AutomationBench 1.0.6 | +5,4pp sobre su predecesor con esfuerzo alto | 58% menos de coste por tarea |
| OSWorld 2.0 offline | Supera a GPT-5.6 Sol con esfuerzo medio | Aproximadamente una décima parte del coste |
| Factualidad | Iguala a GPT-5.6 Sol con esfuerzo alto | Aproximadamente una centésima parte del coste |
Con esas cifras van dos matices. OpenAI describe a Sol y Luna como un 50% más baratos que el precio promocional de GPT-5.6. Promocional es palabra de OpenAI y es importante: la base es un descuento, no el precio de tarifa. Frente al precio de tarifa de GPT-5.6 Luna que documentamos en nuestra propia cobertura de lanzamiento —$1 por millón de entrada y $6 por millón de salida—, la bajada a $0,10 y $0,50 se acerca más al 90% en entrada y al 92% en salida. El recorte real es mayor que el titular, y el titular se mide contra una oferta.
Y todas las comparaciones con Anthropic de esa tabla son contra Claude Opus 5. Anthropic sustituyó Opus 5 por Opus 5.5 el mismo día en que OpenAI publicó, a $4 por millón de entrada y $20 por millón de salida frente a los $5 y $25 de Opus 5. Lee esos márgenes como medidos contra la generación anterior, porque así fue. No declaramos un ganador entre los dos buques insignia actuales, y ninguno de los dos proveedores ha publicado esa comparación directa.
Artificial Analysis, un tercero y no ninguno de los dos proveedores, sitúa a Luna en 37 en su índice de inteligencia frente a 58 de Opus 5.5. Luna no es un modelo de frontera y no se vende como tal. Es un trabajador competente con precio de servicio básico, que es justamente el punto.
La propiedad que decide qué baja de nivel
Los equipos clasifican el trabajo de los agentes por dificultad. Ese es el eje equivocado: la dificultad es una propiedad del problema, y tu exposición es una propiedad del bucle de revisión. Clasifica por verificabilidad.
El trabajo pertenece al nivel barato cuando se cumplen ambas condiciones. El resultado se puede verificar sin rehacerlo, mediante un test, un diff, una regla de lint o diez segundos de lectura. Y un resultado incorrecto le cuesta a quien revisa un minuto, no una tarde, porque el radio de impacto es una etiqueta, un comentario o un archivo.
Ese par es la razón por la que el andamiaje de tests cualifica y una revisión de seguridad no, aunque ambos sean generación de texto sobre el mismo repositorio. Un test generado se ejecuta o no se ejecuta, y lo descubres en el mismo minuto. Un agujero de autorización que se pasa por alto en un comentario de revisión se ve exactamente igual que uno limpio.
Qué delegar
| Trabajo | Qué devuelve el Agent | Cómo se verifica | Radio de impacto si falla |
|---|---|---|---|
| Triaje de informes de bugs entrantes | Resumen, componente sospechoso, intento de reproducción, sugerencia de prioridad | Cuatro líneas que se leen al retomar la Task | Una Task mal enrutada |
| Etiquetado y metadatos | Etiquetas y tipo de Task, indicando la regla aplicada | Visible en el tablero | Una etiqueta incorrecta |
| Changelog y notas de versión | Borrador de notas a partir de los diffs fusionados de un Sprint | Diff contra los commits | Editorial, detectado antes del lanzamiento |
| Comentarios de revisión de primera pasada | Observaciones como comentarios, explícitamente sin ser una aprobación | Quien revisa los lee o los ignora | Ruido, si nada depende de ellos |
| Andamiaje de tests | Archivos de test que compilan y se ejecutan, con los huecos evidentes marcados | La ejecución de los tests | Build en rojo |
| Actualizaciones de dependencias | Una actualización por Task, con extracto del changelog y resultado de los tests | CI | Un revert |
| Seguimientos de documentación tras un merge | Ediciones en la documentación citando el diff de origen | Revisión del diff | Una página obsoleta sigue obsoleta |
La forma común: cada uno devuelve un artefacto que otra persona evalúa en segundos, sobre la evidencia que el Agent adjuntó. Ninguno tiene la última palabra sobre nada, que es el criterio que hay que aplicar cuando amplíes la lista a cualquier cosa que tu equipo aborde después.
Qué no delegar
Merece la pena enunciar tres líneas divisorias, porque un nivel barato invita a estos errores.
Una revisión de primera pasada no es una revisión. Un Agent que publica observaciones sobre un diff genera material de lectura. No es una aprobación, y en el momento en que un equipo trata una primera pasada limpia como señal de que un cambio es seguro, el nivel barato ha ascendido a la decisión de aceptación. Sé preciso sobre qué puede y qué no puede verificar un agente de revisión, y etiqueta el comentario como primera pasada en el propio comentario.
Una etiqueta sobre la que el tablero automatiza es una decisión, no una nota. Si mover una Task a un estado dispara una ejecución, o la prioridad determina lo que el equipo aborda después, un Agent de etiquetado está marcando la dirección. O mantienes la automatización fuera de esos campos, o mantienes el etiquetado en el nivel al que confías la dirección.
El trabajo que nadie va a revisar no se abarata, se vuelve invisible. Una respuesta incorrecta barata solo es barata cuando alguien la nota. Si un trabajo no tiene lector, la solución es eliminar el trabajo, no usar un runtime más barato.
El par de decisión, entonces. Usa Luna cuando el trabajo sea de alto volumen, acotado y verificado por algo distinto de la confianza. Usa Sol o Opus 5.5 cuando una Task deba mantener contexto durante horas, cruce varios módulos o cueste más detenerla a medias que los tokens. Si ejecutas un solo Agent sobre un solo repositorio, no dividas niveles en absoluto: elige el runtime que encaje con tu trabajo más difícil.
Escribir una Task que un runtime barato pueda completar
Un Agent en Sharkly es una configuración de trabajo guardada, no un prompt puntual. Sus instrucciones, Runtime, Skills, repositorios, entorno y ajustes de ejecución determinan cómo maneja el trabajo, así que la unidad correcta es un Agent por cada tipo de trabajo aburrido, no un Agent listo que haga los siete. Un equipo puede mantener Agents separados para cambios de código, revisión, testing, documentación o triaje operativo sin reescribir instrucciones para cada Task.
Un runtime barato necesita un alcance estrecho y una línea de meta mecánica:
SH-312 Triaje: 9 informes de bugs sin asignar de esta semana
Responsable: Triage Agent (Codex Runtime, gpt-6-luna)
Para cada informe, devuelve en la Task:
- una frase que reformule el comportamiento observado
- el componente sospechoso, con el archivo o módulo que te llevó hasta ahí
- si pudiste reproducirlo en local y el comando exacto que ejecutaste
- una sugerencia de prioridad con una razón
No modifiques archivos. No cierres ni fusiones nada.
Termina con cualquier pregunta que deba responderse antes de implementar.
Tres cosas de esa Task hacen el trabajo. El alcance es una pasada sobre nueve elementos, así que descartar un fallo sale barato. Cada afirmación lleva su evidencia, así que verificar es leer en lugar de volver a investigar. Y las dos últimas líneas marcan el límite: este Agent informa, no actúa.
Hay un ajuste que conviene decidir a propósito. Los logros publicados de Luna se sitúan con esfuerzo de razonamiento alto y máximo, y el esfuerzo es una decisión de coste y latencia, no un dial de calidad que dejes al máximo. Artificial Analysis, de nuevo un tercero, midió la variante de razonamiento máximo en 153,9 tokens de salida por segundo para Luna, con unos 124 segundos hasta el primer token. [VERIFY] Sea cual sea la cifra actual, la forma se mantiene: con esfuerzo máximo, los modelos baratos no son los de arranque rápido. Un trabajo de etiquetado que piensa durante dos minutos parece colgado en un tablero. Ejecuta los trabajos cortos con un esfuerzo moderado y reserva los ajustes altos para las Tasks que se lo ganen.
Dos notas sobre el acceso, ya que este nivel es donde los equipos se incorporan. Luna funciona en Codex y ChatGPT Work para los planes Plus, Pro, Business, Enterprise y Edu, y las cuentas Free y Go lo reciben en la aplicación de escritorio. Todavía no está en Chat. En Sharkly el modelo se configura en el Runtime o en la configuración de la herramienta Computer, nunca en el Agent, y Sharkly no te mostrará el nombre del modelo de vuelta.
La parte que un recorte de precio no arregla
Nueve resúmenes de triaje a precios de Luna cuestan casi nada. Siguen produciendo nueve cosas que una persona debe leer. Un equipo que traslada todo su entorno a un nivel barato no ha reducido las decisiones que esperan a un humano, solo las ha abaratado de generar, que no es lo mismo que abaratarlas de aceptar. Por eso la cola de revisión sigue siendo el techo, haga lo que haga la tarifa por token.
Lo que sí puedes cambiar es lo legible que es esa cola. Mantén el objetivo, la ejecución, la evidencia, los bloqueos y la revisión humana en la Task desde la solicitud hasta el lanzamiento, para que un comentario de primera pasada se vea claramente como una primera pasada, un resumen de triaje lleve el comando que lo generó, y los elementos que realmente esperan por ti se distingan de los que solo hacen ruido. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, otorgan autoridad y aceptan el resultado.
Si ejecutas varios agentes y los baratos están a punto de multiplicarse, Sharkly te da un único lugar donde asignar sus Tasks, ver qué produjo cada ejecución y decidir qué se lanza. Conecta un Computer, crea un Agent para tu trabajo más aburrido y asígnale una Task real.
