Manifest, la empresa detrás de un gateway LLM open source con 7.000 usuarios en la nube, deprecó su router de modelos después de cuatro meses de uso real. El router clasificaba cada solicitud en cuatro niveles de complejidad y la dirigía hacia el modelo más económico adecuado. Los problemas surgidos: la complejidad de una tarea no se deduce del prompt inicial, a menudo emerge solo después de las primeras llamadas a herramientas; la caché en los tokens iniciales ahorra más que el routing; y cambiar de modelo a mitad de sesión reduce la calidad del trabajo.

El mismo día, el proyecto qm recaudó 538 puntos en Hacker News. Es un harness multi-agente donde cada empleado tiene un workspace aislado, los agentes colaboran en canales Slack, y el modelo lo eliges tú. Pi, OpenCode, Codex, Claude Code: todos pilotan el mismo core, y el cambio de uno a otro es manual.

Para quien construye agentes, la pregunta práctica está cambiando. El debate sobre qué modelo usar cede lugar a cómo orquestar quién hace qué. Como contábamos el 20 de julio, la arquitectura importa más que el modelo individual: ahora lo confirma quien había construido el router y lo desmontó.

Si quieres explorar, el repo de qm es público en GitHub.

En detalle

Qué había antes.

Los LLM routers prometían resolver un problema real: los modelos potentes cuestan mucho, y usarlos para tareas simples es un desperdicio. La idea era clasificar cada solicitud por complejidad y enviarla al modelo más económico capaz de gestionarla. Manifest lanzó su router en marzo, clasificando en cuatro niveles: simple, standard, complex, reasoning. Después de cuatro meses con 7.000 usuarios, lo deprecó en junio y lo cerrará el 1° de septiembre.

Por qué el routing automático no funciona.

El primer problema es que el prompt inicial no contiene la información necesaria. «Evalúa los tests de este repo y mejóralos» puede ser una tarea de cinco minutos en un sitio HTML o una empresa titánica en el kernel de Linux. La complejidad emerge durante el trabajo, cuando el agente ya ha comenzado a llamar herramientas e investigar. Un router que decide antes de saber qué requiere la tarea parte con información insuficiente.

El segundo problema es económico, pero contraintuitivo. La caché en los tokens iniciales (system prompt, historial de conversación) cuesta entre el 75% y el 90% menos que un input sin caché. Si un router cambia de modelo en cada solicitud, pierde el beneficio de la caché. Si lo mantiene fijo para no perderlo, deja de hacer su trabajo. Manifest lo escribe explícitamente: el router termina por no hacer routing, irónicamente, para ahorrar.

El tercer punto trata sobre la calidad del trabajo. Cambiar de modelo a mitad de sesión rompe la consistencia del comportamiento. Manifest argumenta que los ingenieros deberían conocer sus modelos como un carpintero conoce sus herramientas: elegir basándose en la intención, no delegar la elección a un clasificador.

Qué hace qm diferente.

qm parte de una suposición opuesta: la orquestación es explícita. Cada empleado tiene un workspace aislado con su memoria, sus archivos, sus permisos, sus crons. Los agentes colaboran en canales Slack compartidos, pero cada uno con su scope. El modelo y el harness (Pi, OpenCode, Codex, Claude Code) los elige el usuario o el administrador, no un router.

La arquitectura tiene tres niveles: un core headless con API, identidad y scheduler; un agent loop que puede ejecutarse en harnesses diferentes; y una capa de presentación en Slack y web. Las skills son scope-owned y shareable, con promoción controlada por admin a toda la organización. El proyecto es abierto y tiene 3.000 estrellas en GitHub.

Limitaciones.

qm es un proyecto joven: 40 commits, 10 issues abiertos, 27 pull requests. La documentación está presente pero no es extensa, y no hay casos de uso documentados más allá del README. Manifest habla por 7.000 usuarios reales en cuatro meses, qm habla por un repo en ascenso en Hacker News. El patrón es interesante, pero la validación en producción aún está por demostrar.

Los dos señales, tomados en conjunto, dicen algo más sólido que los proyectos individuales. La pregunta sobre qué modelo usar tiene un horizonte limitado: los modelos cambian, los precios bajan, las diferencias se desvanecen. La pregunta sobre cómo orquestar se enriquece cada semana, con el patrón swarm de Cursor que converge en la misma dirección: planificador fuerte que decide, ejecutor económico que trabaja, modelo elegido por rol y no por solicitud.