TITAN — El orquestador multimodelo de Theus

TITAN es el modelo/orquestador propio de Theus. Cuando pides el modelo titan, el gateway no hace un proxy simple: TITAN analiza tu petición y decide si la responde con un solo modelo (lo normal) o si la descompone en subtareas repartidas entre varios modelos del catálogo y luego sintetiza una única respuesta final.

Qué es

TITAN vive en el gateway de Theus (theus.pe/v1). Aparece en el catálogo con el id titan (alias heredado: theus-router-auto) y está disponible en todos los planes, incluido el gratuito. Su trabajo es elegir por ti: en lugar de decidir a mano entre los modelos de la suscripción, le das la tarea a TITAN y él asigna el modelo —o los modelos— más adecuados por costo y capacidad.

• Un id, todos los modelos — titan reparte trabajo entre los modelos del catálogo que tienen ruta a un proveedor operativo.
• Sesgo a lo simple — para la gran mayoría de peticiones elige un único modelo y hace proxy directo con streaming real. El modo multi se reserva para tareas que de verdad se benefician de dividirse (p. ej. investigar + implementar + revisar).
• Cerebro configurable — el modelo que «piensa» el plan y la síntesis se configura desde la consola de administración o por entorno; cambiarlo no requiere tocar código ni reiniciar.
• Una sola voz — la respuesta siempre habla como Theus; TITAN nunca revela qué modelo la produjo por debajo.
• Fail-open — si el planificador falla o responde algo inválido, TITAN degrada a modo single con el modelo por defecto: titan siempre responde.

El flujo: plan → ejecución → verificación → síntesis

prompt del usuario  (model: "titan")
        │
        ▼
┌────────────────────────────────────┐
│ 1 · PLAN                           │  el cerebro TITAN lee la conversación,
│     ¿single o multi?               │  el menú de modelos CON su costo
│     ¿qué depende de qué?           │  relativo, y decide la estrategia (JSON)
└────────────────────────────────────┘
     │                       │
     │ single                │ multi (hasta max_subtasks)
     ▼                       ▼
┌─────────────────┐   ┌────────────────────────────────┐
│ proxy directo   │   │ 2 · EJECUCIÓN por olas         │
│ al modelo       │   │ las subtareas independientes   │
│ elegido, con    │   │ corren EN PARALELO; las que    │
│ streaming real  │   │ declaran depends_on reciben    │
│ (SSE)           │   │ las salidas de sus etapas      │
└─────────────────┘   │ previas (multi-proveedor real) │
                      └────────────────────────────────┘
                                    │
                                    ▼
                      ┌────────────────────────────────┐
                      │ 3 · VERIFICACIÓN               │
                      │ el cerebro audita cada         │
                      │ resultado: lo conserva, lo     │
                      │ descarta o lo re-despacha con  │
                      │ la instrucción corregida       │
                      └────────────────────────────────┘
                                    │
                                    ▼
                      ┌────────────────────────────────┐
                      │ 4 · SÍNTESIS                   │
                      │ el cerebro integra SOLO el     │
                      │ material aprobado y entrega    │
                      │ UNA respuesta final coherente  │
                      └────────────────────────────────┘

1. Plan. El cerebro recibe la conversación y un menú con los modelos servibles hoy —cada uno con su costo relativo, para que «a igual capacidad, el más barato» sea una decisión informada— y responde un objeto JSON: {"mode":"single","model":"…"} o {"mode":"multi","subtasks":[{"model":"…","instruction":"…","depends_on":[…]}]}. El planificador está instruido para preferir single salvo que dividir aporte de verdad. Si la petición trae herramientas (function-calling del CLI), el planificador lo sabe y lo tiene en cuenta: el modo multi nunca rompe el bucle de herramientas. Hasta Studio AI el plan se resuelve siempre con un solo modelo; el reparto en subtareas se desbloquea desde Max Agent (ver el tope por plan).
2. Ejecución por olas. Las subtareas sin dependencias corren en paralelo; una subtarea con depends_on corre después y recibe las salidas de sus etapas previas como contexto (investigar → implementar → revisar). El transporte se resuelve por subtarea: cada modelo va a su proveedor upstream según las rutas del panel (multi-proveedor real). El tope de subtareas por turno lo fija tu plan.
3. Verificación. Antes de sintetizar, el cerebro audita cada resultado contra su instrucción: keep (útil), discard (fuera de tema o refusal — no entra a la síntesis) o redo (salvable — se re-despacha con una instrucción corregida, también en paralelo, hasta TITAN_MAX_ROUNDS rondas). Si el verificador descarta todo, TITAN cae a un single real: jamás sintetiza sobre nada.
4. Síntesis. El cerebro funde los resultados aprobados en una única respuesta: integra lo mejor de cada uno, descarta errores y contradicciones, y mantiene el idioma y el formato que pediste.

El tope de subtareas lo fija tu plan

El reparto en subtareas es una capacidad del plan, y el gateway la aplica en cada turno:

Solo ocurre cuando la petición va al modelo automático (titan o theus-router-auto) y una vez por turno tuyo, no en cada paso del bucle de herramientas. Si fijas un modelo concreto con /model, no hay orquestación. Cada subtarea consume créditos aparte — ver Multi-agente y visión y Cómo consume cuota.

TITAN Fleet: ejecución distribuida real

Cuando una tarea necesita programación, herramientas o un entorno de ejecución, TITAN no depende de procesos locales desconectados. El Gateway mantiene una cola central durable y coordina workers reales de Theus CLI, Chat y Enterprise mediante el protocolo theus.titan.fleet.v1.

• Queue central — el plan validado se convierte en jobs ordenados por prioridad, dependencias, disponibilidad y requisitos de capacidad.
• Leases exclusivos — cada job solo puede pertenecer a un worker a la vez. Un token de lease y una generación monotónica impiden que un worker antiguo publique después de perder la tarea.
• Heartbeats y capacidad — los workers anuncian salud y cupo; cada ejecución renueva su lease y puede informar progreso sin llenar indefinidamente el ledger.
• Entrega terminal durable — completar o fallar una tarea usa una clave idempotente y un outbox local: si se pierde el ACK, el mismo resultado se reproduce exactamente después de reiniciar.
• Recuperación automática — un lease vencido vuelve a la cola con fencing; los intentos agotados pasan a dead-letter y la cancelación cerca también los resultados tardíos.
• Aislamiento por propietario — el perfil productivo usa workers y queues del dueño de la corrida. Los claims globales de plataforma permanecen apagados por defecto hasta disponer de identidad tenant→organización verificable en todos los runtimes.

Gateway TITAN
   │
   ├── queue durable ── lease ──▶ Theus CLI
   ├── queue durable ── lease ──▶ Theus Chat
   └── queue durable ── lease ──▶ Theus Enterprise
                            │
             heartbeat + progreso + resultado idempotente

Fiabilidad ante caídas

Cuando un proveedor upstream falla (error de red o 5xx) o se pone lento, TITAN no te devuelve el error: reintenta la petición en el siguiente proveedor compatible por prioridad (failover), de forma transparente para ti. Factura por el proveedor que realmente respondió.

• También en streaming. El failover actúa antes de enviarte el primer byte: si el primario acepta la conexión pero muere sin producir nada, se prueba el siguiente candidato. Una vez que empieza a llegar la respuesta, el stream ya no se interrumpe por un cambio de proveedor. En la práctica, el chat deja de cortarse a mitad por una caída upstream.
• Circuit breaker por proveedor. Si un proveedor acumula fallos, TITAN lo «abre» y lo salta durante un tiempo (con reintentos espaciados) en vez de pagar su timeout una y otra vez; una sonda lo cierra de nuevo cuando se recupera. Con esto, la caída de un proveedor no ralentiza al resto.

Identidad Theus

La respuesta visible al usuario —tanto en modo single como en la síntesis multi— lleva antepuesta la identidad Theus como primera instrucción de sistema: el asistente se llama Theus, fue creado por Theus, y tiene prohibido revelar, mencionar o insinuar el modelo o proveedor que lo soporta por debajo. Para el usuario existe una sola voz. Los nombres reales de los modelos solo se muestran donde corresponde: en el catálogo y en la traza de TITAN del chat, que dice a qué modelo fue tu turno —en modo directo («Respondido con …») y en modo multi, una fila por subtarea—. Saber por qué modelo se te cobra no es revelar quién habla: la respuesta sigue siendo de Theus.

Cómo usarlo

Desde el CLI

El comando /model (alias /modelo) cambia el modelo de la sesión. Tras iniciar sesión con tu cuenta Theus, el proveedor oficial queda configurado con theus-router-auto (el alias de TITAN) como modelo por defecto, así que TITAN ya está activo sin hacer nada. Para pedirlo explícitamente:

/model titan

Por API

En el gateway compatible OpenAI, basta con pedir "model": "titan":

curl https://api.theus.pe/v1/chat/completions \
  -H "Authorization: Bearer $THEUS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "titan",
    "messages": [{"role": "user", "content": "Refactoriza este módulo y explica los cambios"}],
    "stream": true
  }'

El cerebro configurable

El «cerebro» de TITAN —el modelo que planifica y sintetiza— vive tras una interfaz simple: un endpoint compatible OpenAI (base_url + api_key + model). Se configura con esta prioridad, leída por request (un cambio aplica al instante, sin reiniciar el servicio):

1. Consola de administración (titan_config): proveedor del panel + modelo + max_subtasks. Es la vía recomendada; ver panel de administración.
2. Entorno (TITAN_*): configuración estática del operador.
3. Transporte por defecto del gateway: si no hay nada de lo anterior, el cerebro usa el upstream por defecto, de modo que titan siempre responde.

Ruteo aprendido (TITAN-U)

Además del planificador, TITAN incorpora un motor de ruteo aprendido (TITAN-U) que puntúa cada modelo del menú con señales de uso real —turnos completados, latencia, regeneraciones, ediciones, streams cortados— y decide el worker del carril agéntico single cuando su ventaja supera un margen de confianza; si hay empate, decide el planificador (y esa elección también entrena al motor). Viene encendido; desde el panel de administración se puede pasar a modo sombra (aprende sin decidir) o apagar al instante, sin reiniciar el servicio.

Consumo

El trabajo de TITAN entra en tu cuota de créditos ponderado por el modelo trabajador realmente usado, no como un uso plano del modelo titan: el planificador, cada subtarea y la síntesis se suman al total de tokens del turno, y ese total se pondera por el costo relativo (peso) del worker —entrada y salida a su peso respectivo— así que un modelo más pesado consume más créditos. En modo single, el plan y la respuesta se ponderan por el modelo que TITAN eligió. En modo multi, el total (plan + subtareas + síntesis) se pondera —de forma conservadora, para no sub-cobrar— por el worker más pesado del plan.