Stripe Projects + Daytona: The Agent Billing Verdict
One command provisions a sandbox, meters the compute, and keeps the card locked inside Stripe. This is the agent-wallet architecture I've been asking for — read the fine print before you ship on it.
- Stripe Projects went generally available April 29, 2026 at Stripe Sessions with 32 providers; Stripe's docs now list 50+ across hosting, databases, auth, analytics, and AI.
- `stripe projects add daytona/sandbox` (developer preview since April 29) provisions Daytona compute with usage-based billing through a Shared Payment Token — Daytona never sees the payment method.
- Credentials auto-deliver to env vars scoped per service, rotate with one command, and live in an encrypted vault at .projects/vault/.
- Daytona claims sub-90ms sandbox creation; E2B counters with Firecracker microVM isolation 'made to run untrusted workflows' and sub-200ms same-region starts.
Stripe Projects is Stripe's CLI (v1.43.3+) for provisioning and billing 50+ providers from one command surface. Running `stripe projects add daytona/sandbox` gives AI agents Daytona compute sandboxes billed through a Shared Payment Token, so the payment method stays with Stripe and never reaches Daytona. Credentials auto-sync to scoped env vars and rotate with one command; the Daytona integration is still a developer preview.
Stripe Projects plus Daytona is the pairing I’ve been waiting on since I wrote my agent wallets guide… An AI agent that can buy its own compute without ever holding the card.
One command — stripe projects add daytona/sandbox — provisions a Daytona sandbox, turns on usage-based billing through a Shared Payment Token, and drops scoped credentials straight into your env vars. Stripe keeps the payment method. Daytona never sees it.
Full disclosure: I don’t have this wired into production. This is the paper verdict — me reading the docs like an SRE reads a postmortem.
What is Stripe Projects and how does Daytona fit in?
Stripe Projects is a CLI layer (Stripe CLI v1.43.3+) that provisions and bills 50+ providers — hosting, databases, auth, analytics, AI — from one command surface, per Stripe’s docs. Daytona joined April 29, 2026 as a sandbox provider in developer preview, so agents get stateful compute billed through Stripe.
The timeline moved like a startup, not a bank. Developer preview March 26 with PlanetScale co-designing. General availability April 29 at Stripe Sessions, where 14 new partners pushed the count to 32 and John Collison declared “Vibe coding is so 2025. The leading edge is now in vibe deploying.” By June 11 it was 49 providers plus agent integrations — Hermes from Nous Research, Factory Droids, Warp. Netlify joined July 22, framing the whole thing around Agent Experience.
How does an agent pay for Daytona sandboxes through Stripe Projects?
Through a Shared Payment Token. Per Daytona’s integration post, the payment method stays with Stripe and is never shared with Daytona. Credentials auto-deliver to env vars, scoped per service, rotatable with stripe projects rotate daytona/top-up-0025, synced with stripe projects env --sync, vaulted encrypted at .projects/vault/.
This is the part I care about. I build AdOps billing tooling for a living, and my whole thesis has been that agents need budgets before they need brains. Stripe’s June update shipped per-provider spending caps and dev/staging/prod isolation… That’s the budget line item I’ve been yelling about, now as a CLI flag.
Scoped keys. One-command rotation. A card the vendor never touches. That’s not a feature list — that’s blast-radius control.
Daytona vs E2B: which sandbox should agents use?
Daytona claims sub-90ms sandbox creation and stateful, long-running sandboxes, but its site doesn’t state the isolation mechanism. E2B states every sandbox is a Firecracker microVM “made to run untrusted workflows,” starting under 200ms same-region. Trusted agent workloads with clean billing: Daytona. Untrusted code: E2B’s paper is stronger.
| Sandbox | Billing path | Speed (vendor claim) | Isolation (stated) | Where it loses |
|---|---|---|---|---|
| Daytona via Stripe Projects | Shared Payment Token, card stays with Stripe | Sub-90ms creation | Not publicly stated | Untrusted code — no published isolation story; integration still developer preview |
| E2B | Direct with E2B | Sub-200ms same-region (80ms optimized) | Firecracker microVMs for untrusted workflows | No Stripe Projects billing rail; you manage the payment relationship yourself |
Both rows are sub-second per vendor claims. The real fork is isolation transparency versus billing architecture.
Is Stripe Projects with Daytona ready for production?
Not fully. Stripe Projects is GA; the Daytona provider is still developer preview, and Netlify’s post notes the preview provisions a Stripe sandbox account by default. Two-layer status matters: the rail is GA, the train is preview. Prototype on it today; keep production billing on rails you control until the preview label drops — same call I made in my production AI stack verdict.
Stop giving agents your card. Start giving them a token with a cap.
#TheAIMogul
Bottom lineStripe Projects plus Daytona is the first agent-compute setup where the money story is actually right: Stripe holds the card, the agent gets scoped rotatable credentials, and every sandbox is metered. Use it for trusted agent workloads now — for untrusted code, E2B's stated Firecracker isolation is still the safer paper.