Claude Routines + Opus 4.7: Mijn Eerste Build-logboek

Claude Routines + Opus 4.7: Mijn Eerste Build-logboek

Het was 6:47 uur op een vrijdag en mijn telefoon lag met het scherm naar beneden op het nachtkastje. In de keuken was iets — iets wat ik zelf niet had gestart, op een machine die niet van mij was — bezig met het uitlezen van mijn laatste 24 uur aan e-mails, die te sorteren in drie stapels, conceptantwoorden te schrijven op de vijf die er eentje nodig hadden, en een Slack-samenvatting te droppen in #morning-brief met de onderwerpregels en een urgentiescore op één regel per stuk.

Toen ik de keuken binnenliep voor koffie, stond de samenvatting al 31 minuten in Slack. Twee conceptantwoorden stonden al in mijn Gmail-conceptenmap, en hadden elk ongeveer negen woorden aanpassing nodig voordat ik op verzenden kon drukken. Een derde concept werd door de routine zelf gemarkeerd als "behoeft jouw context — niet versturen". De laptop op mijn bureau was sinds 23:14 uur de vorige avond dichtgeklapt gebleven.

Dit is de eerste week waarin ik bovenstaande zin werkelijk kan zeggen — “iets draaide terwijl ik sliep, op een machine die niet van mij was” — over een workflow die ik zelf bouwde, in minder dan drie minuten, zonder een regel cron-syntaxis te hoeven schrijven of een EC2-box op te zetten. Dat is wat er verscheen toen Anthropic op 14 april 2026 Claude Routines uitbracht, twee dagen voordat op 16 april Opus 4.7 werd gelanceerd. Die twee releases zijn onlosmakelijk met elkaar verbonden. Routines zijn de container. Opus 4.7 is wat het werk ín de container daadwerkelijk bruikbaar — in plaats van louter gepland — maakt.

Inmiddels heb ik zes Routines gedraaid, verspreid over zeven dagen. Twee heb ik in productie gezet. Twee heb ik volledig opnieuw opgebouwd nadat ze faalden op manieren waarvoor de documentatie niet waarschuwt. Eentje heb ik helemaal verwijderd. En eentje draait nu, op de achtergrond, terwijl ik deze zin schrijf.

Wat volgt is geen herhaling van het persbericht. For the official word, kun je prima de post van Anthropic lezen. Wat volgt, is hoe het werkelijk aanvoelt om in die eerste week met Claude Routines op Opus 4.7 te bouwen — de patronen die werken, de faalmodi waar ik tegenaan liep, de security-houding die je móét bepalen voordat je een geplande job toegang tot je inbox geeft, en de specifieke workflows die ik zelf als volgende zou oppakken als ik weer een vrij weekend had.

Laat ik beginnen met wat Routines eigenlijk zijn, omdat de helft van de coverage die ik deze week heb gelezen één detail stelselmatig verkeerd heeft.

Wat Routines Eigenlijk Zijn (En Wat Ze Niet Zijn)

Een Routine is een opgeslagen Claude Code-configuratie — een prompt, een set repositories, een set connectors en een trigger — die draait op de infrastructuur van Anthropic zelf, volgens een planning, een API-call, of een GitHub-webhook-gebeurtenis. Wanneer de trigger wordt geactiveerd, start Anthropic een nieuwe Claude Code-sessie op, voert de opgeslagen prompt in, geeft toegang tot de connectors die jij hebt goedgekeurd, laat het geheel afronden, en sluit de sessie daarna weer af. Je lokale machine is er niet bij betrokken. Je laptop kan dicht blijven. Je kunt zelfs in vliegtuigmodus in een vliegtuig zitten.

Juist dat laatste punt is wat mijn kijk op deze technologie veranderd heeft. Elke geplande AI-werkstroom die ik voorheen bouwde — elke cron-job rondom een Python-script dat een API aanroept, elke GitHub Action die Claude via de SDK aanspreekt — was afhankelijk van een apparaat dat ik zelf bezit, dat aan staat, online is en gezond draait. Met Routines is die afhankelijkheid voor het eerst volledig verdwenen.

Wat Routines níét zijn: het is geen vervanger voor n8n. Het is geen Zapier-killer. Het is geen visuele workflow-bouwer waar je blokken sleept en pijlen verbindt. Het is een opgeslagen prompt, triggers, machtigingen voor hulpmiddelen, en een plek waar Claude zo lang mag draaien als de klus vereist. De visuele interface is het Routines-paneel van de desktopapp. De werkelijke intelligentie is datgene wat Claude beslist te doen wanneer de trigger afgaat en jouw prompt wordt gelezen.

Dat onderscheid is van belang, want de hele ontwerpfilosofie is anders. Een Zapier-flow faalt meteen als er iets wijzigt aan de structuur van een API-respons. Een Routine leest in theorie wél de nieuwe structuur en past zich aan. Of dat in de praktijk altijd gebeurt, is waar Opus 4.7 het verschil zou kunnen maken.

Triggers, Tools en de Drie Cijfers Die de Functionaliteit Bepalen

Routines ondersteunen exact drie triggerelementen, die elk scherpe randen hebben waar je goed naar moet kijken voordat je een workflow hieraan toewijst.

Schedule triggers (schema-triggers) draaien op een cron-achtige frequentie met één harde beperking: het minimale interval is één uur. Je kiest in de UI uit vier presets — elk uur, dagelijks, werkdagen, wekelijks — en als je een aangepast schema wilt zoals “elke twee uur” of “de eerste maandag van elke maand”, selecteer je de preset die het dichtst in de buurt komt en gebruik je daarna /schedule update via de CLI om een specifieke cron-expressie te zetten. Meer dan één keer per uur toestaan is uitgesloten. Dus als je hoopte elke vijf minuten een Routine als polling job te draaien, gaat dat met Routines vandaag niet lukken.

Webhook triggers worden geactiveerd als je Routine een API-call ontvangt met de juiste key. Dit is waar ik telkens op terugkom. Alles wat een POST naar een URL kan sturen, kan een Routine triggeren — je CRM, je projectboard, je contactformulier, of je eigen scripts. Het is de generieke escape. Als het schema niet uitkomt, kun je praktisch elk cadansprobleem oplossen door vanuit een ander systeem een webhook op je gewenste schema te laten POSTen.

GitHub triggers reageren op GitHub-webhook-gebeurtenissen — pushes, PR-openingen, comments, releases — tegen repositories die je via de Claude GitHub App koppelt. In de research preview zijn deze events onderhevig aan limieten per routine en per account, gemeten per uur. Push je tien keer in vijf minuten? Dan worden niet alle tien de pushes verwerkt; sommige worden genegeerd tot het volgende uur aanbreekt. Belangrijke kennis voor als je een workflow bouwt zoals “Claude reviewt elke PR” en je je afvraagt waarom er maar de helft doorheen komt.

Er zijn drie cijfers die bepalen hoeveel je uit Routines haalt, afhankelijk van je abonnement. Pro-accounts kunnen tot 5 Routine-uitvoeringen per dag doen. Max-accounts hebben er 15. Team en Enterprise accounts tot 25. Meer kan op aanvraag, opt-in voor bijkomende kosten. Dit zijn limieten per dag, niet per Routine; dus een Pro-gebruiker met vijf verschillende Routines die elk één keer per dag draaien, zit op de limiet. Een Pro-gebruiker met één Routine die ieder uur afgaat, raakt de limiet al voor 11 uur 's ochtends.

Dit laatste rekenwerk is waar de meeste mensen voor het eerst de mist in gaan als ze een Routine uit willen schalen voorbij het demoniveau. Draai je op Pro en wil je ieder uur een Routine uitvoeren, dan kom je dus uit op 5 runs per dag; een echte hourly job kan op Pro alleen als je overage billing inschakelt. Dit is een beperking tijdens de research preview en vrijwel zeker tijdelijk, maar het is wel de realiteit van nu.

Hier wordt het pas echt interessant — en hier gaat het model achter Routines belangrijker worden dan de onderliggende techniek.

Opus 4.7 Is Waarom Routines Echt Nuttig Zijn

Anthropic bracht Claude Opus 4.7 uit op 16 april 2026, twee dagen nadat de Routines research preview werd geopend. Ik denk niet dat dat toeval is. Elke gepubliceerde benchmark wijst in dezelfde richting: Opus 4.7 presteert beter op langdurige, meerstaps, tool-intensieve taken dan welk model dan ook daarvoor. Routines zijn, per definitie, langdurige, meerstaps, tool-intensieve processen.

De cijfers waar ik het meest op vertrouw, omdat ze komen van de engineering partner-evaluaties van Anthropic zelf in plaats van van marketingmateriaal, zijn deze. Bij interne productie-evaluaties van Box, bereikte Opus 4.7 een vermindering van 56% in model calls en 50% minder tool calls ten opzichte van Opus 4.6, reageerde het 24% sneller in dezelfde tests, en werden 30% minder AI Units gebruikt in end-to-end werk. Op Rakuten’s productiebenchmark voor coderen voltooit Opus 4.7 ongeveer drie keer meer productietaken dan Opus 4.6, met dubbele cijfers verbetering in Code Quality en Test Quality. Op CursorBench, dat echte IDE-geïntegreerde codeerworkflows meet in plaats van kunstmatige probleemoplossing, stijgt Opus 4.7 van 58% (de score van Opus 4.6) naar 70% — een verbetering van 12 punten op de benchmark die het beste lijkt op het werk van echte ontwikkelaars.

De benchmark die het meest relevant is voor agentic workloads is echter SWE-bench Verified. Opus 4.6 scoorde 80,8%. Opus 4.7 scoort 87,6%. Dat is bijna een winst van zeven punten op een ranglijst waar winst van één punt aan de top al zwaar bevochten is, en het plaatst Opus 4.7 boven Gemini 3.1 Pro (80,6%) en ruim boven GPT-5.4 op dezelfde taakset.

Er is nog iets belangrijks om te benoemen, omdat het de allerbelangrijkste vlag is om te weten voordat je een Routine configureert: Opus 4.7 wordt geleverd met een nieuw inspanningsniveau genaamd xhigh. Niet "extra hoog", niet "uitgebreid", niet "high-plus" — de letterlijke naam van de vlag in de API en CLI is xhigh. Het is de aanbevolen standaard voor Opus 4.7 bij complexe redenatie en agentic werk, en het is standaard geactiveerd binnen Claude Code voor dit model. Wat xhigh in feite doet, is dat het meer tokens toewijst aan het interne redeneer- en toolverkenningsproces van het model voordat het terugrapporteert. Voor een enkele chat is het overkill. Voor een Routine die e-mails moet ophalen, categoriseren, antwoordconcepten opstellen, en een Slack-samenvatting versturen zonder dat jij hoeft bij te sturen, is dit precies het niveau dat je wilt.

Een kanttekening die blogposts vaak niet benadrukken: xhigh is prijzig. Gecombineerd met een nieuwe tokenizer in Opus 4.7, die grofweg 1,0 tot 1,35 keer meer tokens telt voor dezelfde tekst als 4.6, en de natuurlijke output-inflatie die samengaat met diepere interne redenatie, kunnen je API-kosten per gelijkwaardige taak 20% tot 50% hoger uitvallen dan in het 4.6-tijdperk. Het werk is beter. Het werk is duurder per uitvoering. Beide waarheden bestaan naast elkaar. Als je Routines draait via de API en niet binnen het inbegrepen verbruik van Claude Code, maak dan eerst een rekensom op een laagdrempelige testtaak voordat je xhigh koppelt aan een Routine die dagelijks 25 keer draait.

Met de functie en het model in kaart gebracht, laat ik je nu zien wat ik daadwerkelijk heb gebouwd.

De Routine Die Ik Heb Gedeployed: Ochtendelijke E-mailtriage Die Echt Werkt

Ik bouwde de e-mailtriage Routine als eerste om dezelfde reden als iedereen: de demo die Anthropic lanceerde bij de introductie was een e-mailtriage Routine, en de aard van het probleem — voorspelbare input, begrensde output, eenvoudig te valideren — maakt dit de meest logische eerste build met deze feature. Wat ik niet had verwacht, was hoe sterk de kwaliteit van de output afhing van het schrijven van de prompt alsof ik een taak overdraag aan een onbekende opdrachtnemer.

Hier is de prompt waar ik op uitkwam na drie iteraties. Hij is lang, en dat is juist de bedoeling.

Je draait een unattended e-mailtriagejob om 6:45 lokale tijd.
Ik kan geen vragen beantwoorden tijdens het uitvoeren. Maak bij elke beslissing de best mogelijke inschatting. Bij twijfel: maak een concept, niet verzenden.

STAP 1 — OPHALEN
Haal alle ongelezen berichten uit mijn Gmail-inbox van de afgelopen 24 uur. Sla alles over uit Promoties, Sociaal en Updates.

STAP 2 — CATEGORISEREN
Deel elk bericht exact in één van deze drie categorieën in:
  - URGENT — een specifiek genoemde persoon is geblokkeerd tot ik antwoord, of een deadline is binnen 48 uur, of er is geld/contracten mee gemoeid
  - REACTIE_NODIG — een reactie wordt verwacht maar er is niets geblokkeerd en er is geen haast
  - GEEN_ACTIE — nieuwsbrieven, ontvangstbewijzen, FYI’s, geen reactie verwacht

STAP 3 — CONCEPT OPSTELLEN
Voor elk URGENT- en REACTIE_NODIG-bericht maak je een conceptantwoord aan en sla je deze op in mijn Gmail-conceptenmap. Niet verzenden. Neem mijn toon over van de laatste tien antwoorden in mijn Verzonden-map (korte zinnen, geen "Hope you’re well," afsluiten met "— M"). Als je onvoldoende context hebt om zeker te concepten, stel dan een concept op met exact de context die je nodig hebt en markeer het concept met [NEEDS_CONTEXT] in het onderwerp.

STAP 4 — SAMENVATTEN
Plaats een Slack-bericht in #morning-brief in dit format:
  URGENT (N): één regel afzender + één regel onderwerp + jouw draft oordeel
  REACTIE_NODIG (N): zelfde structuur
  GEEN_ACTIE (N): alleen aantal, geen details

STAP 5 — FOUTAFHANDELING
Als een stap faalt, plaats dan in Slack #morning-brief met @here en de foutmelding. Een stille fout is het slechtste scenario. Liever een rood bericht dan niets.

STAP 6 — CONTEXT OPHALEN VAN EERDERE RUNS
Lees vóór Stap 1 het vastgemaakte bericht in #morning-brief van de vorige dag. Als er nog URGENTE punten openstaan uit de vorige run die niet in mijn Verzonden-map staan, neem deze dan vandaag op als CARRIED_OVER.

Zes genummerde stappen. Expliciete foutafhandeling. Expliciete instructies voor het ophalen van context uit de voorgaande run. Geen aannames over wat Claude zelf wel zal bedenken.

Die laatste stap — context ophalen van eerder gedraaide runs — was degene die me twee rebuilds kostte om te leren. Routines hebben standaard géén geheugen tussen runs. Elke uitvoering start met een frisse sessie. Als je wilt dat de run van gisteren de uitkomsten van vandaag beïnvloedt, moet je Claude exact vertellen waar te zoeken — een Slack-kanaal, Google Doc, GitHub gist, Notion-pagina, overal waar hij via een connector kan lezen en schrijven. Sla je deze stap over, dan maakt de Routine ieder ochtend vrolijk opnieuw een concept voor dezelfde mail, want elk ochtend lijkt voor hem de eerste.

De foutafhandelingsinstructie was de andere harde les die een rebuild kostte. Mijn eerste Routine crashte op één slecht geformatteerd MIME-bericht en stopte zonder waarschuwing. Ik merkte pas dat hij was gestopt toen ik om 7 uur géén Slack-samenvatting kreeg. Toen ik het herbouwde met de @here-foutmelding was ik al twee écht urgente mails misgelopen, omdat ik aannam dat een rustige ochtend betekende dat er gewoon niets was om op te reageren. Een stille fout is het allerslechtste scenario in elk unattended workflow. Schrijf het foutcallback vóór je het happy path codeert.

De Eerste Week: Resultaten

Dit zijn de feitelijke data over zeven dagen met deze ene Routine. Niet gecureerd, maar simpelweg geobserveerd.

Berichten verwerkt: 294 ongelezen mails over 7 dagen (ongeveer 42 per dag). Categorisatieprecisie, door mij ’s morgens om 9 uur handmatig beoordeeld: In 91% van de gevallen was ik het eens met Claude’s indeling. De 9% verschil kwam vrijwel altijd doordat Claude "URGENT" overclassificeerde — meestal omdat de toon van de afzender urgent leek, maar de inhoud gewoon een statusupdate was. Conceptkwaliteit: 6 van de 10 concepten verstuurde ik na minder dan 15 woorden aanpassen. 2 op 10 herschreef ik substantieel. 1 op 10 verwijderde ik en schreef ik zelf opnieuw. 1 op 10 werd correct gemarkeerd als [NEEDS_CONTEXT] en heb ik zelf beantwoord. Stille fouten: Nul sinds de callback. Één (de MIME-crash) ervoor. Tijdsbesparing, ruwe schatting: Voorheen was ik elke ochtend circa 25-35 minuten kwijt aan e-mailtriage. Met deze Routine duurt de review-en-verzenden-prik circa 7-10 minuten. Dat levert ruwweg drie uur per week op.

Nog één belangrijke kanttekening: de Routine presteert alleen zo goed omdat de prompt zo gedetailleerd is. Ik testte een kortere versie — "Triage mijn mail, maak conceptantwoorden, plaats een Slack-samenvatting" — en die werkte slechts voor zo’n 60%. Vage prompts leveren vage routines. Zie de prompt als een specificatiedocument, niet als een chatbericht.

De keuze tussen Trusted en Full Tool Mode die je niet mag overslaan

Voordat een Routine toegang krijgt tot je tools, kies je één van twee modi: trusted of full. Dit is de belangrijkste beveiligingsbeslissing van je hele setup, en het verdient aanzienlijk meer aandacht dan de twee alinea’s die de documentatie eraan besteedt.

In de trusted-modus kan de Routine alleen tools gebruiken die je expliciet hebt goedgekeurd — Gmail, Slack, Google Drive, alles wat je individueel hebt aangezet. Als de prompt Claude vraagt om iets te doen waarvoor een niet-goedgekeurde tool nodig is, weigert de Routine die stap of faalt deze. Dit is de standaardinstelling. Dit is ook altijd het juiste beginpunt voor elke workflow die je bouwt.

In de full-modus kan de Routine elke tool gebruiken die een connector met jouw account heeft. Besluit de Routine halverwege om het web te doorzoeken, een bestand te schrijven of een nieuwe API te benaderen, dan kan dat zonder jouw toestemming. Full-modus geeft je de meeste autonomie en ontgrendelt de meest ambitieuze vormen van automatisering. Het is echter ook hoe je per ongeluk een AI-agent zonder toezicht de bevoegdheid geeft om je hele klantenbestand te e-mailen, omdat de prompt niet duidelijk genoeg was en het model "reach out" breder interpreteerde dan je bedoelde.

Mijn regel na een week: bouw elke Routine eerst in trusted-modus, voer hem minstens drie keer uit, controleer de tool-calls, en schakel alleen over naar full-modus als je precies kunt benoemen welke functionaliteit trusted-modus mist die je echt nodig hebt. Elke Routine die ik momenteel in productie draai, staat in trusted-modus. De enige Routine die ik in full-modus testte, heb ik verwijderd, omdat hij meteen precies deed waarvoor je nooit een agent zonder toezicht wilt draaien — hij besloot dat de beste manier om "op oude leads te volgen" was: zeventien mensen e-mailen waarmee ik twee jaar geen contact had gehad.

Er is geen technische oplossing voor prompt-ambiguïteit in full-modus. De enige echte oplossing is een scherpere prompt schrijven en in trusted-modus draaien.

Als je al productie-agents hebt gebouwd met de Agent SDK, zal veel hiervan bekend voorkomen — dezelfde discipline rondom capability boundaries geldt hier, met minder code en een iets andere interface. Voor een diepgaandere uiteenzetting van die grenzen, zie mijn walkthrough van de Anthropic Agent SDK.

Wat Ging Fout, En Wat Ik Heb Moeten Herbouwen

Niet alles wat ik probeerde werkte. De twee Routines die het hardst faalden zijn eigenlijk nuttiger om te bespreken dan de succesvolle, omdat de faalpatronen vrijwel zeker dezelfde zijn waar anderen in hun eerste week tegenaan lopen.

Faalpunt 1: De PR review Routine die te vaak afging. Ik koppelde een GitHub-trigger aan een middelgrote Laravel-repo — elke PR open, elke push naar een openstaande PR, voer een code review uit en plaats deze als PR-comment. Op een drukke dinsdag pushte ik 11 commits naar één PR binnen zo’n 90 minuten. De Routine werd zes keer geactiveerd en stopte toen stilletjes. Ik dacht dat hij stuk was. Wat er in werkelijkheid gebeurde: ik had de limiet per Routine per uur voor GitHub webhook-events bereikt tijdens de research preview, en de overige vijf events waren gedropt. De documentatie noemt dit in één regeltje; ik had het bij de eerste keer lezen gemist. Mijn oplossing: debounce de trigger naar “bij PR openen” en “bij PR klaar-voor-review” in plaats van op elke push. Dit verminderde de frequentie van zes-per-PR naar één-per-PR en voorkwam het verlies van events volledig.

Faalpunt 2: De wekelijkse rapportage Routine die het verkeerde tijdsvenster pakte. Ik bouwde een Routine die elke maandag om 8:00 uur draait, mijn Stripe-uitbetalingen en Fiverr inkomsten van de voorgaande week ophaalt, de trend samenvat en post naar een privé Slack-kanaal. De eerste run leverde een getal op dat ongeveer 40% te laag was. Het model had “vorige week” geïnterpreteerd als “de laatste zeven dagen vanaf nu” in plaats van “de vorige kalenderweek van maandag tot en met zondag”. Omdat elke Routine-run opnieuw begint zonder kennis van wat vorige week betekent, had het model geen ankerpunt om op te kalibreren. De fix was expliciet: “Haal data op van de kalenderweek die start op maandag [datum in ISO-8601] en eindigt op zondag [datum in ISO-8601]. Niet de laatste zeven dagen. De voorgaande kalenderweek.” Daarna kwamen de cijfers exact overeen met mijn Stripe-dashboard.

Beide fouten hebben dezelfde vorm. Beide waren falen door aangenomen context. In beide gevallen had ik een prompt geschreven die prima werkte voor een menselijke collega die mijn werkwijze kent, maar ambigu zou zijn voor een gloednieuwe contractor op zijn eerste dag. Routines beleven altijd hun eerste dag, elke keer dat ze draaien. Schrijf prompts voor een first-day contractor en de meeste van dit soort fouten verdampen voordat ze optreden.

Als je al langer geautomatiseerde agentic workflows schrijft en je wilt een diepgaander framework voor deze vorm van promptconstructie, raad ik het framework uit mijn Opus 4.6 hands-on review aan — de principes vertalen 1-op-1 naar 4.7, met het extra voordeel dat 4.7 meer ambiguïteit tolereert voor het van het script afwijkt. “Meer tolereren” is echter niet “elimineren”. Strakke prompts blijven winnen.

Waar Routines Nog Tekortschieten

Dit is het onderdeel dat de meeste launch-week verslaggeving zal overslaan, dus ik neem er bewust de tijd voor. In de eerste week liep ik tegen vier concrete beperkingen aan die het benoemen waard zijn, omdat ze bepalen wat je wél en niet kunt bouwen.

1. Geen cross-run geheugen standaard. Ik heb het hierboven al aangestipt, maar het verdient herhaling. Elke Routine-uitvoering is een volledig nieuwe Claude Code-sessie zonder enige herinnering aan eerdere runs. De workaround is expliciete contextherstel — wijs Claude op een Slack-kanaal, een Google Doc, een database-record, overal waar het de output van gisteren kan lezen voordat het aan het werk van vandaag begint. Dit is op te lossen, maar het is handmatig. Als je het vergeet op te lossen, eindig je met drie dagen aan dubbele antwoorden.

2. Minimale cadans van één uur. Als het echte werk elke vijf minuten moet draaien — een polling job voor statuschecks, een live-signaalmonitor, iets in trader-tijd — dan kan dat niet met Routines binnen de ingebouwde scheduler. De workaround is een webhook-trigger die wordt aangeroepen door een externe scheduler, maar dan ben je weer infrastructuur elders aan het beheren, wat het oorspronkelijke voordeel deels tenietdoet. Voor echt sub-uurlijk geplande taken zijn Routines nog niet het juiste gereedschap.

3. Beveiligingshouding van full mode is nog niet volwassen. Full mode is even krachtig als riskant. Er bestaat geen sandboxmodus die eerst een full-mode run simuleert vóórdat productie-tools geraakt worden. Er is geen kostenplafond per tool om te voorkomen dat een workflow out-of-control raakt en onnodig tokens verspilt in een slechte lus. Er is geen limiet op bevragingssnelheid per connector die je zelf kunt instellen. Je enige echte vangnet is de kwaliteit van je prompt plus starten in trusted mode. Professionele teams die full mode gebruiken met echte klantdata moeten verwachten zelf extra waarborgen rondom de Routine te bouwen — denk aan approval-queue patronen, audit-logs via zijkanalen, circuit breakers op kosten.

4. Research preview betekent dat de API kan veranderen. Alles wat ik in deze post beschrijf, is waar op 21 april 2026. Anthropic heeft expliciet aangegeven dat request- en responsevormen, rate limits, en token-semantie kunnen veranderen zolang Routines nog onder research preview vallen. Als je deze maand missie-kritische infrastructuur bouwt bovenop Routines, reserveer dan tijd om binnen zes maanden delen opnieuw te moeten schrijven. Dit is geen fout — het is een eerlijk compromis bij werken met een research preview — maar het is belangrijk om te benoemen. Ik heb teams meegemaakt die een research preview als een stabiele API beschouwden, om vervolgens dagen te verliezen aan een shape-change die ze niet hadden opgemerkt.

Geen van deze punten is een echte showstopper. Maar dit zijn wel precies de dingen die je moet weten voordat je een workflow commit aan Routines en iemand anders belooft dat die workflow het gewoon blijft doen.

Als je nu al scheduled automations draait in de Claude Code desktop-app in plaats van in Routines, dan vind je mijn vergelijking tussen die twee in de Claude CoWork scheduled-tasks gids waarschijnlijk nuttig — de interfaces lijken op het eerste gezicht vergelijkbaar, maar het onderliggende executiemodel verschilt fundamenteel, en je keuze maakt uit, afhankelijk van of het aanstaan van je laptop een factor is.

De Vijf Routines Die Ik Hierna Zou Bouwen

Als ik het weekend opnieuw kon beleven en het meeste uit Routines wilde halen voordat de limiet ingaat, is dit mijn lijst — gerangschikt op ROI per opzetminuut.

1. Ochtend-e-mailtriage + concepten. De routine die ik al gebouwd heb. Als je verder niets doet, bouw dan deze. De tijdwinst is direct en de faalmodi zijn beperkt.

2. Wekelijkse bedrijfsrapportage. Stripe, Fiverr, wat je inkomstenkanalen ook zijn, elke maandagochtend opgehaald, als trend samengevat, gepost in een privé Slack-kanaal. Het cumulatieve voordeel: je denkt niet meer “ik zou naar de cijfers moeten kijken”, want de cijfers komen naar jou. Voor solo-ondernemers is dit misschien nog waardevoller dan de e-mailtriage.

3. Automatische triage van inkomende leads met gepersonaliseerde concept-antwoorden. Webhook-trigger vanaf je websitecontactformulier. Claude haalt het bericht op, onderzoekt het bedrijf van de afzender via hun domein in ongeveer veertig seconden, schrijft een antwoord waarin iets echts over hun business wordt aangehaald, slaat het concept op en pingt je in Slack. Jij controleert en verstuurt. Reactietijden dalen van uren naar minuten zonder het persoonlijke karakter te verliezen dat de lead over de streep trekt.

4. Dagelijkse changelog-samenvatting voor een publieke repo. GitHub-trigger bij elke merge naar main. Claude haalt de diff op, schrijft een changelog-entry voor eindgebruikers in jouw toon, voegt deze toe aan CHANGELOG.md, opent een PR. Jij reviewt wekelijks. Uren documentatiewerk per maand worden minuten reviewtijd.

5. Onderzoeksbriefing voor de meetings van morgen. Dagelijkse trigger om 20:00 uur. Claude leest je agenda voor de volgende dag, haalt de headlines van LinkedIn-profielen van aanwezigen op, hun recentste publieke output en de laatste e-maildraad met ieder, produceert een briefing van één pagina per meeting en zet deze in een Google Doc. Je loopt elke meeting morgen binnen met context waar je anders een halfuur aan onderzoekswerk in zou moeten steken.

Geen van deze ideeën is nieuw. Al deze dingen zijn technisch al jaren mogelijk met cron plus een taalmodel plus een API-wrapper. De reden dat ik ze zelf nooit had gebouwd: elke routine vroeg om infrastructuur die ik niet wilde beheren — een server voor de cron, een wrapper om het model aan te roepen, een queue om falen af te handelen, een monitor die meldde wanneer de queue stuk was. Routines vouwt die hele stack samen in één opgeslagen configuratie die draait op andermans infrastructuur. De barrière was niet het idee. De barrière was het gezeur eromheen.

Dat is hier echt nieuw. Niet de automatisering. De afwezigheid van het gezeur. Voor een diepere analyse van hoe het bredere AI-model-landschap er in april 2026 uitziet rondom deze release, vind je het hele plaatje over Kimi K2.6, GPT-5.5 Spud-geruchten en hoe Opus 4.7 zich in echte workloads verhoudt tot de rest in mijn AI-model-overzicht van april 2026.

Veelgestelde Vragen

Wat zijn Claude Routines en hoe werken ze?

Claude Routines zijn opgeslagen Claude Code-configuraties — een prompt, repositories, connectors en een trigger — die draaien op de cloudinfrastructuur van Anthropic wanneer een schema, API-call of GitHub-event wordt geactiveerd. Je lokale machine hoeft niet online te zijn. Bij elke uitvoering wordt een nieuwe Claude Code-sessie gestart zonder geheugen van eerdere runs, tenzij je expliciet in de prompt aangeeft waar eerdere context terug te vinden is. Voor een volledige installatiehandleiding, zie de sectie Morning Email Triage hierboven.

Wat is het minimale interval voor het plannen van een Claude Routine?

Eén uur. Schedule triggers ondersteunen vier presets — elk uur, dagelijks, weekdagen, wekelijks — en weigeren elke cron-expressie die vaker dan één keer per uur draait. Voor een kortere frequentie kun je een webhook-trigger gebruiken die wordt aangestuurd door een externe scheduler, al introduceert dat weer het externe-infrastructuurprobleem dat Routines juist willen oplossen.

Is Opus 4.7 beter dan Opus 4.6 voor agentisch werk?

Ja, aanzienlijk. In de partner-evaluaties van Anthropic maakte Opus 4.7 56% minder model-calls en 50% minder tool-calls dan Opus 4.6 voor gelijkwaardige taken, loste ongeveer drie keer meer productietaken op in de Rakuten coding benchmark, en steeg van 58% naar 70% op CursorBench. Het nieuwe xhigh effort-niveau is de standaard voor 4.7 binnen Claude Code en is de aanbevolen optie voor meerstaps, onbeheerd werk.

Wat is xhigh in Claude Opus 4.7?

xhigh is het nieuwe effort-niveau van de hoogste klasse in Opus 4.7 — de letterlijke vlagnaam die wordt gebruikt in de API en CLI. Dit niveau reserveert meer tokens voor intern redeneren en tool-onderzoek voordat het model een resultaat teruggeeft. Het is het standaard effort-niveau voor Opus 4.7 in Claude Code en wordt aanbevolen voor complexe redeneringen en agentisch werk. Dit kost wel meer per taak vanwege de diepgaandere redeneerlus en een nieuwe tokenizer, dus houd rekening met 20% tot 50% hogere kosten per vergelijkbare taak ten opzichte van 4.6.

Hoeveel Routines kan ik per dag uitvoeren op het Pro-abonnement?

Vijf Routine-uitvoeringen per dag voor Claude Pro. Claude Max-gebruikers krijgen 15 per dag. Team- en Enterprise-gebruikers krijgen 25 per dag. Meer gebruiken is mogelijk met overage billing, maar de limieten zijn per account over al je Routines, niet per Routine afzonderlijk — dus een Pro-gebruiker die vijf verschillende dagelijkse Routines draait, zit al aan zijn limiet.

Moet ik trusted- of full tool-mode gebruiken voor een nieuwe Routine?

Altijd trusted mode bij een nieuwe Routine. Trusted mode beperkt Claude tot de specifieke tools die je individueel voor die Routine hebt goedgekeurd. Full mode geeft Claude toegang tot elke connector op je account tijdens de uitvoering, wat handig is voor de meest ambitieuze workflows, maar ook de manier waarop onbeheerde agenten dingen kunnen doen die je niet bedoeld had. Begin met trusted mode, laat drie schone uitvoeringen draaien, controleer de tool-calls, en ga pas over naar full mode als je een specifieke functionaliteit kunt benoemen die trusted mode niet dekt.

Laten We Samenwerken

Wil je AI-systemen bouwen, werkstromen automatiseren of je tech-infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io