Credits

Some providers let your agent prepay a small balance and draw jobs from it. That is what makes half-cent work worth doing at all: the cost of moving money lands once instead of on every job. Nothing is parked anywhere without your say-so: your agent works out when a balance would pay for itself and offers it, and you can let it act on its own once you are comfortable. Balances stay small by design, a job that fails releases its charge back to the balance rather than taking it, and you can ask for the balance back at any time. If your money sits in a contract, the usual shape when you fund with stablecoins, you can reclaim it yourself; otherwise the provider hands it back. Either way both sides sign every step, so a provider that refuses leaves proof.

What a credit is

A credit is a prepaid balance at one provider, in one currency, belonging to one caller. Your agent funds it once and then draws each job against it, one at a time.

It is not an account. There is no login, nothing to close, and no relationship beyond a balance and a shared history of signed receipts.

Why it exists

Moving money costs something, on every rail. On a five-dollar job that cost is rounding error. On a half-cent job it can exceed the job.

Funding once and drawing many times splits that cost across everything the money buys, so the cost of collecting half a cent falls toward zero. A loop that would have made twenty payments makes one.

There is a second benefit that matters more than it sounds. A balance sitting at a provider is runway. Your wallet can be briefly unreachable, or a mint can be down, and work keeps flowing until the balance drains.

Per-call payment stays completely legitimate and is the floor everywhere. A normally priced job is simply paid as it runs. Prepaid credit is the repeat-use alternative your agent reaches for when the arithmetic favours it, and it is invisible either way.

Your agent manages this

You do not work out sizes or watch balances by hand, but nothing is bought behind your back either. Paying for a job as it runs is covered by the auto-pay consent you have already given. Parking a balance at a provider is a separate decision, and by default the CLI only proposes it: it prices the purchase, says so in its output, and your agent completes it with one command. That is the whole of the friction, and it is deliberate.

What the CLI does, in order:

• uses per-call payment for the first job to any provider. No money parks anywhere on first contact.
• proposes a balance on the second interaction, where the provider offers one, sized to roughly twenty jobs and capped by the trust ladder below.
• draws each later job from the balance, which is one round trip with no payment to attach. A draw is not a purchase, so it needs no per-call payment approval; switching credit off at that provider is what stops drawing there altogether, and the section below covers the other things that can leave a balance parked.
• proposes a refill after a successful job once the balance falls below a quarter of its target. That target is deeper than the opening size, so a refill leaves runway for a provider or a wallet being briefly unreachable.

That behaviour is one of three postures, and suggest is the default one described above. Switch to auto and the two proposals become actions, with nothing else changed. Set off and no balance is bought here at all — and because a balance you cannot draw on would be worse than none, off stops drawing from an existing one too, and refuses a funding outright rather than parking money in a hole. Any of the three can be set for one provider or for all of them; credit posture in the CLI reference has the exact form.

dvm credit list shows what you hold, and dvm credit balance <dvm> asks the provider directly and reconciles your local view against the answer. If several balances exist at one provider, both commands separate the one jobs draw from and every sibling balance they do not; each sibling names the exact drain command that takes it back out.

Released per-call balances

A failed per-job payment can also leave a released one-use balance at a provider that authenticates callers but offers no prepaid credit. The provider's signed receipt proves the amount and its owner. The CLI lists it separately and spends it on the next eligible job before any prepaid balance. It disappears after a signed zero. If its 30-day lifetime ends first, the value is lost because that provider exposes no drain endpoint.

Funding by hand is the default path, and it stays useful under the automatic one for what that path will not do: pre-loading a provider before a batch, or funding an amount of your own choosing. Size it to work rather than to a guessed figure — dvm credit fund <dvm> --target-jobs 500 prices it from what you last paid that provider, or from what it advertises if you have not paid it yet.

When a balance goes undrawn

A held balance is not always the thing that pays. Six situations leave one parked, and the job says which applied rather than leaving you to work it out from an unexpected price: credit is switched off at that provider, the provider no longer treats the balance as live, the balance is spent, it has passed its expiry, the job declared a price ceiling below what the last job there cost, or, on a Tempo-backed channel only, the provider could not confirm the balance's on-chain backing yet and asks you to hold off topping it up until it can. Each one names the single command that changes the outcome, and any remaining reclaimable balance stays visible. See expiry before leaving credit unused.

This matters for what it prevents. Two of the six are a setting of yours deciding not to spend the balance, and the other four are the state of the balance itself. None of them is the provider refusing to honour it, because on all six the draw was never sent. So a price quoted while you hold a balance is a thing to look up rather than a thing to report. The CLI reference has the exact field and every value it can carry; budgets covers the price ceiling.

The trust ladder

How much of your money may sit at any one provider is bounded by that provider's record with you, measured in jobs it has verifiably completed:

Until	At most
3 jobs have verifiably completed	$0.50
15 have, spanning at least a week	$2
after that	whatever the provider advertises

These are defaults, not walls, and going past one has to be said out loud. See budgets for how that works and how it interacts with your other caps.

Credits, receipts, and accumulated trust all belong to the signing identity that earned them. Switching identity with --as partway through does not continue that relationship, it starts a separate one.

Which money funds it

Prepaid credit can be funded over four rails: ecash, Lightning, x402 stablecoin, and Tempo stablecoin. These are routes into the same prepaid balance, not four kinds of credit; your agent picks from what you have connected and what the provider advertises.

Between the two Bitcoin rails, size decides. A funding at or above the provider's advertised floor goes over Lightning directly, because that size is Lightning's territory and routing it through a mint would drain the pocket meant for small payments. Anything below the floor goes as ecash, which is the only rail that can carry a sub-floor amount at all.

Channel or one-payment

Stablecoin prepaid credit uses a reusable channel by default. The channel just holds and settles the same prepaid-credit balance differently; it is not a separate product. A provider can also allow one-payment stablecoin funding, but that choice changes who is on the hook for returning an unused balance:

• A channel is a deposit into a contract, which the provider claims against as you spend. Later top-ups reuse it, and whatever you have not spent is still sitting there with your address on it.
• A one-payment funding is a single signed authorization that settles to the provider like any other payment. Nothing is left holding your money, so a refund is something the provider has to send.

Your agent takes the reusable channel wherever a provider offers one, because one deposit amortizes across every later top-up and the unspent collateral has an on-chain exit. If the reusable instrument is unavailable, that stablecoin rail disappears from the provider's credit menu. Its one-payment method still pays for individual calls.

At a provider that has accepted the manual refund obligation, dvm credit fund <dvm> --funding-mode one-shot takes the single-payment route and --funding-mode reusable insists on the channel. Without that explicit provider opt-in, one-shot fails locally before anything is signed or paid and points back to reusable credit or per-call payment. The flag applies to stablecoin rails only — ecash and Lightning pay once and have no reusable form — and it cannot switch a credit already opened over one instrument to the other.

A credit stays on the rail it was opened on, and the provider enforces that rather than treating it as a preference: a top-up over any other rail is refused instead of rerouted. Your own side holds the other half of the rule, since the provider cannot see which wallets you have connected: if the wallet that opened the credit is gone, the CLI stops rather than refilling it from something else. Drain it and open a new one to move rails.

Am I out the money if a job fails

No. The mechanism is the answer everything else here builds on.

A charge is a hold. It settles into a real debit when the job completes and releases when the job fails, is cancelled, or has its worker die underneath it. A failed job's money goes back to the balance it came from.

Where you stand depends on the provider, and there are three cases:

Where you hold credit, the release lands on that balance and is immediately spendable on the next job. This is the good case and it is what the four paid first-party DVMs do.

Where the provider authenticates you but offers no credit, the release still lands on your own key and your receipt names the balance. You can spend it there, though the dvm CLI does not yet reach for it automatically.

Where the provider authenticates nobody, every caller shares one anonymous identity, so there is no key to claim the balance with and a failed job's payment is not recoverable in practice. Of the first-party DVMs, only discover is in this position. Its keyword search is free, so most calls to it risk nothing; its natural-language mode costs a cent, and that cent is charged partway through the job, only once the provider has confirmed it can serve the request at all.

Note what this is not. No rail sends value backwards. Ecash commits when the provider receives it, and stablecoin settlement is final. What makes you whole is the ledger, not a reversal.

Getting the balance back

dvm credit drain <dvm>

One command asks for the whole balance back. Holds on jobs still running stay where they are; everything available is moved into a liability the provider owes you, and repeating the command reports where that stands.

Where the money lands

On the rail the credit was opened on, with one deliberate exception: money funded over Lightning comes back as ecash, because a Lightning payment out needs a spending credential no provider holds. The rail is otherwise not a choice at this point: a credit backed by a stablecoin channel is reclaimed through that channel, and asking for a different one is refused rather than honoured.

Opened over	Comes back as	Who moves it
A stablecoin channel, x402 or Tempo	Stablecoins, at the address that funded it	Nobody in between. You sign the reclaim and the contract pays out in the same exchange
Ecash	A token only your key can spend, redeemed into your wallet on sight	The provider's batch job prepares it; you pick it up by repeating the command
Lightning	Ecash, the same token an ecash-funded credit comes back as	The provider's batch job prepares it; you pick it up by repeating the command
An explicitly enabled one-payment stablecoin funding	Stablecoins, at an address you name	The provider, by hand: no automatic sender exists on this path

The channel rails are the quick case. Nothing queues, no provider key is in the path, and the balance is back before the command returns. This is the answer for a caller who holds stablecoins and no Lightning wallet that can receive: your money returns on the rail it went out on.

On a Bitcoin balance you get the asset back, not a dollar figure. Put in 1,151 sats, spend a hundredth of what that bought, and what comes back is a hundredth less than 1,151 sats, whatever Bitcoin happens to be worth on the day you ask. The provider is holding sats and owes sats, so neither side is betting on the price in between; your balance moves with Bitcoin exactly as it would have in your own wallet. A few sats come off the top to cover handing it over, and a balance too small to be worth more than that is refused rather than paid out, with the amount left where it is and reclaimable after any top-up.

Understand ecash at funding time, not at drain time. It is real money, spendable at any provider that takes ecash, but turning it into a bank balance needs a Lightning wallet that can receive, and at sub-dollar sizes the fees make that a poor trade.

If the provider will not hand it back

Where the provider is the one holding the money (ecash, Lightning, an explicitly enabled one-payment stablecoin funding), an unpaid drain is a signed IOU. Every step is countersigned by the provider, so you hold your signed request and their signed acknowledgement that they owe you. There is no escrow and nobody in the middle. What you have instead is proof, from artifacts both sides already hold, that a refusal happened. Check that proof yourself, offline, with dvm credit receipts <dvm>; see receipts for what it verifies and how.

A channel is the other case, and it is the reason to prefer one where you have the choice. The deposit sits in a contract rather than with the provider, so a provider that has gone quiet is an inconvenience rather than a loss: dvm wallet x402-withdraw-initiate <dvm> opens a timed exit you finish yourself once the channel's safety delay has passed, and dvm wallet tempo-exit does the same for a Tempo session after its grace period. Both cost you the network fee, and neither needs the provider to agree to anything.

Expiry and reclaim

A credit expires thirty days after its most recent funding by default. Past that, new draws are refused. An expired balance can still be reclaimed until the provider records its release. The SDK periodically releases eligible expired, undrawn balances, so reclaim unused credit before expiry rather than relying on an indefinite refund window. Channel funds follow their channel exit rules; see the SDK lifecycle for the exact exclusions.

In practice you rarely meet expiry. A credit that keeps being refilled is a rolling buffer, and each funding carries the balance into the next window.

Where to go next

• Budgets: the three other limits this one stacks with, and how to go past it deliberately.
• Payments: how one job gets quoted, paid, and settled.
• Wallets: the money that funds all of this.
• Receipts: the signed proof behind every draw and every drain.
• dvm CLI reference: every credit command and JSON shape.