Economics & Spend Policy
Akshi tracks and limits what agents spend on paid APIs and services. Every agent can have a spend policy that caps costs, restricts payment methods, and enables dry-run simulation.
SpendPolicy
Each agent’s spend policy includes:
| Field | Purpose |
|---|---|
budget_cap | Maximum total spend for the agent’s lifetime (or per reset period) |
per_action_limit | Maximum cost of a single action |
allowed_rails | Which payment rails are permitted (e.g., ["stripe", "l402"]) |
simulation_mode | When true, costs are tracked but not actually charged |
Agents without a configured spend policy cannot make paid requests.
SpendLedger
The SpendLedger tracks cumulative spend per agent. Before each paid action,
the policy engine checks the ledger against the agent’s policy. If the action
would exceed any limit, it is denied.
Deny reasons
When a spend request is blocked, the agent receives a structured denial:
- NoBudgetConfigured — no spend policy exists for this agent.
- BudgetExceeded — the action would push total spend over
budget_cap. - PerActionLimitExceeded — the single action cost exceeds
per_action_limit. - RailNotAllowed — the payment method is not in
allowed_rails.
L402 support
Akshi parses L402
HTTP challenges (402 Payment Required responses with a WWW-Authenticate: L402 header). This allows agents to interact with paid Lightning Network
endpoints when L402 is an allowed rail.
Kill switch
Set AKSHI_SPEND_KILL_SWITCH=1 to immediately halt all paid actions across
every agent. This is a global emergency stop — useful if you suspect runaway
spending. The kill switch takes effect without restarting the runtime.