Green Software Foundation · Reference Implementation · for education & awareness

What does your AI agent cost —
in dollars & in carbon?

An agent isn’t one model call — and increasingly it isn’t even one agent. Modern systems are small teams of roles: a router that classifies, a worker loop that reasons and acts, a guardrail that checks — each role a model of its own, all re-processing a growing transcript on every turn. Cost compounds invisibly, and the energy, carbon and water behind it never appear on any invoice. What can’t be seen can’t be reduced. This educational tool makes the shape visible: design the team, read its bill, flip the reduction levers.

Multi-agent edition Per-role stages: each agent priced on its own model Single-agent mode remains the default — leave stages off

This edition extends the earlier single-agent calculator to multi-agent implementations: turn on per-role stages to give each agent its own model tier and token profile, or leave it off to model one agent with one profile — the original behaviour, unchanged.

GSF Reference Implementation · for awareness, not reporting — an educational, illustrative example of applying SCI for AI (ISO/IEC 21031:2024). Its purpose is to raise awareness of the cost and environmental impact of agentic AI and build intuition about reducing it. Its figures are estimates from cited defaults and must not be used for sustainability reporting, ESG disclosure, or marketing claims. About reference implementations →
ESTIMATION PROXIES, NOT INSTRUMENTED TELEMETRY — use these numbers to compare architectures and drive efficiency, never to publish. For SDK-measured, per-call figures, see the GSF sci-for-ai reference implementation.

1 Your workload

An agent is a loop: every turn re-processes the growing transcript, then adds output and tool results to it. That accumulation — not the answers — is what dominates the bill.

Model calls in one task: a chatbot exchange is 2–5, a coding agent 8–15, deep research 20+.
Scaled over a 22-workday month.

Why it compounds

Each bar = the input tokens processed at that turn: bar(t) = system prompt + everything generated before turn t (outputs + tool results), from your inputs above. This staircase is default behaviour across major LLM APIs: whether your client resends the transcript or the provider stores conversation state for you, the full context is processed — and billed — on every request, so cumulative cost grows roughly quadratically. The departures from that default are exactly the levers below: caching discounts the re-processed prefix, and a memory layer (summarise & retrieve) shrinks what is carried at all. The heights are your assumptions, not measurements: change the sliders and the staircase changes.
turn 1
Fine-tune tokens per turn
What a cached input token costs vs. a fresh one — applies when the caching lever is on. Provider economics vary widely: ~10% (Anthropic cache reads) to 25–50% (others). Cache-write premiums, TTL and storage fees are not modelled.
100% = accelerators amortized at rated load, the most favorable case. Real inference fleets run well below that — lower this to see how idle hardware inflates the embodied carbon of every token (M scales as 1/utilization).

2 The model

Price bands from 2026 API pricing surveys; per-token energy calibrated so a short query lands in the published 0.3–1 Wh range and a long reasoning prompt approaches ~33 Wh.

3 Where it runs

The same kWh emits 13× more CO₂e on a coal-heavy grid than on hydro or nuclear. Facility overhead (PUE 1.2) and water use are added on top.

4 Reduce it

Levers apply as a waterfall: each one transforms the workload and the whole run is re-simulated, so overlapping savings are honest and never sum past 100%.

First, the problem

Every organization shipping agentic AI faces the same two questions — what does this actually cost, and what is its environmental impact? — and finds that neither is visible where decisions get made.

01 An agent is not one model call — and a production system is rarely one agent. A single user request fans out across a team of roles — a router, a worker loop with its planning, tool use and retries, a guardrail — each potentially a different model, and every turn re-processes an ever-growing transcript. Cost compounds in a way no per-token price sheet reveals; teams routinely discover it only when the invoice arrives.

02 The environmental side never appears on an invoice at all. The energy, carbon and water behind a workload depend on which model ran, on what hardware, in which region, at what hour — details that sit outside most engineering dashboards.

03 What can't be seen can't be reduced. And waiting for perfect measurement before starting leaves teams without a starting point at all.

This educational reference implementation exists to make that shape visible: a place to build intuition about where the dollars and grams of an agentic workload come from, and which design decisions move them — before, and alongside, real measurement.

From idea to estimate: a worked example

The calculator is abstract until you map a real application onto it. Here is one job, worked end to end twice — first as a single agent (the calculator’s default mode: stages off, one model, one profile), then as a three-agent system priced per role with stages mode — showing how each design decision becomes a number, what each baseline looks like, and in which order a team would reduce it. Same job, same engine, two architectures: the gap between them is the whole argument. All figures are computed live.

1

The job to be done

A retailer receives 800 support tickets a day: order status, refunds, delivery issues. The team wants an agent that reads the ticket, looks up the order, consults policy, and either resolves or drafts an escalation. Before building, they want to see the shape of the cost and footprint — per ticket and per month.

2

Design the workflow — one agent does everything

The simplest architecture: one model, one loop, one token profile. The intent classification, the tool-calling turns and the final policy self-check are all just turns inside the same loop — which means every one of them, however trivial, is priced at the workhorse rate. This is what the calculator models with stages off: the four sliders in panel 1 describe every turn identically.

Design choices that will dominate the bill: how many turns the loop runs, how much each tool returns, and how big the standing prompt is — because the loop re-processes all of it, plus the growing transcript, every turn.

In practice: this is LangGraph’s create_react_agent, a single ADK LlmAgent with tools, or one OpenAI Agents SDK Agent — see the In practice tab for the full mapping.

3

Translate the design into the model

Each decision maps to one calculator input — the classic single-profile mapping:

Design decisionReasoningInput
Eight turns of one loopclassify (1) + retrieve & act (6) + self-check (1) — all the same agent, same modelturns = 8
Standing instructions + the ticketpersona, policies, tool schemas (~1,500) plus the ~300-token ticket — re-processed every turnsystem + task = 1,800 tok
Tool returnsorder record + KB/policy slice returned on each acting turn (incl. the initial retrieval)tool results = 1,000 tok/turn
Replies kept tightcustomer-facing answers, not essaysoutput = 250 tok
Light deliberationbrief reasoning on refund decisions onlyreasoning = 200 tok
Flaky order APIobserved failure + re-run rateretries = 10%
One model for everything, global gridthe workhorse tier does every job; region not yet chosenmid · 450 gCO₂e/kWh

How the engine prices it. Same formula as always — input(t) = 1,800 shared tokens + everything earlier turns appended — but here every token is read at mid-tier prices. Turn 1, the one-line classification, reads and costs ; by turn 8, the routine self-check, the loop re-reads for . Those are exactly the trivial jobs the multi-agent tab prices at small-tier rates instead.

4

Read the baseline

The engine prices the single-agent design at and per ticket — which feels like nothing until step 1’s scale applies: at 800 tickets/day over a 22-working-day month that is , and every month. Notice the carbon split (): the embodied share is small on this grid, but it would dominate on a low-carbon one — and only using less compute reduces it. For reference, the multi-agent tab delivers the same job at from architecture alone.

5

Reduce it — in the order a team would

In single-agent mode, routing is approximated, not designed: the right-size lever sends 50% of turns to the small tier as a statistical stand-in for the explicit router/guardrail split the multi-agent tab builds in. So the plan is: add a memory layer first — summarise history and retrieve the relevant slice (the carried transcript is the biggest line item), cache the stable prefix (those 1,800 system tokens are identical every turn), right-size the model, then bound the loop. With those four levers this design lands at and per month — .

The remaining levers (batching, carbon-aware placement) are the operations conversation to have once the design is efficient. And when you’re ready to make the routing explicit instead of statistical, switch to the multi-agent tab — same job, per-role pricing.

2

Design the multi-agent workflow

A production agentic system is a small team of agents relaying one transcript. This example uses three — and the design discipline is to give each agent its own model, sized to its job, rather than paying the workhorse rate for a one-line classification:

Design choices that will dominate the bill: how many turns the worker loop runs, how much each tool returns, how big the shared standing prompt is — because every agent re-processes all of it, plus the growing transcript, on every turn — and which model each role runs on.

In practice: one LangGraph StateGraph node per role, or ADK’s SequentialAgent(sub_agents=[router, LoopAgent(worker), guardrail]) with a model= per agent — the In practice tab shows the code.

3

Translate the design into stages

In stages mode, each agent maps to one stage — its own model tier, turn count and per-turn token profile — while the standing prompt, retries and grid stay shared:

Design decisionReasoningInput
Three agents, one relayrouter → worker loop → guardrail; the transcript flows through all of themstages = 3 · turns = 1 + 6 + 1
Router agentclassify intent; a one-line verdict, no toolssmall · 1 turn · 60 tok out
Worker agent (loop)reasons, calls the order & refund tools (1,000 tok returned per acting turn, incl. the initial retrieval), drafts the reply, with light deliberation on refundsmid · 6 turns · 250 out · 200 reason · 1,000 tool
Guardrail agentpolicy check on the final replysmall · 1 turn · 100 tok out
Standing instructions + the ticketpersona, policies, tool schemas (~1,500) plus the ~300-token ticket — shared, re-processed by every agent on every turnsystem + task = 1,800 tok
Flaky order APIobserved failure + re-run rateretries = 10%
Region not yet chosenworld-average carbon intensityglobal · 450 gCO₂e/kWh

How the engine prices it, stage by stage. Every turn’s input follows one formula — input(t) = 1,800 shared tokens + everything earlier turns appended — but the price and energy of those tokens depend on which stage’s model is reading them. The table below is computed live by the engine (raw stage sums; retries and facility overhead are applied at the bottom, exactly as in the methodology formula):

stagemodelturnsinput tok (Σ)output tok (Σ)costenergy

Follow the transcript through three of the eight turns. Turn 1 — Router (small): nothing carried yet, so input = ; at small-tier prices that turn costs , and its 60-token verdict joins the transcript. Turn 2 — Worker (mid): the expensive tier meets a growing context: input = 1,800 + 60 carried = , costing — and each worker turn appends another 1,250 tokens (250 output + 1,000 tool results), so by its last turn the worker is re-reading . Turn 8 — Guardrail (small): it reads the most tokens of any agent — , the full accumulated transcript — yet costs only , because tier beats length. That single turn is the whole argument for per-role stages.

Why per-role, demonstrated. The lazy mapping — all 8 turns priced on the mid tier — would put this same ticket at and , at scale. Giving the router and guardrail their own small tier is the multi-agent design’s first free win: , before any reduction lever is touched. The single-agent tab walks that uniform mapping through in full.

4

Read the baseline

The engine prices the three-agent design at and per ticket — which feels like nothing until step 1's scale applies: at 800 tickets/day over a 22-working-day month that is , and every month. Notice the carbon split (): the embodied share is small on this grid, but it would dominate on a low-carbon one — and only using less compute reduces it.

5

Reduce it — in the order a team would

Add a memory layer first — summarise history and retrieve the relevant slice (the carried transcript is the biggest line item), cache the stable prefix (those 1,800 system tokens are identical every turn), right-size the model (the router and guardrail already run small — this lever routes the easy turns inside the worker loop to the small tier too), then bound the loop (only the 6-turn worker shrinks; the 1-turn agents are already minimal). With those four levers this example lands at and per month — — with the waterfall showing what each lever contributed, honestly, after the ones before it.

The remaining levers (batching, carbon-aware placement) are the operations conversation to have once the design is efficient.

From calculator to code: framework grounding

Every concept this calculator prices has a concrete handle in the mainstream agent frameworks — pick yours, then expand the architecture you’re building. Both worked-example architectures can be built as written. Names checked against the linked docs (vintage 2026-Q3); framework APIs evolve quickly, so verify before you build.

LangChain’s runtime for stateful, graph-structured agents (docs). Translation key: a calculator turn = one model-calling graph step · a stage = a node · the transcript = the messages state · bound the loop = recursion_limit.

Single agent — stages offcreate_react_agent · recursion_limit

One model, one tool-calling loop — the calculator’s default mode, with the four sliders describing every turn identically.

agent = create_react_agent( model=mid_model, # panel 2’s tier tools=[order_lookup, refund_api]) agent.invoke({"messages": [ticket]}, config={"recursion_limit": 8}) # bound the loop
Multi-agent — per-role stagesStateGraph · one node per role

A stage = a node; each node calls its own model — exactly what stages mode prices. The supervisor pattern is the dynamic-routing variant of the same idea.

g = StateGraph(State) g.add_node("router", router_node) # small model inside g.add_node("worker", worker_agent) # mid model + tools g.add_node("guardrail", guardrail_node) # small model g.add_edge(START, "router") g.add_edge("router", "worker") g.add_edge("worker", "guardrail") g.add_edge("guardrail", END) g.compile().invoke(state, config={"recursion_limit": 8})

Google’s Agent Development Kit: LLM agents composed under deterministic workflow agents (docs). Translation key: a stage = a sub-agent · the worker stage’s turns = LoopAgent(max_iterations=…) · the shared memory = session.state relayed via output_key.

Single agent — stages offone LlmAgent · one model

Everything — classification, tool calls, self-check — happens inside one agent at one tier.

agent = LlmAgent( name="support", model=mid, # one tier for every job tools=[order_lookup, refund_api], instruction="Resolve the ticket.")
Multi-agent — per-role stagesSequentialAgent · model per sub-agent

The three-agent worked example, literally — each role its own model=, the loop bounded, early exit via escalation or exit_loop.

router = LlmAgent(name="router", model=small, instruction="Classify intent.") worker = LlmAgent(name="worker", model=mid, tools=[order_lookup, refund_api]) guardrail = LlmAgent(name="guardrail", model=small, instruction="Policy-check reply.") pipeline = SequentialAgent(sub_agents=[ router, LoopAgent(sub_agents=[worker], max_iterations=6), # the worker stage’s turns guardrail])

OpenAI’s Agents SDK: Agents with tools, connected by handoffs, driven by a Runner (docs). Translation key: a turn = one run-loop step · a stage = an Agent · bound the loop = max_turns.

Single agent — stages offAgent · max_turns
agent = Agent(name="support", model=mid, tools=[order_lookup, refund_api]) Runner.run(agent, ticket, max_turns=8) # bound the loop
Multi-agent — per-role stagesper-agent model · handoffs

Each Agent sets its own model; the relay is a chain of handoffs (guardrail logic can also live in the SDK’s output-guardrail hooks).

worker = Agent(name="worker", model=mid, tools=[order_lookup, refund_api]) guardrail = Agent(name="guardrail", model=small, instructions="Policy-check the reply.") router = Agent(name="router", model=small, instructions="Classify, then hand off.", handoffs=[worker]) worker.handoffs = [guardrail]

CrewAI: role-based crews of agents executing tasks under a process (docs). Translation key: a stage = an Agent + its Task · per-stage model = per-agent llm= · bound the loop = max_iter.

Single agent — stages offone Agent · max_iter
support = Agent(role="Support agent", llm=mid, max_iter=8, # bound the loop tools=[order_lookup, refund_api]) Crew(agents=[support], tasks=[resolve_ticket]).kickoff()
Multi-agent — per-role stagesCrew · llm per agent · sequential process
router = Agent(role="Router", llm=small) worker = Agent(role="Worker", llm=mid, tools=[order_lookup, refund_api]) guardrail = Agent(role="Guardrail", llm=small) Crew(agents=[router, worker, guardrail], tasks=[classify, resolve, check], process=Process.sequential).kickoff()
Calibrate from real tracescode → calculator

Close the loop the other way: run your framework with tracing on (LangSmith, ADK’s dev UI, OpenAI traces), read turns per run, input/output tokens per role and retry rate from the trace, and type them into the calculator — stage rows for multi-agent, sliders for single. The estimate then reflects your system, not these defaults; the trace’s billed token counts are the ground truth this simulator approximates.

Honesty note. This mapping shows the concepts are implementable, not that the numbers transfer: frameworks add their own token overhead (system scaffolding, handoff messages, state serialization) that this calculator does not model. Measure with traces; treat the mapping as the bridge, not the bill.

Every reduction lever has a framework handle

Same names, groups and order as panel 4 of the calculator. Expand a lever to see how each framework — or the model provider underneath — implements it.

Spend fewer tokens
Right-size the modelper-agent model= · stages mode, priced
all frameworksThe per-node / per-agent model= (CrewAI: llm=) parameter — stages mode is this parameter, priced. In single-agent mode this lever approximates what a router node makes explicit.
Trim the reasoning budgetper-agent reasoning controls
provider layerAnthropic extended-thinking token budgets · OpenAI reasoning_effort · Gemini thinking budgets — all settable per agent.
with stagesSpend reasoning only in the stage that needs it — the worked example budgets it to the worker’s refund decisions.
Memory layer: summarise & retrievetrim / summarize / shared state
LangGraph / LangChaintrim_messages caps carried history; LangMem’s SummarizationNode replaces overflow with a summary message.
Google ADKRelay distilled state between agents via session.state + output_key instead of the raw transcript; Memory services for long-term recall.
patternProvider-agnostic context engineering: carry a compact summary + the relevant retrieved slice, not the whole transcript.
Reuse instead of recompute
Cache the stable prefixprovider caching · works through any framework
AnthropicPrompt caching via cache_control breakpoints on the stable prefix.
OpenAIAutomatic prompt caching on repeated prefixes.
GoogleGemini context caching for reused context blocks.
the one ruleKeep the system prompt + tool schemas byte-identical at the front of every request — exactly what this calculator’s cache lever assumes.
Take fewer steps
Bound the looprecursion_limit · max_iterations · max_turns · max_iter
LangGraphrecursion_limit on invoke() caps graph steps.
Google ADKLoopAgent(max_iterations=…); early exit by a sub-agent signalling escalation or calling exit_loop.
OpenAI Agents SDKmax_turns on the run.
CrewAImax_iter per agent.
the design half“Exit when the goal is met” is the stop condition / escalation — the cap is the safety net, not the plan.
Harden against failurestool error handling · node retries
LangGraphToolNode error surfacing and node-level retry policies keep one failure from re-running the run.
Google ADKCallbacks around tool execution for validation and recovery.
the design halfIdempotent tools + narrow retries, so a flaky API never replays the whole transcript.
Place the work well
Batch non-urgent workprovider batch tiers · ~50%
provider layerAnthropic Message Batches and the OpenAI Batch API price asynchronous workloads at ~50% — this lever’s default — callable from any framework for non-interactive jobs.
Carbon-aware placementregion choice · scheduling
deployment layerA deployment decision, not a code decision: choose low-carbon cloud regions for the serving endpoint, and schedule flexible batch work to cleaner grid hours — see the methodology’s carbon-aware sources.

Extend this reference implementation

This is one worked example, meant to be adapted. Everything the engine reads — models, grids, workload presets, reduction levers, assumptions — lives in a single DATA block at the top of the page's script, each entry carrying its source. Organizations are encouraged to fork it and swap in their own data; the UI, the maths and the waterfall recalculate automatically.

+Add your own models

Append your measured or contracted numbers to DATA.models — a tile appears automatically.

{ id:"ours", nm:"Acme in-house 8B", inPrice:0.30, outPrice:1.2, // $/M tok eIn:0.05, eOut:0.25, // Wh/1k tok src:"internal telemetry, 2026-Q2" }

+Add your region & presets

Add your grid's intensity to DATA.grids and your real workloads to DATA.presets so colleagues explore your systems, not generic ones.

{ id:"in-south", nm:"India — South", g:632, src:"Electricity Maps, 2026" }

+Add your own levers

A lever is a name, a note and a function that transforms the workload — the waterfall re-simulates it honestly alongside the rest.

{ id:"distill", group:"Spend fewer tokens", nm:"Distilled house model", st:"−40% energy", note:"Fine-tuned small model for tier-1 asks.", apply:p=>{ p.routeFraction=.8; } }

If you build a variant — a different workload class, a measured back-end, an alternative methodology — consider contributing it back to the GSF Reference Implementations repository. Multiple valid approaches to the same problem are a feature of the collection — stages mode (role-based model assignment with a distinct token profile per role) shipped in this version; the most-wanted contributions now are per-stage caching economics and a measured, instrumented back-end, as flagged in the methodology roadmap.

How it calculates

input(t) = system + task + min(history, cap)  · transcript re-processed each turn
stages (optional) = the run is a sequence of roles, each with its own model & per-turn profile; the transcript flows through all of them
cost/run = Σ (in·Pin + out·Pout) / 10⁶  × (1+retry) × batch
kWh = Σ (in·Ein + out·Eout) / 10⁶  × (1+retry) × PUE
gCO₂e = E·I + M  =  (kWh × grid intensity × carbon-aware)  +  embodied
M (embodied) = accelerator Wh × [ 1,200 kg / (5 y × 8,760 h × 700 W) ] ≈ 0.039 g/Wh   ·  water = kWh × 1.8 L

The calculation follows the Software Carbon Intensity shape — SCI = (E·I + M)/R, per the SCI for AI specification (extending ISO/IEC 21031:2024) — with the functional unit R = 1 agent run. Both terms of the SCI numerator are modelled: E·I, the operational emissions of the electricity consumed, and M, the embodied emissions of manufacturing the hardware, amortized over the accelerator time a run occupies. The split matters for decision-making: moving to a cleaner grid or scheduling carbon-aware shrinks E·I but not M — the only way to shrink M is to use less compute. On a low-carbon grid, embodied emissions can become the dominant share.

Default behaviour, and the departures modelled. The baseline models the documented default of major LLM APIs: the full conversation context is processed and billed as input tokens on every request. This holds even when the provider stores conversation state server-side — OpenAI's documentation states that even when using previous_response_id, all previous input tokens in the chain are billed as input tokens; stored state changes where the transcript lives, not how many tokens are processed. The departures from that default are modelled explicitly as levers, so they are a visible choice rather than a hidden assumption: prompt caching (re-processed prefixes discounted — default 10% of input price and energy, Anthropic-style cache reads — adjustable via the cache-read slider in Fine-tune, since other providers discount differently) and a memory layer (summarisation / retrieval, which reduces the tokens carried at all). Provider billing evolves — verify against your provider's current documentation.

Known limitations & roadmap. Stated so they are choices, not surprises. (1) Per-role stages: stages mode assigns each role (router, loop, guardrail…) its own model tier and per-turn token profile, with the transcript flowing through all of them; the single-profile sliders remain the default for simplicity, and the right-size lever approximates routing within a stage. What is still shared across stages: the cache-read rate and the memory-layer cap — per-stage caching economics are the top remaining roadmap item. (2) Caching: modelled as a flat read-rate discount; cache-write premiums, TTL and storage fees are not modelled. (3) Embodied M: amortized at rated load by default; the utilization slider lets you explore how under-utilized fleets (utilization fluctuates widely in real inference deployments) inflate per-token embodied carbon. (4) Scope: water uses a single indicative factor; training, networking and end-user-device emissions are outside the boundary. Feedback that sharpens these is welcome via the GSF repository.

What this is and isn't. This tool simulates from calibrated defaults — it does not instrument real API calls, and estimation proxies of this kind have been reported to undercount measured energy by 2–6×. Use it to build intuition and compare scenarios, not to report numbers. For a measured, instrumented application of SCI for AI, see the GSF sci-for-ai reference implementation, which obtains per-call energy from provider SDKs and replayable recorded fixtures.

Sources behind the defaults

Each constant in the code carries the reference it is calibrated against. Vintage: 2026-Q1.

  • short-query energy
    0.24–1 Wh    Jegham et al. 2025, How Hungry is AI? — 30-model benchmark, ~0.42 Wh for a short GPT-4o query (arXiv:2505.09598) · Google 2025 — production-measured median Gemini text prompt 0.24 Wh, 0.03 gCO₂e, 0.26 mL water (arXiv:2508.15734) · OpenAI 2025 — ~0.34 Wh average query (Altman, The Gentle Singularity)
  • reasoning prompts
    up to ~33 Wh    Jegham et al. 2025 — the most energy-intensive reasoning models (o3, DeepSeek-R1) exceeded ~29–33 Wh per long prompt, over 65× the most efficient systems. The "reasoning-heavy" tier is calibrated against this ceiling.
  • API pricing bandsCloudZero and PE Collective 2026 LLM API pricing surveys — roughly $0.10/M (budget) to $30/M (frontier reasoning) input tokens. cloudzero.com
  • grid intensity
    50–650 gCO₂e/kWh    Ember Global Electricity Review · Electricity Maps · IEA Electricity 2024 — world average ~450–480; hydro/nuclear regions 20–80; coal-heavy grids 600–900.
  • PUE 1.2 · water 1.8 L/kWhModern hyperscale operators report PUE ~1.1–1.2 (sustainability reports). Water is a combined on-site cooling + generation figure; it varies enormously by site — indicative only.
  • carbon-aware schedulingÖzcan et al. 2025 model LLM-inference emissions under real grid conditions and explore carbon-aware scheduling via energy-system co-simulation (arXiv:2507.11417); the reported potential of time/location-shifting varies widely by region and flexibility. This demo deliberately uses a conservative 30% — adjust it to your own grid's data.
  • measurement caveatEstimation proxies based on FLOPs or GPU utilisation have been reported to undercount measured energy consumption by 2–6× (Fernandez et al. 2025, arXiv:2504.17674, ACL 2025). All figures here are estimates, subject to the same class of uncertainty.
  • caching & batch pricingCache reads at 10% of base input price and Message Batches at −50% are Anthropic’s published rates; the OpenAI Batch API is likewise −50%, while OpenAI’s automatic-caching read discount varies by model (50–90%). The cache-read slider defaults to the 10% figure and is adjustable; cache-write premiums (×1.25–×2 on Anthropic) are not modelled, which slightly flatters the cache lever.
  • context billed
    per request (default)    Provider documentation confirms the full conversation is billed as input on each request even with server-side state (OpenAI — Conversation state). Caching discounts and memory architectures are the modelled departures; billing details vary by provider and change over time.
  • embodied emissions
    M ≈ 0.039 g/Wh    Reported LCAs and vendor disclosures put a data-centre AI accelerator (A100/H100 class) at roughly 1,000–1,500 kgCO₂e embodied (Patterson et al.; Boavizta); amortized here over 5 years at ~700 W under load, i.e. assuming full utilization — the most favorable case; real inference fleets run lower, and per-token M scales inversely with utilization (see the Fine-tune slider). Replace with values for your hardware.
  • framework groundingConcept-to-code mapping (see the In practice tab) checked against LangGraph docs · Google ADK docs (LlmAgent, SequentialAgent, LoopAgent/max_iterations) · OpenAI Agents SDK · CrewAI docs, vintage 2026-Q3. Framework scaffolding overhead is not modelled.
  • metric standardSCI for AI — the Green Software Foundation's AI extension of Software Carbon Intensity (SCI), ISO/IEC 21031:2024 · GSF Reference Implementations.
  • equivalencesSmartphone charge ≈ 12 Wh · typical passenger car ≈ 400 gCO₂e/mile (≈ 250 g/km) — US EPA GHG Equivalencies Calculator · LED bulb ≈ 10 W.

Honesty note. These defaults are calibrated estimates anchored to the published measurements above — they are not measurements of any specific vendor, model or region, and this tool does not produce the definitive number for your workload. Different teams will reasonably make different choices about measurement providers, assumptions and approach; this implementation documents its choices so you can evaluate them against your own context. The value of the tool is its structure and its levers, not any single constant.

Link copied — paste it anywhere