9Router: waarom je AI-agenten wél moet routeren, maar nooit zonder governance

14.200 sterren op GitHub, 2.100 forks, 650 commits in een paar maanden. De AI-wereld is in de ban van 9Router. "Unlimited FREE AI coding. Never stop coding." Na grondig in de code te hebben gedoken kan ik zeggen: 9Router is niet wat de hype suggereert, en precies dát maakt het interessant.

---

Wat 9Router wél is (en wat niet)

Ik zie 9Router te vaak gepositioneerd als "verbind al je AI-tools aan 40+ providers." De belofte: Claude Code, Codex, OpenCode, Cursor, Cline, allemaal via één lokaal endpoint op http://localhost:20128/v1. Met automatische fallback van subscription naar cheap naar free, zodat je nooit vastloopt.

Maar de echte waarde zit niet in het aantal providers. Die heeft LiteLLM ook. Drie dingen maken 9Router onderscheidend. Ten eerste de RTK Token Saver, die comprimeert tool-outputs zoals git diff, grep en logs voordat ze naar de LLM gaan, en bespaart daarmee 20 tot 40 procent op input tokens per request. Ten tweede OAuth auto-refresh, zodat je Claude Code- en Codex-subscriptions actief blijven zonder handmatig te her-authenticeren, geen "your session expired" mid-sprint. En ten derde free-tier aggregatie: Kiro AI (onbeperkt Claude 4.5), OpenCode Free, Vertex AI-credits, providers die je met LiteLLM niet zomaar aanspreekt.

Dit is geen enterprise gateway. Dit is een developer-first agent router.

---

De architectuurfout die ik iedereen zie maken

De natuurlijke reflex is: kan dit LiteLLM vervangen? Ik denk dat die vraag verkeerd is. Laat ik de posities naast elkaar zetten. LiteLLM blinkt uit in enterprise governance: virtuele keys, tenant-isolatie, budgetten, rate limits, chargeback, SSO, guardrails. Daar is 9Router beperkt. Omgekeerd pakt 9Router de developer-ervaring: tokenreductie voor CLI-output als kerntaak, OAuth auto-refresh, free-tier routing, dingen die bij LiteLLM niet primair zijn. Op fallback en provider-routing scoren ze allebei sterk. Voor gereguleerde workloads is LiteLLM de juiste keus, maar 9Router werkt prima als je het wikkelt in een governance-laag.

De conclusie is helder: 9Router is geen LiteLLM-killer. Het is een bovenlaag, een agent-router die vóór de governance-gateway zit.

---

De juiste architectuur: stapelen, niet kiezen

In mijn ideale opstelling zie ik drie lagen. Bovenin de developer-tools: Claude Code, Codex, OpenCode, Kilo, Cursor, Cline, Continue, Roo. Daaronder 9Router als agent-router met RTK Token Saver, OAuth auto-refresh, free-tier aggregatie en format translation. En dááronder LiteLLM als governance-gateway met virtuele keys, tenant-isolatie, budgetten, rate limits, spend tracking, chargeback, guardrails, logging hooks en admin dashboard. Op de bodem de approved providers: lokale Ollama en vLLM, Azure OpenAI, Anthropic, Gemini, NVIDIA endpoint, en waar toegestaan OpenRouter.

Dit geeft het beste van beide werelden. 9Router optimaliseert de developer experience. LiteLLM bewaakt de governance. En policy bepaalt welke route welke workload mag nemen.

---

Drie routes, drie risicoprofielen

Voor productie definieer ik drie gescheiden routes. Local-Only, voor gevoelige code, security analyses en interne repositories, routeert uitsluitend naar lokale modellen via Ollama, vLLM of llama.cpp, nooit via 9Router naar externe providers. Approved-Cloud, voor niet-gevoelige engineeringtaken, gaat via 9Router naar LiteLLM en dan naar goedgekeurde cloudproviders, met logging, budgetten en policies intact. Experimental-Free, voor disposable tests, benchmarks en demo's, mag 9Router direct laten schakelen tussen free-tier providers, maar nooit met secrets, credentials of klantdata.

---

RTK Token Saver: de stille motor die ik het meest waardeer

RTK is voor mij de meest ondergewaardeerde feature. Het detecteert tool-outputs en past lossless compressie toe voor de request naar de LLM gaat. De resultaten spreken voor zich: een git diff van 500 regels gaat van 47K naar 28K tokens, een besparing van 40 procent. Een grep door de codebase van 12K naar 8K tokens, 33 procent. Een ls -la van node_modules van 35K naar 20K tokens, 43 procent.

Het mechanisme is elegant: RTK peekt de eerste kilobyte van elke tool_result, herkent het formaat, en kiest het juiste compressiefilter. Faalt een filter? Dan wordt de originele output doorgestuurd, errors breken nooit je request. Voor een intensieve Claude Code-sessie met meer dan honderd tool-calls praat je over duizenden tokens per dag bespaard.

---

Waar 9Router níet thuishoort

Publieke sector, enterprise, gereguleerde omgevingen, daar hoort 9Router niet thuis. Niet uit onkunde, maar uit architectuur. De free-tier providers zijn Vietnamese en Aziatische services. Je prompts, code-snippets en tool-outputs verlaten het LAN. Dat is onacceptabel voor overheidsinstellingen met BIO2-classificatie, zorginstellingen onder NEN 7510, financiële instellingen onder AVG artikel 32, en elke organisatie met dataclassificatie boven "openbaar."

Daarnaast concentreert 9Router credentials, OAuth-tokens en logs in één lokale service zonder de governance-laag die LiteLLM biedt. Door een MCP-security-lens bekeken is 9Router een proxy met dezelfde kwetsbaarheden, token lifecycle, message integrity, audit trail, maar zonder protocol-level hardening.

---

Conclusie

9Router is geen enterprise-alternatief voor LiteLLM. Het is een developer-first agent-router die excelleert in tokenbesparing, provider-flexibiliteit en free-tier aggregatie. De juiste architectuur is niet kiezen, maar stapelen: 9Router als optimaliserende bovenlaag vóór LiteLLM als governance-gateway.

Voor persoonlijke R&D, Agentic OS-experimenten en coding-workflows is het een uitstekende toevoeging. Voor regulated workloads alleen met een stevige governance-wrapper eronder.

De les is breder dan 9Router alleen. In het AI-infrastructuurlandschap van 2026 is "kan X Y vervangen?" zelden de juiste vraag. De betere vraag is: op welke laag in de stack levert X de meeste waarde, en welke laag moet eronder om het veilig te houden?

---

Dit artikel is onderdeel van DjimIT's doorlopende analyse van AI-infrastructuur. Eerder besprak ik MCP-security volgens de NSA en CUSP's bevindingen over AI-forecasting.