Run AI coding agents. Skip the sandbox operations.
Run your AI coding agents on fully managed, isolated infrastructure — without building any of it. You keep the model, the reach and the budget; we keep the infrastructure.
- Repository connected
- Agent running in its own microVM
- Budget and egress enforced
Scaling agents means becoming an ops team
You wanted to ship faster with AI coding agents. Instead you are running infrastructure.
An agent that writes and runs code is untrusted code. Give it a real workload and you inherit a real ops problem:
Agent infrastructure becomes a second platform.
Spinning sandboxes up and down, wiring networking, injecting credentials and tearing down cleanly is a platform, and someone has to keep it alive. Containers share the host kernel, so real isolation means VMs — and VMs mean plumbing.
Credentials and network reach spread across scripts.
Every runner that needs a model key or a git token defines the reach of an agent in one more place. After a while nobody can say what a session can actually reach without reading all of them.
Long-running sessions need lifecycle and cost controls.
Long runs, headless jobs and parallel agents need supervision, budgets and stop conditions. Watching them is a job, and none of it ships product.
How it works
Three decisions, and the session runs on our infrastructure rather than on a runner you keep alive.
1. Connect a repository
A git remote and a scoped token. Nothing to install, and no runners to keep alive.
2. Bring the model and configuration
Your token and your provider, or an EU-hosted model. No model lock-in, and no platform to migrate off later.
3. Set the boundary and budget, then run
A runtime-minute cap and an idle timeout, both with auto-stop, and a session that reaches only what its configuration names.
Run agents, not infrastructure
ainclave is a fully managed control plane for AI coding agents. You point your agent at it and go. There is no infrastructure for you to stand up, patch or babysit.
Managed session lifecycle
Sessions spin up, run and tear down on our infrastructure. You never touch a host, and there is nothing for you to patch.
Model and repository choice
Bring your own token for the provider you already use, or run against an EU-hosted model. The repository is a git remote and a scoped per-user token.
Deny-default network boundary
A session starts with no route out and reaches only the destinations its own configuration names at create time. Enforcement sits on the host datapath, outside the guest.
Live session visibility
A running session streams a structured event feed you can watch, boundary decisions included. It is live only — persistence and export are listed under Roadmap below.
Give security a boundary they can review.
Isolation, data residency and the current limits of the boundary are documented on their own pages rather than summarised into a badge here.
What runs today, and what does not
Available now
Every line below is wired in the product today.
- One Firecracker microVM per session, with its own guest kernel.
- Egress closed by default, enforced on the host datapath.
- Bring your own token for the provider you already use, or an EU-hosted model.
- A runtime-minute cap per account and a lifetime cap per session, both with auto-stop.
- A live event feed per session, boundary decisions included.
Roadmap
Designed and not shipped. None of the following is available today.
- Session persistence, resume and fork.
- A self-service egress allowlist you edit per session.
- Persistence, export and retention for the session event feed.
- Agent-blind credential injection.
- A public CLI and agent skill.
Related
Explore the agent sandbox
What one session is, and the four things a sandbox for a coding agent has to do.
Read about microVM isolation
The control stack, layer by layer, including the parts that are not finished.
Review pricing
The billing model, which is session runtime.
Ship with agents. We keep the infrastructure.
We are onboarding a small group of design partners.