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 elige el mejor modelo single para uso agéntico: el modo multi nunca rompe el bucle de herramientas.
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 es max_subtasks (1–6, por defecto 3).
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.

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.

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://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.

Consumo

Todo el trabajo de TITAN entra en tu cuota como un único uso del modelo titan: los tokens del plan, los de cada subtarea y los de la síntesis se suman al total del turno. En modo single, el costo del plan se añade al del modelo elegido.