Stub is the general ledger for agent spend. Set one company-wide budget across your whole fleet, and a spend that would breach it fails the database transaction before any money moves.
Agent wallets cap each session. Across a fleet, no single budget holds: every session stays in bounds while the total quietly runs over.
A failed transaction that retries can re-send an already-irreversible payment. The ledger shows one charge; the vendor was paid twice.
When finance asks how much agents spent, and on what, application logs aren't an answer. There's nothing to reconcile or audit against.
Policies, the budget hierarchy (org → team → agent), and velocity limits are evaluated inside a single ACID transaction, before any money moves.
Under concurrent cross-region writes, Aurora DSQL's optimistic concurrency control returns a serialization failure: SQLSTATE 40001. The overspend never commits.
Stub retries against the fresh balance or records a denial. The balance never goes negative. Every line is immutable and hash-chained for audit.
Correctness here isthe database's consistency model. The load-bearing property is active-active, multi-region strong consistency: writers in us-east-1 and us-east-2 hitting the same balance resolve to one outcome. No other AWS database offers it. Aurora PostgreSQL Global is single-writer, and DynamoDB global tables are eventually consistent, which means silent overspend during replication.
Org → team → agent caps, enforced together in one transaction.
Reserve, pay once, settle the real cost. A retry around an irreversible payment can't double-charge.
Per-transaction and rolling-window caps, vendor rules, approval thresholds.
Tag every spend to a team, customer, or feature and answer chargeback questions cloud bills can't.
Hash-chained entries that detect any altered row, exportable as accounting journal lines.
Runaway spend trips a limit and auto-freezes the account.
Freeze one agent or the entire fleet instantly.
Plain-English questions answered over the ledger, never raw SQL.
Drop the budget gate in front of any paid call. Money moves only after it commits.
Hold an estimate, run the call, settle the real token cost. Reads OpenAI and Anthropic usage alike.
Timeouts and bounded retries, keyed so a retried request resolves to the same entry instead of charging twice.
Split a hot balance across shards for throughput. No shard can go below zero, so the cap still holds.
Stub runs on local Postgres too. Transactions run at SERIALIZABLE, so you get the same 40001 conflicts as production. A model, not a mock.
Ten agents, one $3 budget: three commit, seven denied, balance floors at $0.00.
npm run db:up
echo 'DATABASE_URL=postgres://stub:stub@localhost:5432/stub' >> .env
npm run migrate && npm run seed
npm run dev
npm run test:local # watch the cap hold, with real 40001sGive the whole fleet one budget and let the database enforce it. Every spend is a double-entry transaction that also decrements the budget, so one that would go below zero never commits. Alerts only tell you after the money is gone.
One of them loses. Both read the same balance and try to write it, so Aurora DSQL commits exactly one and returns SQLSTATE 40001 to the other. Stub retries against the fresh balance, or records a denial. The balance never goes negative.
No. Stub reserves the estimate, pays exactly once outside the transaction, then settles the real cost and refunds the difference. Retries replay the ledger, never the payment. The SDK also keys every spend, so a retried request resolves to the same entry.
No. Set DATABASE_URL and Stub runs on local Postgres, console and ledger included. Transactions run at SERIALIZABLE, so you hit the same 40001 conflicts as production.
Both. The SDK holds an estimate, runs the call once, then settles the real token cost. It reads OpenAI and Anthropic usage fields. You supply the rates, because a price table shipped inside a package goes stale and quietly mis-bills you.
Because the guarantee is the database's consistency model, not your code. One budget across regions needs active-active strong consistency. Aurora PostgreSQL Global is single-writer, and DynamoDB global tables are eventually consistent, so last-writer-wins means silent overspend. Stub runs on plain Postgres too, single-region.
Replay a runaway agent and watch the overspend get refused, transaction by transaction.