What an agent runtime sells is the time between turns

You are picking where your agents run. Most comparisons rank models, tools and integrations, and leave out the number your invoice is built from: how long the machine stays alive after the agent stops talking.

An agent runtime is the infrastructure under an agent. It boots a machine, holds it through the work, and decides what happens to it when the work pauses. Kortix is the open-source AI Operating System that runs agents on their own cloud computers, and its answer to the pause is 15 minutes. The runtimes you are likely to shortlist answer it in four different units, which is why their numbers slide past each other.

Every runtime answers the gap on a different clock

AWS quotes a deadline in minutes, E2B a default timeout plus a plan cap, Modal a meter in seconds, Daytona an interval beside a vCPU-hour rate, and LangSmith a rate in vCPU-hours. The units do not line up, so the numbers do not either.

Amazon Bedrock AgentCore ends a session "due to inactivity (default 15 minutes)" or at its "max compute lifetime (default 8 hours)". A session lasts "up to 8 hours for each lifecycle on microVMs, or up to 14 days on Instances" (AgentCore session docs). When it stops, the microVM is terminated and memory is sanitized. Files return on the next invocation only if session storage was configured.

E2B stops a sandbox before its plan ceiling. Every sandbox has a timeout, and it "defaults to 5 minutes if you do not set one", with a kill on expiry by default (sandbox lifetime). The 1-hour Hobby and 24-hour Pro figures are a continuous-runtime cap. That is the time a sandbox runs without being paused, and pausing resets it. Hobby caps at "Sessions up to 1 hour"; Pro starts from a $150 plan base and reaches "Sessions up to 24 hours". Paused sandboxes do not expire, and E2B keeps them indefinitely.

The meter is flat: "We charge per second of a running sandbox" (E2B pricing).

Modal prices the same seconds and adds a floor. Its Functions and Sandboxes are "billed by the second for CPU, memory, and GPU time", and once an application has scaled down to zero you no longer get charged. The FAQ adds a window: Modal keeps an application alive for 60 seconds after the last input, and bills that time (Modal pricing).

Daytona publishes a rule and a rate card. Sandboxes "auto-stop after 15 minutes of inactivity" by default, the interval is configurable, and 0 disables it. A Linux VM sandbox that sets neither interval pauses at 60 minutes instead, and a paused VM sandbox keeps its filesystem and memory state (sandbox lifecycle). The meter is "vCPU $0.0504/h", "Memory GiB $0.0162/h", "Storage GiB $0.000108/h", and "All billing is calculated per second" (Daytona pricing).

LangSmith Deployment meters the deployment's own machine at "Runtime Compute · 0.0675 LSU / vCPU-hr" and "Runtime Memory · 0.0090 LSU / GiB-hr", with 1 LSU at $1 (LangSmith pricing).

A deadline, a ceiling, a meter and a rate are four different objects, and comparing headlines flatters the smallest rate.

A waiting machine keeps its repo, its folders and its ports

A sandbox that stays up between messages is a Linux machine holding whatever the session mounted, and no pricing table shows that half.

One isolated sandbox per session. Each session has its own isolated machine and branch. In Kortix the project repository is cloned at /workspace on that branch (sandboxes and previews). With Files on, /drives holds the shared folders the session may read. The agent runs as the kortix user with passwordless sudo. Any server it starts is reachable from outside through a preview address. A preview request to a stopped sandbox wakes it.

They are ordinary during a turn, and they are the same 15 minutes later. For as long as the machine lives, a process with passwordless sudo can read the repository and the shared folders it was given, and answer on a port the runtime proxies to a browser.

Cloudflare reaches durability from the other side. Each agent session has "a durable identity, local SQL storage, real-time connections, scheduled work, and recoverable execution" (Cloudflare Agents). The object holds the state while the machine comes and goes. AgentCore's stop is the strictest: the microVM ends and memory is sanitized, so the interval reaches nothing.

A stopped machine reaches nothing. That sentence is the security case for a short interval, and it is also the reason a short interval hands you a cold start.

The interval is a line on the invoice

Idle time looks like a rounding error next to model spend. The meters run while the machine exists, and the interval policy decides how long that is.

The stop rule is what makes the meter safe to read. E2B's 5-minute default ends a waiting sandbox rather than billing it, so the 24-hour Pro cap matters only to work that keeps running. A session parked between messages dies unless its timeout was set to pause. Daytona's 15-minute default does the same for its default sandbox class, while its VM class swaps the stop for a pause that keeps memory and filesystem. Modal's 60 seconds after the last input is the shortest window here, and the only one Modal says it bills.

Kortix ties the two together. A sandbox stops 15 minutes after its last turn; a running turn holds it for 4 hours, renewed while Kortix sees the turn running; any new message starts a turn and wakes it (when a session sleeps). The credit meter stops with the sandbox: it "bills per second while it runs and costs nothing while it is stopped" (Kortix pricing).

So the invoice question is never the rate alone. Convert each meter to the machine size you reserve, then multiply by the hours the workload leaves it parked. Kortix's pricing page prices the computer by the second and leaves the stop rule to the docs.

What survives the stop is a branch

No runtime here keeps a machine forever, and none needs to. The work has to outlive the machine, not the other way round. In Kortix the session's branch is named after its session_id, and the agent pushes commits to it (git). Session work reaches main through a change request. Merge is default-deny for agents.

A 15-minute stop keeps the disk, the branch and the conversation, and removes running processes and memory. A server the agent started has to be started again after the wake, and a preview request wakes the sandbox, not the process. The next message resumes the sandbox in place. A new sandbox boots from the branch only when the old one is gone, after a lost sandbox is recovered or a deleted session is restored.

Four checks settle a runtime comparison

• A stop rule with two numbers. Ask when an idle session stops and when a running turn stops. A vendor that publishes one number describes half a policy.
• A store outside the machine. If files and conversation state die with the microVM, you are buying a machine and renting your own memory. Ask where they land and who can read them.
• A rate you can convert. Per second, per vCPU-hour, per LSU. Convert one hour of a parked machine at your own CPU and memory size before you look at plan prices.
• A record you keep. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan, so ask which plan, and whether the record sits in your repository or the vendor's.

Those four checks are why the interval comes first and the feature grid comes last. Kortix is the answer on all four, and three of them are written down as rules you can read before you run a single session.

Where to read next

The harness inside your repo takes the grant list apart, and what a cloud agent hands back follows the branch through review.

Run your first session at kortix.com.