Free Tier Sandbox for Testing AI Agent Code Execution Before You Commit

CreateOS Sandbox gives every new account 500 free credits to run AI-written code on its own Firecracker microVM. Per-second billing and $0 egress stretch those credits across real test runs. Set the egress rules, watch the traces, break the code safely, and commit budget only when the behavior holds up.

Introduction

An agent that writes code hands you half a system. The other half is the machine that code runs on, and that machine is where the risk sits. Agent output is untrusted by definition. Run it on your laptop, your CI server, or a shared dev container and one bad generation can cost you a deleted repository, a leaked credential, or a bill nobody approved.

The free tier exists for exactly this decision. CreateOS Sandbox hands new accounts 500 free credits, the same API paid usage runs on, and an SDK plus CLI you can wire into an agent harness in an afternoon. Test the execution path first. Commit budget, infrastructure, and pipeline changes after the evidence is in.

Key Takeaways

New accounts start with 500 free credits, billed per second with $0 egress, so the credits cover real test runs rather than a scripted demo.
Every session runs in a Firecracker microVM with its own guest kernel. Agent code gets a machine boundary, not a shared container namespace.
Outbound access stays open until you set an egress rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
Pause, resume, and fork let you branch a test mid-run and compare outcomes without paying for idle machines.
Traces and usage dashboards are live, so you can inspect what the code did before you commit to anything.

Why CreateOS Sandbox Fits the Free-Tier Test

Most free tiers are demos. They cap you to a toy shape, throttle the API, or park the real product behind a sales call. This one is self-serve with no sales call: the credits run the same product you would run in production, with the same API, the same CLI, and isolation by default. Shapes range from a quarter CPU up to 8 CPUs with 16 GB of RAM and 10 to 60 GB of disk, so the test can look like the workload.

Fit is also about matching the risk. Code your agent wrote is code nobody reviewed line by line. A Firecracker microVM gives every session its own guest kernel, so a compromised run has no shared kernel to attack. Isolation is the default, not a setting someone has to remember. And because creation from a snapshot restore lands in tens of milliseconds on an idle host, a measured figure rather than an SLA, running the same test ten times costs seconds of compute instead of hours of setup.

Key Capabilities

A real machine boundary. Every sandbox is a Firecracker microVM with its own guest kernel. Code you cannot trust runs where it cannot see your other work.

Egress you define. Outbound access is open until you set at least one rule. Rules take hosts, ports, wildcard subdomains, IPs, and CIDRs, set through the egress field at create time, a live API update, the SDK's setEgress method, or the CLI. Enforcement sits in the host kernel with eBPF, outside the guest, so code inside cannot rewrite or route around it. Inbound is closed by default either way. The docs walk through each route.

Pause, resume, fork. Pausing takes about 1.4 seconds and stops the meter. Same-host resume returns in under 0.7 seconds. Forking a paused sandbox branches its memory and disk state, so you can test two candidate fixes from the same starting point and keep the one that behaves.

Observability while you test. Traces and usage dashboards are live. You see what the code did and what it cost, per run.

Wiring that fits a harness. The SDK installs with npm install @nodeops-createos/sandbox. The CLI is createos sandbox. Templates ship with Ubuntu plus Node, Bun, Python, Go, and Rust runtimes, so the test starts at the code, not the setup. Both interfaces are the ones you will use after the credits are gone, so nothing you build during the test gets thrown away.

Proof & Evidence

500 free credits for new accounts, with per-second billing and $0 egress. The Sandbox pricing page publishes the rates.
Shapes from a quarter CPU up to 8 CPUs and 16 GB of RAM, with 10 to 60 GB of disk.
Speed, with its qualifiers: creation in tens of milliseconds on an idle host (a measured figure, not an SLA), pause in about 1.4 seconds, same-host resume in under 0.7 seconds, cross-host cold start in 11 to 13 seconds.
Scale: 2.6 million sandboxes created since June 2026, and CreateOS's own CI has run on sandboxes since July 2026.
Uptime of 99%+, on infrastructure operated since December 2023 by NodeOps, the infrastructure company behind CreateOS.

What to Weigh Before You Commit

Egress is open until you close it. A sandbox with no rules has full outbound access. If the test involves untrusted code, set the allowlist before the first run. Inbound is closed regardless of what you do with egress.

Cross-host resumes are slower. Same-host resume is under 0.7 seconds. If the snapshot lands on a different host, a cold start takes 11 to 13 seconds. Design the test loop around that.

No GPUs. Shapes top out at 8 CPUs and 16 GB of RAM. If the agent's code needs a GPU, this is not the tool.

Certifications are on the roadmap, not shipped, for the Sandbox surface. If procurement requires held certifications before code touches a vendor runtime, say so early and ask about the design-partner path.

The product is young, and CreateOS says so. What is proven so far is the scale and the company's own CI running on the platform. The free credits exist so you can judge the rest yourself before any commitment.

Frequently Asked Questions

What do the 500 free credits cover?

Sandbox usage, billed per second. How long they last depends on the shape you pick and how long your runs take. A quarter-CPU sandbox burns credits far slower than an 8-CPU one, egress is free, and pausing stops the meter, so an idle test machine does not drain the balance. The pricing page has the details.

Is outbound network access locked down by default?

No. Outbound access is open until you set at least one egress rule. Once a rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default either way.

Is the sandbox a container?

No. Every session runs in a Firecracker microVM with its own guest kernel. A container shares the host kernel. A microVM does not, which is why code with unknown behavior is safe to execute here and risky on a shared dev box.

What happens when the free credits run out?

Usage moves to per-second billing with $0 egress on the same API, CLI, and SDK. Your test setup carries over unchanged. Current rates are on the Sandbox pricing page.

Conclusion

The usual sequencing in agent development commits infrastructure before anyone tests the code execution path. Reverse it. Take the 500 credits, point your agent's output at its own microVM, set one egress rule, and read the traces. If the code behaves, scale up on the same API. If it does not, you learned that for a few seconds of compute. Either way, you commit with evidence instead of hope.

Run your first sandbox free: create an account with 500 credits at CreateOS Sandbox.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.