Cresec

How to reduce token usage in repeatable AI workflows

By the Cresec team · Published

When an AI workflow repeats, part of each model call may be work you have already described: checking required fields, grouping records, choosing a template or formatting the same output. Moving those fixed steps into code can reduce the material the model needs to process on each run.

The amount depends on the workflow. Count the one-time conversion work and compare outputs of equivalent quality before making a savings claim. This guide gives you a worksheet for that comparison.

Start with a routine you can explain

Consider the Jira-to-Slack weekly update. Required-field checks, duplicate detection, status counts and the message layout have explicit rules. They can run as code. Interpreting a vague blocker or shortening a long description may still need a model or a person.

Write down each step and the judgment it needs. Do not move a step into code by quietly dropping information the result depends on. If someone still needs to reconstruct the missing detail, you have moved the work rather than saved it.

Use a transparent token ledger

The numbers below are illustrative inputs for a worked calculation, not measurements from Cresec or a customer. Both paths have the same assumed 300 output tokens per run. The code-based path has a one-time build and review budget before the repeated runs begin.

Illustrative token budgets for 20 equivalent runs
Budget itemRepeated promptCode plus bounded AI
One-time setup input tokens012,000
One-time setup output tokens02,000
Input tokens per run4,200900
Output tokens per run300300
Total input tokens after 20 runs84,00030,000
Total output tokens after 20 runs6,0008,000
Total tokens after 20 runs90,00038,000

For the first run, those assumptions give 4,500 tokens for the repeated prompt and 15,200 for setup plus the new path. At 20 runs, the totals are 90,000 and 38,000. The example shows why one-time setup and the number of useful repeats matter; it does not establish a result for your workflow.

Calculate cost separately from token count

Input and output tokens can have different prices. Caching, model choice and other billing categories can also affect the bill. Apply your provider’s actual rates to each category rather than treating every token as the same unit of money.

Model cost =
  (input tokens × input rate per million
   + output tokens × output rate per million) / 1,000,000

Total workflow cost =
  build and review cost
  + successful-run cost
  + failed attempts and retries
  + hosting and other service charges

If the new path costs less per equivalent run, divide its additional setup cost by that per-run difference to estimate break-even. If the per-run difference is zero or negative, repeating it will not recover the setup cost under those assumptions.

Keep quality and failures in the comparison

Use the same permitted inputs and acceptance rules for both paths. For the weekly update, check the counts, blocker, owners, dates and audience. Include an unknown status, a missing owner and contradictory notes. A shorter answer that omits a blocker is not an equivalent result.

Record every model attempt, including retries, repair prompts and calls whose outcome is uncertain. Note cached-input usage separately where the provider reports it. Keep model, configuration and workflow version with the results so a later rewrite can be compared fairly.

Copy this measurement worksheet

Workflow and version:
Repeated-prompt version and model:
New tool version and model:
Input set and required output checks:
One-time conversion and review usage:
Per-run input, cached input and output usage:
Failed attempts, retries and uncertain calls:
Accepted outputs / attempted runs:
Human correction and review time:
Hosting and other charges:
Observed repeat count and estimated break-even:

Download the token-usage spreadsheet starter and record totals for all attempts; retry usage is part of those totals, not an extra amount to add twice. Measure a small set of representative cases first, then keep the ledger across real repeats. Cresec puts fixed steps in code and keeps AI judgments explicit; the result you should evaluate is useful, repeatable work with governance and control. Start with the skill-to-tool blueprint, check a routine, or discuss a pilot with a measurable repeated job.

See it fail against a design, not a detector.

One poisoned ticket, two designs of the same routine, and a model assumed fully fooled in both.

Watch the attack fail