DeepSeek gaf zijn harnas weg. Zes harnassen naast elkaar gelegd

Op 13 augustus 2026 zette DeepSeek zijn agent-harnas open op GitHub. MIT, TypeScript, en binnen een paar dagen ruim 120.000 sterren.

Ik heb er een ochtend in doorgebracht. Niet om te kijken of ik overstap, want dat doe ik niet, maar omdat ik wilde weten wat een lab bouwt dat niet aan een abonnement vastzit.

Dit is wat ik vond, wat het je kost, en de vier dingen die ik er nu al uit overneem.

Waar het echt anders is

Alles is een plugin, en dat is architectuur en geen slogan.

Het draait op Cordis, een plugin-systeem waar modellen, gereedschap, skills, opslag, planning en de UI allemaal dezelfde soort component zijn. Bij Claude Code, het harnas dat ik dagelijks gebruik, is die scheiding er wel conceptueel. Maar je kunt er niet tussen komen.

Het praktische verschil zie je bij providers. In hun eigen ontwerpnotitie staat het zo: een provider-route is een declaratie, geen catalogus-opzoeking. Je zet er api, baseURL en een modellijst neer en de route bestaat.

Elke OpenAI-compatibele gateway, een self-hosted server, een model dat nieuwer is dan de meegeleverde catalogus.

Bij een gesloten harnas is de providerlijst wat de leverancier erin heeft gezet. Punt.

Het sessielogboek is een eersteklas artefact met een versienummer.

Dit is het deel waar ik het langst naar heb gekeken, omdat ik hetzelfde probleem heb.

Ze schrijven elke stap weg als JSONL, gecomprimeerd met Zstandard, waarbij elke duurzame batch een eigen frame met checksum krijgt. De frame-grenzen vallen samen met de commit-momenten, dus compressie kost je niet je herstelgedrag na een crash.

Belangrijker dan het formaat is wat eromheen zit. Het logboek draagt één monotoon versienummer, en de leesregels hangen af van de richting. Leest een oude runtime een nieuwer logboek, dan weigert hij, benoemt de richting ("geschreven door een nieuwer harnas, upgrade"), en wijst naar het ruwe bestand zodat je de tekst nog kunt zien.

Andersom converteert hij in het geheugen, en schrijft de conversie pas weg als je de sessie daadwerkelijk voortzet.

Dat laatste is een scherp besluit. Converteren bij het openen maakt van een lees-actie een schrijf-actie, en dan corrumpeert een fout in de converter je logboeken op het moment dat je ze bekijkt.

Er is een ignorable-markering per event, en de default is "verplicht".

Deze vond ik het mooist. Een lezer die een onbekend event-type tegenkomt weigert het logboek te interpreteren, tenzij dat event expliciet ignorable: true draagt.

Hun redenering staat er letterlijk bij: de markering vergeten leidt tot een sessie die onterecht wordt geweigerd, en dat is lastig. De default omdraaien leidt ertoe dat dezelfde vergissing stil een uitgeklede sessie hervat, en dat is een veiligheidsfout.

Dat is fail-closed denken op het niveau van één veld, en het is precies de afweging die ik in mijn eigen systeem te vaak de andere kant op heb zien vallen.

En dan de notities.

In .agents/notes/ stonden half augustus 685 beslissingsnotities, inmiddels ruim 1.200. Niet per kwartaal, maar bij elke beslissing waarvan de reden niet uit de code blijkt. Een uitgevoerde beslissing heeft steeds dezelfde vier koppen: Problem, Decision, Alternatives considered, Consequences.

Onderverdeeld naar feature, architecture, bug-fix, process, simplification en testing, met proposed/, implemented/, rejected/ en archived/ als levensfase.

Ik heb er 38 in Nygard-format. Zij hebben er ruim 1.200 omdat ze er ook een schrijven bij een bugfix of een vereenvoudiging, zolang de reden blijvend is.

Hun repo draagt bovendien zelf AGENTS.md, CLAUDE.md en een .claude/-map. Ze bouwen agent-gedreven, met een beslissingsspoor per stap.

Wat het betekent als je op een abonnement draait

Ik ging er van uit dat een open harnas je vrijheid geeft in wie je aanroept. Dat klopt, maar er zit een grens omheen die ik niet had zien aankomen.

De protocoltabel bevat bewust alleen routes die je volledig kunt beschrijven met een sleutel, een endpoint en headers. In hun eigen woorden zijn Bedrock, Vertex, Azure en Codex daarom afwezig in plaats van aangeboden als routes die niet kunnen authenticeren.

En in een bugfix van 13 augustus staat het onomwonden: "OAuth support is not attempted. It needs a persistent credential store, a login flow, and a surface to run it from." Providers die alleen OAuth doen werden uit de lijst gehouden.

Bij de release was er dus geen OAuth-pad. Dat is snel veranderd. Sinds eind augustus kun je bij een deel van de providers inloggen met OAuth, en sinds september ook met een DeepSeek-account.

Voor mij verandert dat weinig. Mijn werk draait op een Claude-abonnement, en Anthropic staat niet toe dat je dat abonnement via het harnas van een ander gebruikt. Door dit harnas zou elk Claude-model dus op een API-sleutel lopen, per token afgerekend.

Dat is concreet. Op een drukke dag meet ik in mijn eigen administratie een API-equivalent van ruim achthonderd dollar aan modelverbruik. Dat is nu een plat abonnementsbedrag. Het grootste deel zit in de orkestrerende laag, niet in de workers.

Model-agnostisch klinkt als winst. Voor wie op een abonnement draait is het vooral een ander bedrijfsmodel.

Twee dingen die er nog bij horen. Het is expliciet developer preview, met de aankondiging dat er brekende wijzigingen komen. En het is TypeScript op Node, wat voor mij een tweede stack betekent naast Python.

Het is geen open tegen gesloten

Toen ik hieraan begon had ik de vergelijking in mijn hoofd als open tegen gesloten. Dat klopt niet, en het is de moeite waard om recht te zetten voordat iemand anders het overneemt.

Er waren al open harnassen. Meer dan ik dacht.

Codex CLIvan OpenAI enGemini CLI van Google staan allebei onder Apache-2.0. Van de drie harnassen die ik dagelijks gebruik is alleen Claude Code gesloten.

opencode (anomalyco/opencode, voorheen sst/opencode) staat op bijna 210.000 sterren, MIT, TypeScript. Providers configureer je met API-sleutels of met een OAuth-login (ChatGPT, Copilot, Kimi), en er is een gecureerde modellijst, OpenCode Zen.

Het is de volwassenste open speler en het is er al een tijd.

kimi-cli (MoonshotAI/kimi-cli) is Apache-2.0, Python, ruim 11.000 sterren. Ik draaide hem zelf, versie 1.46.0. Op 23 september heeft Moonshot hem gearchiveerd, ten gunste van Kimi Code CLI (MIT, TypeScript).

Wat DeepSeek doet is dus niet "als eerste open". Het is een harnas met een plugin-architectuur onder de motorkap in plaats van een agent met configuratie eromheen. Dat is een ander soort claim, en de session-log-laag hierboven is het duidelijkste bewijs dat het meer is dan een marketingwoord.

Wat ik er zelf mee meemaakte hoort er wel bij: op 15 en 16 augustus haalde de kimi-lane in mijn opstelling nul geslaagde opdrachten op veertien pogingen. Dat is mijn configuratie op twee dagen en geen oordeel over het product, maar het is wel de reden dat hij vandaag niet mijn standaard is.

De vergelijking in één tabel

De derde regel is de belangrijkste. Een bug in de levering van een gesloten harnas kun je alleen omzeilen. Bij een open harnas is het een pull request in plaats van een leefregel. Hoe duur zo'n omweg wordt, beschreef ik in de vorige post.

Wat ik overneem

Ik stap niet over. Maar vier dingen neem ik mee, en twee ervan heb ik inmiddels gebouwd.

Een versienummer op mijn eigen logboek. Mijn kwitantieregister droeg regels uit meerdere schema-generaties, met negentien verschillende statuswaarden. Een versielezer die per richting weet wat hij moet doen, heb ik op 16 augustus gebouwd.

De ignorable-markering met verplicht als default. Ik repareerde in augustus een fout waarbij een classificatie stil tweeduizend geslaagde regels liet vallen omdat één statuswoord niet in een lijst stond. Precies de faalvorm waar deze markering tegen ontworpen is.

Een gegenereerde vocabulaire-lijst met een controle erop. Zij genereren de lijst van bekende event-types uit de code en hebben een CI-stap die controleert of hij nog klopt. Die heb ik op dezelfde dag gebouwd. Sindsdien weigert mijn logboek een statuswaarde die niet op de lijst staat.

Een beslissingsnotitie per wijziging, niet per architectuurbesluit. En dan vooral de kop die ik zelf het slechtst bedien: Alternatives considered, met per afgewezen optie de reden. In hun notities is dat consequent het interessantste deel, omdat je daar leest waarom de voor de hand liggende oplossing niet is gekozen.

Dat de categorie simplification bestaat, met een eigen archief, vind ik verder het beste detail van de hele repo. Verwijderen als eersteklas beslissing.

Wat ik ervan vind

Het interessante is niet dat er een open harnas bij is gekomen, want opencode was er al. Het interessante is dat inmiddels vier modelmakers hun harnas open hebben gezet: OpenAI, Google, Moonshot en DeepSeek. Anthropic is de uitzondering.

Als het harnas open is, verschuift de concurrentie naar het model en naar wat jij eromheen bouwt. Dat is voor mij goed nieuws, want ik heb negentien maanden in die laag gestopt en die investering wordt hierdoor beter overdraagbaar, niet minder waard.

En hun sessielogboek bevestigt iets dat ik al langer denk. Als een lab dat een harnas vanaf nul ontwerpt uitkomt op een append-only logboek met versionering en een fail-closed leesregel, dan is dat geen voorkeur van mij. Dan is het de vorm die het probleem afdwingt.

Mijn eigen harnas staat open source op GitHub, in Python, met dezelfde acht lagen die ik in de vorige post uit elkaar heb getrokken. Vergelijken is welkom, en ik hoor graag wat je in het jouwe anders hebt opgelost.

Twijfel je welk harnas bij jouw situatie past? Zo pak ik die keuze aan bij bedrijven die AI inzetten.