How it works

Your agent finds a provider, asks what a specific piece of work will cost, shows you the price, pays, and collects the result. A job is a conversation rather than a single request, so a provider can ask a question part way through, or say the work will take a while and hand back a way to check on it later. None of it needs an account on either side. The first call to a provider that has been sitting idle takes ten seconds or so while it wakes up, longer for a provider that does more work to start, and is fast after that.

This is the readable version of the protocol specification, which has the exact wire format.

The four steps

Find one. dvm search "transcription" ranks the catalog by what you describe; dvm browse walks it. Each result carries an identifier that passes straight into the next command. If you already know the provider, skip this entirely.

Ask what it will cost. dvm describe says what inputs a provider expects. dvm quote prices the specific work you are about to send. This is the moment your agent has a real number to put in front of you, and it happens before anything is committed.

Submit. dvm request sends the job with payment attached. Payment rides inside the request rather than happening beforehand, which is why there is no account: a provider your agent has never contacted is one paid request away.

Collect. Most jobs come back inline. Some hand back artifacts to fetch separately, and some ask a question first.

A job is a conversation

This is what makes DVMs more than a paid API call: it shapes everything your agent does after submitting.

A provider takes a turn, then yields control back. There are five ways a turn can end, and each has an obvious next move:

The provider says	Meaning	What happens next
done	The work is finished	Read the result
a question	It needs your input to continue	Answer it, and the job resumes
a payment is due	A further step needs paying for	Approve it, and the job resumes
still working	This will take a while	Check back later
cancelled	The job failed	No charge settles. What becomes of the money depends on the provider: see payments

While a turn is running, the provider can also stream status text, progress updates, and intermediate artifacts without yielding. Those do not need any action.

In the CLI this arrives as one field. Every response carries next_action, and it is null when the job is done, or one of respond, pay, or poll for the three cases where the job is still alive and waiting on you. A fourth value, refund, shows up when money is coming back from a mid-job Cashu payment rather than the job itself waiting on you. Each one arrives carrying the exact command to run.

One rule matters more than the rest. When a job is waiting on you, it is still open. Answer it, pay it, or poll it, but do not re-submit the request, because a fresh submit starts a second job and a second charge.

Where the result actually is

A completed job carries a payload_in field with one of two values, and reading the wrong one silently loses the output.

"summary" means the summary string is the whole result. Read it and you are done.

"messages" means the summary is a one-line gloss and the real output is in artifact messages, which you fetch with dvm messages <job-id>. Transcripts, audio files, and rendered pages arrive this way. The response tells you how many artifacts are waiting.

Long jobs

A provider with minutes or hours of work ahead does not hold the connection open. It says so, closes the stream, and keeps working.

Your agent disconnects and checks back with dvm status <job-id>. The provider persists everything it produces in the meantime, so reconnecting picks up from where the conversation left off rather than starting over. A job outlives the connection that started it, and it outlives your agent's session too.

First contact is slow, once

Providers scale to zero when nobody is calling them. The first request after an idle stretch has to wake the machine, which typically takes ten to fifteen seconds; a provider with more to start up, like scrape launching a browser, can take longer. Calls after that are fast.

The practical consequence: a timeout or a gateway error on first contact is usually the wake rather than an outage. Retry once, against a machine that is now awake, before concluding a provider is down.

What is happening underneath

Two more things matter here.

Your agent is identified by a key, not a login. It signs its requests. A provider knows you as a public key and a payment history, never as a name or an email address, and the private half never leaves your machine.

Every job leaves a receipt signed by the provider. You get a verifiable record of what you asked for and what you were charged, which you can check later without asking anyone's permission. That is what a provider's track record is built from. Where you hold a prepaid balance, each draw against it is countersigned into the receipt as well, so that part is signed by both sides.

The protocol specification has the message types, the endpoints, and the authentication scheme in full.

Where to go next

• Payments: how the quote and the payment actually work.
• Wallets: where the money that pays for all this lives.
• Budgets: what your agent can spend without asking you.
• dvm CLI reference: every command and JSON shape.