A router that knows
when to say no.

Type your own request. Watch it decide.

Live against the hosted router, business-only lanes (IT helpdesk, general tools, chat). Off-topic input should abstain, not guess.

The same POST /v1/route your agents would call. A few tries per visitor; grab a wallet for more.

One call. Three typed answers.

A single request returns a validated route, a calibrated confidence, and a tool-fill proposal — or a clean escalate if it doesn't know.

$ curl -s localhost:8080/assess -d '{"req":"hi team, this is the third time my VPN drops today"}'

{
  "route":       "create_ticket",
  "confidence":  0.87,
  "noul":        0.91   // "novel / unhandled / loss" — abstention dial,
  "candidate":   "open_ticket",
  "score":       0.83,
  "action":      "tool_fill",
  "fill": { "subject": "VPN drops repeatedly", "priority": "high" }
}

Built for SME workflows, not datacenters.

The requests that eat SME time are decisions, not essays — sort the inbox, dispatch the ticket, route the quote. That's exactly what a router is for.

Mixture of experts — one trunk, many brains.

The frozen 7M trunk is the shared brain. Domain knowledge lives in ~7KB heads you can ship, swap, and audit like config files. A gate head picks the expert; the expert picks the route.

Each head declares its own feature tap — last-token, mean@-3, max@-3 — so a single instance serves the pooling recipe that actually won each domain's eval. Known-domain clients can also pin their expert and skip the gate entirely.

                 ┌─────────────────────────────────────┐
  request  ──▶  │  mtlm-router trunk — frozen 7M model  │
  tokens         └──────────────┬──────────────────────┘
                    prefill hidden state (1 × d_model)
            ┌────────────┐ ┌─────────────┐
            │ gate.head  │ │ expert.head │   ← per-domain, ~7KB
            │ pick a domain │ │ pick a route   │
            └────┬───────┘ └─────┬───────┘
       it_helpdesk ───┘        reset_password ───┘  + calibrated conf

Numbers — held-out, calibrated, honest.

Held-out sets pass candidates that real canary traffic rejects — both published here. The gap between lab accuracy and live aggregate is what per-domain constraints and the flywheel are for.

How the conformal abstention gate works → blog.intrane.fr

It trains on its own traffic.

Every /v1/route decision is logged. A daily flywheel harvests the log, files uncertain rows into a persistent review queue, merges judged verdicts into the train-only corpus, and dedupes before retraining. The gate thickens from real requests — never from its own confident predictions.

decisions.jsonl ──▶ harvest ──▶ review queue ──▶ judge ──▶ train corpus ──▶ new head
                 (replay domain-less rows · seen = resolved only · dedupe at merge)

Watch a real lane decide.

The municipal lane runs the flagship head — trained on a real production export, served live on the public demo (pin expert:"mairie"): dépôt illicite. micro onde → depot_illicite @ 1.00, demande de passeport → escalate → delegate. ~190ms per decision on CPU.

» "Dépôt illicite. micro onde"          [router] depot_illicite @ 1.00 (186ms)
» "1ere dotation. bac pour le verre"    [router] dotation_bacs  @ 1.00 (174ms)
» "demande de passeport"                [router] escalate       @ 0.42 — delegates, not guesses

The alternatives, honestly compared.

From zero to routed in days.

Honest limits.

Free route audit on your own requests.

Leave your email. We reply with a short questionnaire (your routes, 30 example requests); 48 hours later you get a report: accuracy on your vocabulary, calibration, what would escalate. No commitment.

Ready-made lanes. Certified numbers.

A .lanepack is a decision lane for one domain — head weights plus its leak-free eval, calibration point and license, all in one ~500KB tarball. Drop it in the appliance and that request type is handled. Every pack shows its numbers; demo packs are marked as demos.

Catalog + install: github.com/javimosch/mtlm-heads — a lane fitted on your routes is the custom-head offer below.

Three ways to run it. One of them is free.

Self-host the appliance for nothing, pay per decision on the hosted API, or have us train the head for your routes. Same trunk, same typed answers, same honest numbers.

Prices in EUR excl. VAT. Hosted API decisions are served from EU infrastructure; hosted traffic is logged for calibration only and never used to train other customers' heads.

One tarball. Runs anywhere.

The whole stack — server binary, tokenizer, int8 model, heads — ships in one fully self-contained ~7.8MB tarball. Untar, run ./start.sh, done. No anvil install, no pip, no model download, no license server — nothing leaves the machine.

$ tar xzf mtlm-router-v0.3.0-linux-amd64.tar.gz && cd mtlm-router-v0.3.0-linux-amd64
$ ./start.sh &
$ curl localhost:8097/v1/route -d '{"state":"Dépôt illicite. micro onde","expert":"mairie"}'
{"route":"depot_illicite","domain":"mairie","action":"tool_call","confidence":0.999,...}

Agent-operable, not just agent-readable.

The tarball ships a mtlm-router CLI built for AI agents: JSON-only stdout, semantic exit codes, an embedded guide, a health-polled daemon lifecycle, and content-hash self-update. The server self-describes — /guide, /llms.txt, /v1/whoami, /v1/feedback. 28/28 on cli-spec-conformance — checked, not claimed.

$ ./mtlm-router daemon start        # loopback, polls /_health — never a fixed sleep
{"daemon":"up","port":8097,"url":"http://127.0.0.1:8097"}
$ ./mtlm-router guide               # embedded operator manual (JSON)
$ ./mtlm-router update --check      # content-hash self-update → .bak rollback
$ ./mtlm-router daemon stop         # clean POST /_shutdown