Sandbox voor AI-agents: Daytona vs E2B vs Firecracker

Het is 23:47 op een zondag. Er is net een nieuwe Linux-kernel-CVE op oss-security verschenen, score 8.8. Jouw AI-research-agent draait ~970 Python-sessies per dag in Linux-microVMs die diezelfde kernel delen. Iemand patcht. De enige vraag die er toe doet voor je een sandbox-contract tekent: wie.

We hadden dit gesprek vorige maand met een Amsterdams data-adviesbureau van 19 man. Zij hebben een research-agent gebouwd die klant-CSV's inleest, pandas-transformaties draait tegen een referentiedataset van 14 GB, en een gestructureerd rapport terugschrijft. Ruwweg 6.800 sessies per week, bijna allemaal onder 90 seconden CPU. De agent werkt. De sandbox-laag eronder lag nog open.

We rekenden er drie door. De eerlijke vergelijking ging om drie kolommen: kosten per sessie, cold-start tegen de 14 GB-dataset, en wie je belt als er een kernel-bug binnenkomt.

De workload, in één alinea

Elke agent-run is een verse Python 3.13-omgeving met pandas, polars, pyarrow, en een eigen interne package die read-only gemount staat. De referentiedataset van 14 GB (gededupliceerde vastgoedrecords sinds 2008) staat op een gedeeld volume. Cold runs moeten 'm memory-mapped krijgen; warme runs hergebruiken 'm. Mediane sessie: 38 seconden CPU. p99: 4 minuten. De agent doet retries bij tijdelijke fouten. De piek ligt op 22 gelijktijdige sandboxes rond 14:00 CET op maandagen.

Optie één: Daytona

Daytona is gebouwd voor developer-omgevingen, niet voor wegwerp-agent-sessies. Je kunt er een research-agent op draaien. Ze hebben een API, de sandboxes booten onder de 100 ms zodra de warm pool geïnitialiseerd is, en de developer experience is netjes.

De rekensom bij ons sessievolume was het probleem. De prijsstructuur van Daytona gaat uit van workspaces met een langere levensduur. Bij 6.800 starts per week met een mediaan van 38 seconden betaal je voor compute-granulariteit die je niet gebruikt. Per sessie kwamen we uit op ongeveer €0,018, zodra we de warm pool-overhead realistisch meenamen. Over 354.000 sessies per jaar is dat €6.372. Niet rampzalig. Goedkoop ook niet.

De 14 GB-dataset was het lastigere punt. Daytona laat je een volume mounten, maar de agent bleef 'm bij de eerste run hot-mappen, wat 6 tot 9 seconden kostte voor pandas een bruikbare handle had. Hun snapshot-model is geoptimaliseerd voor code-state, niet voor 14 GB aan arrow-files. Ze eindigden tweede.

Optie twee: E2B

E2B is specifiek gebouwd voor dit type workload. Code interpretation, agent-sandboxes, sub-seconde cold starts. Onder de motorkap draaien ze Firecracker microVMs (dezelfde door AWS gebouwde microVM-techniek die Lambda aandrijft). Hun snapshot en restore is scherp. Hun SDK is twee regels.

from e2b_code_interpreter import Sandbox

with Sandbox(template="pandas-arrow-14gb") as sbx:
    result = sbx.run_code(agent_generated_python)
    print(result.text)

Kosten bij ons volume, op basis van hun gepubliceerde per-seconde compute-prijs voor een 2 vCPU / 4 GB-template plus persistente template-storage voor de 14 GB-dataset, kwamen uit op ongeveer €0,011 per sessie. Op jaarbasis: circa €3.900. Inclusief de regel voor datasetopslag: circa €4.800.

Cold start tot een werkend pandas-proces met de dataset memory-mapped: 340 ms mediaan, 1,1 s p99 op onze test-template. Dat is wat een managed Firecracker-snapshot je oplevert. De dataset zit in de template; restore brengt 'm terug als copy-on-write mapping.

Toen CVE-2024-1086 (de Linux-kernel netfilter use-after-free) bekend werd, rolden managed Firecracker-operators snel patches uit. Omdat het moest: elke klant was kwetsbaar. Hun team patchte het. Jij niet.

Optie drie: Firecracker plus Kata, self-hosted

Dit was de optie waar de twee engineers van het adviesbureau zin in hadden. Ze hadden eerder KVM-workloads gedraaid. De belofte: zelf de stack bezitten, kosten per sessie naar marginaal duwen.

Op papier ziet de rekensom er prima uit. Eén Hetzner AX102 (~€280/maand) kan bij deze workload ruwweg 80 tot 120 gelijktijdige Firecracker-microVMs draaien. Twee hosts dekken de piek met marge. De rekensom: €560/maand gedeeld door 29.500 sessies per maand is €0,019 per sessie. Slechter dan E2B op managed-prijs.

Die 'slechter' verraste ze. Dat had niet gehoeven. De prijs van E2B weerspiegelt dat zij deze workload op schaal draaien, met bin-packing die je met 19 mensen niet repliceert.

De andere kolom was doorslaggevend. De CVE-zondag.

Een redelijke on-call-toeslag voor twee engineers, gemodelleerd op €400/maand per persoon om de kernel-patch-verantwoordelijkheid te dekken (niet de rest van hun werk), telt op tot €9.600 per jaar. Daarmee alleen al wordt self-hosted drie keer zo duur als E2B.

De niet-financiële argumenten voor self-hosting (data residency, regulatoire afscheiding, geen externe verwerker) waren reëel voor twee van de klanten van het adviesbureau. We hebben dat genoteerd. Het gold niet voor de referentiedataset van de agent, want dat was publieke Kadaster-data.

Wat we niet op de shortlist zetten

Eén alinea waard: we keken naar de recente release van Pyodide, waarmee je WebAssembly-wheels direct op PyPI kunt publiceren. Oprecht interessant voor browser-side agents en offline analyse. Voor een 14 GB pandas-dataset die memory-mapped moet worden op een Linux-kernel is WASM het verkeerde gereedschap. Goed antwoord, verkeerde vraag.

De cijfers, naast elkaar

Jaarkosten, 354.000 sessies

• Daytona: ~€6.400
• E2B: ~€4.800 (compute plus datasetopslag)
• Self-hosted Firecracker + Kata: ~€6.700 (hardware plus on-call-toeslag)

Cold start, 14 GB-dataset memory-mapped

• Daytona: 6 tot 9 s (volume hot-mapped bij eerste run)
• E2B: 340 ms mediaan, 1,1 s p99 (template-snapshot)
• Self-hosted: 280 ms mediaan, mits je de snapshot-pipeline zelf bouwt; dat kost vooraf ongeveer vier engineer-weken

CVE-patch op zondagavond

• Daytona: hun team
• E2B: hun team
• Self-hosted: jouw team

De keuze

Het adviesbureau koos E2B. Niet omdat het met ruime marge het goedkoopst was (dat was het, maar nipt), maar omdat de cold-start-rekensom tegen de 14 GB-dataset het schoonst was, en omdat hun twee backend-engineers geen kernel-patch-team wilden zijn. Ze wilden het agent-team zijn.

Toen we bij ABN de research-agent-integratie voor ze bouwden, lag de lastige plek niet bij de sandbox-laag. Het was de gewoonte van de agent om binnen één research-sessie dezelfde pandas-filter op vier verschillende manieren te regenereren, wat het aantal sessies met ongeveer 18% opblies. We losten 'm op met een structured intermediate-result cache tussen agent-beurten. De sandbox-rekening zakte naar het niveau dat we hadden gemodelleerd. Bouw je een AI-agent die elke beurt een sandbox raakt, kijk dan eerst naar die lus voor je naar de sandbox-leverancier kijkt.

Wil je vandaag een audit van vijf minuten doen: open de laatste 100 sessies van je agent en tel hoeveel daarvan een vrijwel identieke pandas-operatie tegen dezelfde input draaiden. Zijn dat er meer dan vijftien, dan liegt je sandbox-rekensom tegen je, en ligt de echte fix één cache-laag hoger.