Versioned pricing and Project/Token Guard

Cost governance is not one global budget switch. Halro answers four separate questions in order:

1. Price Version: how this Attempt is priced;
2. Project controls: whether the application may start more work;
3. Token Guard: whether this request or recent behavior is anomalous;
4. Run budget: whether one business execution may spend more.

1. Establish trustworthy pricing

Price Versions are immutable and effective-dated. Bind the exact Provider, target, Region, tier, currency, token classes, and any per-request fee. Never use zero to mean “unknown”; mark a genuinely free target explicitly.

1. Establish trustworthy pricing

Item	Console unit	Typical use
Input	USD / 1M tokens	Ordinary input tokens
Cached input	USD / 1M tokens	Provider-reported cache-read input
Output	USD / 1M tokens	Ordinary output and Provider-defined reasoning tokens
Fixed per request	USD / request	Media, Rerank, resource operations, or contract fees

Pricing evidence and recalculation

Store source type and reviewable notes. Public list, contract, internal transfer price, and temporary estimate carry different assurance. Confirm model, Region, Tier, caching rules, and units. The confirmation example catches million-token, fixed-fee, and decimal mistakes but does not replace independent recalculation. Each Attempt binds the full pre-I/O snapshot; later versions never rewrite history.

Immediate, scheduled, and time-window prices

• An immediate version cannot be deleted; supersede it with a later version.
• A scheduled version may be canceled before activation; every new scheduled time must be after all uncanceled scheduled versions.
• If a future version exists, do not insert an earlier “immediate” version; cancel the blocker or schedule after it.
• Time-window pricing uses the Provider’s IANA timezone, not Project Accounting timezone; split windows across midnight.
• Uncovered times use the version’s base rate and are never treated as free.

After restoring an old backup, a scheduled version may have crossed its effective time during downtime. The Deployment enters pricing quarantine until an administrator reviews the timeline and confirms restored pricing.

2. Use Projects for deterministic boundaries

2. Use Projects for deterministic boundaries

Setting	Risk protected	How to set it
Allowed Models	Wrong environment or unapproved model	Only required public Route aliases
Daily Budget	Unbounded daily cost	Normal daily use, peaks, and stop policy; it is a hard gate, not an alert
RPM / TPM	Retry storms or input spikes	Real peak plus justified headroom
Max concurrency	Upstream/local exhaustion	Combine application, Deployment, and Provider concurrency
Input/output token limits	Excessive worst-case request cost	Longest business input and acceptable answer
Body/stream limits	Images or long streams occupy resources	Encoding expansion, client and Gateway timeouts
Allowed CIDRs	Key use from another network	Actual application egress or controlled networks

Separate development, staging, production, owners, and cost centers into distinct Projects. Gateway Keys inherit Project boundaries and never bypass them. Daily Budget follows Accounting timezone, so a day may be 23, 24, or 25 hours. Timezone changes apply after the current period and do not rewrite UTC evidence.

Budget is reserved before Provider I/O and settled from actual or conservative usage afterward. Retries and fallbacks belong to the same visible request but can create multiple billable Attempts.

3. Use Token Guard for abnormal behavior

Token Guard complements, not replaces, Project rate, concurrency, and budget boundaries. Simulate real samples before binding. Fixed thresholds cover per-request tokens, per-minute tokens and cost, concurrency, error rate with minimum samples, and unique source IPs per minute.

3. Use Token Guard for abnormal behavior

Action	Effect	Recommended stage
observe	Initial fixed-threshold hits are recorded; repricing or policy-version rechecks may still fail closed	Establish baseline and observe recheck rejection
alert	Initial hits are recorded and delivered; rechecks may still fail closed	Validate thresholds, delivery, and response
temporary_block	Blocks after the configured violation count	Only after false positives and unblock flow are accepted

Configure violations-before-block, block TTL, and cooldown. Manual unblock is not root-cause remediation. EWMA detects deviation from history; establish absolute RPM, TPM, per-request token, and cost thresholds first, then configure warmup, evaluation window, minimum sample, and cooldown. Current EWMA alerts only and is not an automatic block boundary.

4. Add Run budgets only for business execution boundaries

A Run budget limits the combined committed + reserved + pending cost of one execution, while the Project budget covers the business boundary. Provider retries and fallbacks consume the same Run balance. A new execution of the same Work Unit gets a new Run; do not reset a budget by relabeling a retry. Halro atomically checks both budgets before Provider I/O. Insufficient Run balance does not auto-close the Run. Unknown price cannot pass Run-budget admission even when the instance permits ordinary unknown-price requests.

Run Governance is experimental. Use it only when the application can define a stable Work Unit and Outcome Definition and can close or expire abandoned Runs.

5. Roll out in stages

1. Price review: FinOps/contract owner confirms identity, units, caching, and effective time.
2. Project hard boundaries: allowed models, output, budget, RPM, TPM, and concurrency.
3. Observe: use Token Guard observe over normal peaks, troughs, and releases; test repricing/policy recheck rejection.
4. Alert: validate recipient, deduplication, retry, response deadline, and recheck path.
5. Temporary block: enable only high-confidence fixed thresholds and drill expiry/manual unblock.
6. Run budget: pilot after the application defines real Work Unit/Run boundaries; do not derive them mechanically from HTTP requests.

6. Acceptance matrix

6. Acceptance matrix

Test	Expected result
Deployment has no effective Price Version	Refused before Provider I/O, never shown as $0.00
Explicit free	Known zero cost with a free price snapshot
New Price Version	New Attempts use the new snapshot; historical amounts remain
Scheduled version not active	Current version remains until the effective instant
Project daily budget insufficient	Refused before Provider I/O; blind retry cannot help
Token Guard observe	Initial fixed hit records only; higher Attempt cost or policy change can still return token_guard_blocked on recheck
Temporary block triggered	Subsequent requests reject until TTL or reviewed admin action
Run balance insufficient	Project may have balance, but this Run rejects
Missing Provider Usage or ambiguous result	Attempt is estimated or unknown, never zero by default

After acceptance, expand the Attempt under Usage & Calls and verify reported tokens, price snapshot, input/output/fixed fees, estimated, and final amount.