Budgets

You set the limits and your agent works inside them. Four of them stack: whether it needs your approval for a given job, how much it may spend across a day, a week, or a month, how much your connected wallet will release to it at all, and how much may sit prepaid at any one provider. The wallet cap is the strong one, because it lives inside your own wallet and your agent has no way to change it. Underneath all of them sits the balance: money that is not in the wallet cannot be spent, and there is no card behind the wallet to run up.

The four are independent. None of them replaces another, and each catches a different way spending gets away from you.

1. Whether it asks you at all

By default, a paid job needs your say-so. Your agent shows you the provider, what it is about to do, and the quoted price, and waits.

Two flags change that, and each carries your consent on its own:

• --auto-pay pays without asking, but not up to the whole of --budget. Unless you say otherwise it auto-approves a single charge only up to 20% of the budget, and stops to ask about anything larger. The budget bounds the job; the threshold bounds each payment inside it.
• --auto-pay-below <amount> sets that per-charge threshold explicitly, and carries consent on its own, so it needs no --auto-pay. This is the one most people want: small things flow, big things surface.

Neither flag is needed to spend a balance you already hold. That money left your wallet when the prepaid balance was funded, so drawing on it is not a new charge and does not ask for one. Switching credit off at that provider is what stops drawing there altogether; credits covers that and the other things that can leave a balance undrawn. What the two flags do bound is how expensive a job may be before your agent stops drawing: that ceiling is --auto-pay-below when you set one, otherwise --budget, measured against what the last job at that provider actually cost, since this job's price is not known before it is sent. So a --budget under that figure does stop a draw, and the job says so rather than quietly charging you per call.

If you set neither

Nothing bounds the price of a draw. The balance parked at that provider becomes the only limit, and a job can spend from it without you having seen a price. The stakes are bounded by money already committed to one provider rather than by your whole wallet, and a --budget is what closes the gap, even on a job you expect the balance to cover.

Per job, --max-payments <n> bounds how many separate payments a single job may ask for, defaulting to 5, and --max-increment <amount> bounds how large any one of them may be. A long job that keeps asking cannot quietly become an expensive one.

One rule sits underneath all of this and is not a flag. An instruction to spend that reaches your agent from a web page, a file, or a tool result is not consent. Only your word is.

Standing settings, and the one thing they cannot do

Three settings in ~/.dvm/config.json save you repeating yourself on every call:

Setting	Stands in for	With neither the flag nor the setting
defaultBudget	--budget	Nothing bounds the price of a draw, as above. On a job that pays per call, a request to pay is refused for being over a budget of nothing
autoPayThreshold	--auto-pay-below	The per-charge threshold falls back to 20% of the budget
defaultMaxPayments	--max-payments	5

Both amounts take the same forms the flags do: '$0.50' for fiat, a bare number for millisats.

A standing threshold sizes a charge, it never approves one. This asymmetry is deliberate. --auto-pay-below on the command line carries your consent by itself, because you typed it for this job. The same figure sitting in your config does not: it sets how large an auto-approved charge may be, and something still has to authorize auto-approval at all. That something is --auto-pay or --auto-pay-below on the call. Without one of them, a configured threshold changes nothing and your agent still stops to ask.

Which knob was actually in force is not left for you to guess. When a job leaves a prepaid balance undrawn because its price sat above the ceiling, the response names the ceiling's source as auto_pay_below, config_threshold, or budget, and points at that one specifically — raising either of the others would move nothing.

2. Caps on a day, a week, or a month

dvm budget set --daily '$5' --weekly '$20' --monthly '$50'

These are enforced locally, before any money moves. Set one, all three, or none. dvm budget status shows where you stand against them.

Top-ups count against these caps, not just job payments. The cap is on how much money your agent moves, so funding the wallet with $10 and then spending that $10 on jobs uses $20 of a daily cap. dvm budget status breaks spend down by source, job payments, Lightning float top-ups, and prepaid credit fundings, so the number is never a mystery. Prepaid credit counts once, when it is funded, and the jobs that later draw it down are not counted again.

3. The cap inside your own wallet

If you have connected a Lightning wallet as a float, you set a spending cap on that connection inside the wallet itself.

This is the strong one. It lives in your wallet's database, on the other side of a boundary your agent has no access to, so unlike the caps above it is not a local setting anything on your machine can edit. When it is reached, your wallet refuses the payment and your agent gets a plain refusal it can explain to you.

That single property is what makes autonomous funding reasonable to turn on at all. Your agent can top itself up at three in the morning without waking you, and the worst case is bounded by a number only you can change.

Two caveats. The cap only holds if the wallet runs somewhere your agent cannot reach: a wallet self-hosted on the same machine as the agent gives you less than it looks like. And dvm treats that cap as write-only. --budget on dvm wallet connect records what you told it you set, so it can show the figure back to you, and it is never enforced here and never read back as live state. dvm will not invent a "remaining budget" number, because it has no honest way to know one.

4. How much can sit at one provider

Where a provider offers prepaid credit, a fourth limit caps how much of your money may sit there at any moment. It starts small and rises in two steps as that provider earns a record with you, measured in jobs it has verifiably completed for the identity you sign with, spanning at least a week for the top step. At the top step the provider's own advertised maximum is the only thing left bounding it. The trust ladder has the figure at each step.

These are defaults rather than walls. You can go past them, but only by naming it: a funding that would leave more on deposit than the tier allows is refused until you pass --over-trust, or use dvm credit trust to pre-grant every DVM signed by that builder identity. That persistent grant is builder-wide, not specific to the provider you name. Nothing that was blocked before becomes possible; the oversized path just has to say so out loud, in a transcript you can read. Which means an instruction that reached your agent from a web page has to say so out loud too.

Pre-granting a provider

dvm credit trust <provider> <builder-max|$amount> is the command for this. It reads the provider's /v1/info to learn its builder pubkey, then writes the grant against that key rather than the endpoint, so it covers every DVM that builder signs, not just the one you named. Pass builder-max to pre-grant the provider's own advertised maximum instead of a fixed number. dvm credit trust --list shows every grant you have set, and dvm credit trust --remove <provider> takes one back. The CLI reference has the full command, its JSON shape, and its error codes.

Under the hood the grant lives in ~/.dvm/config.json, under credit.trustOverrides: an object keyed by builder pubkey, each value a dollar string like "$5.00" or the literal "builder-max". dvm credit trust is what writes and reads it now, so you rarely need to open the file yourself; a raw builder pubkey is the one case where it helps to know the shape, since that is also what --remove takes after a provider changes identity and the old key is all that is left to point at.

--over-trust on the command line stays the one-off path when you only need to clear the cap once.

Credits covers the rest of how those balances work.

Underneath all four: the balance

The wallet holds what you put in it. Fund five dollars and five dollars is the most your agent can spend, whatever every setting above says, because there is nothing behind the wallet to draw on. No overdraft, no card, no credit line.

This is why the honest posture is to start small. Fund a few days of expected spend, watch how your agent actually uses it, and top up once you have seen. dvmkit is in beta: treat the wallet as spending money rather than savings, and the risk stays boring.

Seeing where you stand

dvm budget status
dvm wallet history --today

dvm budget status shows spend against each cap, with top-ups and job payments separated. dvm wallet history is the itemised log: every confirmed spend across every rail, newest first, roughly the last month. It is the local wallet's own record, so spends made by another client on another machine are not in it.

Where to go next

• Credits: prepaid balances and the trust ladder in full.
• Payments: how one job gets quoted and paid.
• Wallets: connecting the wallet whose cap is brake number three.
• dvm CLI reference: every flag and JSON shape.