What an AI Research Workflow Actually Costs in Tokens

Language-model providers do not bill in dollars per question. They bill in tokens — small chunks of text, often smaller than a whole word — and almost always at two different rates: one for the tokens you send in (the prompt, or input) and a higher one for the tokens the model writes back (the completion, or output). If you have never sat down and actually worked the arithmetic for a real workflow, your intuition about what a research project "costs" in AI usage is probably wrong in one direction or the other. This walks through the real calculation, using placeholder rates you should replace with whatever your own provider currently quotes.

Why prices are never stated as fact on this site

Any specific dollar-per-million-token figure printed on a web page is a snapshot of one provider, one model tier, on one day. Rates change, competitors undercut each other, and providers introduce new tiers regularly. Stating a number as if it were current fact would make this page wrong within months, and worse, it would train you to trust a number instead of checking one. Every figure in this article uses clearly hypothetical rates — think of them as stand-ins you swap for your own provider's published pricing page before you rely on the total for a real budget.

From words to tokens

You think in words; the bill is in tokens. For English prose, a workable rule of thumb is about 0.75 words per token, so a given word count converts to roughly a third more tokens — 400 words comes out to about 533 tokens, and 900 words comes out to about 1,200 tokens. This ratio is an approximation, not an exact tokenizer result: punctuation, unusual words, and non-English text all shift the real count. It is accurate enough for planning a budget, which is the only thing this kind of estimate is for.

A worked example: one exchange

Suppose a single research exchange looks like this: you send a 400-word prompt containing your question and some pasted context, and the model returns a 900-word response. Using placeholder rates of $3 per million input tokens and $15 per million output tokens — a realistic shape for how input and output are typically priced relative to each other, not a claim about any specific provider's current numbers — the arithmetic comes out to roughly 533 input tokens costing about $0.0016, and 1,200 output tokens costing about $0.018, for a total of just under two cents for that one exchange. Output dominates the cost here, which is normal: output tokens are priced higher per unit, and a useful response is usually longer than the question that produced it.

Scaling it to an actual project

A single exchange costing two cents sounds trivial, and in isolation it is. Projects are not single exchanges, though — they are dozens of them, spread across outlining, follow-up questions, revision passes, and rephrasing requests. Run that same 400-in/900-out exchange twenty times over the life of a project, which is a realistic count for anything beyond a short assignment, and the same placeholder rates put the total at roughly $0.39. That number matters less for its size — it is still small change — than for what multiplying by request count teaches you: cost scales linearly with how many times you go back to the well, so the real lever on your AI spending is not the per-request price, it is how many times you make a request and how long each response runs.

Where the real cost actually lives

Because output is priced higher than input and tends to be the larger side of the exchange, the fastest way to make a workflow expensive is to habitually ask for long generated output — full drafts, exhaustive lists, restated context — rather than short, targeted answers. Two research habits that keep the meter low are worth building early. First, ask narrow questions that call for a focused answer rather than open-ended ones that invite a sprawling response; a request for "the three strongest counterarguments" produces a shorter, more useful output than "tell me everything relevant to this topic." Second, avoid re-pasting large blocks of context you have already sent earlier in the same conversation when the tool retains it; redundant input tokens are pure waste, even at input's lower rate, because they add up across every single exchange in a long thread.

Comparing two shapes of workflow

The same total word count can cost very different amounts depending on how it is split between input and output, which is worth seeing side by side. A "light" workflow — short, targeted questions with short answers, say 200 words in and 300 words out, run ten times — moves comparatively little output through the pricier side of the meter. A "heavy" workflow with the same ten requests but 200 words in and 1,800 words out each — the shape you get from repeatedly asking for long, fully-written responses rather than short, structural ones — pushes several times more tokens through the expensive side of the bill for the same number of requests. Neither total is large in absolute dollars at typical rates, but the ratio between them is the real lesson: the cost of a workflow is driven far more by how much finished prose you ask the model to generate than by how many times you ask it something.

This matters beyond the dollar figure. A workflow full of long generated responses is also a workflow that hands you a lot of text to read, evaluate, and verify before any of it is trustworthy. Every one of those output words is a word you are responsible for fact-checking if it contains a claim, a number, or a citation. A cheap workflow in dollars can still be an expensive one in the verification time it creates downstream — which is its own kind of cost, separate from the invoice, and arguably the one that matters more for the integrity of your final document.

Batching requests without hiding the total

When a task genuinely repeats — the same kind of prompt run across many small chunks of a large document, for instance — it helps to estimate for one representative chunk and then multiply by how many chunks you expect, rather than trying to guess a project-wide total directly. This is the same principle a request multiplier applies: work out the per-request input and output word counts once, get the per-request cost, and scale it by the count. Doing this explicitly, on paper or in a spreadsheet, also surfaces a batch that has quietly grown far larger than planned before you are surprised by it, which is a more common way these costs get out of hand than any single expensive request.

Budgeting as a habit, not a one-off calculation

The most useful way to apply this arithmetic is at the start of a project rather than only after a surprising bill. Sketch out roughly how many substantive AI exchanges a project of your scope typically needs — outlining, three or four rounds of feedback on drafts, a final proofreading pass — estimate a representative input and output word count for each type, and multiply by your provider's actual current rates. You will usually find that for an individual working alone, the token cost of a genuinely thoughtful workflow is a rounding error compared to the value of the time saved, provided you are using the tool for the things it is actually good at: outlining, explaining a concept, restructuring a paragraph, checking your own prose. That is the workflow worth costing out. A workflow built around generating pages of finished prose for you to submit unread is a different problem entirely, and it is not one that a lower per-token price makes acceptable — the arithmetic tells you what something costs, not whether it is honest to do.

Model tier is a variable too

Most providers sell more than one tier of model, and the tiers are usually priced differently by a wide margin — a smaller, faster model priced well below a larger, more capable one, sometimes by an order of magnitude on both input and output rates. This is another reason a single quoted price is misleading: "the cost of using AI" depends on which tier you picked for the task, and the right tier depends on what the task needs. Routine, low-stakes work — reformatting a citation, tightening a sentence, checking a definition — rarely needs the most expensive tier a provider offers. Reserve the pricier tier for the exchanges where the extra capability genuinely changes the quality of what comes back, and estimate each tier's contribution to your project total separately, since lumping them together under one assumed rate will throw the whole estimate off in whichever direction you guessed wrong.

Keep the estimate honest

Three habits keep a token-cost estimate useful instead of misleading. Always pull the actual current input and output rates from your provider's own pricing page immediately before budgeting, rather than reusing a number you remember from months ago. Track output length specifically, since it is both the pricier side of the ledger and the side most within your control through how you phrase a request. And treat the resulting dollar figure as a planning tool for deciding whether a long prompt is worth trimming or whether a batch job is worth restructuring — never as a bill, because only your provider's own invoice is that.