Ask a language model to compute the EMI on a ₹12 lakh loan at 9.2% over seven years and it will give you a number. The number will look right. It will have the right number of digits, land in a believable range, and be delivered with total confidence. It will also, quite often, be wrong.
This is the gap that code execution tools exist to close. Instead of the model reasoning about the arithmetic, it writes a few lines of Python, runs them, and reports what actually came back. AWS ships this as a managed service under Bedrock AgentCore, and once you look past the name it turns out to be a more interesting piece of infrastructure than “sandbox for the LLM” suggests.
I’ve been building on AgentCore for a while now, and the question I keep getting asked is some version of: why wouldn’t I just use Lambda for this? It’s a fair question. The answer is more about trust boundaries than about compute.
What it is
AgentCore Code Interpreter is one of the built-in tools in the AgentCore family. It gives an agent a sandboxed environment where it can write and run real code — Python, JavaScript, or TypeScript — and get the actual output back, including tracebacks and generated artifacts like charts.
The environment is a dedicated microVM with its own CPU, memory, and filesystem. When the session ends, the microVM is torn down and its memory sanitised, so one user’s session can’t leak into another’s. You configure a network posture when you create the tool: Sandbox for limited external access, Public if the code genuinely needs to reach the internet, or VPC. You also attach an IAM execution role, which determines what AWS resources the code inside the sandbox can touch.
File handling is more generous than you’d expect. Inline uploads go up to 100 MB, and if you push files to S3 through terminal commands inside the session you can work with objects up to 5 GB.
The part people get wrong
Code Interpreter is not welded to AgentCore Runtime. AgentCore is a set of composable services — Runtime, Gateway, Memory, Identity, Observability, Browser, Code Interpreter — and each one bills separately and works on its own. The whole platform is framework-agnostic: LangGraph, CrewAI, LlamaIndex, Strands, or your own hand-rolled loop.
In practice, Code Interpreter is just an AWS API with session semantics:
from bedrock_agentcore.tools.code_interpreter_client import CodeInterpreter
client = CodeInterpreter('ap-south-1')
client.start()
response = client.invoke("executeCode", {
"language": "python",
"code": "import pandas as pd; print(pd.__version__)"
})
client.stop()Or with boto3 if you want to manage session lifecycle yourself — start_code_interpreter_session, invoke, stop_code_interpreter_session.
Which means anything holding AWS credentials can drive it. A Lambda. An EKS pod. A script on your laptop. A node inside a LangGraph agent running on someone else’s cloud entirely. Runtime gives you session isolation and identity propagation for free, and that’s genuinely useful, but it isn’t a prerequisite.
So how is this different from Lambda?
The difference is when the code exists.
With Lambda, you write the function, review it, package it, deploy it. The code is a known quantity by the time anything invokes it. You’re paying AWS to run your artifact on demand.
With Code Interpreter, the code doesn’t exist until runtime. A model writes it, and you ship it across the wire as a string to be executed. Nobody has read it. Nobody has approved it. It might import something strange, or loop forever, or try to curl an endpoint in a country you’ve never done business with.
Every other difference falls out of that one.
State. Lambda is stateless by contract. Warm container reuse is an optimisation you shouldn’t lean on. Code Interpreter is explicitly session-based — you start a session, run code, and the state persists between executions. Variables stay in memory. Files stay on disk. The model runs something, reads the traceback, fixes line four, and re-runs with the DataFrame from step one still loaded. Reproducing that iteration loop on Lambda means round-tripping state through S3 on every hop, and at that point you’ve built a worse version of this service.
Trust model. Both use Firecracker-style isolation, but the boundary is drawn differently. Lambda’s blast radius is scoped to a function version whose code you wrote. Code Interpreter’s is scoped to a session running code you didn’t write, with network egress denied by default. Sandbox mode is doing real work there.
Billing shape. Lambda charges GB-ms of wall clock during the invocation. Code Interpreter bills per second across the whole session lifetime, splitting CPU and memory: CPU is charged on actual consumption, so I/O wait and idle time are free if nothing is running in the background, but peak memory is billed for every second the session is alive. That asymmetry is the one that catches teams out. A session held open “just in case” while the model thinks, or while a user takes ninety seconds to type their next message, is quietly accruing memory charges the entire time. Explicit stop calls and aggressive idle timeouts matter far more here than they do for a Lambda you simply stop invoking.
Concurrency. This is the one that bites at scale. The default quota sits around 25 concurrent sessions per account per region for tools like Code Interpreter. Lambda’s default is 1,000 and adjustable into five figures. Both are adjustable, but they’re different orders of magnitude and you should design accordingly. Check Service Quotas for your region before you commit to an architecture.
Runtime environment. With Lambda you own the deployment package, the layers, the pinned versions. Code Interpreter gives you pre-built runtimes with the usual analysis libraries, and package installation is restricted — that restriction is one of the documented sources of head-scratching, alongside execution timeouts and memory limits during heavy data processing.
The dividing line I’d draw: if you can write the function ahead of time, write a Lambda. It’s cheaper, it scales further, and you control the supply chain. Reach for Code Interpreter when the computation is genuinely unknown until the model decides on it.
What it’s actually good for
Ad-hoc analysis of a file that just arrived. Someone uploads a billing CSV and asks for spend broken down by product category, as a chart, with commentary. The agent writes pandas code, runs it, gets a real chart back, then reads its own output to write the interpretation. You can’t pre-build this as a Lambda because the grouping, the filter, and the chart type change with every question.
Financial and quantitative work. Amortisation schedules, IRR, position sizing, statistical tests. The failure mode of an LLM doing this in its head is confident wrongness, which is the worst kind. AWS’s own walkthrough builds a used-car sales agent that queries a DynamoDB inventory table, runs the statistics, and answers a customer’s financing question with code it generated on the spot.
Format wrangling. Messy Excel exports, nested JSON that needs flattening, CSV to something else, generating a report file from computed results. Low glamour, high frequency, and different in shape every single time.
Live data. With public network mode you can pip-install a package and pull current data — AWS’s sample notebook does exactly this with Yahoo Finance to fetch a stock price. Useful, but be honest about the trade: that’s the posture where model-authored code can talk to the internet.
Read-only work against your own AWS account. This is the one that got my attention as a platform engineer. The sandbox supports shell and AWS CLI commands, and you attach an execution role. So an agent can run CLI queries and post-process the JSON in Python inside a single session. “Which accounts in the org have unencrypted buckets, grouped by OU” is exactly the kind of question whose script you write once, run once, and never need again. Now you don’t write it at all.
Self-verification. The agent reasons its way to an answer, then writes code to check itself, sees the mismatch, and corrects. Session state is what makes this cheap — the failed attempt is still sitting there for the retry.
The things I’d watch
Don’t treat it as a general compute layer. Deterministic work you could have written yourself belongs in a Lambda, and putting it here costs more for no benefit.
Don’t put it on a high-concurrency request path without first sorting out your quota.
And be careful with that execution role. The entire security argument for this service is that model-generated code runs somewhere it can’t hurt you. Hand it broad write permissions across your account and you’ve thrown that away for convenience. Sandbox network mode plus a tightly scoped read-only role is the sane default; widen it deliberately, per use case, when something specific demands it.
Where this fits
The pattern I’ve settled on is a split. Stable, well-understood operations get written as Lambdas and exposed to agents as proper tools through AgentCore Gateway. The exploratory tail — the analysis nobody anticipated, the one-off aggregation, the arithmetic that has to be right — goes to Code Interpreter.
That split maps neatly onto the trust question. Code you wrote and reviewed runs with the permissions it needs. Code a model wrote thirty milliseconds ago runs in a box with the door shut.