Keeping AI Costs Under Control: What Building With AI Really Costs

The first AI invoice rarely surprises people because prices are high. It surprises them because the wrong mental model is in play: the assumption that you pay per question. In reality you pay for volume of text — and for all of the text you send along on every single call. Once that distinction lands, you start making different decisions while building.

This article explains the mechanics, not today's prices. Numbers change, plans get renamed, promotions come and go. The four levers underneath stay the same, whether you work with Claude, ChatGPT, Gemini or a local model.

Billing is per token, not per question

A token is a chunk of text — depending on the language, roughly half a word to a whole one. Providers bill separately for what goes in and what comes out: input tokens are usually far cheaper than output tokens. A short question with a very long answer can therefore cost more than a long question with a terse one.

That has an immediate practical consequence: "keep it brief" is not a politeness formula, it is a cost instruction. Stating a format and a length in your request caps the more expensive half of the bill. It is also why a precise request pays twice over — in quality and in money. How to build one is covered in your first good prompt.

Context is the real cost driver

Here is the surprise that explains most invoices: a language model has no memory between two calls. For a conversation to feel like a conversation, the history so far is sent again with every new step — and billed again as input.

So step twenty of a session pays for the nineteen steps before it. In a coding session, where files, error messages and tool output also land in the history, that baseline grows fast. Ten short, fresh conversations regularly cost less than one long one carrying everything along.

From this follows a habit that saves more than any price comparison: start a new chat as soon as the topic changes. Not out of tidiness, but because the old history is otherwise paid for at every further step. The same applies to agents: a tightly bounded task with a clear stopping criterion produces fewer tool calls than the open-ended exploration that AI agents otherwise like to start.

Subscription and API are two separate worlds

A paid chat subscription is a flat fee with usage limits: you pay a fixed amount monthly and occasionally hit a wall. The API works the other way round — it has no included allowance and bills every call individually. In exchange it blocks nothing, as long as your payment method holds.

The two are separate: a plan contains no API credit, and API usage runs through its own account with its own rate limits and its own billing. Confusing them means either waiting needlessly for a reset or unintentionally starting paid usage. Which limit is currently stopping you, and when it renews, is covered in the piece on Claude and Codex limits.

For everyday work the rule is simple: hands-on work belongs in the subscription, automation belongs in the API — and automation needs a cap.

Four levers that genuinely change the number

Keeping context small is the strongest and cheapest lever, because it applies on every single call. New chat for a new topic, only the relevant file instead of the whole folder, no error logs pasted in full.

Cache what repeats. When many calls share the same long opening — a system instruction, a rulebook, a reference document — providers offer caching for exactly that: Anthropic as prompt caching with a short lifetime, Google as context caching in the Gemini API. The recurring part is then billed at a lower rate than a full retransmission. With short prompts that are fresh every time, caching gains you nothing — it only pays off once there is real repetition.

Batch instead of calling one by one. When a task does not have to finish immediately, asynchronous processing is the cheaper route. Anthropic offers message batches for this, Google a batch API. The price is waiting time — for overnight analyses, bulk translation or data preparation that is usually irrelevant.

Pick the right model size. The largest model is not always the most expensive outcome. For clearly bounded, mechanically checkable tasks a small model is often enough. For open-ended planning and hard debugging the large model is frequently cheaper, because it solves the task on the first attempt rather than the fourth. Three failed cheap attempts cost more than one successful expensive one.

The cap comes before the experiment

The most expensive invoices are not caused by expensive models but by loops nobody stopped: a script that retries on every error, an agent without a stopping criterion, a forgotten cron job. Without a spending cap you find out from the invoice.

Hence a simple order of operations: set the spending cap in the provider account before the first automated call runs. Not afterwards, not "once it goes live". Low rate limits for new keys, separate API keys per project and a maximum token budget per response all help on top.

The monthly five-minute routine

Cost control is not a one-time setting. Four questions per month are enough:

• Does the consumption match what I actually did?
• Is an automated call still running somewhere that I forgot about?
• Is there a recurring long prompt opening that is not cached yet?
• Does the model choice still fit the task, or is it just historical?

What counts is always the provider's usage view, not your own estimate. Anthropic additionally offers a Usage and Cost API for this, which lets you pull consumption and cost into a dashboard of your own.

What this article deliberately does not do

It quotes no concrete price per million tokens and no plan comparison in euros or dollars. Numbers like that are wrong the day a provider changes them — and that happens more often than suits a blog post. The binding values live on the linked pricing pages and in your account view.

What remains is the mechanics: tokens rather than questions, context as a multiplier, separate budgets for plan and API, and a cap that acts before the mistake rather than after it. Set those four things up once and AI costs rarely need thinking about again.