Toen ik de broncode van opencode naast die van mijn eigen framework legde, verwachtte ik twee verschillende oplossingen te vinden. Wat ik vond was twee keer dezelfde oplossing, met één keuze anders.
Die ene keuze verklaart vervolgens alles.
Waar ze hetzelfde doen
Beide systemen doen de acht taken van een harnas: context samenstellen, gereedschap aanbieden, rechten afdwingen, de lus draaien, geheugen beheren, herstellen, vastleggen, en de levenscyclus bewaken.
En beide komen uit op hetzelfde instinct voor die zevende taak. opencode heeft een sessiemodel dat elke stap bewaart. Ik heb een append-only NDJSON-grootboek. DeepSeek, dat ik eerder naast elkaar legde, kwam er ook op uit.
Drie onafhankelijke ontwerpen, dezelfde conclusie: als je een model gereedschap geeft, moet je kunnen terugkijken wat het zag en deed. Dat is dus geen voorkeur van mij.
Ook de providerlaag lijkt op elkaar. Beide zijn model-agnostisch, beide hebben een adapterlaag, beide laten je per taak kiezen.
Waar het splitst, en dat is precies één regel code
In packages/opencode/src/auth/index.ts staat dit:
export const OAUTH_DUMMY_KEY = "opencode-oauth-dummy-key"
export class Oauth extends Schema.Class<Oauth>("OAuth")({
type: Schema.Literal("oauth"),
refresh: Schema.String,
access: Schema.String,opencode kent drie soorten credentials: een OAuth-token met refresh, een API-sleutel, en een well-known variant. Bij OAuth geeft het de SDK een dummy-sleutel en zet het de echte autorisatie zelf in de headers.
Dat is netjes gebouwd en het werkt. Het betekent wel dat opencode het protocol zelf implementeert en een token van jou bewaart en vernieuwt.
Mijn framework doet dat niet. Het start de CLI van de leverancier als subproces:
claude --model sonnet --permission-mode acceptEdits --strict-mcp-config
--mcp-config '{"mcpServers":{}}' --allowedTools ... --disallowedTools ...Ik raak de authenticatie nooit aan. De binary brengt zijn eigen auth mee. Ik bepaal alleen wat hij mag, waar hij draait, en wat er van hem terugkomt.
Dat is de hele splitsing. Eén keuze: praat je zelf met de API, of laat je dat over aan het gereedschap van de leverancier.
Waarom die keuze alles bepaalt
Toen ik dit voor mezelf op een rij zette, viel het kwartje. Alle andere verschillen zijn gevolgen.
Waarom mijn isolatie een git-worktree is. Als je een los proces start, heeft dat een eigen bestandssysteem nodig, anders schrijven twee opdrachten door elkaar heen. Een harnas dat in één proces draait heeft een scoping-primitief nodig, geen aparte map.
Waarom ik een phantom-guard heb. Ik kan niet zien wat er ín de worker gebeurde, alleen wat er op schijf achterbleef. Dus heb ik een controle die weigert als een opdracht succes meldt met een lege diff. Een harnas dat de lus zelf draait heeft dat niet nodig, want het zag elke stap.
Waarom ik de CLI's van alle drie de leveranciers kan aansturen. Codex CLI en Gemini CLI zijn open source, Claude Code niet. Als subproces draaien ze alle drie met hun eigen login. Een harnas dat zelf met de API praat, mag Claude niet op een abonnement bereiken.
Dat laatste is de reden dat DeepSeek's harnas geen OAuth ondersteunt. In hun eigen bugfix van 13 augustus staat het onomwonden: OAuth is niet geprobeerd, want het vraagt een persistente credential-store, een login-flow en een plek om die te draaien.
Drie harnassen, drie antwoorden. opencode bouwt het zelf. DeepSeek weigert het. Ik omzeil het door de binary van de leverancier te draaien.
Waarom ik voor de omweg koos
Niet omdat het eleganter is, want dat is het niet. Een subproces starten is trager en omslachtiger dan een functie aanroepen.
Ik koos het omdat ik geen token van mijzelf wil bewaren in code die ik zelf schrijf. Het moment dat mijn framework een access-token vasthoudt en vernieuwt, is het een client die zich voordoet als de officiële.
Voor Claude is dat geen open vraag. Anthropic verbiedt sinds februari 2026 expliciet dat abonnement-tokens in andere tools worden gebruikt, en opencode haalde de Claude-login op 19 februari weg.
Voor een hobbyproject is dat een aanvaardbaar risico. Voor het account waar mijn productiewerk op draait niet. Ik heb dat als harde regel vastgelegd: geen SDK-aanroep op mijn abonnement, alleen de CLI.
Dat is geen technisch oordeel over opencode. Voor ChatGPT en Copilot doet opencode nog steeds OAuth, voor Claude niet meer.
Lees ook: Best OpenClaw Alternative in 2026: The CLI Subprocess Pattern That Survived the OAuth Ban
Wat er beter is aan mijn kant
De auth-grens is er niet één die ik kan overschrijden. Ik hou geen token vast, dus ik kan hem ook niet verkeerd gebruiken. Dat is beter dan een regel die zegt dat je iets niet moet doen.
Ik kan het gereedschap van de leverancier zelf aansturen. Op 20 augustus draaide ik in één sessie Claude op abonnement, met DeepSeek en GLM als alternatieve routes, allemaal door dezelfde deur. Een harnas dat zelf met de API praat, mag de eerste niet op abonnement bereiken.
Isolatie op procesniveau. Een opdracht die ontspoort zit in een eigen worktree en kan de hoofdcheckout niet raken. Ik heb dat in augustus meer dan eens nodig gehad.
Governance is de kern, niet een logboek. Elke opdracht levert een kwitantie, elke merge vraagt een groene CI-run op precies die commit, open punten worden alleen gesloten met bestand-en-regel of commando-uitvoer als bewijs. Op 20 augustus ving die keten zes verkeerde conclusies van mijn eigen orkestrator.
Wat er slechter is, gemeten
Ik heb dit op 20 augustus gemeten, niet geschat.
Mijn grootboek had geen leesregel voor zijn versienummer.Er stonden 27.740 regels in metnegentien verschillende statuswaarden, waaronder failed naast failure voor hetzelfde ding, en 2217 regels zonder status. opencode en DeepSeek hebben een getypeerd sessieschema. Ik had een gegroeide gewoonte.
Sterker nog: ik rapporteerde dit aantal eerst als twaalf, omdat mijn telling een limiet van twaalf had en geen telling was. Dat is exact de klasse fout die een schema voorkomt.
Levering kon missen. Opdrachten vielen om doordat de instructie de terminal nooit bereikte. Een functie-aanroep kan niet "de levering missen". Een toetsaanslag naar een terminal wel. In september heb ik die terminal-route volledig verwijderd. Workers draaien nu alleen nog headless.
Rapportage kan wegvallen zonder dat het werk wegvalt. Een opdracht van die ochtend deed zijn werk, committeerde het, en leverde geen kwitantie. Het werk was er, de administratie niet. Dat is een gat dat een in-proces harnas per constructie niet heeft.
Ik zie de worker alleen achteraf. Sinds de headless-lane bewaar ik per opdracht de stroom van events, maar ik draai de lus niet zelf. Vandaar de phantom-guard, en die blijft een pleister.
Mijn testafdekking was minder groen dan hij leek. 137 van de 1053 testbestanden stonden uitgesloten van CI. Elke uitsluiting was gedocumenteerd met een open punt, dus niets gebeurde stiekem. Maar "CI groen" betekende bij mij dertien procent minder dan je zou denken.
Het is trager. Een proces starten plus een worktree aanmaken kost seconden. Een plugin mounten kost microseconden.
En het is één persoon. opencode heeft ruim 200.000 sterren en dagelijkse commits. Ik heb 38 architectuurbesluiten en mijzelf.
Wat ik ermee deed
Ik stap niet over, want de auth-grens is de reden dat dit ding bestaat en die geef ik niet op.
Maar drie van de zeven punten hierboven waren geen gevolg van mijn architectuur. Ze waren achterstallig onderhoud dat ik met de keuze had goedgepraat.
Dus heb ik ze aangepakt. Eerst een versielezer op het grootboek die per richting weet wat hij moet doen, en één gegenereerde lijst van geldige statuswaarden met een CI-controle erop.
Nieuwe onbekende waarden worden nu geweigerd bij het schrijven. Van de 137 uitgesloten testbestanden zijn er inmiddels 121 over, op ruim 1.250. Die schuld loopt nog.
De architectuur is een keuze. De rommel eromheen is dat niet.
Mijn framework staat open source op GitHub. Vergelijken is welkom, en als je in het jouwe een van deze zeven beter hebt opgelost hoor ik dat graag.
Wil je AI-agents inzetten zonder dat je account of je data op het spel staat? Zo pak ik dat aan bij bedrijven die AI inzetten.