Manifest, l’azienda dietro un LLM gateway open source con 7.000 utenti cloud, ha deprecato il suo router di modelli dopo quattro mesi di uso reale. Il router classificava ogni richiesta in quattro livelli di complessità e smistava verso il modello più economico adeguato. I problemi emersi: la complessità di un compito non si deduce dal prompt iniziale, spesso emerge solo dopo le prime chiamate agli strumenti; la cache sui token iniziali risparmia più del routing; e cambiare modello a metà sessione abbassa la qualità del lavoro.

Lo stesso giorno, il progetto qm ha raccolto 538 punti su Hacker News. È un harness multi-agente dove ogni dipendente ha un workspace isolato, gli agenti collaborano in canali Slack, e il modello lo scegli tu. Pi, OpenCode, Codex, Claude Code: tutti pilotano lo stesso core, e il passaggio fra l’uno e l’altro è manuale.

Per chi costruisce agenti, la domanda pratica sta cambiando. Il dibattito su quale modello usare lascia spazio a come orchestrare chi fa cosa. Come raccontavamo il 20 luglio, l’architettura conta più del modello singolo: adesso a confermarlo è chi aveva costruito il router e lo ha smontato.

Se vuoi guardarti intorno, il repo di qm è pubblico su GitHub.

Nel dettaglio

Cosa c’era prima.

I LLM router promettevano di risolvere un problema reale: i modelli potenti costano molto, e usarli per compiti semplici è uno spreco. L’idea era classificare ogni richiesta per complessità e mandarla al modello più economico in grado di gestirla. Manifest ha lanciato il suo router a marzo, classificando in quattro livelli: simple, standard, complex, reasoning. Dopo quattro mesi su 7.000 utenti, lo hanno deprecato a giugno e lo chiuderanno il 1° settembre.

Perché il routing automatico non regge.

Il primo problema è che il prompt iniziale non contiene l’informazione necessaria. «Valuta i test di questo repo e migliorali» può essere un compito da cinque minuti su un sito HTML o un’impresa titanica sul kernel Linux. La complessità emerge durante il lavoro, quando l’agente ha già iniziato a chiamare strumenti e fare ricerche. Un router che decide prima di sapere cosa il compito richiede parte con un’informazione insufficiente.

Il secondo problema è economico, ma controintuitivo. La cache sui token iniziali (system prompt, storia della conversazione) costa fra il 75% e il 90% in meno di un input non cachato. Se un router cambia modello a ogni richiesta, perde il beneficio della cache. Se lo tiene fisso per non perderlo, smette di fare il suo lavoro. Manifest lo scrive esplicitamente: il router finisce per non routeare, ironicamente, per risparmiare.

Il terzo punto è sulla qualità del lavoro. Cambiare modello a metà sessione rompe la consistenza del comportamento. Manifest argomenta che gli ingegneri dovrebbero conoscere i loro modelli come un falegname conosce i suoi attrezzi: scegliere in base all’intento, non delegare la scelta a un classificatore.

Cosa fa qm di diverso.

qm parte da un’assunzione opposta: l’orchestrazione è esplicita. Ogni dipendente ha un workspace isolato con la sua memoria, i suoi file, i suoi permessi, i suoi crons. Gli agenti collaborano in canali Slack condivisi, ma ognuno con il suo scope. Il modello e l’harness (Pi, OpenCode, Codex, Claude Code) li sceglie l’utente o l’amministratore, non un router.

L’architettura ha tre livelli: un core headless con API, identità e scheduler; un agent loop che può girare su harness diversi; e un layer di presentazione su Slack e web. Le skill sono scope-owned e shareable, con promozione admin-gated a tutta l’organizzazione. Il progetto è aperto e ha 3.000 star su GitHub.

Limiti.

qm è un progetto giovane: 40 commit, 10 issue aperte, 27 pull request. La documentazione è presente ma non estesa, e non ci sono casi d’uso documentati oltre il README. Manifest parla per 7.000 utenti reali in quattro mesi, qm parla per una repo in ascesa su Hacker News. Il pattern è interessante, ma la validazione in produzione è ancora da dimostrare.

I due segnali, presi insieme, dicono qualcosa di più solido dei singoli progetti. La domanda su quale modello usare ha un orizzonte limitato: i modelli cambiano, i prezzi scendono, le differenze si assottigliano. La domanda su come orchestrare si arricchisce ogni settimana, con il pattern swarm di Cursor che converge sulla stessa direzione: pianificatore forte che decide, esecutore economico che lavora, modello scelto per ruolo e non per richiesta.