Documentation
Budgets that act
A budget that only reports tells you about the money after it is gone. ARC1’s budgets act before dispatch, at a threshold or on an episode, and each action leaves a signed record.
Three kinds of budget
- Billed budgets
- Read and reconcile provider charges against plan. They inform and alert; they do not stop requests.
- Allowances
- Monthly tokens, dollars or both for a person, a group or an application, admitted by the ARC1 Gateway before each request is dispatched.
- Budget-triggered substitution
- When a team reaches a set percentage of its monthly dollar allowance, its requests move to a cheaper approved model.
Every screen that shows a budget says which of the three it is.
Allowances LAB
An allowance can observe, warn or enforce, and its warning threshold defaults to 80%. Under enforcement, the gateway reserves each request’s worst case before dispatch and settles at the provider’s reported usage afterwards. A request whose worst case cannot be bounded is refused, and so is a dollar allowance on a connection without an approved price.
Admission is a test, not a ceiling. Settlement can exceed a reservation; the overage is signed and the next reservation is refused. An allowance keeps spend close to its limit, but it does not promise to stop at the last cent, and nothing it prevents counts as a saving until finance confirms one.
Daily token quotas
For Azure API Management, ARC1 compiles a per-person daily token quota into an approved API policy, reset at midnight UTC. Counters are kept per gateway, so a quota set on two gateways is two quotas, and concurrent or streamed requests can run past it. Readback confirms the configuration, not a refusal.
Alerts that act LAB
Alerts read attention episodes: an agent that stalls, loops, spikes, bloats its context, fans out or runs unattended. The default rules page someone on $25 of spend since an episode began, on fan-out above $50 an hour, on five identical calls in a row, and on every open stall. From an alert, the owner can pause the runner, propose a limit, mark the episode expected or notify whoever owns the work.
Pause is a session action, so a second person approves it. The approved command reaches the runner’s wrapper at its next heartbeat, and the wrapper’s acknowledgment is the stop. An alert never stops anything by itself.
Price it before you set it LAB
The priced policy simulator drafts a limit for a person, team, agent or workload, a routing or substitution rule, a cache lifetime or a model retirement, and prices it on the organization’s recorded traffic. Only a refused request counts as saved; a warned one is still served and paid for. Where coverage is incomplete the figure is a floor, and where a price is unknown the figure is left empty rather than shown as zero.
The result is arithmetic over past traffic, not a forecast or a commitment. It opens in the allowance editor as a draft that still needs two people.
When money counts as saved
Nothing is saved until something is switched off. A realized saving needs a recorded expense reduction on a ledger line, confirmed by finance. Forecast, provisional and finance-confirmed value are kept apart and never added together.
Where it stands
| Capability | State | Evidence |
|---|---|---|
| Billed budgets, forecasts and pre-invoice alerts | LIVE | On our hosted production deployment, with synthetic data. |
| Authoring and approving allowances and substitutions | LIVE | On our hosted production deployment, with synthetic data. |
| Allowance admission and budget-triggered substitution at the ARC1 Gateway | LAB | Built; tested against a stand-in provider. |
| Per-person daily token quotas on Azure API Management | LAB | Contract-tested. |
| Alerts that pause a runner through a second approval | LAB | Built; awaiting release. |
| Priced policy simulator | LAB | Built; awaiting release. |
| One hard stop across every provider’s billing | NEXT | Specified. |
LIVE: in the released product and running on our hosted production deployment, with synthetic data. LAB: built or being built, and run only in our lab or against a vendor’s documented interface. NEXT: designed, not yet built. How we use these words.