Manifest, the company behind an open source LLM gateway with 7,000 cloud users, deprecated its model router after four months of real-world use. The router classified each request into four complexity levels and routed it toward the most cost-effective suitable model. The problems that emerged: a task’s complexity cannot be inferred from the initial prompt alone, it often only becomes clear after the first tool calls; caching initial tokens saves more than routing does; and switching models mid-session degrades work quality.

On the same day, the qm project collected 538 points on Hacker News. It’s a multi-agent harness where each employee has an isolated workspace, agents collaborate in Slack channels, and you choose the model. Pi, OpenCode, Codex, Claude Code: they all pilot the same core, and switching between them is manual.

For those building agents, the practical question is shifting. The debate over which model to use is giving way to how to orchestrate who does what. As we covered on July 20, architecture matters more than any single model: now it’s being confirmed by those who built the router and took it apart.

If you want to explore further, qm’s repo is public on GitHub.

In detail

What came before.

LLM routers promised to solve a real problem: powerful models cost a lot, and using them for simple tasks is wasteful. The idea was to classify each request by complexity and send it to the most cost-effective model capable of handling it. Manifest launched its router in March, classifying into four levels: simple, standard, complex, reasoning. After four months across 7,000 users, they deprecated it in June and will shut it down on September 1st.

Why automatic routing doesn’t hold up.

The first problem is that the initial prompt doesn’t contain the necessary information. “Review these tests and improve them” could be a five-minute task on an HTML site or a monumental undertaking on the Linux kernel. Complexity emerges during the work, when the agent has already started calling tools and doing research. A router that decides before knowing what the task requires starts with insufficient information.

The second problem is economic, but counterintuitive. Caching initial tokens (system prompt, conversation history) costs 75-90% less than uncached input. If a router changes models with each request, it loses the caching benefit. If it keeps it fixed to avoid losing it, it stops doing its job. Manifest states this explicitly: the router ends up not routing, ironically, to save money.

The third point concerns work quality. Switching models mid-session breaks behavioral consistency. Manifest argues that engineers should know their models like a carpenter knows their tools: choose based on intent, not delegate the choice to a classifier.

What qm does differently.

qm starts from the opposite assumption: orchestration is explicit. Each employee has an isolated workspace with their own memory, files, permissions, and crons. Agents collaborate in shared Slack channels, but each with its own scope. The model and harness (Pi, OpenCode, Codex, Claude Code) are chosen by the user or administrator, not by a router.

The architecture has three layers: a headless core with API, identity, and scheduler; an agent loop that can run on different harnesses; and a presentation layer on Slack and web. Skills are scope-owned and shareable, with admin-gated promotion across the organization. The project is open and has 3,000 stars on GitHub.

Limitations.

qm is a young project: 40 commits, 10 open issues, 27 pull requests. Documentation exists but isn’t extensive, and there are no documented use cases beyond the README. Manifest speaks for 7,000 real users in four months; qm speaks for a rising repo on Hacker News. The pattern is interesting, but production validation still needs to be demonstrated.

The two signals, taken together, say something more solid than either project alone. The question of which model to use has a limited horizon: models change, prices drop, differences narrow. The question of how to orchestrate enriches every week, with Cursor’s swarm pattern converging on the same direction: strong planner that decides, economical executor that works, model chosen by role not by request.