Estimate and Cap the Cost of an AI Workflow

Tier: Core · Hands-on time: ~45 minutes

This playbook walks one worked example end-to-end and leaves you a reusable calculator.

When to use

• •
  Before automating any recurring AI task against an API (the pb-03 extraction batch, a summarization pipeline, a triage bot).
• •
  When asked "what will this cost us per month?" and the answer must survive scrutiny.
• •
  After any surprising bill — to find which term of the equation blew up.

Prerequisites

• •
  The workflow defined: what goes in, what comes out, how often it runs.
• •
  Your provider's current pricing page open (prices change; the method here is the durable part).
• •
  One representative real input for measurement.

The workflow

1. 1.

   Learn the one formula. Everything reduces to:

   Copy

   monthly_cost = runs_per_month ×
     ( (input_tokens  / 1,000,000) × input_price_per_Mtok
     + (output_tokens / 1,000,000) × output_price_per_Mtok )
   

   Two facts to internalize: output tokens usually cost 3–5× input tokens, and English text runs ~4 characters (≈0.75 words) per token, so 1,000 words ≈ 1,300 tokens.

2. 2.

   Measure, don't guess, the tokens. Run your representative input once through the real prompt and read the usage report — every provider's API response includes exact input/output token counts (and chat consoles/AI dashboards expose them too). Record: input_tokens, output_tokens. Remember input includes your entire prompt: instructions, few-shot examples, and the document itself.

3. 3.

   Do the worked calculation. Example — nightly support-ticket summarizer: 400 tickets/day, each ticket ~600 words plus a 300-word prompt template (~1,200 input tokens), ~150-token summary out, on a mid-tier model at illustrative rates of $0.60 per M input / $2.40 per M output tokens:

   Copy

   per-run  input: 1,200/1M × $0.60 = $0.00072
   per-run output:   150/1M × $2.40 = $0.00036
   per-run total:                     $0.00108
   monthly: 400 × 30 × $0.00108    ≈ $13.00/month
   

   Now stress it: same workflow on a frontier tier at 10× rates ≈ $130/month; with a verbose prompt that doubles output ≈ $17. You've just seen which knobs matter — tier first (pb-10), output length second.

4. 1.

   Build the calculator once. Put the formula in a spreadsheet with cells for the six variables (runs, in-tokens, out-tokens, two prices, days). Add rows for pessimistic cases: 2× volume, 2× output. If the pessimistic monthly number is still fine, proceed; if it's scary, you've found that out for free.

5. 2.

   Cap it in the provider console. Estimates guard the plan; caps guard the wallet. In your API provider's billing/limits settings, configure before going live:

   • •
     A hard monthly spend limit at ~3× your pessimistic estimate (headroom for legitimate growth, ceiling for bugs).
   • •
     Email alerts at 50% and 80% of that limit.
   • •
     A per-key budget if the provider supports it — one key per workflow, so a runaway script can only spend its own allowance and the bill tells you which workflow spiked.
6. 3.

   Reduce the big terms. Attack in order of leverage: route to a cheaper tier if your eval allows (pb-10); shrink the prompt template, or use prompt caching if offered (repeated prefixes typically become ~90% cheaper); cap output with explicit length limits ("max 100 words") — output is the expensive direction; and use batch processing where available (~50% discounts for non-urgent jobs like nightly runs).

Tool variants

• Spreadsheet calculator (this playbook): transparent, auditable, shareable with finance; the right default.
• Provider dashboards + token counters: every major AI platform shows usage/cost breakdowns per key and model, and most expose a token-counting endpoint or tokenizer tool for pre-measuring inputs without paying for a run.
• Gateway/proxy layers (open-source or hosted): sit between your code and providers, adding per-team budgets, rate limits, and unified cost reporting across vendors — the upgrade path once several workflows and people share one bill.

Verification

• •
  Your measured token counts came from an actual API usage report, not from word-count guessing — re-check: does input_tokens include the prompt template? It must.
• •
  Recompute the worked example with your provider's current prices; your spreadsheet's per-run cost matches the provider dashboard's reported cost for a real run within ~10%.
• •
  Trigger the alert path: set a temporary $1 limit on a test key, run calls until the 50% alert email actually arrives, then restore real limits. An unverified alert is a hope, not a control.
• •
  The pessimistic-case row exists and the hard cap is set at ~3× it — check the console, not your memory.

Pitfalls

• Forgetting the prompt template. The document is 600 words but you're sending 900 — instructions and examples are billed input on every single run. This is the most common 2–3× estimate miss.
• Ignoring the output-price multiplier. Verbose outputs on a 4× output-price model dominate the bill; "be concise" is a cost control.
• Retries and loops. Error-retry logic and agentic multi-step flows multiply runs invisibly. Count API calls, not "tasks" — one agent task can be 15 calls.
• Estimating without capping. The estimate that's wrong by 100× is survivable only if the hard limit exists. Set caps the same day the key is created.
• Conversation-history bloat. In chat-style workflows, each turn resends prior turns as input — costs grow quadratically with conversation length. Truncate or summarize history in long-running flows.

Restricted-environment variant

• •
  Local models (pb-07) change the equation: marginal cost ≈ 0, so the calculation becomes hardware amortization + your time; the cap discipline still applies to any hosted fallback path in the same workflow.
• •
  Client-billable work: keep one API key per client engagement so the provider's cost dashboard doubles as your billing evidence, and anonymize any client text before it enters hosted token counters or playground consoles — pricing tools are still data ingestion.
• •
  Enterprise tenants often bill through cloud marketplaces; the formula is identical, but confirm which console owns the hard limit — a cap set in the wrong console caps nothing.

Success criteria

• •
  A reusable cost spreadsheet exists with the formula, your measured token counts, and optimistic/expected/pessimistic rows.
• •
  Your estimate for one real workflow matched the provider-reported actual within ~20% after a day of live running.
• •
  Hard monthly cap and two alert thresholds are configured and the alert email was proven to fire.
• •
  You can name, from your own numbers, the single most expensive term in your workflow — and what you did about it.