Reasoning effort max Pro Ultra y subagentes

El parámetro más caro de toda la API de OpenAI no es el modelo que eliges: es el reasoning effort, un dial que la mayoría de desarrolladores deja en default sin pensarlo. Puede multiplicar tu factura por 68 sin cambiar una sola palabra visible en la respuesta, y entender cómo funciona es clave si trabajas con modelos de razonamiento.

Qué hace reasoning effort y por qué encarece tu factura

Después de construir un árbol de decisión para elegir entre Sol, Terra y Luna en la clase anterior, hoy abrimos el capó del motor que realmente mueve los costos: los modos de razonamiento. Son tres mecanismos completamente separados, y confundirlos invalida cualquier benchmark que intentes correr.

El reasoning effort controla la profundidad de pensamiento en una sola cadena. Acepta seis valores: none, low, medium, high, xhigh y max, con medium como default [00:53]. Cada nivel genera más reasoning tokens internos, tokens que nunca ves en la respuesta pero que se facturan como output. Es un taxímetro que corre mientras el conductor piensa la ruta: no ves el cálculo mental, pero pagas el tiempo.

¿Qué son los reasoning tokens? Son tokens internos que el modelo genera para pensar antes de responder. No aparecen en la salida visible, pero se cobran a tarifa de output y se reportan en output_tokens_details.reasoning_tokens dentro del objeto usage.

Simon Willison corrió 18 pruebas cruzando los tres modelos con los seis niveles [01:09]. El resultado va desde 0.00071 dólares con Luna en none hasta 0.4855 con Sol en max: 68x de diferencia en la misma tarea y familia.

Cómo se dispara el precio con max

Max se sienta encima de xhigh y simplemente genera muchos más reasoning tokens por call. No tiene precio propio separado, pero las trampas de billing son varias:

• Los reasoning tokens solo aparecen en output_tokens_details.reasoning_tokens. Si no lo monitoreas, tu factura se dispara sin explicación visible.
• En sesiones agénticas, cada subagente hereda el nivel de esfuerzo del padre. Un Sol con max lanza todos sus hijos también en max, y cada hijo factura independientemente [02:01].
• Si tu input cruza 272,000 tokens, toda la request pasa a doble precio de input y 1.5x de output. Combinado con max, Sol salta de 30 a 45 dólares por millón de output [02:13].

Max solo se justifica cuando dos condiciones se cumplen a la vez: la calidad es lo único que importa, y xhigh no da resultados suficientes en tu tarea real. La guía oficial recomienda comparar siempre max contra xhigh antes de comprometerte.

Qué hace el Pro mode y cómo persiste el razonamiento

Pro se activa con reasoning.mode: pro en la Responses API. Aplica más trabajo interno a una request, pero su mecánica exacta no está documentada. Se factura a tarifa estándar, sin slug separado.

Lo distinto de Pro en producción es la persistencia entre turnos. El parámetro reasoning.context controla qué razonamiento se preserva cuando encadenas turnos con previous_response_id. Tiene tres valores:

• auto: es el default.
• all_turns: mantiene el razonamiento acumulado entre turnos, útil cuando los objetivos son estables a lo largo de una conversación larga.
• current_turn: descarta todo lo anterior, útil cuando cada turno es independiente.

Piénsalo como un equipo de consultoría. All turns es mantener al mismo consultor briefeado durante todo el proyecto. Current turn es contratar uno nuevo cada sesión que empieza de cero. Pero ojo: los ítems persistidos son opacos. La API nunca devuelve el texto de ese razonamiento, así que tienes continuidad sin visibilidad.

¿Cuándo conviene all_turns en Pro? Cuando tu conversación mantiene el mismo objetivo por muchos turnos y quieres que el modelo no pierda el contexto de razonamiento previo. Si cada turno es un tema nuevo, usa current_turn para no arrastrar carga innecesaria.

Cómo funciona Ultra y por qué multiplica el costo

Aquí la arquitectura cambia de naturaleza. Ultra es exclusivo de Sol. Cuando lo activas con multi_agent.enabled, el modelo descompone la tarea y lanza múltiples subagentes en paralelo [04:19]. No confundas: max profundiza una cadena; Ultra paraleliza.

El número default de subagentes concurrentes es tres según la documentación de la API, aunque la cobertura de prensa del lanzamiento dijo cuatro. Contradicción no resuelta; usa tres como referencia.

Cuánto cuesta Ultra en producción

Cada subagente factura sus propios tokens a tarifa completa de Sol, sin descuento por ser hijo. Si un call estándar cuesta 10 centavos, con tres subagentes moderados llegas a 30 centavos, 3x. Pero en uso intensivo real en Codex, usuarios reportaron entre 6x y 12x [05:00].

¿Por qué se dispara? Porque los subagentes cargan reasoning tokens pesados, heredan cache frío a 1.25x sin reutilizar el del padre, y si alguno cruza los 272,000 tokens, el cliff de precio se multiplica por cada subagente que lo cruce.

Las ganancias reportadas por OpenAI son modestas: aproximadamente tres puntos porcentuales en Terminal-Bench y menos de dos en BrowseComp, ambas self-reported sin reproducción independiente. Ultra se justifica cuando el trabajo se divide limpiamente en partes independientes. La mayoría de tareas no lo necesitan.

Qué palancas de control tienes y cuáles no

Antes de usar Ultra en producción, conoce lo que puedes tocar:

• developer messages: para gatear cuándo se crean subagentes.
• fork_turns: para decidir cuánto contexto del padre recibe cada hijo.
• max_concurrent_subagents: para fijar el tope.

Lo que no puedes hacer: asignar un modelo diferente por subagente, asignar un effort diferente por subagente, ni ver las instrucciones de orquestación inyectadas al sistema.

Hay un bug confirmado en Codex CLI donde el modelo auto-selecciona MultiAgent V2 y oculta los campos model y reasoning_effort del schema de spawn [06:09]. Resultado: cualquier directiva para usar modelos ligeros en workers se ignora silenciosamente y todos heredan Sol. El workaround en TOML es establecer features.multi_agent_v2.hide_spawn_agent_metadata = false.

El principio de diseño que cruza todo esto: define el outcome y las constraints a nivel root. Describe cómo luce el éxito y deja que el modelo elija el camino. No intentes micromanagear pasos que el sistema no te expone.

Ahora tienes la escala completa: effort controla profundidad, Pro controla persistencia y Ultra controla paralelismo. Tres diales independientes que se combinan y se multiplican en costo. ¿Cuál de los tres usas hoy sin haberlo medido? Cuéntame en los comentarios cómo lo estás calibrando.