Requests in practice

More budget

You gave “Trading desk” a $200 cap for buying ETH weekly. Week five, the cap has $8 left. The next $50 buy is refused with EXCEEDS_ALLOWANCE, so the model calls its meta-tool:

// waypoint_request_budget
{
  "delegationId": "dlg_7f3a…",
  "addUsdc": 100,
  "reason": "weekly ETH buys resume Monday; $8 remaining of $200 cap"
}

You see it in your dashboard next to the session’s history — what it spent, what it bought. If the record looks right, you approve and sign; the cap becomes $300 and the model’s next buy goes through. If not, you dismiss it. The model is told either way.

A new capability

Your model has a swap allowance and notices your idle stablecoins could earn 4% on a lending market. It can’t touch lending — that waypoint was never granted — so it requests one:

// waypoint_request_grant
{
  "route": "aave:supply",
  "capUsdc": 500,
  "tokens": { "out": ["aUSDC"] },
  "reason": "idle USDC could earn ~4% APY; supply-only,
             withdrawable by owner anytime"
}

The request names the exact waypoint, cap, and tokens. Approving means signing a new allowance, same as ever — and because the grant you sign is the grant, the model can’t widen the ask after the fact.

The ask you ignore

Requests have no timer and no default. One you never act on simply sits there. Nothing changes on-chain, and the model keeps operating inside its existing limits. A budget_increase can only raise a cap it names, on a session it owns — the backend rejects anything else before you ever see it.