Code interpreters handle isolated, short-lived execution tasks — run a script, return a result, discard everything. Agent runtimes handle multi-step workflows that require persistent state, tool access, browser control, file I/O, or long-running sessions. The right choice depends on your workload, not on the label a product uses to describe itself.
What a Code Interpreter Actually Does
A code interpreter gives a language model a way to run code and see the output. The model writes a Python script, the interpreter executes it in isolation, and the result comes back as text, a file, or a rendered chart. When the session ends — or even between turns in some implementations — the environment is reset. Nothing carries over.
That design is intentional. Code interpreters prioritize safety and simplicity over continuity. The isolation boundary is tight because the only thing that needs to happen is: run this code, return this result.
The practical footprint is small: a sandboxed Python (or similar) runtime, a filesystem scoped to the session, enough network access to fetch libraries or external data if the use case needs it, and a mechanism to return artifacts. The session might live for 30 seconds or 10 minutes, but the app treats it as fundamentally ephemeral.
This maps cleanly to several high-value workloads:
- Single-script execution: a user asks the model to compute something, and the result comes back as a number, table, or file.
- Data analysis: upload a CSV, generate a summary, produce a chart. The work starts and finishes within one interaction.
- Quick computation: math, data transformations, format conversions, and similar tasks that fit in a single code block.
- Educational environments: where each exercise is isolated and there is no expectation of session continuity.
What code interpreters do not handle well is anything that requires the environment to remember something, take an action outside the sandbox, or continue working after the user stops watching.
What an Agent Runtime Adds
An agent runtime is an execution environment designed for work that spans multiple steps, involves external tools, and may take minutes or hours rather than seconds. The session is not discarded between steps — it is a workspace the agent uses to build toward a goal.
The practical additions over a simple interpreter are significant:
Persistent workspace: files written in one step are still there in the next. A coding agent can create a branch, edit files, run tests, fix failures, and push a commit — all within one session, without starting over.
Installed packages and system tools: an agent runtime typically supports installing dependencies, running shell commands, calling CLIs, starting background processes, and working with a real development environment rather than a locked-down Python sandbox.
Browser and web access: agents that need to read documentation, interact with web apps, fill forms, or automate web workflows need a browser in the execution environment. A code interpreter has no concept of a persistent browser session.
File storage and artifact persistence: outputs that need to outlast a single execution — generated code, intermediate data, downloaded files, screenshots — need a filesystem that persists across steps and, in some cases, across sessions.
Long-running sessions: some agent tasks take 20 minutes. Some take longer. An agent runtime is designed to stay alive for the duration of a workflow, not to spin up and tear down for each function call.
Multi-tool orchestration: real agent workflows involve calling multiple tools in sequence — a web search, followed by a file edit, followed by a test run, followed by a git push. An agent runtime is built to coordinate that chain reliably.
The tradeoff is real: agent runtimes are more complex to operate, cost more per session than a lightweight interpreter, and expose a larger attack surface that requires careful policy configuration. For workloads that fit the interpreter model, adding all of this complexity is waste.
Key Decision Dimensions
The table below maps the practical decision criteria. Most apps fall clearly on one side; hybrid patterns are covered in the next section for cases that span both.
| Dimension | Code Interpreter | Agent Runtime |
|---|---|---|
| Session lifetime | Seconds to minutes, ephemeral | Minutes to hours, persistent |
| State between steps | Discarded or limited | Preserved |
| Tool access | Code execution only | CLI, browser, file I/O, APIs, subprocesses |
| Package install | Fixed image or restricted | Dynamic, with policy controls |
| Browser/web interaction | Not available | Supported |
| File storage | Session-scoped only | Persistent across steps |
| Cost per session | Low | Higher |
| Infrastructure complexity | Low | Higher |
| Human-in-the-loop checkpoints | Not typical | Common — approve before deploy, merge, or external action |
| Concurrency model | Many parallel short sessions | Fewer longer sessions |
Session lifetime and state requirements are the fastest filters. If your workload resets between turns, use an interpreter. If your workload builds toward a goal across multiple turns, use a runtime.
Tool breadth is the second filter. Browser control, git operations, CLI tools, and external API calls require a runtime. If your only tool is code execution, an interpreter is sufficient.
Human-in-the-loop checkpoints almost always indicate a runtime. Pausing a session to wait for approval and then continuing requires persistent state and a session that can be resumed. Interpreters are not designed for this.
Where Code Interpreters Fit Best
Code interpreters are the right choice when execution is bounded and self-contained. The strongest use cases:
Data analysis assistants: the user uploads a file, asks a question, gets back charts and summaries. The work is done when the model returns the output. There is no next step that depends on memory of the previous one.
Math and computation tools: calculators, unit converters, statistical analysis, numerical simulations. These are single-pass: input goes in, output comes out.
Automated reporting: scheduled jobs that generate a report from a data source and email it or save it. The job runs, produces an artifact, and exits.
Chart and visualization generation: the model writes matplotlib or similar code, the interpreter runs it, and the user gets an image. No need for a persistent environment.
Sandboxed LLM tool use: when a model needs a code_interpreter tool to reason over data, verify calculations, or format output — and nothing else — a code interpreter is precisely what the API is designed for.
The appeal of interpreters in these scenarios is practical: they are cheaper per session, easier to operate, and simpler to secure. There is no persistent state to manage, no session lifecycle to track, and the attack surface is narrow because the code runs once and the environment disappears.
Where Agent Runtimes Fit Best
Agent runtimes are the right choice when a task cannot complete without coordinating multiple tools over time, maintaining state across steps, or taking actions outside the code execution sandbox.
Coding agents: an agent that reads a codebase, writes changes, runs the test suite, fixes failures, and opens a pull request needs a persistent workspace with git, a terminal, and a file system. This is architecturally incompatible with an ephemeral interpreter.
Browser and web automation agents: scraping dynamic content, filling forms, navigating multi-step web flows, extracting structured data from visual interfaces — all of these require a real browser session that persists long enough to complete the workflow.
Research and data collection pipelines: agents that retrieve documents from multiple sources, cross-reference information, write intermediate results to disk, and produce a final synthesized output need a workspace that persists across all of those steps.
Evaluation and RL workloads: running many agent episodes in parallel, each maintaining its own state, tracking scores, and writing checkpoints requires a runtime designed for concurrency and session isolation at scale.
Long-running infrastructure agents: agents that provision resources, run deployments, monitor outputs, and react to changes over a multi-minute or multi-hour window need a session model that can pause, resume, and checkpoint.
Agentic coding tools like Codex-style agents or IDE-connected agents that take actions on a real project need the full surface of a development environment — not a sandboxed interpreter.
The cost of a runtime is justified when the alternative is manually wiring together state management, tool coordination, and session persistence yourself. The runtime provides that infrastructure; you configure the policy.
Hybrid Patterns: Using Both in One App
Many real applications embed both patterns. A coding assistant might use an agent runtime for the overall session — maintaining repository context, tracking which files have been changed, managing a branch — while calling a code interpreter specifically for running tests or executing sandboxed user-supplied scripts as a sub-operation within the larger agent workflow.
A data analysis product might use an agent runtime to orchestrate the full workflow — downloading data, cleaning it, joining multiple sources — while using isolated interpreter invocations for the individual computation steps where tight sandboxing matters and state does not need to persist.
The pattern looks like this in practice:
- The outer layer is an agent runtime: it holds the session, coordinates tools, and manages state.
- Inner operations that require tight isolation use short-lived code interpreter invocations as one tool among many.
- The agent runtime decides when to invoke the interpreter, what inputs to pass, and what to do with the output.
This is not a complex architectural pattern; it is just using each layer for what it is designed for. The agent runtime manages the workflow; the interpreter handles sandboxed execution when needed.
Evaluating Sandbox Infrastructure for Each Model
Whether you are evaluating a managed sandbox provider or designing your own, the questions you need to answer differ significantly based on which model you are building for.
For code interpreter workloads, the evaluation criteria are relatively narrow:
- What is the startup latency? Sub-second startup matters for interactive use.
- What languages and packages are available in the default image?
- Can users install additional packages, and is that allowed by your security model?
- What are the resource limits (CPU, memory, execution time)?
- How are session artifacts returned — synchronous response, file download, or presigned URL?
- Is there a persistent filesystem option, or is everything discarded on exit?
For agent runtime workloads, the criteria expand considerably:
- Does the environment support persistent filesystems that survive across steps in a session?
- Can the session be paused and resumed — for human-in-the-loop workflows or cost management?
- Is there browser support, and how is it configured?
- What shell tools and CLIs are available?
- How is network access controlled — egress policies, DNS filtering, outbound allowlists?
- What is the session concurrency model, and how does it scale?
- How are secrets injected and scoped?
- What observability exists — command logs, file change tracking, resource metrics?
- How does the platform handle long-running sessions that outlast typical request-response cycles?
Novita Agent Sandbox is designed for agent runtime workloads — coding agents, browser automation, data analysis pipelines, and evaluation/RL workloads that need persistent state, tool access, and session control. It uses microVM isolation, supports Pause/Resume, and integrates with Novita’s model API platform so teams that use Novita for LLM inference can run sandbox workloads on the same platform. For teams evaluating sandbox infrastructure for agent workflows, the Novita Agent Sandbox documentation covers isolation model, lifecycle API, and resource configuration.
For workloads that are genuinely interpreter-only — single-script, ephemeral, stateless — a full agent runtime is overhead you do not need. Use the simpler tool.
The practical test: can your workflow complete correctly if the execution environment is destroyed and rebuilt between every model turn? If yes, an interpreter is likely sufficient. If no — because state, tool access, or session continuity matter — you need a runtime.
FAQ
What is the main difference between a code interpreter and an agent runtime?
A code interpreter executes code in a sandboxed environment and discards the environment when the session ends. An agent runtime maintains a persistent workspace — with files, installed tools, browser access, and session state — across multiple steps of a workflow. The interpreter answers “run this code and return the result”; the runtime answers “work toward this goal across as many steps as needed.”
Can a code interpreter use tools like web search or file access?
Some code interpreter implementations support limited tool use — file uploads, network calls within the sandbox, or returning artifacts. What they do not support is a persistent workspace that carries state across turns or a browser session that outlasts a single function call. If your app needs to read a web page, write a file, and then reference that file in a later step, you need a runtime.
Is an agent runtime always more expensive than a code interpreter?
Per-session, yes. Agent runtimes involve more infrastructure — persistent filesystems, longer-lived processes, browser or CLI access — and those components cost more than a short-lived interpreter sandbox. For workloads that genuinely require multi-step coordination, the runtime cost is justified. For single-pass tasks, it is overhead.
When should I use both in the same application?
When the outer workflow requires persistent state but individual sub-operations benefit from tight isolation. A coding agent that runs the test suite in a sandboxed interpreter, or a data pipeline that delegates computation steps to ephemeral interpreters while the orchestration layer holds the overall state, are both common hybrid patterns.
Does Novita Agent Sandbox support both models?
Novita Agent Sandbox is designed for agent runtime workloads — persistent workspaces, Pause/Resume, browser access, and multi-step session control. For isolated, ephemeral interpreter invocations, lighter-weight execution may be more appropriate depending on your use case. See the Novita Agent Sandbox documentation for current capability details.
How do I know if my workload needs a runtime?
The practical test: can your workflow complete correctly if the execution environment is destroyed and rebuilt between every model turn? If yes, an interpreter is sufficient. If the answer is no — because state, tool access, browser control, or session continuity matter — you need a runtime.
