Illustratie: Contextlengte Instellen bij Lokale LLM's

Werk uitbesteden aan gespecialiseerde codeermodellen via een proxy en taakroutering

Een coding-harness of agentraamwerk is in essentie een orchestrator: de uiteindelijke codekwaliteit en de bijbehorende rekening worden bepaald door het onderliggende taalmodel dat de taken uitvoert. In deze praktijkgids lees je hoe je orchestrators zoals Claude Code of vergelijkbare CLI-assistenten zwaar programmeerwerk laat uitbesteden aan kostenefficiënte modellen via een tussenliggende OpenAI-compatibele proxy, inclusief een sluitende audit-trail en realtime inzicht in je verbruik per taak.

Waarom een harness loskoppelen van het uitvoerende model?

Veel populaire coding-harnesses en assistenten worden geleverd als een hechte monoliet. De systeemprompt, gereedschapsdefinities, gespreksgeschiedenis, contextmanagement en API-verbindingen zitten verwerkt in één enkel binaire bestand of afgesloten pakket. Wil je een ander model inzetten of een externe toolchain aansluiten, dan moet je sleutelen in de broncode van software van derden. Zodra de onderliggende software bijgewerkt wordt, loop je het risico dat eigen aanpassingen verloren gaan of breken.

Door de interface en orkestratie functioneel te scheiden van de feitelijke modelaanroep, ontstaat een flexibele modulaire architectuur. In zo'n opzet blijft de orchestratielaag verantwoordelijk voor de interactie met de ontwikkelaar en de lokale context (zoals het doorzoeken van een git-repository of het inlezen van lokale bestanden), terwijl het rekenintensieve programmeerwerk via een flexibele adapter wordt doorgestuurd naar een model dat voor die specifieke taak het meest geschikt en voordelig is.

Deze ontkoppeling biedt drie grote voordelen voor indie developers en kleine teams:

Kostenbeheersing: Zware, herhalende taken (zoals het genereren van unit-tests, datamigratiescripts of omvangrijke boilerplate) hoeven niet altijd over het duurste frontier-model te lopen als een gespecialiseerd redeneermodel het werk voor een fractie van de prijs aankan.
Vermijden van vendor lock-in: Wanneer een nieuwe generatie modellen beschikbaar komt, pas je enkel de routering in je tussenlaag aan. Je ontwikkelomgeving, sneltoetsen en scripts blijven onaangeroerd.
Centrale registratie en auditing: Alle interacties vanuit verschillende assistenten passeren één punt, waardoor je exact weet welke taak hoeveel tokens heeft verbruikt en wat de kosten waren.

Het uitgangspunt: orkestreren en uitvoeren strikt scheiden

In een robuuste ontwikkelstraat vervult elk component een afgebakende rol. Een orchestrator (zoals een interactieve agent in je terminal) begrijpt de context van je codebase, maakt een actieplan en bepaalt welke bestanden moeten worden bewerkt. Het genereren van complexe logica, wiskundige algoritmes of refactoring delegeert de orchestrator vervolgens aan een gespecificeerde uitvoeringslaag.

De architectuur bestaat uit drie functionele lagen:

De orchestratielaag: De CLI-tool of plugin die je opdrachten vertaalt naar concrete deeltaken.
De delegatielaag (harness/wrapper): Een geautomatiseerd script of pluggable runtime die de taakbeschrijving inpakt en als gestructureerde prompt aanbiedt.
De routerings- en proxylaag: Een zelfgehoste, OpenAI-compatibele proxyserver (zoals LiteLLM of een vergelijkbare gateway) die de aanroep opvangt, van metagegevens voorziet, logs wegschrijft en doorstuurt naar de API-eindpunten van de gekozen modelprovider.

Het scheiden van deze verantwoordelijkheden sluit naadloos aan bij de principes van robuuste API-integraties, waarbij foutafhandeling, herhaalpogingen (retries) en logging gecentraliseerd worden in plaats van versnipperd over individuele CLI-tools.

De architectuur van de aanroepketen

Het datapad van een gedelegeerde programmeertaak verloopt sequentieel van de lokale werkplek naar de provider en weer terug:

Ontwikkelaar / CLI Orchestrator (bv. Claude Code, Kimi Code)
  │
  ▼
Delegeer-script / Lokale wrapper (taakdefinitie & contextbundeling)
  │
  ▼
Uitvoerings-harness (headless worker)
  │
  ▼
Zelfgehoste OpenAI-compatibele proxy (bv. LiteLLM op http://localhost:PORT/v1)
  ├─ Registreert: Traceer-ID (cid), taaktype, timestamp
  ├─ Berekent: In- en out-tokens, geschatte kosten
  │
  ▼
Externe Provider API (bv. DeepSeek, Qwen of OpenAI-compatibel eindpunt)
  │
  ▼
Respons keert via de proxy terug naar de lokale werkomgeving

Doordat de proxy een standaard OpenAI-interface nabootst, merkt de aanroepende harness niet dat er een inspectie- en loglaag tussen zit. De configuratie vereist slechts het instellen van een alternatieve basis-URL.

Stap voor stap: de opstelling inrichten

Stap 1: De proxy opzetten voor routering en logging

De kern van deze opzet is een lokale of zelfgehoste reverse proxy die API-aanroepen vertaalt en logt. Een bekend open-source voorbeeld hiervan is LiteLLM, maar je kunt hiervoor elke OpenAI-compatibele proxy of gateway inzetten. De proxy draait als een achtergrondproces of binnen een container.

Draai je de infrastructuur lokaal of op een thuisserver, bekijk dan de instructies voor lokale modellen in Docker draaien om containers netjes te isoleren en via een intern netwerk te benaderen.

Een typische configuratie van zo'n proxy koppelt een logisch model aan een specifiek provider-eindpunt en slaat de sessiegegevens lokaal op. Hieronder zie je een conceptueel configuratievoorbeeld (bijvoorbeeld proxy-config.yaml):

# proxy-config.yaml - Voorbeeldconfiguratie voor een lokale LLM-proxy
model_list:
  - model_name: code-worker-heavy
    litellm_params:
      model: deepseek/deepseek-chat
      api_base: https://api.deepseek.com/v1
      api_key: "os.environ/DEEPSEEK_API_KEY"
  - model_name: code-worker-fast
    litellm_params:
      model: openai/gpt-4o-mini
      api_base: https://api.openai.com/v1
      api_key: "os.environ/OPENAI_API_KEY"

general_settings:
  master_key: "sk-jouw-lokale-proxy-sleutel"
  database_url: "sqlite:////pad/naar/proxy_tracking.db"
  logging_format: "jsonl"
  log_file_path: "/pad/naar/logs/api_access.jsonl"

Start de proxy vervolgens op een poort naar keuze (in voorbeelden aangeduid als PORT):

# Starten van de proxy (voorbeeld)
litellm --config /pad/naar/proxy-config.yaml --port PORT

Stap 2: De uitvoerings-harness koppelen

Een harness is het raamwerk dat de codeeropdracht ontvangt, eventuele bestandsbomen analyseert en de daadwerkelijke prompt construeert. Configureer de harness zo dat deze communiceert met je lokale proxy in plaats van rechtstreeks met de cloudprovider.

In het configuratiebestand van je harness (vaak een YAML- of JSON-bestand in je thuismap) stel je de basis-URL en de API-sleutel in:

# settings.yaml van de harness
model_provider:
  name: "custom-proxy"
  baseURL: "http://localhost:PORT/v1"
  apiKey: "sk-jouw-lokale-proxy-sleutel"
  defaultModel: "code-worker-heavy"

Let op de URL-structuur: De meeste SDK's en harnesses voegen zelf automatisch /chat/completions toe aan de basis-URL. Geef daarom uitsluitend het basispad op tot en met /v1 (bijvoorbeeld http://localhost:PORT/v1 of https://jouw-proxy.example/v1). Sluit je per ongeluk af met /chat/completions, dan leidt dit tot 404-foutmeldingen.

Stap 3: Het delegatiescript en geautomatiseerde skills

Om vanuit een interactieve CLI-sessie soepel werk te delegeren, maak je een klein wrapper-script. Dit script start de harness in zogeheten 'headless' modus (zonder interactieve TUI), stuurt de opdracht door en registreert de uitkomst.

#!/usr/bin/env bash
# delegate-task.sh — Delegeer een afgebakende taak naar het gespecialiseerde model
set -euo pipefail

TASK_DESCRIPTION="$1"
LOG_DIR="/pad/naar/project/logs"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
CORRELATION_ID="task-$(openssl rand -hex 4)"

mkdir -p "$LOG_DIR"

echo "[INFO] Start taak ${CORRELATION_ID}: ${TASK_DESCRIPTION}"

# Aanroep van de headless harness met injectie van het correlatie-ID
HARNESS_TASK_ID="${CORRELATION_ID}" execute-harness --headless \
  --endpoint "http://localhost:PORT/v1" \
  --task "$TASK_DESCRIPTION" \
  > "${LOG_DIR}/${TIMESTAMP}_${CORRELATION_ID}.log" 2>&1

echo "[SUCCESS] Taak ${CORRELATION_ID} afgerond. Zie logboek voor details."

Om te zorgen dat orchestrators zoals Claude Code consistent van deze werkwijze gebruikmaken, definieer je een instructiebestand (een zogeheten skill of prompt-instructie). Plaats dit bestand in de configuratiemap van je orchestrator (bijvoorbeeld .claude/skills/delegatie/SKILL.md of .agent/skills/delegatie.md):

# Richtlijn voor taakdelegatie

Wanneer je een taak tegenkomt die voldoet aan de volgende criteria:
1. Het betreft een opzichzelfstaande module, refactor of testsuite met duidelijke specificaties.
2. De taak vereist substantiële codegeneratie (meer dan 100 regels code).
3. Er zijn geen multimodale invoerbestanden (zoals afbeeldingen of UI-mockups) vereist die het doelmodel niet ondersteunt.

Voer de taak NIET zelf direct uit, maar delegeer deze via het script:
`./scripts/delegate-task.sh "<volledige instructie inclusief context en bestandspaden>"`

Controleer na uitvoering het resultaat via het gegenereerde logbestand en valideer de gewijzigde bestanden.

Kostenbeheersing en het meten van verbruik

Het belangrijkste argument voor deze modulaire opzet is inzicht en besparing. Wanneer ontwikkelaars alle codeeropdrachten blindelings naar het standaard frontier-model van hun orchestrator sturen, lopen de kosten bij grote context-windows snel op. Door zwaar werk te routeren naar modellen die geoptimaliseerd zijn voor codeer- en redeneertaken, behoud je een hoge doorvoersnelheid tegen beheersbare kosten.

In het artikel over rate limits en kostenbeheer wordt dieper ingegaan op budgetbewaking en concurrency-limieten bij intensief API-gebruik.

Illustratief rekenvoorbeeld: Kosten per ontwikkeltaak

Om het financiële effect inzichtelijk te maken, vergelijken we een hypothetische refactoringstaak. Stel dat een complexe herstructurering van een backend-module 50.000 input-tokens aan context vereist (bestanden, types, eerdere tests) en 4.000 output-tokens aan nieuwe code genereert.

Modelcategorie (illustratief)	Aard van de taak	Context (Tokens)	Gegenereerd (Tokens)	Kostenfactor
Algemeen Frontier Model	Orkestratie & Planning	50.000 in	4.000 uit	100% (Referentie)
Gespecialiseerd Redeneermodel	Gedelegeerde Code-uitvoering	50.000 in	4.000 uit	~10% tot 20%
Lokaal Open-Weight Model	Boilerplate & Eenvoudige Tests	50.000 in	4.000 uit	Enkel stroom/hardware

In een actieve ontwikkelweek waarin tientallen van dergelijke deelopdrachten draaien, zorgt de routering ervoor dat de totale API-rekening aanzienlijk daalt, zonder dat je inboet op de kwaliteit van de softwarearchitectuur.

Het juiste model kiezen per programmeertaak

Niet elk model blinkt uit in dezelfde discipline. Het voordeel van een centrale proxy is dat je per taaktype dynamisch kunt schakelen. Raadpleeg het overzicht van gespecialiseerde modellen voor code om te bepalen welke modellen op dit moment toonaangevend zijn voor talen als TypeScript, Python, Rust of Go.

Daarnaast helpt de gids over het selecteren van het juiste model per taak bij het opstellen van routeringsregels op basis van redeneerkracht, contextgrootte en latentie. De benchmarks op modelkwaliteit per taak bieden houvast bij het objectief vergelijken van programmeerprestaties.

Type Programmeertaak	Aanbevolen Modelklasse	Waarom via de router?
Architectuurontwerp & Planningsfase	Algemeen High-Reasoning Model	Vereist breed abstractievermogen en sterke instructievolging.
Implementatie van algoritmes & Refactoring	Gespecialiseerd Codeermodel (bv. DeepSeek, Qwen)	Hoge dichtheid van correcte syntax tegen lage tokentarieven.
Unit tests schrijven & Type-definities	Snel, kleiner model of lokaal model	Repetitief werk met lage complexiteit waarbij snelheid telt.
Documentatie & Changelogs	Lichtgewicht taalmodel	Minimale redeneerkracht nodig, focus op natuurlijk taalgebruik.

Valkuilen uit de praktijk

Het opzetten van een meervoudige keten brengt een aantal praktische aandachtspunten met zich mee:

Modelnaam-validatie door clients: Sommige interactieve CLI-tools controleren vooraf of de opgegeven modelnaam voorkomt in hun hardgecodeerde lijst met ondersteunde modellen. Als je in je proxy een alias gebruikt (zoals code-worker-heavy), kan de client een foutmelding geven. Los dit op door de proxy de modelnaam te laten herschrijven of door in het /v1/models-eindpunt van de proxy de bekende namen terug te geven.
Contextbeheer en tokenverlies: Wanneer een taak wordt gedelegeerd naar een headless worker, moet alle noodzakelijke context (zoals type-definities en omgevingsvariabelen) expliciet in de prompt of meegeleverde bestanden zitten. Een losstaande worker heeft immers geen weet van de eerdere chatgeschiedenis van je interactieve sessie.
Foutafhandeling en time-outs: Complexe redeneertaken kunnen aanzienlijk langer duren voordat de eerste chunk met data binnenkomt (Time To First Token). Zorg ervoor dat de time-outs in je reverse proxy en in je HTTP-client ruim genoeg staan afgesteld (bijvoorbeeld minimaal 120 tot 300 seconden voor zware codeertaken).
Beeld- en multimodale data: Niet alle gespecialiseerde codeermodellen ondersteunen afbeeldingsinvoer (vision). Stuur taken met wireframes of screenshots altijd via een routeringsregel naar een multimodaal model om parsingfouten te voorkomen.

Logging, auditing en governance inrichten

Een belangrijk aspect van professioneel software ontwikkelen met AI is verantwoording. Door alle verzoeken via een centrale proxy te routeren, bouw je automatisch een JSONL-logbestand op. Dit bestand fungeert als het centrale logboek van je geautomatiseerde ontwikkelstraat.

Een representatieve regel uit zo'n logbestand ziet er als volgt uit:

{
  "timestamp": "2026-08-19T14:32:10Z",
  "correlation_id": "task-8f3a1b2c",
  "orchestrator": "claude-code",
  "routed_model": "deepseek-chat",
  "provider": "deepseek",
  "task_type": "unit-test-generation",
  "tokens": {
    "prompt_tokens": 14250,
    "completion_tokens": 1820,
    "total_tokens": 16070
  },
  "cost_estimate_usd": 0.0052,
  "status": "success",
  "latency_ms": 4210
}

Met behulp van eenvoudige command-line utilities zoals jq kun je direct analyses uitvoeren op je dagelijkse of wekelijkse verbruik:

# Bereken het totale aantal tokens dat vandaag via de proxy is verwerkt
jq -s 'map(.tokens.total_tokens) | add' /pad/naar/logs/api_access.jsonl

# Toon alle taken die langer dan 10 seconden duurden
jq 'select(.latency_ms > 10000) | {id: .correlation_id, model: .routed_model, duur: .latency_ms}' /pad/naar/logs/api_access.jsonl

Voor wie is deze aanpak waardevol?

Deze modulaire architectuur is met name geschikt voor:

Indie developers: Die intensief gebruikmaken van AI-assistenten en grip willen houden op hun maandelijkse API-uitgaven zonder in te leveren op het gebruiksgemak van moderne CLI-tools.
Kleine ontwikkelstudio's: Die moeten kunnen aantonen welke code met behulp van welk model is gegenereerd en die de kosten nauwkeurig willen doorbelasten per project of klant.
Teams met strikte privacy- en compliance-eisen: Die bepaalde gevoelige repositories uitsluitend via lokale modellen of specifieke private endpoints willen routeren, terwijl generieke taken naar publieke API's mogen.

Door de orkestratie los te koppelen van de daadwerkelijke modeluitvoering en daar een intelligente proxy tussen te plaatsen, transformeer je een verzameling losse AI-tools in een schaalbare, kostenbewuste en transparante ontwikkelomgeving.