AI Agents Need Stateful Computers, Not Disposable Code Sandboxes

Ivan Burazin says Daytona’s public slogan, “Run AI Code,” is useful because it is simple, but increasingly incomplete. The phrase suggests a narrow product: isolated boxes that receive generated code, execute it, and return output. Daytona’s current claim is broader. Burazin describes the company as providing “composable computers for AI agents” through an API.

That distinction matters because agents will not all need the same execution environment. A developer’s laptop, an office workstation, and a Windows machine with a graphics card for architectural rendering are all computers, but they are different compositions of CPU, memory, disk, operating system, graphics, network, and state. Agents, Burazin says, will likewise need different kinds of computers for different tasks: Linux sandboxes for code, Windows environments for legacy enterprise applications, macOS environments for Apple-specific workflows, GPU-backed machines for rendering or CAD-like workloads, and stateful long-running machines that can be paused and resumed.

The operational stakes show up in Daytona’s own scale claims: one sandbox in roughly 60 milliseconds, 50,000 concurrent sandboxes in about 75 seconds, one customer running about 850,000 sandboxes per day, mean utilization around 15% because workloads are so spiky, and RL/eval workloads expected to reach roughly half of usage in the month discussed.

Daytona’s documentation, shown during the discussion, frames the product as “full composable computers — sandboxes — that you can manage programmatically using the Daytona SDKs, CLI, and API.” The same documentation lists agent-facing tools such as file system access, Git operations, language server protocol, process and code execution, pseudo terminals, log streaming, MCP server support, and computer use. Another documentation page shown on screen describes sandboxes as isolated environments with their own kernel, filesystem, network stack, allocated vCPU, RAM, and disk. The visible docs state that sandboxes have 1 vCPU, 1GB RAM, and 10GB disk by default, and that organizations on a premium usage tier run sandboxes on 4 vCPU, 8GB RAM, and 100GB disk per sandbox.

The boundary Burazin draws is between a sandbox as a test fixture and a sandbox as production infrastructure. The word “sandbox” often implies a demo or ephemeral test environment, while Daytona is trying to provide a production-grade compute substrate for agents. The analogy he returns to is the human computer: a worker does not want a laptop arbitrarily shut down mid-task, and does not expect all work to fit inside a stateless function invocation. An agent, in his telling, needs the same basic affordances: state, persistence, speed, and access to tools.

The market is therefore not sized by today’s developer population. Burazin contrasts the already-large market for human engineering environments with “the market for every single agent that will exist ever in the future.” If every meaningful agent task needs a computer, the compute layer is not a developer-tool niche; it is a candidate cloud substrate.

Daytona did not begin as an agent-compute company. Burazin and his co-founder had spent years circling the “end of localhost” thesis. Before Daytona, they had built CodeAnywhere, which Burazin describes as one of the first browser-based IDEs. CodeAnywhere attracted roughly three million users, but it arrived before today’s surrounding stack: no VS Code, no Kubernetes, and Docker either just emerging or not yet public, by Burazin’s recollection. They had to build much of the infrastructure themselves.

That experience later became relevant, but Daytona’s immediate predecessor was not an agent product. It was an attempt to automate development environments for human engineers: the underlying stack of CodeAnywhere made modern. The hard pivot came in January 2025, after a failed attempt to take that human-dev-environment product and adapt it for agents.

Burazin says the initial signal came at the end of 2024. Devin was not yet public; Shawn Wang says he had given Burazin access, and OpenDevin, now OpenHands, was available. Daytona tried to combine its development environment infrastructure with OpenDevin and launch that as a SaaS product. Few users signed up. But people building agents reached out with a different request: their agents needed a compute sandbox or runtime.

Daytona first offered those builders the infrastructure it already had. The answer was broadly negative. Burazin says 20 or 30 early users told them it was not what they needed and that it broke in the wrong ways. That was the first important lesson: agent infrastructure looked superficially similar to human development environments, EC2, VMs, or existing cloud primitives, but the requirements were different.

Burazin, who describes himself and his co-founder as infrastructure people rather than AI people, responded by trying to understand the agent market directly: podcasts, blogs, conferences, meetups, white papers, and customer conversations. On New Year’s Eve, after putting his wife and baby daughter to sleep, he “half-vibe coded” the first MVP of what Daytona would become. He sent it to his CTO, who, according to Burazin, called it “absolute garbage” but said the idea was good. The CTO rebuilt it over two weeks.

When Daytona showed that rebuilt version to the same people who had rejected the earlier product, the reaction changed. Fifteen-minute calls became 25- or 30-minute calls. The product had no login, only API keys, but users wanted access immediately. If Daytona did not send an API key the next day, those users followed up asking where it was.

The first version was still basic: a Linux box where users could define CPU count, disk, and RAM. It did not yet support multiple operating systems, live resizing, GPUs, or the broader set of composable-machine capabilities Daytona now discusses. But it contained the new primitive: an agent-oriented, API-controlled machine.

Daytona was bare metal from the start. Most providers, in Burazin’s description, run sandboxes on top of VMs, often using Firecracker or similar isolation layers. Daytona can use multiple isolation layers too, but its core design choice was different: run on bare metal, write its own scheduler, use local disk, CPU, and RAM, and preload templates or snapshots on the underlying machines.

The goal was to combine two properties that conventional cloud primitives usually separate. Daytona wanted startup behavior closer to Lambda, but with long-running state closer to EC2. Agents, Burazin says, want machines that are fast to start and also durable enough to pause, resume, and preserve work. They do not want a preemptible box with an arbitrary time limit, nor a machine whose disk state is outside the sandbox abstraction.

The company looked at Kubernetes and Nomad, but found they did not enable the combination it wanted. That pushed Daytona back toward lessons from CodeAnywhere, where the team had built its own scheduler years earlier. Burazin says the third co-founder joked that the new architecture looked like “2008”; the CTO’s answer was effectively that those older learnings were exactly what the workload needed.

The performance argument depends heavily on locality. Daytona preloads snapshots on bare metal machines, stored on local NVMe drives. When a sandbox is created from a template or snapshot, the request is routed to the machine where that snapshot already exists. That avoids network latency between the compute machine and remote block storage such as EBS. The sandbox turns on locally, with local I/O.

A ComputeSDK sandbox benchmark leaderboard shown on screen listed Daytona near the top by sequential time to interactive, close to providers such as archil and deslow and ahead of several better-known names. Burazin says sandbox definitions vary across providers, and that benchmarks do not map directly to market share or revenue. His point is narrower: providers still need to be competitive on time to interactive because it is table stakes.

For concurrent startup, Burazin says Daytona can spin up 50,000 sandboxes in about 75 seconds. He contrasts that with public data from other providers that, in his telling, can take roughly 2,000 seconds for similar high-concurrency startup. The largest current customer, he says, runs just shy of a million sandboxes daily — about 850,000 per day. Daytona has also received a request for half a million concurrent sandboxes, which he describes as “literally half a million CPUs somewhere running.”

Cost is shaped by the same resource hierarchy. CPU is the most expensive resource, followed by RAM, then network from Daytona’s perspective because Daytona was not charging customers for network at the time, and then disk. Disk size and transfer matter, especially around snapshots, but CPU remains the main cost driver.

Burazin divides Daytona’s usage into two broad workload families: background or long-running agents, and reinforcement-learning or evaluation workloads. Their utilization patterns are different enough that they create different operating problems.

Background agents, in his description, look more like human work. He names companies such as Cognition, Lovable, and Harvey as examples of long-running agent products. Usage follows the sun: noon is higher, midnight is lower, weekdays are higher, weekends lower. It is global, with Daytona seeing usage across Asia, Europe, and the United States. Burazin says Singapore is Daytona’s top city by user headcount, not by revenue, and that Tokyo and Brazil also show up strongly.

That global spread helps distribute load, but it does not solve the newer workload pattern: RL and eval runs. Those arrive as rectangular bursts. A customer may use nothing, then ask for 10,000, 50,000, or 100,000 CPUs at once, run the job, and drop back down. These are not necessarily aligned to business hours; researchers may launch a run at midnight and check results in the morning.

This changes capacity planning. For follow-the-sun agent products, a provider can project growth and allocate capacity gradually. For RL and eval workloads, the provider must be ready for peak. Daytona therefore locks some of those customers into commits, because the company has to reserve capacity for bursts.

The utilization consequence is severe. Burazin says Daytona’s mean utilization is about 15%, while peak utilization can reach 90%. That gap is not framed as ordinary inefficiency; it is a property of a new demand curve. The infrastructure problem is not merely to lower startup latency, but to make enough CPU available at the exact moment a run begins.

This was one of the shared themes at Daytona’s Compute Conference, which brought together people building infrastructure for AI agents. Burazin says that in conversations with Parag Agrawal of Parallel, Lin Qiao of Fireworks AI, and Nikita from Neon, he heard versions of the same problem: agent-first infrastructure produces unpredictable, spiky workloads. He contrasts this with the way Cloudflare can move workloads geographically and optimize utilization around more predictable human traffic. That model helps with follow-the-sun load, but not with midnight research runs that jump by orders of magnitude.

There are two basic ways to handle overflow, as Burazin presents it. One is overprovisioning: own or reserve enough capacity to absorb bursts. The other is what he calls “just-in-time compute”: when usage exceeds available capacity, request VMs or bare metal from other cloud providers, provision them, and route work there. That can be more cost-effective but slower. For RL workloads paired with expensive GPUs, slowness becomes costly because GPUs may be waiting on CPU-side environment startup. If a GPU is expensive, the customer wants it running near 100% utilization; CPU sandbox delays can make the GPU idle.

RL and eval workloads went from zero to roughly half of Daytona usage in only a few months, according to Burazin. By the month of the recording, he expected them to reach 50%.

The technical shape of those workloads differs from dynamically generated one-off code. For a run, customers often start from a snapshot. Daytona’s declarative image builder lets them specify dependencies, environment variables, and other image requirements on the fly when creating sandboxes. Daytona builds the image, propagates the snapshot, and then customers can spin up many sandboxes against it. If the next run needs different packages or configuration, the model or automation layer can modify the image and repeat the process.

In this environment Daytona is usually competing not against another “sandbox” brand in the abstract, but against managed Kubernetes: EKS, GKS, and similar systems. Burazin says teams that try Daytona versus EKS or GKS tell him they are not going back.

The reasons are practical rather than ideological. First is ergonomics. Kubernetes requires teams to manage the interface and orchestration interactions themselves. Daytona, although compute infrastructure, behaves more like Twilio or Stripe from a consumption perspective: API, SDK, and direct provisioning. Second is speed and scale. Third is live resource flexibility. Daytona can dynamically resize sandboxes on the fly, making out-of-memory failures much harder than in most alternative systems, Burazin says.

The workload also benefits from nested execution. Daytona’s default isolation, as Burazin explains it, is Docker hardened with Sysbox: a container interface that he says is security-equivalent to a VM while remaining a container. Daytona enables Docker-in-Docker, Docker Compose, and even K3s inside sandboxes. Burazin says that matters for RL runs that need nested workloads and unlocks jobs that are harder to support on other providers.

The Harbor and Terminalbench ecosystem appears to have helped pull Daytona into this use case. A Harbor documentation page shown on screen listed integrations with cloud sandbox providers “like Daytona, Modal, E2B and Runloop for horizontal scaling.” Burazin says there are stronger Daytona mentions in other places, and that the Terminalbench and Harbor teams liked Daytona’s Docker-like interface and nested-workload support. He also says Daytona did not pay for those mentions.

The product roadmap is tightly coupled to customer repetition. If three to five customers ask for the same thing in a week, Daytona treats it as roadmap signal. The ecosystem is small, customers talk to one another, and models are advancing in parallel, so requests cluster. Daytona maintains around a thousand Slack Connect channels, by Burazin’s estimate, and he tries to be in as many sales and customer conversations as possible.

The next large claim is that agents need computers not only for code, but for graphical and legacy application work. Daytona has been investing in “computer use”: programmatic control of desktop environments within sandboxes. The documentation shown on screen says computer use provides mouse movements, keyboard, screen recording, and display operations for automating GUI interactions and testing desktop applications; it works with VNC for manual interaction and exposes a programmatic API for agents. Linux is available, while Windows and macOS support are described as private alpha.

Burazin frames this as part of a broader “human emulator” trend. Models are sophisticated enough to do useful work, he says, but do not yet have access to all tools. He personally believes the most efficient agent interface is usually headless, through a terminal or similar mechanism. But much knowledge work is not available through clean APIs or headless systems.

His market arithmetic is deliberately rough. Burazin says there are about 100 million knowledge workers in the United States and about one billion worldwide, with aggregate salaries of roughly $10 trillion in the U.S. and $50 trillion worldwide. He then narrows to five major sectors such as healthcare, government, and financial services, which he says account for about 56% of that work. Treating that as roughly half, and assuming agentic automation could capture a larger share than traditional RPA — he uses 40% as a hypothetical versus 25% in an RPA-like market — he gets to roughly $10 trillion per year in potentially automatable work. He is explicit that this is TAM for models and agent systems broadly, not Daytona’s direct revenue.

The infrastructure point is that much of that work is still locked inside Windows applications and enterprise software that will not be rewritten soon. Today, Burazin says, the main options for Windows machines are EC2 with Windows or Azure, and those can take three to five minutes to spin up. Daytona’s goal is to provide Windows as an actual sandbox, with startup in seconds, point-in-time snapshots, forking, and the other sandbox affordances.

His own board-deck example explains why APIs are not enough. Burazin tried to automate board reporting with Claude Code connected to systems such as ClickHouse, PostHog, QuickBooks, and Brex. The agent could pull some reports, but repeatedly produced polished documents that contained “partial data” or “missing data” because not everything was exposed through MCP, APIs, or integrations. He then created a Mac Mini virtual sandbox with OpenCore, gave it a company account like an intern, and created read-only accounts across services. When the agent hit an API limitation, he told it to log in. It could use the website, export the data, and complete the report.

That experience leads him to a broader conclusion: even a startup using modern tools still needs computer-use agents, so large enterprises with legacy systems will need them even more.

Mac support is harder for reasons Burazin attributes to Apple licensing and technical constraints. He says macOS permits only two parallel VMs per machine and allows licensing to a different user only every 24 hours. If Daytona charged a user for one second of macOS sandbox use, it would still have to leave that capacity idle for the rest of the day, forcing 24-hour pricing. He also says macOS memory snapshots, pause, and resume are limited to the same physical machine, preventing the kind of background migration Daytona can use with Windows or Linux to manage load. He understands the security rationale, but says it undermines scalable agentic workloads.

Burazin expects Daytona to offer macOS sandboxes soon, but with different pricing and a stricter feature set. He also argues that Apple is missing a compute or licensing revenue opportunity by not enabling a concurrency model more like Windows and Linux.

Shawn Wang presses Burazin on MCP versus CLI, and the answer is that the trend toward CLI-capable agents helps Daytona because it moves work from narrow integrations into executable environments. MCP, in Burazin’s framing, is an interface against an API. A CLI lets an agent actually do things: run scripts, inspect data, perform analysis, and combine tools in ways an API integration may not expose.

This connects to the Claude Code and Anthropic Agent SDK effect. Claude Code was “very interesting” for Daytona, Burazin says, because app-layer agent companies realized they could build a new agent product by putting Claude Code inside a sandbox and building a human-facing interface around it. That increased demand for sandbox compute.

Wang characterizes this as a layer-of-indirection shift similar to agentic search versus RAG: instead of retrieving from a fixed interface, the agent acts through tools. Burazin agrees. The more workflows include agents that can use terminals and run commands, the more often those workflows need sandboxed computers.

The same logic explains why he thinks agent builders will need sandboxes for “every single thing.” He compares it to a laptop: one person uses a computer every day, and that person is an N of one. If every agent task needs its own machine, the number of required computers could exceed the human PC market. Burazin says the PC market is roughly comparable to the three hyperscale cloud providers in annual size, around $150 billion to $180 billion, and then asks how many agents will be running in two, ten, or a hundred years. In his framing, the addressable demand is effectively unbounded.

He also cites Dylan Patel of SemiAnalysis, who spoke at Daytona’s conference, as saying CPUs may become a bottleneck as agent compute grows. Wang adds that SemiAnalysis has discussed shortages cascading from GPUs to memory and CPUs, with networking already constrained in some GPU contexts. Burazin’s point is not that GPUs stop mattering; it is that agent execution creates a CPU demand curve of its own.

Daytona is open source, but Burazin is careful about what that has and has not done for the business. The original Daytona product was open source, and that helped the company. He jokes with Wang about the hierarchy of startup metrics: strong companies measure free cash flow, weaker ones EBITDA, and the weakest GitHub stars. Daytona started closer to the GitHub-star stage and has since moved toward revenue as the relevant metric.

Before the pivot, Daytona split its core into a clean Apache 2.0 repository and bundled enterprise features separately in a proprietary repo. During the pivot, the team did not have time to rethink everything and did not want to abandon the open-source community. For the new sandbox product, Daytona used AGPLv3. Burazin describes this as a licensing trade-off: it keeps the project open and usable, including by enterprises, while adding a restriction that makes it harder to build a closed-source competitor directly on top of Daytona’s work.

Nearly everything outside feature-flagged areas such as Windows and GPU work is in the open-source repository, including Daytona’s scheduler, according to Burazin. Some competitors, he says, have told Daytona that it is “actually open source, open source.”

The surprising benefit is not classic self-host-to-cloud conversion. Open source has helped consumption of Daytona’s cloud product because agents integrating Daytona can inspect the repository and get more context about how it works. Wang notes that good docs might provide similar context, and Burazin agrees in principle. But the repository gives the agent another source of truth.

Open source also has not been the main route into enterprise accounts. Wang describes the common argument that open source can be either a free tier or a way into large companies that would not otherwise approve a young vendor. Burazin says that has historically been true, but in the current AI transition, market pull is strong enough that Daytona can move through procurement unusually quickly. Daytona’s customers range, he says, from single developers and YC startups to Fortune 5 companies and large “neo labs.” In some large-company cases, customers themselves push Daytona through vendor approval. Processes that normally take two or three months can take five days, according to Burazin. He presents that less as proof of Daytona’s greatness than as evidence of market urgency.

The emergence of agent-first coding workflows is also stressing adjacent tools. Many long-running background agents were initially coding agents, and Daytona saw customers struggle with versioning. GitHub, in Burazin’s view, is not designed for the agent inner loop. It is post-laptop infrastructure: the place code goes after local work, where the outer loop begins. Sandboxes, by contrast, are increasingly where inner-loop work happens.

Some customers therefore invented unusual alternatives. Burazin describes one customer that periodically dumped the entire codebase inside a sandbox into JSON and pushed it to S3. There were no diffs; it was a full snapshot every time. Because the files were text and relatively small, the network cost was acceptable, and the approach was fast. To Burazin, that kind of workaround is evidence that a new agent-first versioning layer is needed. Git and GitHub may still exist as deployment artifacts or CI triggers, but something else may sit before them as an agent collaboration layer.

CI/CD faces a related pressure. Agent-generated pull requests can increase throughput dramatically. Burazin says one company Daytona spoke with was creating about a thousand PRs a day and then waiting in CI queues. The bottleneck is not only GitHub Actions; high-throughput PR workflows can strain any CI provider. Wang observes that Daytona’s technology could be used for CI runners, and Burazin says that was indeed the conversation with some customers, though Daytona is not positioning itself as a CI provider.

The possible fit is straightforward: a Daytona sandbox could replace or augment the machine currently used as a CI runner. Wang questions whether CI is too cheap and background-oriented to be attractive; Burazin counters that performance still matters. The discussion stops short of claiming Daytona will become a CI company, but it treats agent-driven CI pressure as another example of old developer infrastructure meeting a new workload shape.

When Wang asks what actually sells startups after they compare Daytona against a wall of competitors, Burazin does not lead with benchmarks. The most common reason customers come back, especially after initial evaluation, is “insane responsiveness” from the team.

The company has third-party case studies in which customers are more candid than they might be with Daytona directly. Those interviews sometimes include praise for competitors or criticism of Daytona, but the repeated differentiator is support. Customers message in Slack, ask for a huddle, and Daytona joins within minutes. Email and calls exist, but Slack Connect is the dominant channel.

Daytona had 25 people at the time of the discussion. Burazin says the support posture is possible partly because many employees have worked together for years: of the 25, about 13 had worked with Burazin and the founders for seven years or more. Newer hires are often one degree removed. That creates a high-trust, high-throughput operating mode with an expectation of being online and responsive.

For Daytona, responsiveness is not just a support policy; it is part of the company’s product posture in a market where customers are building on unstable new primitives and need rapid answers when workloads break.

Burazin’s broader startup-market critique is that investors and founders may be overvaluing SaaS vendors that show reacceleration by reselling model tokens through AI features. His argument is about revenue quality. Traditional SaaS revenue had certain margins, stickiness, and economics. If a SaaS company now sells an embedded agent powered by Anthropic, OpenAI, or another model provider, the gross margin structure is different. Treating that token pass-through as equivalent to the old SaaS revenue is, in Burazin’s view, wrong.

The second part of the critique is product utility. Burazin says he often does not want a SaaS vendor’s agent. He wants the SaaS vendor to expose the data and functionality to his agent. The current problem is data siloed across systems: ClickHouse, QuickBooks, and other applications. If each vendor adds its own agent, the data remains siloed and the user still has to move information between agents. Burazin’s preferred model is API consumption: keep seat-based pricing for human users, expose the product’s capabilities through APIs, and charge for agent usage. If the product has value, more agents will call it and revenue will grow from real consumption.

He points to a recent Marc Benioff post that, as Burazin recounts it, said every Salesforce product had been exposed via an API. Burazin’s reaction was strongly positive: that is the direction of the world. Real acceleration from API consumption would be meaningful; token resale dressed up as SaaS reacceleration may face a “cold shower” when customers do not continue paying for the embedded agents at the assumed levels.

He is not condemning companies for trying. Everyone has to get revenue, multiples, valuations, and the next financing step. His objection is to the community treating token resale as a magical route out of slower SaaS growth.

Daytona expects to offer GPU sandboxes, but not primarily for inference. The model is again the computer: if a computer can have a GPU, a sandbox should be able to have a GPU. Burazin gives 3D rendering as the simplest example, and says RL on CAD-like workloads would need GPU-backed sandboxes.

Daytona currently runs on bare metal machines through colocation providers rather than owning data centers. The architecture could run in Daytona-owned data centers, but that does not make sense yet from a gross-margin and risk perspective, according to Burazin. Owning data centers would require large capital raises and significant risk for what he describes as single-digit percentage-point gains. Still, the architecture preserves the option.

The bigger strategic question is what this market becomes. Daytona had publicly shown close to 75% month-over-month growth after giving up a purely self-hosted model. Burazin also asserts that the broader infrastructure market around this category is growing around 40% month over month, and half-jokingly says that if a company in the market is not growing around that rate, it may simply be underperforming the market itself.

He also thinks CPU supply may become a go-to-market weapon. GPU providers are already constrained by how many GPUs they can obtain. CPU-heavy infrastructure companies — sandboxes, databases, deployment platforms — are not yet constrained in the same way, but Burazin expects that as agent demand grows, having CPUs available in advance may matter.

When Wang asks whether the analogy is the new Heroku, new AWS, or new Stripe, Burazin rejects a simple “AWS for AI agents” framing. There will be a cloud built specifically for agents, he says, but it may look more like Stripe than AWS: API-first, developer-consumable, abstracted into primitives that agent builders call directly. That agent cloud would include sandboxes, web search, databases such as SQLite or Neon-like systems, and other primitives that do not yet exist.

Cloudflare, in Burazin’s view, understands much of the go-to-market vision for agents, even if he sees technical limitations in constraining everything under Workers. But the larger point is that the current set of primitives is incomplete. Sandboxes are one piece. Web search and databases are others. More agent-native infrastructure will be built.