The App Started Guarding Before the Invoice Arrived — an AI Cost-Cap Spend Guard in AIO Helper

On April 16, 2026, I implemented a safeguard in the API server of AIO Helper, our SEO analysis SaaS platform. This mechanism halts processing if a site's monthly AI API spend approaches its per-site cap of $50, before any AI call is initiated. Requests that exceed the remaining budget are halted before the AI is invoked. The cost is only recorded after a successful AI call.

I merged the budget check and usage recording into a single database INSERT operation instead of executing them as separate steps. However, the strict budget guarantee under concurrent requests has not been thoroughly tested against a live Postgres database. Additionally, any overruns caused by concurrent requests cannot be prevented after the fact.

On April 23, I introduced a warning system that activates when the budget falls below 10% (240 tests were passed after implementation). This system monitors three features that utilize the text-generation AI: page-goal auto-generation, title and description suggestions, and batch suggestions. The batch suggestions feature rechecks the budget right before each page's AI call. However, calls that generate search vectors were excluded at this point.

The primary objective is to utilize AIO Helper efficiently and minimize manual research time. However, AI API costs accumulate not only due to increased usage but also when the same processing is repeated due to bugs. Simply displaying the spend on the admin dashboard is insufficient, as by the time the cost is noticed, it has already been incurred.

To address this, I created two components: a mechanism that prevents spending and a ledger that records each text-generation call's details, including site, model, endpoint, token counts, and cost. The budget and usage records are stored in the API server's database, and the three text-generation features read these records right before invoking the AI.

The goal is to achieve both stopping and improving from the same records, rather than just stopping at $50 per month. I aimed for a state where stopping and improving can be achieved from the same records. The processing flow is as follows: when a request for one of the three text-generation features is received, the API server calculates the cost based on the selected model and expected input/output.

It then compares the monthly spend and the estimated cost within the database. If the remaining budget is insufficient, the request is halted without calling the external AI API. For page-goal auto-generation and single-page suggestions, a 402 HTTP status code is returned. For batch suggestions, pages that exceed the remaining budget are skipped, and a 200 HTTP status code is returned along with the number of skipped pages.

If the budget is sufficient, the AI API is called, and after a successful call, the actual usage is recorded in the ledger. At the time of recording, the same SQL statement rechecks the cap. It's important to note that stopping at the app's entry point is the key to the cap functioning as a control mechanism, and this ledger is not a substitute for the final invoice.

While the app estimates costs based on token counts and its internal price table, it may not necessarily match the provider's final bill. The in-app ledger represents the number used to halt processing early, while the invoice is the actual amount you ultimately pay.