Research-backed calculator guide

Code Interpreter Execution Cost: Meter Tokens, CPU, Memory and Session Lifetime

Learn how code interpreter execution cost is metered across tokens, CPU, memory, session lifetime, and idle time, with formulas and a worked example.

What a code interpreter bill actually contains

A code interpreter is a sandboxed environment in which a model can write and execute code. OpenAI describes its Code Interpreter container as a fully sandboxed virtual machine, with selectable 1 GB, 4 GB, 16 GB, and 64 GB memory limits. The 1 GB tier is the default, and the selected tier applies for the life of the container. ^[2] AWS describes AgentCore Code Interpreter as an isolated sandbox that can preserve state during a session and dynamically allocate resources. ^[3]

Those descriptions explain why “per execution” is ambiguous. One logical user request may produce several Python runs: load a file, discover a column error, retry, calculate an aggregate, and render a chart. A provider may regard that sequence as one session, several tool calls inside one session, or several new containers if your application fails to reuse the environment. Count logical jobs, tool calls, sessions, and containers separately in your ledger.

1. Model tokens

The model still incurs its ordinary input and output token charges. Input can include the user prompt, conversation history, tool instructions, file descriptions, and earlier execution results. Output can include prose, generated code, error interpretation, and revised code. The sandbox meter does not replace the model meter. OpenAI’s pricing page lists model token prices separately from its Containers tool price. ^[1]

For a token-priced model, use:

model cost = input tokens ÷ 1,000,000 × input rate + output tokens ÷ 1,000,000 × output rate

Use usage fields from the response or provider export where possible. A rough token count is useful for planning, but it is not an invoice reconciliation. If the model retries code three times, include the tokens for all three attempts.

2. CPU time

CPU can be metered by active consumption or by reserved capacity. Active-consumption billing charges for the CPU actually used by the process. Reserved billing charges for the vCPUs allocated while the sandbox is running, even if the code spends part of that interval waiting on a file or an API.

AWS AgentCore’s published Code Interpreter rate is $0.0895 per vCPU-hour. Its pricing page says billing is calculated per second using actual CPU consumption, with a one-second minimum, and that CPU used during I/O wait is not charged when no background process is running. ^[3] A CPU-second estimate is therefore:

CPU cost = vCPU-hours consumed × CPU rate

Convert seconds before multiplying: vCPU-hours = vCPUs × CPU seconds ÷ 3,600. If a workload uses 1 vCPU for 12 active seconds, the AWS rate component is 1 × 12 ÷ 3,600 × $0.0895 = $0.0002983, before memory and other charges. This is arithmetic using a vendor-published rate, not a vendor quote for your workload.

3. Memory held or reserved

Memory behaves differently from CPU. Active-resource providers may charge memory for the peak amount consumed up to each second, including the period when the model is deciding what to do next. Reserved-resource providers may charge the configured RAM for the full running interval. AWS lists $0.00945 per GB-hour for AgentCore Code Interpreter memory and states that a 128 MB minimum memory billing level applies. ^[3]

For an active-memory estimate:

memory cost = billed GB × seconds held ÷ 3,600 × memory rate

If your process holds 0.75 GB for 90 seconds at the AWS rate, the memory component is 0.75 × 90 ÷ 3,600 × $0.00945 = $0.0001772. In practice, confirm whether the provider rounds, includes system overhead, applies a floor, or uses peak rather than average memory. Averaging a large dataframe over the whole session can understate the charge.

4. Session lifetime and reuse

A session is a cost-control variable as much as a state-management feature. OpenAI says a container expires after 20 minutes without use; when it expires, associated data is discarded and cannot be recovered. ^[2] Its pricing page lists Containers at $0.03 for 1 GB and $1.92 for 64 GB per 20-minute session per container on the page checked November 2, 2026. ^[1] The model tokens remain separate.

Azure Foundry documents a different lifecycle: enabling Code Interpreter creates additional charges beyond Azure OpenAI token fees, each session is active by default for one hour, and the idle timeout is 30 minutes. Separate concurrent conversations create separate sessions. ^[4] Together’s announcement describes a 60-minute Code Interpreter session that can be called multiple times and lists $0.03 per session. ^[5] These are vendor-specific observations, not interchangeable rates.

The useful operational metric is cost per successful logical job, not merely cost per Python call. Reusing a session can spread one session charge across several calls, but keeping a session alive can also keep memory or reserved capacity billable. Ending it too aggressively can force repeated startup, package installation, file upload, and model context work. Measure both paths.

How to calculate code interpreter execution cost

Start with an event ledger. Record a job ID, provider, model, container or session ID, session start and end, memory tier, CPU seconds, peak memory, input tokens, output tokens, tool-call count, retry count, and outcome. Then apply the provider’s meter rules rather than a generic “execution price.”

For an active CPU-and-memory provider, the planning formula is:

estimated cost = token cost + (active vCPU-seconds ÷ 3,600 × CPU rate) + (billed GB-seconds ÷ 3,600 × memory rate) + storage + network

For a reserved sandbox, replace active CPU and memory with the allocated resources multiplied by the entire billable lifetime. For a session-priced tool, use:

session cost = billable sessions × price per session

Then add model tokens and any separately charged file, storage, network, or downstream service usage. If a vendor applies minimum seconds, minutes, memory floors, or rounding, apply those before multiplying. If you do not know the rule, label the result as a range and validate it against a real invoice.

Do not count a rejected request as successfully completed just because it was not charged. A failed execution can trigger an application retry, a second session, and additional model tokens. Also exclude vendor credits, free allowances, tax, and support-plan fees from a base estimate unless your decision specifically needs fully loaded spend.

Worked cost example

Assume one data-analysis job uses a model that consumes 40,000 input tokens and 8,000 output tokens. For the execution environment, assume 1 vCPU is active for 12 seconds, the process holds 0.75 GB for 90 seconds, and there are no storage or network charges. Use AWS AgentCore’s published Code Interpreter rates checked November 2, 2026: $0.0895 per vCPU-hour and $0.00945 per GB-hour. ^[3] The model rates below are illustrative inputs; replace them with the selected model’s current rate card.

The table illustrates an important result: under these token-rate assumptions, model tokens dominate the environment meter. That will not always be true. A long-lived sandbox, a large reserved memory tier, repeated retries, or a session fee can reverse the mix. The example also assumes that 0.75 GB is above the provider’s billed memory floor and that the measured memory is the billable amount. AWS says billing includes system overhead and uses peak memory up to each second, so production reconciliation may be higher than this simplified arithmetic. ^[3]

For a session-priced provider, rerun the same job with session reuse. If 1,000 jobs fit into 100 billable sessions at $0.03 each, the environment component is $3.00, not $30.00. If every job creates its own session, it is $30.00. Those are scenario calculations, not a forecast of any provider’s actual session-allocation behavior. The decisive field is the number of sessions created, so export and monitor it.

Cost controls that do not hide failures

Reuse a session when the state is useful and the provider’s billing model rewards reuse. Set an explicit maximum lifetime and clean up sessions that no longer have work. Persist important files outside an ephemeral container; OpenAI explicitly recommends treating containers as ephemeral. ^[2]

Measure CPU and memory separately. A memory-heavy dataframe may be cheap on active CPU billing but expensive if it sits in RAM during a long model turn. A reserved sandbox may charge both resources throughout that turn. Track p50 and p95 session lifetime, peak memory, active CPU seconds, tokens per successful job, and retry rate.

Cap tool iterations and distinguish code errors from infrastructure errors. An agent that keeps rewriting code can multiply model tokens and execution charges while appearing to have one user request. Keep the original job ID across retries, and record whether a new container or session was created. This makes the AI API invoice reconciliation calculator useful because you can match provider usage rows to logical work rather than guessing from request count.

Budget for tails, not only averages. Use the AI agent budget guardrail and P95 calculator to model high-memory or long-session cases, and use the AI agent development cost estimator when the execution environment is part of a broader build-and-run decision. The AI Agent Cost Calculator can then roll the per-job estimate into monthly volume and workload mix.

Frequently asked questions

Is code interpreter execution billed per token or per execution?

Usually both can matter. The model provider charges input and output tokens, while the code environment may charge a session, active CPU and memory, or reserved resources. OpenAI lists model prices separately from its Containers price, and AWS lists Code Interpreter CPU and memory meters separately. ^{[1] [3]} A correct estimate needs both ledgers.

How do I calculate code interpreter cost per run?

First define what “run” means: one Python tool call, one session, one container, or one successful user job. Then calculate model token cost, add the provider’s CPU/memory or session charge, apply minimums and reuse rules, and divide by successful logical jobs. If several tool calls share one session, allocate the session cost consistently, such as by call count or active seconds, and disclose the allocation method.

Does idle time cost money?

It depends on the meter. AWS says AgentCore Code Interpreter does not charge CPU during I/O wait when no background process is running, but it continues to bill memory according to its active-resource rules and includes system overhead. ^[3] Reserved-resource platforms can charge the allocated CPU and memory while the sandbox remains alive. A session-priced service charges according to its session rule, not simply the number of seconds your Python code used the processor.

Is a larger memory tier always more expensive?

For a tiered session product, a larger selected tier normally carries a higher session price. OpenAI lists 1 GB and 64 GB container prices of $0.03 and $1.92 per 20-minute session on its pricing page checked November 2, 2026. ^[1] For active-memory billing, a larger limit may not increase the bill if actual peak memory stays unchanged, but provider floors and system overhead still matter. Do not confuse a maximum limit with measured usage.

Does reusing a code interpreter session lower cost?

It can, but not automatically. Reuse may spread one session charge across several jobs and avoid repeated uploads or package setup. It can also extend memory lifetime or reserved capacity. OpenAI’s containers expire after 20 minutes without use, while Azure documents a one-hour active session with a 30-minute idle timeout. ^{[2] [4]} Compare the cost of reuse with the cost of keeping resources alive, using observed session IDs and lifetime data.

What should I exclude from a first-pass estimate?

State exclusions explicitly. A base execution estimate may exclude tax, credits, free allowances, storage, network egress, observability, data-transfer fees, support plans, human review, and downstream databases. It should also say whether retries, failed requests, and model-generated tool calls are included. Add these items when you need a fully loaded unit-economic view rather than a narrow sandbox estimate.