Cost and latency you can measure

Nothing was budgeted before I built it, so the cost only became visible when I measured it: about 25,000 input tokens per model step and two steps per widget answer. At 300 requests a day that is roughly $63 a month on a cheap model, against a goal of about $5.

I planned the cost before changing code. Caching alone, or a smaller prompt alone, did not get under budget; a small core prompt with detail fetched on demand, plus caching, did. I built a cost calculator that reads the same prices and formula as the evaluations, so any daily limit can be priced before changing it, and a ceiling table that assumes every paid request is the largest the agent can build. Cached and fixed replies cost nothing and do not count toward the daily limit, so the limit times the cost of one paid request is a true ceiling. Every request logs its tokens and the time of each stage. When I measured a reasoning-effort setting, it made answers about 16% faster and 29% cheaper with the same number of checks passed, but one real regression (a career-length question answered with only the timeline) and an untested red-team set, so I left it off by default and wrote down how to repeat the test.

Kept a typical answer at about $0.0001 and computed a monthly ceiling of about $7 at the daily cap. Added a cost calculator that projects any daily limit before it is changed, and logged per-stage timings and token usage on every request. Measured the effect of the model's reasoning-effort setting.

• I left about 0.4 seconds and a third of the cost on the table to avoid shipping a change I could not fully test.
• Prices go stale, so every result carries the date its prices were checked.
• The ceiling uses estimated token sizes, not measurements.

A typical answer costs about $0.0001, the monthly ceiling at the daily cap is about $7, and a cost or latency question is answered by running a command instead of guessing.