Wil je OpenRouter gebruiken?

Ik beheer Olly, een AI-assistent die in iMessage leeft, en gebruik hiervoor open-source modellen via OpenRouter. Tot nu toe heeft Olly meer dan 18 miljoen berichten verwerkt, waarvan ongeveer een derde via open modellen via OpenRouter verloopt. Dat is voldoende volume om elk denkbaar edge-case scenario minstens één keer tegen te komen. Hier is een lijst met zaken die ik graag had geweten voordat ik begon.

Terminologie

Vooropgesteld even wat basisbegrippen:

  • Het model: dit zijn de gewichten (weights).
  • De provider: dit is de partij waarnaar OpenRouter je routeert. Zij hosten het model op hun GPU's, met hun eigen gekozen precisie en "proprietary" optimalisaties, inclusief hun eigen XML/tool-parsers. Dit betekent dat elke provider ook een eigen lijst met specifieke bugs heeft.

Wanneer je vraagt om deepseek/deepseek-v4-flash, krijg je een van de ongeveer 20 bedrijven waar je waarschijnlijk nog nooit van hebt gehoord. Op papier zijn ze hetzelfde model, maar in de praktijk verschillen ze sterk.

Hier zijn de valkuilen waar je op moet letten.

---

1. Hetzelfde model scoort verschillend in benchmarks

OpenRouter voert per provider benchmarks uit op hetzelfde model: GPQA Diamond (kennis) en TAU-Bench Airline (een tool-calling taak).

Kijk naar de gegevens van 7-september-2026 voor DeepSeek V4 Flash 0731, waarbij elke provider exact dezelfde gewichten gebruikt:

  • First-party DeepSeek: GPQA 90,2%, TAU 81,3%
  • NextBit: GPQA 89,9%, TAU 76,6%
  • Alibaba Cloud Int.: GPQA 89,4%, TAU 76,8%
  • SiliconFlow: GPQA 90,0%, TAU 75,4%
  • NovitaAI: GPQA 89,3%, TAU 76,0%
  • Ionstream: GPQA 87,2%, TAU 78,0%
  • GMICloud: GPQA 89,0%, TAU 75,8%
  • Reka AI: GPQA 89,1%, TAU 75,4%
  • Parasail: GPQA 89,0%, TAU 75,4%
  • Baidu Qianfan: GPQA 89,6%, TAU 74,8%
  • Cloudflare: GPQA 88,4%, TAU 75,0%
  • CoreWeave: GPQA 87,1%, TAU 76,0%
  • DeepInfra: GPQA 89,2%, TAU 73,9%
  • StreamLake: GPQA 87,8%, TAU 74,9%
  • Phala: GPQA 88,2%, TAU 74,5%
  • Inceptron: GPQA 87,9%, TAU 74,1%
  • AtlasCloud: GPQA 88,3%, TAU 73,6%
  • Together: GPQA 86,9%, TAU 75,0%
  • Decart: GPQA 87,9%, TAU 73,3%
  • Venice: GPQA 86,8%, TAU 74,2%
  • AkashML: GPQA 88,5%, TAU 72,5%
  • Morph: GPQA 85,8%, TAU 74,9%
  • Wafer: GPQA 84,1%, TAU 76,0%
  • Ambient: GPQA 86,4%, TAU 73,5%
  • Relace: GPQA 87,2%, TAU 71,7%
  • Io Net: GPQA 84,1%, TAU 74,5%
  • Makora: GPQA 86,9%, TAU 71,7%
  • Mancer: GPQA 85,5%, TAU 70,8%
  • Sail Research: GPQA 70,8%, TAU 75,2%
  • OpenInference: GPQA 70,5%, TAU 70,8%
  • Nebius: GPQA 75,6%, TAU 65,3%
  • DigitalOcean: GPQA 75,3%, TAU 58,4%

Terwijl First-party DeepSeek een TAU-score van 81% haalt, scoort DigitalOcean (met dezelfde gewichten) slechts 58%. De meeste hosts zitten 5 tot 7 punten onder de first-party score voor tool calling, en vier van hen storten volledig in wat betreft kennis. Voor een agent is de TAU-score bepalend, en een verschil van 20 punten is geen ruis. (In juli was het nog erger: Fireworks scoorde 46% op TAU, een gat van 30 punten).

Controleer het benchmarkbord voor de workload die het dichtst bij jouw gebruik ligt voordat je een provider vertrouwt. Controleer dit opnieuw wanneer je van model wisselt; dezelfde providers zagen er compleet anders uit bij GLM-5.3.

2. Visuele modellen kunnen "blinde" providers hebben

Vanwege vreemd, non-deterministisch gedrag bij beeldtaken, heb ik drie kleine afbeeldingen (een letter, een effen kleur, een woord op een achtergrond) door elke host van twee open vision-modellen gehaald.

Qwen3.5 122B (2026-07-31)

  • DeepInfra: ✗ Letter K gelezen als R/I; ✗ Rood genoemd als blauw; ✗ Woord "umbrella" beschreven als "funny, light blue".
  • Alibaba, AtlasCloud, Novita, SiliconFlow: ✓ Alle drie correct.

MiniMax M3 (2026-07-31)

  • Venice & Together: ✗ "No image provided" voor alle drie de afbeeldingen.
  • Overigen (incl. first-party): ✓ Letter en woord correct, maar ✗ overal de verkeerde kleurgetrouwheid.

Bij MiniMax was de kleurfout bij elke host aanwezig, dus dat ligt aan het model. Echter, DeepInfra's Qwen-endpoint maakte grove fouten terwijl vier andere hosts van dezelfde gewichten alles correct deden. Venice en Together "zagen" de MiniMax-afbeeldingen helemaal niet. Hoewel de modelpagina zegt dat beeldinput wordt ondersteund, doen twee providers dit niet, en erger nog: ze doen alsof alles in orde is (HTTP 200 OK).

3. De 'effort'-instelling is voor sommige providers optioneel

reasoning.effort wordt overal geaccepteerd, maar of het ook iets doet, hangt af van het model en de provider. Ik heb elke provider die DeepSeek V4 Flash 0731 serveert getest met dezelfde prompt op low, high en max.

De meeste providers respecteren de instelling, maar DigitalOcean, GMI-Cloud, Mancer en Venice doen dat niet. Houd de reasoning-tokens voor jouw effort-instelling per provider in de gaten.

4. Quantisatie-filters garanderen geen kwaliteit

OpenRouter stelt je in staat om providers te filteren op gedeclareerde precisie (quantisaties), zoals ["fp8"] tegenover fp4. De intuïtie is dat minder bits een dommer model betekenen.

Ik heb dit filter een maand lang op DeepSeek toegepast en de resultaten vergeleken met het benchmarkbord:

  • fp4 (5 providers): Scores variëren van 70,8% tot 89,1% (GPQA).
  • fp8 (11 providers): Scores variëren van 70,5% tot 90,0% (GPQA).
  • bf16 (1 provider): Score 85,8% (GPQA).
  • onbekend (10 providers): Bevat zowel de top-scorer (DeepSeek: 90,2%) als de slechtste (DigitalOcean: 75,3%).

De fp4-hosts landen midden in het fp8-veld. De drie slechtste GPQA-scores op DeepSeek waren verdeeld over één fp4-host, één fp8-host en één host die niets declareerde. De best scorende provider voor GLM (Wafer) declareert helemaal niets. Precisie is een slechte graadmeter voor kwaliteit. Bovendien verkleint een hard filter de pool waar OpenRouter op kan terugvallen als een provider uitvalt. Filter op basis van het benchmarkbord, niet op de bits.

5. De tool-aanroep staat in de tekst

Ideaal gezien genereert het model een aanroep in een bepaalde markup, zet de parser van de provider dit om in een gestructureerde tool-aanroep, en voert mijn code dit uit. Soms mist de parser echter, waardoor dit als antwoord verschijnt:

<useskills><parameters>{"skills":["search"]}</parameters></useskills>

De frequentie hiervan verschilt sterk per provider. Je zult dit vaak genoeg tegenkomen dat je zelf parsing aan de client-zijde moet implementeren. Er zijn twee gevallen die tegengestelde afhandelingen vereisen: wrapped tool calls en wrapped/half-wrapped responses. Voor voorbeelden van parsing voor DeepSeek/GLM kun je kijken naar github.com/0xmmo/190proof.

6. HTTP 200 OK, maar geen antwoord

Reasoning-modellen plaatsen soms alles in het reasoning-veld en leveren als content null aan, met finish_reason: "stop". Je krijgt dan bijvoorbeeld 345 completion tokens en een HTTP 200, maar er is niets om aan de gebruiker te tonen.

Een 200-status betekent dat het verzoek is afgehandeld, niet dat er een bruikbaar antwoord in zit. Geen content en geen tool-aanroep is een fout; gooi een exception en probeer het opnieuw.

7. Lege ('hollow') completions

Dit is gerelateerd aan het vorige punt, maar anders. Sommige endpoints retourneren een 200 met null content, null reasoning, en helemaal geen usage-object. In juli was dit bij StreamLake op DeepSeek (ongeveer 20% van mijn verkeer en 92% van mijn lege completions). Een maand later deed Together hetzelfde op het DeepSeek 0731 checkpoint.

8. Zelfde modellen, verschillende regels voor geschiedenis

DeepSeek in "thinking mode" genereert een reasoningcontent blok. In een agent-loop maakt het model vaak tool-calls met lege reasoning. Als je deze lege reasoning-geschiedenis terugstuurt naar OpenRouter en deze belandt bij bijvoorbeeld SiliconFlow, krijg je een 400-fout met code 20015: "The reasoningcontent in the thinking mode must be passed back to the API". Baidu, Alibaba en Cloudflare accepteren exact dezelfde geschiedenis zonder problemen.

Het "contract" is dus niet per model, maar per provider. En denk niet dat je de tool-geschiedenis kunt overslaan; het model zal de taak anders blijven herhalen. Dit is simpelweg nog een ding om af te handelen.

9. Test vanuit productie, niet vanaf je laptop

Dit geldt voor snelheid en latentie, maar ook als voorbeeld: Venice en Novita werkten perfect vanaf mijn Mac voor DeepSeek V4 Flash, maar gaven bijna elke probe vanuit mijn infrastructuur een 429-fout (Too Many Requests). Dezelfde key, dezelfde minuut. Mijn conclusie is dat ze rate-limiten op basis van IP.

Benchmark dus vanaf de plek waar je productie-omgeving draait, doe dit in kleine batches en gebruik meer samples dan je voor nodig houdt.

10. Waarom pin je niet gewoon één specifieke provider?

Op een gegeven moment had ik provider.order: [cloudflare, baidu, alibaba] met allow_fallbacks: false. Ik had dus drie betrouwbare providers vastgepind. Twee weken later rate-limitte Baidu alles (429s), bleek Cloudflare het model helemaal niet meer te serveren, en ging 100% van het verkeer naar Alibaba, die vervolgens ook begon met 429's.

Het nummer 1 model van OpenRouter (DeepSeek V4 Flash), gepind op de drie meest betrouwbare providers, lag eruit, en daarmee ook Olly.

Veel succes.

---

Referenties

  • openrouter.ai/deepseek/deepseek-v4-flash-0731 (per-provider board onder Performance)
  • openrouter.ai/z-ai/glm-5.3-flash (per-provider board onder Performance)
  • OpenRouter provider routing docs: order, ignore, quantizations, allow_fallbacks
  • OpenRouter endpoints API, declared quantization per endpoint
  • OpenRouter reasoning tokens docs, de effort setting
  • 190proof, Olly's open source AI SDK met uitgebreide error handling
  • Ruwe data achter de grafieken: effort probe (DeepSeek & GLM), DeepSeek board, GLM board, board gekoppeld aan gedeclareerde quantisatie, probe script.