Invoices arrive after the decision
Provider billing is necessary for accounting, but it cannot stop the next request before the money is spent.
Control-plane pillar · Cost
Control AI spend before the next provider call.
Provider invoices tell you what already happened. Talon applies runtime cost policy to the authenticated AI use case on the governed path: per-request limits, per-agent budgets, agent-scoped session soft caps, pre-provider denial, and signed evidence explaining the decision.
request arrives
→ resolve agent key to agent + tenant
→ resolve organization baseline + agent override
→ estimate cost
→ check effective budget
→ allow OR deny before provider access
→ record actual cost and signed decision
asserted session
→ scoped to tenant + authenticated agent
→ accumulate across allowed provider routes
→ deny new request when soft cap is crossedPer-request capPer-agent daily budgetPer-agent monthly budgetSession soft capPre-provider denialSigned evidence
The problem
AI spend is fragmented by use case, not just provider.
A company can use only two model providers and still have many independent cost problems: support automation, coding agents, internal assistants, scheduled jobs and product features each create their own spend pattern and incident path.
Sessions fan out
One coding or agentic session can span many requests and allowed provider routes inside one agent boundary.
Naive token math lies
Cache read/write semantics and provider-specific usage fields affect the cost story and must be preserved in evidence.
Agent / AI-use-case scope
Put a hard runtime decision in front of provider access.
Each AI use case has one agent.talon.yaml, one vault-bound key and one cost-policy override over the organization baseline. When the resolved effective policy denies a request, the provider call does not happen and the denial still produces signed evidence explaining why.
agent:
name: support-slack-bot
key:
secret_name: support-bot-talon-key
policies:
cost_limits:
daily: 10.00
monthly: 200.00
# next request would exceed effective budget
→ DENIED before provider access
→ signed evidence records the reasonSession scope
Understand one multi-request run as a cost unit.
For asserted sessions, Talon accumulates spend across allowed provider routes inside the (tenant, agent) boundary and applies policies.session_limits.max_cost. A new request is denied once accrued spend plus the pre-request estimate exceeds the limit.
Honest boundary: this is a soft cap. In-flight and concurrent requests can overshoot because strict atomic reservation is separate work. Two agents using the same session string remain separate sessions.
policies:
session_limits:
max_cost: 10.00
cost_limits:
daily: 50.00
monthly: 500.00
# accrued session spend + next estimate > limit
→ new request denied
→ provider-native error shape
→ signed session evidenceOne calculation path
Reported caps should be the caps that enforcement actually used.
Talon resolves the organization baseline and the agent override once. The same effective-cap calculation feeds runtime enforcement, talon costs --agent, the budget API and dashboard utilization, so the visible denominator does not drift from the enforced policy.
Organization baseline
gateway.organization_policy provides the common default cost posture.
One agent override
policies.cost_limits and policies.session_limits define the use-case-specific caps.
Signed result
Evidence records the decision, effective policy identity, estimate and provider outcome.
Operator path
Inspect cost by authenticated agent and by asserted session.
| Question | Surface | What you see |
|---|---|---|
| What is this use case spending? | talon costs --agent <name> | Cost attributed to the authenticated Talon agent carried by evidence. |
| What did this session cost? | talon costs --session <id> --json | Machine-readable total inside the agent-scoped asserted session. |
| Which requests were denied? | talon audit list --session <id> | Requests, providers, models, denials and session history. |
| Why was this request stopped? | talon audit show <id> | Structured policy reason, cost facts, policy digests and runtime context. |
| Can I trust the record? | talon audit verify <id> | HMAC integrity verification. |
Cost evidence
The amount should explain how it was derived.
Talon records provider-aware usage facts including input, output and supported cache token semantics, plus pricing basis, currency and whether pricing was known. This supports operational review; Talon is not an accounting or FinOps replacement.
cost evidence can include:
- authenticated agent + tenant
- provider + model
- input / output tokens
- cache read / write tokens
- pricing basis + currency
- request cost
- session rollup
- effective policy digestsWhat is not claimed
Cost control is real; several fleet capabilities remain roadmap.
No automatic model downgrade
Talon does not silently switch to a cheaper model to keep requests running.
No strict concurrent reservation
Session caps remain soft without atomic reservation.
No multi-file fleet serving yet
The agent identity model is shipped, while one process discovering and serving many agent files is tracked separately.
Start with one budget
Put one real AI use case behind a limit.
Create one agent identity, route the application through Talon, set a low evaluation budget, cross it deliberately, and verify that the next request is stopped before provider access with a reviewable evidence record.