Three Meters for One Agent Job: Inventory Your AI Agent Billing Meters Before Fan-Out

One agent job can hit three ai agent billing meters: tokens with cache multipliers, per-call tools, and sandbox minutes with a 5-minute minimum. Cap each one.

Illustrative hero for AI agent billing meters: three gauge meters labeled tokens, tools and sandbox, each with a red ceiling mark, under the title Three meters, one job
Three meters run on one agent job. Inventory them before fan-out, then cap each one.

Picture the receipt for one overnight job, read on a Tuesday morning: $48.00 in tokens, $1.80 in tool calls, $8.64 in sandbox minutes. Three lines, three rates, three clocks. The token line is the one you budgeted for. The other two accrued while a worker waited on a test suite and a search loop ran more often than anyone pictured, and nothing on your desk added them up until the invoice did.

Those are the AI agent billing meters an operator now runs against on a managed harness: tokens, whose rate moves with the cache class mid-job; tools, priced per call; and sandbox or container time, priced per minute with a minimum. Desktop digital employees add a fourth dialect, credits, which no published rate converts into any of the other three. This piece is the inventory-and-ceiling drill. Name every meter a job can touch before it fans out, put a cap on each meter class rather than one budget on the job, price one job across all of them at the real rates, and stop reading a sentence that says there are no additional fees as a sentence that says there is no bill.

The dollar figures in the worked example are modeled; the rates behind them are published and linked.

Sep 10, 2026: two meters in the launch post, three in the docs

On Sep 10, 2026, OpenAI moved the Agents API into public beta. The pricing sentence in the announcement is the one people repeat: “There are no additional fees for using the Agents API – you simply pay for the tokens and tools your agents use, as outlined on our pricing page.” Two meters, tokens and tools.

The docs overview names a third: “Model usage is billed at the selected model’s API rates. OpenAI tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates.” The hosted-environment page says it again from the other side: “OpenAI-hosted sandboxes use standard container rates. Model usage is billed separately at the selected model’s API rates.”

Those container rates sit on the pricing page in a row labeled Containers, Hosted Shell and Code Interpreter: “1 GB $0.03, 4 GB $0.12, 16 GB $0.48, 64 GB $1.92 per 20-minute session per container.” The footnote belongs on a sticky note above your monitor: “Eligible container sessions will be billed by the minute, with a 5-minute minimum per session.” The row does not name the Agents API; the Agents API docs point to it as the standard container rates, and that link is the basis for treating it as the sandbox meter.

OpenAI API pricing page showing the Containers row for Hosted Shell and Code Interpreter at 1 GB $0.03, 4 GB $0.12, 16 GB $0.48 and 64 GB $1.92 per 20-minute session per container, with the by-the-minute and 5-minute-minimum footnote Screenshot: OpenAI Developers, “Pricing” (undated docs page), captured Sep 19, 2026.

What survives a cancel or a delete on this API is its own continuity drill; this piece is about what the meters do in the meantime. Two more docs lines shape how the sandbox meter behaves.

From the multi-agent guide: “Creating a subagent does not create another environment.” Fan-out inside one session multiplies the token and tool meters, not the container meter.

And from the hosted-environment page: “Connected sandboxes receive keep-alives, including between turns. If activity and keep-alives stop for an hour, the sandbox can be deleted. This timeout isn’t configurable.” Whether a connected but idle sandbox is billed between turns, the docs do not say. Until an invoice proves otherwise, model it as billed.

Why an acting agent needs a meter inventory and a chat window does not

A chat session has one meter, and you are its clock. An agent job carries its own clock, and it keeps every meter running while you sleep. Container minutes accrue while a worker waits for a build. Tool calls accrue at whatever rate a retry loop decides.

The token rate itself moves by a factor of ten inside one job on gpt-6-astra ($10.00 uncached input against $1.00 cached, per the model page) and by a factor of forty on Claude Fable 5.1 ($10 against $0.25, per Anthropic’s pricing).

Fan-out then multiplies whichever meters the worker touches. The multi-agent guide’s cap is worth memorizing: “max_concurrent_subagents limits how many subagents can run at once. The default is 6, excluding the coordinator.” Metering the fan-out tree is its own runbook; this one assumes you know how many workers you have and asks which meters each is turning.

Step 1: Inventory every meter a job can touch, before the first spawn

Do this per job template. A nightly dependency-patch job and a weekly research digest touch different meters on the same API key. The table is the inventory for a managed-harness job on Sep 19, 2026; rates are the vendors’ published Standard figures.

Meter class What moves it Published rate examples Minimum or rounding Where it surfaces
Tokens, uncached input Prompt tokens not served from cache gpt-6-astra $10.00/MTok; Fable 5.1 $10/MTok; deepseek-flash cache miss $0.30/MTok peak, $0.15 off-peak Astra: prompts above 272K input tokens billed at 2x input and cache rates, 1.5x output, for the whole request Per-response and per-turn usage fields
Tokens, cache write First pass over a prefix you asked to cache Astra $12.50 (1.25x uncached); Fable 5.1 $12.50 for a 5-minute cache, $20 for 1-hour Anthropic: 512-token minimum cacheable prompt on Fable 5.1 cache_creation_input_tokens (Anthropic)
Tokens, cache read Repeat passes over that prefix Astra $1.00; Fable 5.1 $0.25 (0.025x base); deepseek-flash cache hit $0.006 peak Cache lifetime: 5 minutes by default on Anthropic, refreshed on use cache_read_input_tokens; prompt_cache_hit_tokens (DeepSeek)
Tokens, output Everything the model writes, reasoning included Astra $50; Fable 5.1 $50; deepseek-flash $1.20 peak, $0.60 off-peak None Usage fields
Tools, per call Each built-in tool invocation OpenAI web search $10.00 per 1k calls; file search $2.50 per 1k calls; file-search storage $0.10 per GB per day, 1 GB free Per call, plus search content tokens at model rates Pricing-page rates; not in the token counts
Tool definitions, per request Tool schemas re-sent with every request Anthropic’s computer toolset adds about 4,500 input tokens per request; the browser toolset about 6,600 Every request that carries the toolset Counted as input tokens
Sandbox or container time Minutes a container session exists OpenAI 1/4/16/64 GB at $0.03/$0.12/$0.48/$1.92 per 20-minute session; Anthropic code execution $0.05 per hour per container beyond 1,550 free hours a month; Claude Managed Agents $0.08 per session-hour OpenAI: by the minute, 5-minute minimum; Anthropic code execution: 5-minute minimum; Managed Agents: to the millisecond, only while running Invoice, plus your own timestamps
Credits (desktop agents) Whatever the vendor’s meter decides AutoClaw: daily free credits, a 10,000-credit login promo, 100 million GLM-5.3-Flash tokens worth $12 for new users; no credit-to-token rate published Not published In-app consumption statistics

Three entries in that table are traps rather than rates. Anthropic’s pricing page says of code execution, “If files are included in the request, execution time is billed even if the tool is not called”: a container line with zero container work. Astra’s long-context surcharge reprices the full request, so one 300K-token turn costs 2x on every input token in it. And the credits row has no rate at all, which is why the credit-versus-token drill is a separate piece.

The inventory checklist, per job template:

  1. Which model, at which rate card, and whether the job can exceed 272K input in one request.
  2. Which cache class each phase lands in, and what share of input you expect to be cache reads.
  3. Which built-in tools the harness may call, at which per-call price, and which tool definitions ride on every request.
  4. Which sandbox size, whether one session or several, and what the job does between turns.
  5. Whether any worker on the desk runs on credits, and whether that worker has a schedule.
  6. Which usage fields you will read for each meter, and which meter has no field at all.

Item six decides whether the ledger in Step 4 can be built.

Step 2: Set a ceiling per meter class, not one budget per job

A single dollar budget hides the meter that is misbehaving. On the $58.44 job priced in Step 3, where tokens are over 80 percent of the cost, a $100 job budget still has not tripped when tool calls reach 20x their normal count, because 20x of a small number is still small. Cap each meter in its own unit: tokens in dollars and cache-read share, tools in call counts, sandbox in minutes and gigabytes, credits in measured runs.

# illustrative: per-job meter ceilings, enforced by your wrapper, not by any vendor
job: nightly-dependency-patch
model: gpt-6-astra
meters:
  tokens:
    ceiling_usd: 60
    cache_read_share_floor: 0.70      # page if cache reads fall below 70% of input
    max_input_tokens_per_request: 250000   # stay under the 272K surcharge line
  tools:
    ceiling_calls:
      web_search: 200
      file_search: 400
  sandbox:
    size_gb: 16                       # 4x the 4 GB rate, a quarter of the 64 GB rate
    ceiling_minutes: 420              # 7 hours; the 5-minute minimum applies regardless
    disconnect_after_idle_minutes: 15 # do not wait for the hour-long deletion timeout
  credits:
    ceiling_per_run: measured         # from the credit-dialect drill; no vendor rate exists
on_breach:
  - pause_new_spawns
  - hold_writes
  - page: oncall-agents

Three choices in that file deserve a sentence each. Sandbox size is a rate choice: a 64 GB session bills at four times a 16 GB one for every minute it exists, so the size field caps the meter’s rate. The idle-disconnect line exists because the docs say a sandbox can be deleted after an hour without keep-alives and that the timeout is not configurable; fifteen minutes of your own timer is cheaper than waiting for theirs. And the cache-read floor is a rate alarm rather than a spend alarm: when the share of cached input drops, the job has not gotten bigger, it has gotten ten times more expensive per token, and a dollar ceiling would tell you an hour late.

The page-and-pause order is the same one the cost-anomaly runbook uses: spawns first, writes second, running workers at their next tool-call boundary, never mid-write.

Step 3: Price one job across all three meters at the published rates

This is a modeled job, not a measurement, and every dollar in it is illustrative. The rates are gpt-6-astra Standard ($10.00 input, $1.00 cached input, $12.50 cache writes, $50.00 output per million tokens), the tool rates from the pricing page, and the Containers row.

GPT-6 Astra model page on OpenAI Developers: the header with a $10 input and $50 output price, the 1,050,000-token context and 128,000 max output specs, and the top of the per-1M-token pricing cards for Input, Cached input, Cache writes and Output Screenshot: OpenAI Developers, “GPT-6 Astra” (undated docs page), captured Sep 19, 2026.

Job shape: one coordinator and four subagents in one session, one 16 GB sandbox, six hours of runtime, 120 web searches, 200 file-search calls, and 2 GB of file-search storage for one day.

Token meter. 1.2M uncached input tokens at $10.00 is $12.00. 0.8M cache-write tokens at $12.50 is $10.00. 6.0M cache-read tokens at $1.00 is $6.00. 0.4M output tokens at $50.00 is $20.00. Subtotal: $48.00.

Tool meter. 120 web searches at $10.00 per thousand is $1.20. 200 file-search calls at $2.50 per thousand is $0.50. One billable gigabyte of storage (2 GB minus the free 1 GB) at $0.10 is $0.10. Subtotal: $1.80, plus search content tokens already counted on the token meter.

Sandbox meter. A 16 GB container at $0.48 per 20-minute session is $1.44 per hour. Six hours is $8.64.

Total: $58.44, of which the announcement’s two named meters explain $49.80 and the third explains the rest. Now hold the job fixed and change one setting at a time.

Configuration B keeps everything and picks a 64 GB sandbox: $1.92 per 20 minutes, $5.76 per hour, $34.56 for six hours. Total $84.36, and the sandbox is now 41 percent of the job. Configuration C keeps the 16 GB sandbox and loses the cache, so all 8.0M input tokens bill at $10.00: $80.00 input plus $20.00 output, tokens at $100.00, total $110.44.

Illustrative stacked horizontal bar chart of one overnight agent job in three configurations, split into tokens, tools and sandbox time: $58.44 with a 16 GB sandbox and a warm cache, $84.36 with a 64 GB sandbox, $110.44 with a cold cache Illustrative, modeled at published Standard rates for gpt-6-astra and the Containers row (developers.openai.com, Sep 19, 2026). Same job, three configurations.

Three things the chart says that the announcement sentence does not. The cache is the largest lever on the job, larger than the sandbox and the tools combined, which is why the Fable 5.1 cache-read meter and the DeepSeek off-peak and cache-hit runbook are cost pieces rather than model reviews. The sandbox is the second lever, set by a size field you chose once. And the tool meter is small until a loop runs: 120 searches is $1.20, and 12,000 of them is $120.00 with no change to the token line to warn you.

The rate card changes only the token subtotal. Re-run the same token shape on deepseek-flash at peak ($0.30 cache miss, $0.006 cache hit, $1.20 output per million, cache writes counted as misses since DeepSeek has no write class) and the token meter reads roughly $1.12; the tool and sandbox meters do not care which model was in the loop.

Step 4: One ledger, three meters, a ceiling on each

The ledger is yours, not the vendor’s, because no vendor’s usage view sees the other vendors and none of them sees the credits. One row per job run, with a column per meter class and a ceiling next to each.

Diagram of one agent job feeding three meters, tokens, tools and sandbox time, each with its own ceiling, plus a dashed credits meter for desktop agents, all writing into one operator ledger that drives pause and page actions Three meters feed one ledger. The ceiling lives on the meter, the pause lives on the ledger.

The illustrative row shape:

{
  "run_id": "nightly-dependency-patch/2026-09-19T01:10Z",
  "harness": "agents-api", "session_id": "sess_…", "model": "gpt-6-astra",
  "tokens": {"uncached_in": 1200000, "cache_write": 800000, "cache_read": 6000000, "out": 400000,
             "usd": 48.00, "cache_read_share": 0.75, "ceiling_usd": 60},
  "tools":  {"web_search": 120, "file_search": 200, "storage_gb_days": 1, "usd": 1.80,
             "ceiling_calls": {"web_search": 200, "file_search": 400}},
  "sandbox": {"size_gb": 16, "minutes": 360, "usd": 8.64, "ceiling_minutes": 420,
              "minutes_source": "own timestamps: session created to last turn ended"},
  "credits": null,
  "rates_version": "openai-pricing-2026-09-19",
  "state": "completed"
}

Where each column comes from matters more than the schema. Token counts come from the per-turn usage the Agents API exposes; the events guide describes retrieving a turn to inspect its status, timestamps, usage and error. Tool counts come from the saved items, which the same guide describes as the saved messages and tool calls. Sandbox minutes come from your own clock, between the session’s creation and the last turn’s completion or cancellation, because the docs describe a turn’s usage and do not say that container minutes appear in it.

Anthropic’s Managed Agents meter follows a different rule, “Runtime is measured to the millisecond and accrues only while the session’s status is running”, so a Claude row records running minutes rather than existing minutes, and the row’s minutes_source field names the rule so the two are never summed as if they were the same thing.

Version the rate card as a file the ledger references. Rates moved three times in September’s first two weeks: Fable 5.1’s cache read on Sep 1, Astra’s card on Sep 3, DeepSeek’s on Sep 10 at 04:00 UTC. A row priced against last month’s file is one you will argue with finance about.

Step 5: Read every usage view for what it cannot show

Every vendor ships a usage view. Each is honest about one vendor, one session and one or two meters, and quiet about the rest.

Surface What it shows What it does not show, per the docs
OpenAI Agents API Per-turn status, timestamps, usage and error; a list of turns and saved items; five webhook events Whether the turn’s usage carries sandbox minutes (the docs do not say); whether idle-between-turn time bills; any total across vendors; call arguments in the webhook (it does not include those details)
Anthropic API and Managed Agents cache_creation_input_tokens and cache_read_input_tokens per response; session runtime to the millisecond, accruing only while running Code execution appears in usage only as a code_execution_requests count under server_tool_use; the pricing docs show no container-hours field, and none for the charge that applies when files are included but the tool is never called
DeepSeek API prompt_cache_hit_tokens and prompt_cache_miss_tokens; a balance deducted with the granted balance used first Which clock rate applied; you stamp the UTC hour yourself, since peak is 01:00–04:00 and 06:00–10:00 UTC on weekdays outside Chinese public holidays and everything else is half price
AutoClaw desktop Consumption statistics on hover, per the changelog entry of Aug 4, 2026 (v1.15.3) Any credit-to-token or credit-to-dollar rate; the daily free credit amount

The pattern across all four: the meter you can read is the one the vendor prices in a unit it exposes as a field. Container minutes and credits are not, which is why they are the lines that surprise you. What to export from a vendor-hosted session before it expires is the evidence runbook; the ledger here is its cost twin.

Six signals an agent billing meter is running away

Sandbox minutes advance, tokens do not. A worker is waiting on something, a build, a network call under a restricted policy, a subagent that never reports. Signal: a ledger row where sandbox.minutes grows and every token field is flat for longer than the job’s longest expected tool call. Cancel the turn; the session and its previous work remain available, per the sessions guide. Then end the session on your own timer, because a connected sandbox keeps receiving keep-alives between turns and the docs do not say whether that time bills.

Cache-read share collapses. Someone edited a system prompt, a tool definition changed, or a subagent rebuilt its context from scratch each turn. Signal: cache_read_share below the floor while spend per turn jumps. On Astra the input rate went from $1.00 to $10.00; on Fable 5.1 from $0.25 to $10. Fix the prefix before you raise the ceiling.

Tool count spikes with a flat token line. A retry loop on a search or a file-search call. Signal: tools.web_search past its count ceiling within one turn. Count ceilings catch this; dollar ceilings do not.

The 272K line trips once and reprices everything. One long turn crosses the surcharge and the whole request bills at 2x input and cache, 1.5x output. Signal: a turn whose cost per token is double its neighbors. Cap max_input_tokens_per_request below the line and compact earlier.

A self-hosted environment outlives its session. From the lifecycle page: “Deleting a session neither stops its environment nor emits a deletion webhook.” Signal: a provider compute bill for a sandbox whose session you deleted last week. Stop the compute in the provider, then delete the session, in that order.

A credit-metered worker runs dry mid-schedule. No dollar line, no page, and the scheduled job simply stops. Signal: none from the meter, which is the problem, and why credits get a runway calculation in the dialect drill rather than a ceiling here.

Three meters, one desk: the sum is operating-layer work

A pricing page is one vendor’s view of one meter class at a time. The desk sees a fleet: a managed harness billing three ways, a second vendor billing two ways under different rules, a desktop agent billing in a unit with no rate, and a cloud coordinator such as Claude Code Projects whose threads carry no separate compute charge but can reach plan usage limits faster. Nobody at any of those vendors is going to sum that for you, and none of their usage views can. The sum is the operator’s job, which is what the operating bill argument was about twelve days before the third meter arrived, and what a fleet operations layer is for: one ledger, every meter, a ceiling that belongs to the job rather than to the vendor.

The inventory is a Tuesday task: an hour per job template, and the hour that turns three surprises into three columns.

FAQ: AI agent billing meters

What are the three billing meters on an OpenAI Agents API job?

Tokens at the selected model’s API rates, built-in tools at their standard per-call rates, and OpenAI-hosted sandboxes at standard container rates, which the pricing page lists per 20-minute session per container, billed by the minute with a 5-minute minimum. The launch post names only the first two; the docs name all three.

How much does sandbox time cost compared with tokens on an agent job?

It depends on container size more than on runtime. In the illustrative job above, a 16 GB sandbox for six hours is $8.64 against $48.00 of tokens; the same job on a 64 GB sandbox is $34.56, or 41 percent of the total. Size is a rate choice; set it per job template.

Should an agent job have one budget or a ceiling per meter?

A ceiling per meter class, in that meter’s unit: dollars and cache-read share for tokens, call counts for tools, minutes and gigabytes for sandboxes, measured runs for credits. A single dollar budget hides a tool loop or a cache collapse until the total finally trips, usually hours late.

Sources