Programmatic tool calling: waarom AI-agents hun tools steeds vaker via code aanroepen

Stel dat je agent moet uitzoeken welke teamleden in het derde kwartaal over hun reisbudget zijn gegaan. Met gewone tool calling haalt het model het team op, dan per persoon de declaraties, dan de budgetten. Al die gegevens, samen ruim tweeduizend declaratieregels in het voorbeeld van Anthropic, belanden in het contextvenster. Het antwoord dat je wilt, zijn twee of drie namen.

Programmatic tool calling draait dat om. Het model schrijft een script dat de tools aanroept, dat script filtert de gegevens in een sandbox, en alleen die twee of drie namen komen terug in de context. Anthropic introduceerde het in november 2025 als bètafunctie. Sinds 17 februari 2026, de dag dat Claude Sonnet 4.6 uitkwam, is het algemeen beschikbaar en filtert Claude ook webzoekresultaten op deze manier.

Is dit de toekomst van tool calling? Voor een deel van de agents wel. Voor een ander deel wordt het juist duurder.

Stand van 25 september 2026. Aanleiding voor dit artikel was de video Anthropic Just Killed Tool Calling van het YouTube-kanaal Prompt Engineering. De cijfers hieronder komen uit de primaire bronnen van Anthropic en Cloudflare.

Wat is programmatic tool calling?

Bij programmatic tool calling roept een taalmodel tools niet één voor één aan, maar schrijft het code die ze aanroept. Die code draait in een afgeschermde omgeving. Tussenresultaten blijven daar, en alleen de uitkomst van het script gaat terug naar het model. Dat bespaart tokens en rondes tussen model en tools.

Bij gewone tool calling gaat het zo:

1. Alle tooldefinities staan vooraf in de context.
2. Het model vraagt om één tool-aanroep, als JSON.
3. Jouw code voert die uit en stuurt het volledige resultaat terug.
4. Het model leest dat resultaat, en vraagt om de volgende aanroep.

Elke aanroep is een volledige ronde door het model, en elk tussenresultaat blijft in het contextvenster staan. Je betaalt ervoor, en het model moet er elke volgende stap weer doorheen.

Waarom code in plaats van JSON?

Cloudflare maakte in september 2025 het argument dat de meeste mensen onthouden. Taalmodellen hebben enorm veel echte code gezien, maar weinig synthetische tool-aanroepen. Hun vergelijking: een model laten werken met tool calling is als Shakespeare een maand Mandarijn laten volgen en hem dan een toneelstuk in het Mandarijn laten schrijven. Cloudflare noemt de aanpak Code Mode.

Ruim een maand later kwam Anthropic met hetzelfde idee voor MCP-servers, met een verwijzing naar Cloudflare. Presenteer de tools als code-API's en laat het model een script schrijven. In hun voorbeeld haalt een agent een vergaderverslag uit Google Drive en zet het bij een lead in Salesforce. Normaal gaat dat hele verslag twee keer door de context. Via code daalde het verbruik van 150.000 naar 2.000 tokens, een besparing van 98,7 procent.

Op 24 november 2025 volgde de functie in de Claude API zelf: programmatic tool calling.

Hoe werkt het in de Claude API?

Je geeft het model de code-execution-tool en markeert per tool dat die vanuit code aangeroepen mag worden, met het veld allowed_callers:

"tools": [
  { "type": "code_execution_20260120", "name": "code_execution" },
  {
    "name": "query_database",
    "description": "Voert een SQL-query uit. Geeft rijen terug als JSON.",
    "input_schema": {
      "type": "object",
      "properties": { "sql": { "type": "string" } },
      "required": ["sql"]
    },
    "allowed_callers": ["code_execution_20260120"]
  }
]

Het model schrijft vervolgens Python die query_database bijvoorbeeld drie keer aanroept, voor drie regio's, en de resultaten samenvoegt. Jouw applicatie voert elke aanroep nog steeds zelf uit. Het verschil is dat de resultaten naar het script gaan en niet naar het model. Volgens de documentatie tellen die tussenresultaten niet mee als input- of outputtokens. Alleen de uitkomst van het script en het antwoord van het model tellen.

Hoeveel scheelt het?

Hier lopen de cijfers sterk uiteen, en dat is precies de les:

De extreme besparingen komen van situaties met enorme tooldefinities of grote tussenresultaten. Bij een agent die per beurt één of twee tools na elkaar aanroept, levert het niets op en kost het zelfs meer. Het opstarten van de container en het schrijven van het script zijn dan duurder dan wat je bespaart.

Dynamic filtering: dezelfde truc voor webzoekopdrachten

Tegelijk met Sonnet 4.6 paste Anthropic het principe toe op zijn eigen web search- en web fetch-tools. Voorheen kwamen zoekresultaten en hele HTML-pagina's in de context. Nu schrijft Claude eerst code die de resultaten filtert, en alleen wat relevant is gaat door.

Op BrowseComp, een benchmark waarin een agent informatie moet vinden die bewust moeilijk te vinden is, ging Sonnet 4.6 van 33,3 naar 46,6 procent. Opus 4.6 ging van 45,3 naar 61,6 procent. Dat is een winst van 13 en 16 procentpunten. Gemiddeld over BrowseComp en DeepsearchQA werd het 11 procent beter, met 24 procent minder inputtokens.

Is het altijd goedkoper?

Nee. Je bespaart op inputtokens, omdat ruwe data niet meer in de context komt. Maar het model moet nu code schrijven, en dat zijn outputtokens, die duurder zijn. Anthropic meldt het zelf: de prijsgewogen tokens daalden bij dynamic filtering voor Sonnet 4.6 op beide benchmarks, maar stegen voor Opus 4.6. De kosten hangen af van hoeveel code het model schrijft om de context te filteren.

In de video van Prompt Engineering wordt dat uitgelegd als "Opus is perfectionistisch en schrijft te veel code". Dat is een interpretatie; Anthropic noemt geen oorzaak.

Waar je op moet letten

• Het past bij bepaalde taken. Volgens Anthropic helpt het bij veel parallelle aanroepen (vijftig endpoints controleren, twintig records opzoeken), bij grote resultaten die je kunt filteren of samenvatten, en bij zoek- en onderzoekstaken. Het helpt niet bij strikt opeenvolgende stappen waarin het model steeds over het vorige resultaat moet nadenken, en ook niet bij een paar kleine aanroepen.
• allowed_callers is geen beveiliging. De documentatie zegt het letterlijk: het model wordt sterk gestuurd om het te respecteren, maar het is geen harde blokkade. Je code moet ook een directe aanroep van die tool aankunnen.
• Niet alles kan. Tools uit een MCP-connector kun je niet programmatisch aanroepen. Hetzelfde geldt voor tools met strict: true (structured outputs) en voor schema's met een recursieve $ref.
• Data in de sandbox is invoer voor code. Geeft een tool externe data of gebruikersinvoer terug, let dan op code-injectie.
• Meet het. Anthropic raadt zelf aan de gefactureerde inputtokens met en zonder allowed_callers te vergelijken op een representatief deel van je verkeer, voordat je het overal aanzet.

Dus: de toekomst van tool calling?

Het oude patroon verdwijnt niet. Een agent die één tool aanroept en over het antwoord moet nadenken, blijft beter af met gewone tool calling. Maar een agent die tientallen tools heeft, veel data ophaalt of veel parallel werk doet, betaalt met gewone tool calling voor tokens die niemand leest. Voor dat soort agents is code de logische laag tussen model en tools. Cloudflare bedacht het patroon, Anthropic bouwde het binnen twee maanden in zijn eigen API. Wie agents bouwt met veel tools, kan beter nu gaan meten dan wachten tot het de standaard is.