Claude Code Router: Multi-modelrouter voor efficiënt coderen

Toen ik Claude Code intensief begon te gebruiken, merkte ik al snel twee dingen: de kwaliteit is uitstekend, en de rekening laat dat ook zien. Elke aanvraag, of het nu een docstring van drie regels is of een volledige architectuurrefactor, gaat tegen hetzelfde tarief naar dezelfde Anthropic-endpoint. 

Na verloop van tijd zorgt die afhankelijkheid van één leverancier niet alleen voor kostenstress; het creëert ook risico. Het betekent bovendien dat een rate limit op één model je hele workflow kan stilleggen.

Claude Code Router (CCR) pakt beide problemen direct aan. Het is een open-source proxy die je Claude Code-verzoeken onderschept vóór ze een provider bereiken, en vervolgens elk verzoek doorstuurt naar het backendmodel dat het meest logisch is voor die taak. 

In deze tutorial neem ik je mee door de volledige setup: de router installeren, routingpaden met meerdere providers configureren en het systeem hardenen voor dagelijks gebruik. Om mee te doen, haal je de API-sleutels op voor de providers die je wilt gebruiken (DeepSeek, Gemini, OpenRouter of een andere ondersteunde backend) en open je je terminal. Laten we beginnen.

Voor inspiratie over verschillende nieuwe LLM’s en hun sterke punten, bekijk onze gidsen over deze nieuwste modellen:

• GPT-5.4
• GPT-5.3 Instant
• Gemini 3.1
• Claude Sonnet 4.6
• Claude Opus 4.6
• Qwen3.5
• MiniMax M2.5

Wat is Claude Code Router?

Voordat we in de setup duiken, is het goed om te snappen wat CCR precies is en waarom het zo werkt. Als je nog niet met Claude Code hebt gewerkt, bekijk dan eerst onze Claude Code 2.1 Practical Guide.

Claude Code Router is een lokale proxy-gateway. Wanneer je hem start, bindt hij aan een poort op je machine (standaard 127.0.0.1:3456) en positioneert zich tussen je Claude Code-client en elke externe LLM-provider. Vanuit Claude Code gezien praat het gewoon met een lokaal endpoint. Onder de motorkap beslist CCR in real time waar het verzoek daadwerkelijk naartoe gaat.

Het kernprobleem dat het oplost, is afhankelijkheid van één leverancier. Als alles via één provider loopt, erf je al diens beperkingen: 

• Prijslagen
• Rate limits
• Maximale contextvensters 

CCR haalt dat weg door je routingregels te laten definiëren die modellen automatisch wisselen op basis van taaktype, aantal tokens of eigen logica die je schrijft. Een achtergrondscan van bestanden heeft niet hetzelfde model nodig als een Plan Mode-redeneersessie, en met CCR gebruikt die daar ook niet hetzelfde model voor.

Wat CCR onderscheidt van directe provider-API’s of cloud-aggregators is de plek waar het draait. 

Omdat de proxy lokaal draait, gaan je requestpayloads nooit door een derde-aggregatieservice voordat ze hun bestemming bereiken. Je krijgt ook fijnmazige controle over requesttransformatie, inclusief het aanpassen van headers, verwijderen van cachevelden en begrenzen van tokenlimieten, via een transformersysteem dat volledig op je eigen machine opereert. 

Voor mij is dat lokale executiemodel wat CCR echt praktisch maakt in plaats van alleen een slimme workaround: het resultaat is een setup die kostenefficiënter, robuuster en privacyvriendelijker is dan alles via één cloudprovider routen.

Claude Code Router-architectuur en vereisten

Met een helder beeld van wat CCR doet, kijken we nu naar hoe het onder de motorkap werkt en wat je nodig hebt vóór de installatie.

Kernconceptueel model

Als je de architectuur van CCR snapt, wordt de configuratie veel logischer, en het proxy-patroon valt snel op z’n plek zodra je het end-to-end ziet. 

Wanneer je CCR start, onderschept het alle uitgaande verzoeken vanuit je terminal voordat ze de standaard Anthropic-endpoint bereiken. Voor elk verzoek:

1. Inspecteert het het verzoek.
2. Past het je routingregels toe.
3. Vormt het de payload om naar het verwachte formaat van de doelprovider.
4. Stuurt het door. 

De response komt op dezelfde manier terug, terugvertaald naar het formaat dat Claude Code verwacht, zodat de client nooit merkt dat er iets is veranderd.

Het sleutelmechanisme binnen die onderschepping is taakgebaseerde routing. CCR classificeert binnenkomende verzoeken op type en koppelt ze aan het juiste model. Zo gedragen de belangrijkste taalcategorieën zich in de praktijk:

Elk taaktype krijgt het juiste gereedschap voor de klus, en geen daarvan vereist handmatige tussenkomst zodra het is geconfigureerd. Naar mijn ervaring levert de background-route de grootste onmiddellijke winst op: die stille scanverzoeken van bestanden gebeuren voortdurend tijdens een codersessie, en vóór CCR had ik geen idee hoeveel die ongemerkt optelden.

Essentiële vereisten

Controleer vóór de installatie van CCR het volgende:

• Node.js v18 of hoger als runtime-omgeving

• npm als je pakketmanager

• Claude Code globaal geïnstalleerd (npm install -g @anthropic-ai/claude-code)

• T minimaal één model-backend, ofwel een API-sleutel van een ondersteunde externe provider (DeepSeek, Gemini, OpenRouter, Groq, Volcengine, SiliconFlow en anderen), of een lokale Ollama-instantie met een model dat al is binnengehaald, als je externe providers helemaal wilt vermijden

Je hebt niet meteen bij elke provider een account nodig. Eén werkende backend is genoeg om deze tutorial te voltooien; je kunt later meer toevoegen.

Voor een vergelijking van Claude Code met een van de populairste alternatieven raad ik ons stuk over OpenClaw vs Claude Code aan.

Stapsgewijze tutorial: Claude Code Router instellen

Nu de concepten en vereisten duidelijk zijn, bouwen we de setup stap voor stap.

Installeer en start de router

Met de vereisten op orde kun je CCR globaal installeren met npm. Op Linux kun je echter een permissiefout krijgen bij globale installs omdat npm wil schrijven naar /usr/lib/node_modules, dat eigendom is van root. De aanbevolen oplossing is om de globale directory van npm te verplaatsen naar een map die al van jouw gebruiker is, in plaats van het commando met sudo uit te voeren:

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=~/.npm-global/bin:$PATHMogelijk gemaakt door

Om die PATH-wijziging blijvend te maken, voeg je de export-regel toe aan je ~/.bashrc of ~/.zshrc en laad je je shell opnieuw. Installeer daarna CCR:

npm install -g @musistudio/claude-code-routerMogelijk gemaakt door

Dit maakt de ccr-CLI overal beschikbaar in je shell. Start vervolgens de routerservice:

ccr startMogelijk gemaakt door

CCR bindt standaard aan http://127.0.0.1:3456. Zodra je in de opstartoutput ziet dat de service aan de poort is gebonden, is de proxy klaar om verzoeken te accepteren.

Stel een basisprovider in

Alle CCR-configuratie staat in ~/.claude-code-router/config.json. Voordat je meerdere providers aan elkaar knoopt, raad ik aan om te beginnen met één bekende, goed werkende provider om variabelen te isoleren en te bevestigen dat de basis werkt.

OpenRouter is hier een goed startpunt, en het is degene waar ik het eerst naar grijp bij het opzetten van CCR op een nieuwe machine. Je krijgt toegang tot tientallen modellen, inclusief meerdere gratis varianten, met één API-sleutel. Ideaal om de routinglaag werkend te krijgen voordat je je aan specifieke providers commit. Je kunt je aanmelden en een sleutel ophalen op OpenRouter.

Hier is een minimale configuratie met OpenRouter:

{
  "Providers": [
    {
      "name": "openrouter",
      "api_base_url": "https://openrouter.ai/api/v1/chat/completions",
      "api_key": "YOUR_OPENROUTER_API_KEY",
      "models": ["openai/gpt-oss-120b:free"],
      "transformer": {
        "use": ["openrouter"]
      }
    }
  ],
  "Router": {
    "default": "openrouter,openai/gpt-oss-120b:free"
  }
}Mogelijk gemaakt door

Een paar dingen om op te letten:

• api_base_url moet wijzen naar de volledige chat-completions-endpoint van de provider, niet alleen het basisedomein.

• transformer geeft aan welke ingebouwde payloadadapter CCR moet gebruiken, omdat verschillende providers verschillende requestformaten verwachten. De transformer handelt die vertaling geruisloos af.

• Router.default stelt het fallbackmodel in voor elk verzoek dat niet aan een specifiekere regel voldoet, met de syntaxis provider,model.

Gebruik voor de veiligheid liever geen hardcoded sleutels in het bestand. CCR ondersteunt interpolatie van omgevingsvariabelen: vervang YOUR_OPENROUTER_API_KEY door $OPENROUTER_API_KEY en exporteer de variabele in je shell. De interpolatie werkt recursief door de hele config, dus dit patroon schaalt netjes mee als je meer providers toevoegt.

Verbind Claude Code met de proxy

Met de config op z’n plek is het starten van Claude Code via de router één commando:

ccr codeMogelijk gemaakt door

Dat is alles. ccr code start de proxyservice en lanceert tegelijk Claude Code, met de omgeving automatisch vooraf geconfigureerd. Je hoeft ccr start niet eerst apart te draaien.

Om te verifiëren dat routing actief is, check je de map ~/.claude-code-router/logs/. Een bestand met de naam ccr-*.log bevestigt dat de proxy is gestart en verzoeken ontvangt. Je kunt live meekijken met:

tail -f ~/.claude-code-router/logs/$(ls -t ~/.claude-code-router/logs/ | head -1)Mogelijk gemaakt door

Claude Code Router-logs

Twee dingen zijn de moeite waard om te weten over verificatie. De Claude Code-header toont altijd hethuidige standaard Claude-model, ongeacht naar welk model CCR routeert, omdat het je Anthropic-accountsessie weerspiegelt, niet de actieve backend. Als je het model vraagt "welk model ben je?", zegt het ook “Claude Sonnet 4.6”, omdat de Claude Code-client het zo laat identificeren. Geen van beide is een betrouwbaar signaal.

Claude Code Router-sessie

De log is de enige bron van waarheid. Zoek naar het veld "model" in de response-items. Als je daar je geconfigureerde modelnaam ziet, bijvoorbeeld "model":"openai/gpt-oss-120b:free", dan werkt de routing.

Als je CCR persistent wilt maken zodat je het claude-commando direct kunt gebruiken zonder ccr code, voeg dan dit toe aan je ~/.bashrc or ~/.zshrc:

eval "$(ccr activate)"Mogelijk gemaakt door

Zorg er in dat geval wel voor dat ccr start eerst draait, want activate zet alleen omgevingsvariabelen en start de service zelf niet.

Implementeer routing met meerdere providers

Nu de basis is geverifieerd, breiden we de config uit om verschillende taaktypes naar verschillende providers te routen. Hier is een completere Router-configuratie:

{
  "Router": {
    "default": "deepseek,deepseek-chat",
    "background": "ollama,qwen2.5-coder:latest",
    "think": "deepseek,deepseek-reasoner",
    "longContext": "openrouter,google/gemini-2.5-pro-preview",
    "longContextThreshold": 60000,
    "webSearch": "gemini,gemini-2.5-flash"
  }
}Mogelijk gemaakt door

Elke sleutel koppelt een taalcategorie aan een "provider,model"-paar:

• De background-route handelt het scannen van bestanden en het verzamelen van context af. Deze kunnen veilig naar een lokaal Ollama-model, waardoor ze gratis blijven. Dit was de enkele wijziging die de grootste hap uit mijn maandelijkse API-rekening nam. 

• De think-route pakt Plan Mode en complexe redeneertaken op, waar een model als deepseek-reasoner zijn kosten terugverdient. 

• De longContext-route schakelt automatisch in zodra een verzoek meer dan longContextThreshold tokens heeft (standaard 60.000) en leidt door naar een model met hoge capaciteit zonder handmatig te hoeven wisselen. 

• Voor webSearch moet het model zelf native websearch ondersteunen. Als je via OpenRouter routeert, moet je ook de suffix :online aan de modelnaam toevoegen (bijvoorbeeld "anthropic/claude-3.5-sonnet:online").

Voor veerkracht tegen rate limits kun je met de custom router van CCR fallbacklogica in JavaScript definiëren. Maak een bestand op een pad naar keuze, verwijs ernaar in je config met "CUSTOM_ROUTER_PATH": "/path/to/custom-router.js", en exporteer vervolgens een async-functie die een "provider,model"-string retourneert of null om terug te vallen op de standaardregels:

module.exports = async function router(req, config) {
  // Primary logic here. Return null to fall back to config-defined rules.
  return null;
};Mogelijk gemaakt door

Hier implementeer je bijvoorbeeld retry-bij-rate-limit-logica door een 429-response te detecteren en automatisch te herrouteren naar een secundaire provider. Na elke configwijziging moet je de service herstarten om de wijziging door te voeren:

ccr restartMogelijk gemaakt door

Claude Code Router gebruiken en troubleshooten

Nu de routing werkt, verschuift de focus naar observeerbaarheid, veiligheid en eenvoudig debuggen als er iets misgaat.

Gebruik monitoren en budgetten afdwingen

CCR heeft twee afzonderlijke logsystemen die de moeite waard zijn om te kennen:

• Serverlogs dekken HTTP-verzoeken, API-calls en serverevents. Ze worden weggeschreven naar ~/.claude-code-router/logs/ in bestanden met de naam ccr-*.log. Dit is de log die je in de praktijk het meest gebruikt.

• Applicatielogs leggen routingbeslissingen vast en worden geschreven naar ~/.claude-code-router/claude-code-router.log, al is dit bestand mogelijk niet altijd aanwezig afhankelijk van je setup en logniveau.

Door de serverlog regelmatig te bekijken, krijg je een helder beeld van welke routes afgaan, welke modellen worden aangeroepen en of er providerfouten optreden. 

Voor realtime zichtbaarheid bevat CCR ook een statusline-tool (beschikbaar vanaf v1.0.40) die je via ccr ui kunt inschakelen. Eenmaal actief toont die de huidige routingstatus direct in je terminal terwijl Claude Code draait, zodat je in één oogopslag ziet welk model elk verzoek afhandelt.

Aan de budgetkant is de effectiefste vangrail je routingconfiguratie zelf. Door ervoor te zorgen dat background- en default-routes naar goedkopere of lokale modellen wijzen, voorkom je dat premium modellen voor laagwaardige taken worden ingezet. Reserveer think en longContext voor modellen die hun prijs rechtvaardigen, en houd de tokendrempel voor longContext zo hoog als jouw workflow toelaat. 

Naar mijn ervaring is deze discipline op configniveau betrouwbaarder dan reactieve monitoring, omdat het overspending voorkomt vóór het gebeurt in plaats van het achteraf te signaleren.

Beveilig credentials en toegangscontroles

Credentialbeheer verdient expliciete aandacht, zeker als je lijst met providers groeit. De regels die ik volg, zijn eenvoudig:

• Commit nooit ruwe API-sleutels naar config.json als dat bestand in versiebeheer staat. Gebruik altijd interpolatie van omgevingsvariabelen met de syntaxis "$PROVIDER_API_KEY", en exporteer sleutels vanuit je shellprofiel of een secretsmanager.

• Houd de proxy op localhost voor setups van individuele developers. Als je geen APIKEY in je config zet, dwingt CCR automatisch dat de server alleen bindt aan 127.0.0.1, zodat er geen externe toegang mogelijk is op gedeelde machines of netwerken.

• Zet een APIKEY voor teamdeployments als je de host moet openen naar 0.0.0.0. Elke client die met de router verbindt, moet die sleutel meesturen in de header Authorization: Bearer of x-api-key.

• Schakel logging uit of verminder die als je gevoelige code routeert. Logging staat standaard aan ("LOG": true). Zet "LOG": false om te voorkomen dat requestpayloads op schijf worden geschreven, of "LOG_LEVEL": "warn" om uitgebreide debugoutput te onderdrukken.

Een praktische manier om dit te doen is al je API-sleutels in je shellprofiel te houden en ze via de syntaxis $VAR_NAME in config.json te refereren. Zo bevat het configbestand zelf geen secrets en kan het veilig worden gedeeld of in versiebeheer.

Als je ooit twijfelt of een sleutel in logs lekt, check dan eerst je logniveau-instelling. Overschakelen naar "LOG_LEVEL": "warn" is de snelste manier om te verminderen wat er op schijf wordt geschreven zonder logging volledig uit te zetten.

Los veelvoorkomende routingfouten op

Als er iets stukgaat, bespaart een gelaagde diagnosevolgorde veel tijd. Begin bij de buitenste laag en werk naar binnen.

Stap 1: Controleer of de proxy draait 

Voer ccr code uit en kijk naar de bevestiging dat de service is gestart. Als de poort bezet is of de service niet startte, zie je connection refused-fouten in Claude Code. 

Bekijk de serverlogs in ~/.claude-code-router/logs/ voor details. De meeste opstartfouten komen neer op óf een poortconflict óf een foutieve config.json.

Stap 2: Controleer of de modelnamen overeenkomen

De meest voorkomende configfout is een mismatch tussen de modelnaam in Providers en die in Router. Beide moeten identiek zijn. 

Als ze verschillen, verstuurt CCR een verzoek zonder modelveld en zie je de fout Missing model in request body. Na het corrigeren van de config, run altijd ccr restart om opnieuw te laden.

Stap 3: Controleer instellingen aan providerzijde

Als de modelnaam klopt maar verzoeken nog steeds met een 404 falen, kijk dan naar je provideraccountinstellingen. OpenRouter heeft bijvoorbeeld een standaardprivacybeleid dat gratis modellen blokkeert om data naar derden te sturen. Je ziet dan een fout als No endpoints found matching your data policy. 

De oplossing is je OpenRouter-privacyinstellingen te bekijken en het gebruik van gratis modellen in te schakelen. Andere providers kunnen vergelijkbare toggles op accountniveau hebben die je moet checken bij onverwachte 4xx-fouten.

Stap 4: Controleer de transformerconfiguratie

Als verzoeken de provider bereiken maar responses misvormd zijn of tool-calls falen, ontbreekt meestal een transformer of is die onjuist. Kruis je provider met de lijst ingebouwde transformers en zorg dat de juiste in de "use"-array staat.

In de meeste gevallen isoleer je het probleem snel door deze vier stappen in volgorde te doorlopen. De serverlog legt zowel het uitgaande verzoek als de ruwe response van de provider vast, zodat je alles hebt om te begrijpen waar het misging.

Conclusie

Je hebt nu een werkende routinginfrastructuur met meerdere providers boven op Claude Code. Achtergrondtaken gaan naar snelle lokale modellen, redeneerintensief werk routeert naar gespecialiseerde modellen en long-contextverzoeken worden afgehandeld door providers met hoge capaciteit — allemaal automatisch op basis van regels die jij beheert. 

De directe voordelen zijn lagere API-kosten, geen single point of failure door rate limits en de flexibiliteit om providers te wisselen zonder je workflow aan te raken.

Om de setup efficiënt te houden, bekijk je periodiek je routinglogs. De serverlog laat zien welke routes het vaakst afgaan en of dure modellen worden getriggerd voor taken die een goedkoper alternatief aankan. Het aanpassen van longContextThreshold en fallbackregels op basis van echt gebruik is veel effectiever dan ze één keer instellen en het daarbij laten.

Als je werk eigen (proprietary) code bevat, raad ik sterk aan die verzoeken naar een lokaal LLM via Ollama te routen. Dat doe ik bij elk klantproject met niet-uitgebrachte code. Het toevoegen als provider kost minder dan een minuut, en je meest gevoelige queries verlaten je machine niet.

Voor wie zich verder wil ontwikkelen in AI-applicatieontwikkeling, raad ik van harte aan om je in te schrijven voor onze skill track AI Engineering with LangChain. De lesstof is AI-native, met toegang tot een persoonlijke tutor die je precies de skills aanleert om een echte pro te worden in het engineeren van AI-workflows.