A monthly cap and a per-run cap, both in cents, both editable from the panel. Before a post is written or an image started, canSpend() adds the estimate to what the run and the month have already spent and refuses if either ceiling would break. After the call, the true cost from real token usage is recorded. The month's spend is summed from the ledger rows themselves.
Also called: AI spend cap · monthly budget · cost control · run budget
- 1spentThisMonth() sums cost_cents from seo_actions since the start of the UTC month.
- 2canSpend(cents) checks the run ceiling first, then the month ceiling, and returns a plain-English reason when it refuses.
- 3The writer estimates about 30 cents per post and an image about 8 cents; refusal is recorded as a skipped action with the reason.
- 4After the model call, real input and output token counts produce the actual cost, which is what lands in the ledger.
- 5The panel shows spend against cap as a bar that turns red past 85%.
The design note explains why an estimate is checked but the truth is recorded: "Callers ask can(estimate) BEFORE the expensive call and spend(actual) after — an estimate that turns out low still gets recorded truthfully, it just can't be prevented retroactively. That is the correct trade: the ledger stays honest, and the next check sees the real number." And the meter is deliberately not a separate counter: "The spend meter reads back the SAME ledger rows the record writes, so the limit and the audit trail can never disagree with each other."
- Automated spend was unbounded and only visible on the invoice.
- A separate spend counter can drift from the actual record of work.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →