AI coding agent monthly cost: a budget method

Recommendation: An AI coding agent's monthly cost is the sum of separate ledger rows: the access path that pays for inference, metered model usage, billed machine runtime, billed storage, and other paid services. A short measurement period of real tasks turns those rows into one comparable figure, total observed spend per accepted task.

Five rows in one budget equation

cash cost = subscriptions
          + metered model usage outside included access
          + billed machine runtime
          + billed storage
          + other paid services

Each term is one ledger row:

• subscriptions: active plan fees, counted once per account.
• metered model usage outside included access: API or provider usage billed per token or per request beyond what a plan includes.
• billed machine runtime: time the execution host bills for, in that host's billing unit.
• billed storage: retained snapshots, checkouts, and artifacts that carry a storage charge.
• other paid services: tools the agent calls that bill separately, such as a paid search API.

Not every arrangement charges every row. A local machine has no cloud-runtime invoice, and a hosted plan can bundle storage, so the ledger records the actual product terms instead of forcing identical rows. Reviewer time is a planning cost rather than an invoice line, and it is tracked in hours beside the cash total.

Which account pays: subscription access or API billing

OpenAI documents ChatGPT sign-in and API key authentication as distinct access paths for local Codex work, and API key usage follows API billing (OpenAI authentication). Claude Code's cost documentation separates subscription information from API token usage, and its /usage display reports session usage whose billing relevance differs for API users and subscribers (Claude Code usage and costs). For OpenCode, the provider configuration names the endpoint and account that need inspection (OpenCode providers).

The ledger therefore opens with an authentication column: provider, billing account, and whether the activity used included subscription access or separately metered usage. An existing subscription is not evidence that a separately configured API key is covered. Shared reports can abbreviate account identifiers, and credential values never appear in the ledger.

Token usage and per-million rates

OpenAI's API pricing page lists separate input, cached input, and output rates for applicable models (OpenAI API pricing). A budget based only on generated output therefore misses part of the bill. The calculation groups measured usage by model and billing category, then applies the published rate:

row cost = (tokens in category / 1,000,000) x published rate per million tokens

• tokens in category: measured input, cached input, or output tokens for one model.
• published rate per million tokens: the current price for that model and category, read from the provider's price list.

Multiplying a raw token count by a per-million price overstates the row by a factor of one million. Paid tools and external services get their own rows: a task that calls a paid search API creates spend outside the model's generation bill, and that service's billing record is the source.

Runtime and storage

Runtime is the time the execution host bills for, not the time someone spends watching a terminal. A browser tab is a viewing surface, so closing it is not evidence that a billable machine stopped. GitHub Codespaces, for example, documents explicit lifecycle states and idle-timeout behavior, which describes GitHub's model rather than every provider's (GitHub Codespaces lifecycle). Unattended test runs, waiting processes, and forgotten servers all belong in the runtime row, at the billing granularity the host documents.

Storage needs an object and a unit. A snapshot, a repository checkout, and an artifact archive can follow different retention and billing rules, so each storage row records the object, its retained size, the billing period, and who is responsible for deleting it.

The worksheet

Quantity to record holds values measured on the account, and Calculation applies the rate from the account's current price list. The worksheet contains no vendor prices and no typical bill. Rows change independently: longer billed runtime changes only the runtime row, and a different model changes only the rates in the model row. An exclusions line names what the estimate leaves out, such as taxes, paid data sources, and network transfer, so the total does not look more precise than its evidence.

Cost per accepted task

The first measurement period covers several representative tasks: a small fix, a test update, and a change that needs repository exploration. Each task starts with a recorded configuration and ends with acceptance evidence and spend records.

Failed attempts stay in the ledger. Dropping them hides repeated experimentation from the apparent price of a finished patch. The resulting figure is total observed spend divided by the number of accepted tasks, and it exposes a trade-off that per-token prices hide: a lower rate with more failed attempts can cost more per accepted task.

Budget controls and the hosting comparison

A written operating budget defines the allowed account, the planned runtime, a review checkpoint, and the conditions for ending an unsuccessful run. These are management decisions. An estimate or an alert is not an enforced spending cap unless the service itself enforces it.

Local and cloud hosts compare fairly only on the same workload. The cloud environment comparison covers environment choices, and this ledger supplies the cost side of that decision. Oyren meters Codespace runtime separately from agent model usage, and retained snapshots carry a separate storage cost. The live Plans page lists current rates, and the Codespaces page describes the runtime they apply to.