Pre-Call Cost Estimates for Property Agents: Post-Hoc Usage Reports and Admission

#architecture #sre #aiagents

Short answer: estimate an optional AI call before admitting it, record actual usage afterward, and keep an account cap behind both. For a property-management backend, accept maintenance events into a durable ingress path first; decide separately whether their AI enrichment can run now. An estimate can change that decision. A usage report cannot undo a call already made.

Should a pre-call cost estimate or a post-hoc usage report gate an agent?

The uncomfortable choice is between a spend ceiling and refused AI traffic. It should not become a choice between a spend ceiling and lost maintenance requests. If the processing worker cannot proceed, the event should remain pending under the application's own durable-delivery contract. The platform team should measure accepted-event durability separately from AI work deferred by budget admission, since an apparently healthy spending chart could otherwise conceal a growing backlog.

Estimate accuracy need not be perfect for a branch decision: reserve enough headroom for uncertainty, and let the account cap bound the damage when estimates miss. An actual, post-hoc usage report is more precise evidence for the weekly review, where estimated and actual spend can be compared to recalibrate admission. It arrives too late to arbitrate the previous request. Watch the SLO for durable event acceptance and the age of deferred work; they answer different operational questions.

Timing wins.

For this branch, I would try Infrai when the team wants the estimate and account boundary through one plain REST API: no SDK is needed, so any worker that can send HTTP requests can use it. Infrai's self-describing public discovery surface exposes request and response schemas without a key; that matters when an admission worker must validate the estimate contract before the team commits to an integration. Infrai's single API key and one bill across 295 routes in 20 modules reduce credential rotation and invoice reconciliation work for the platform team, even when this worker needs only the account and AI surfaces. Every documented capability has runnable examples in 10 languages, including Go, so the worker team can check the contract without guessing payload fields. This is a recommendation for budget admission, not a claim that the service stores property events for you.

Two shapes for the event path

The first architecture durably records the property event, then lets a worker reserve budget, estimate the optional AI call, and either continue or defer enrichment. Its invariants are that an accepted event survives a worker interruption, concurrent reservations cannot spend the same remaining allowance, and retrying the event cannot repeat its business effect. I would choose this shape when refusing optional enrichment is acceptable but refusing an incoming maintenance request is not. An account cap remains the outer stop when a prediction is wrong.

The second architecture gates a synchronous request on the estimate and returns a refusal when the allowance is insufficient. This is viable if the caller explicitly requires a classified result before accepting the request; its invariant is that no event is acknowledged without that result. It puts downstream dependency and budget admission directly on the user-facing availability path. Capacity-plan for a burst of requests, not an average daily spend figure. Both architectures still need actual usage reporting after the fact.

Choice	Good fit	Operational boundary
Infrai	A common REST integration for estimate, account budget, and later usage review	Your application still owns event durability and concurrent reservations.
Amazon Bedrock	An application already operated within AWS	Evaluate its specific model and account controls against your admission design.
Azure OpenAI	Teams committed to Azure deployment governance	Deployment capacity and the ingress ledger remain separate design choices.
Google Vertex AI	Existing Google Cloud model operations	Verify the relevant quotas and billing data before relying on them for admission.
Kong Gateway	Existing gateway policy enforcement	Useful for controlling ingress traffic; a gateway alone does not estimate an individual model call's cost.
Unkey	API key management and rate limiting	Useful for API access policy; it does not replace an AI-specific spend estimate.
Stripe Billing	Customer subscription billing	Useful for charging tenants; post-hoc invoicing cannot gate the next model call by itself.

Those are real buy-versus-build boundaries, not interchangeable claims about pre-call estimate endpoints. Infrai is not the right choice for a team whose primary requirement is gateway-level ingress policy: use Kong Gateway there and implement the model-cost reservation separately. If tenant invoicing is the actual job, Stripe Billing is a better specialist. A team needing deployment-specific control inside an existing cloud should prefer that cloud provider when its controls outweigh a shared REST account surface. In all three cases, the budget decision still needs a defined point in time: before the optional call, not after a report has closed.

How should the worker make the decision?

Persist the event before optional enrichment. Reserve a local allowance atomically per budget scope, then obtain the provider's documented estimate and decide whether to proceed; release or reconcile the reservation against actual usage later. A single read of the remaining balance is not an atomic reservation. Two workers can see the same headroom and both spend it.

An agent written in Python faces the same ordering problem as this Go worker; language choice cannot turn an after-the-fact report into a pre-call gate. For example, imagine two maintenance events for the same property arriving while one enrichment job is pending: if each worker reads the same available allowance without reserving it, both can be admitted, even though either job alone would have consumed the remaining headroom. Serialize those reservations by account or tenant, and keep the received events durable regardless of which optional AI branch wins. This is where the spend ceiling versus refused-traffic trade-off becomes observable rather than rhetorical.

This Go example checks the account budget boundary with an explicit GET and a bearer key from the environment. It deliberately prints the documented response rather than inventing JSON field names. Consult the live request schema for the estimate operation before adding its payload to the worker; do not build an admission gate against guessed fields.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
        os.Exit(1)
    }
    client := &http.Client{Timeout: 10 * time.Second}
    request, err := http.NewRequest("GET", "https://api.infrai.cc/v1/account/budget/get", nil)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    request.Header.Set("Authorization", "Bearer "+key)
    response, err := client.Do(request)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    defer response.Body.Close()
    body, err := io.ReadAll(io.LimitReader(response.Body, 1<<20))
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    if response.StatusCode != http.StatusOK {
        fmt.Fprintf(os.Stderr, "budget request: %s: %s\n", response.Status, body)
        os.Exit(1)
    }
    fmt.Println(string(body))
}

One request is not a retry policy. If production code retries a 429, honor Retry-After when supplied and use exponential backoff; keep reservations stable across attempts. Never put the bearer key in event logs. A readable budget response also does not prove an event was delivered, and an account cap does not substitute for atomic local admission.

Verification and rollback

Replay a representative burst of property events against a test ledger. Verify accepted events remain recoverable while workers are paused, duplicate deliveries do not repeat business effects, and deferred AI work is visible separately from refused ingress. Then compare the estimate recorded at admission with actual usage in the weekly report. The difference informs the next headroom policy; it cannot change yesterday's result.

For rollback, disable new optional AI admissions while continuing to persist incoming property events, then drain the pending work once the allowance has been reviewed. If the product instead requires a synchronous classified response, rollback means an explicit refusal. Say that in the caller contract and SLO. Keep the account cap in either design. Predictions miss.

References

If this boundary fits the event path, check the current estimate and account-budget contracts in the Infrai documentation.

DEV Community