Sell directly or through routers

There are two ways to sell tokens from your GPUs, and most GPU owners do both:

	Sell directly	List on routers
Who buys	Your customers, under your contracts	Developers who already buy open-model tokens through OpenRouter or Hugging Face
What you need	A domain, prices, keys, a way to invoice	The router's provider onboarding, and good public metrics
Who pays you	Your customers	The router, under your agreement with it
Price	Yours to set per customer	Yours to set, compared side by side with every other provider of the model
Sales effort	Yours	None; routers rank you on price, speed, uptime and correctness

denv runs both from the same environments. By default, direct customers are served first and router traffic uses the capacity they leave idle.

Sell directly

denv domain add api.yourcloud.com --env ds-flash --stage prod-us

Create this record, then wait for the certificate:
  api.yourcloud.com  CNAME  ds-flash--prod-us.edge.denv.run

Then add customers, keys, limits and prices as in Sell tokens. Offer pay-per-token on a shared stage, reserved throughput with a per-customer --tpm limit, or a dedicated stage for one customer.

List on OpenRouter

OpenRouter's provider guide asks providers to fill out its onboarding form and then:

• Serve a list-models endpoint that OpenRouter polls. Each model declares its id, Hugging Face id, quantization, context length, supported parameters, prices (prompt, cached prompt, completion, reasoning), optional peak and off-peak rates, capacity, datacenters and faster service tiers.
• Be payable automatically, by auto top-up or invoicing.
• Stay up. OpenRouter counts successful requests over total, excluding user errors. At 95% and above you are routed normally; 80 to 94% lowers your priority; below 80% you are used only as a fallback. Calculation starts after 100 requests.
• Stay fast. OpenRouter publishes time to first token and throughput for every provider on each model page. Its guide asks providers to return early 429s instead of queueing, stream tokens as soon as they exist, and send keep-alives during long reasoning.
• Get tool calls right. OpenRouter's Auto Exacto reorders providers for tool-calling requests by throughput, tool-call success rate and benchmark results.

Check what is missing:

denv listing check openrouter --env ds-flash

model feed        -    run `denv listing enable openrouter`
quantization      ok   bf16 declared from release ds-flash@v8
pricing           ok   from `denv price` (prompt, cached prompt, completion)
capacity          ok   tokens per minute derived from stage capacity
early 429s        ok   router customer limited before queueing
keep-alives       ok   SSE comments during reasoning
tool calls        ok   parity suite 512/512, tool-call cases 98/98
onboarding form   you  submit OpenRouter's provider form
payment terms     you  auto top-up or invoicing with OpenRouter

denv listing enable openrouter --env ds-flash --stage prod-us

This serves the model feed from your domain, declares quantization from the release (never a guess), takes prices from denv price, and derives capacity from what the stage can serve. It creates a router customer, so router traffic is metered separately and limited before it would queue.

When a release changes quantization, context length or prices, the feed changes with it. To take a model off OpenRouter before a change, set the stage's listing to not ready:

denv listing disable openrouter --env ds-flash

List on Hugging Face

Hugging Face Inference Providers routes developers to registered providers by speed, price or preference. Its registration guide asks a provider to implement its standard task APIs, register model mappings, implement a billing endpoint, add the provider to its JavaScript and Python clients, and be on a Team or Enterprise Hub plan.

denv listing check huggingface --env ds-flash
denv listing enable huggingface --env ds-flash

denv serves the model-mapping and billing endpoints, backed by its metering. The client pull requests and the plan are yours.

Watch how routers see you

denv listing status --env ds-flash

ROUTER        REQUESTS   SUCCESS   TOK/S   TTFT P50   TOOL CALLS   REVENUE
openrouter    1.2M       99.6%     ...     ...        99.1%        ...
huggingface   84k        99.8%     ...     ...        -            ...

Success is computed the way the router computes it, so a drop shows here before it costs you traffic. A stage alarm on custom: [{ metric: router-success, below: 95% }] rolls back a release that hurts it.

Capacity between the two

--priority	Behavior
below-direct (default)	Router traffic gets only capacity direct customers are not using. When direct load rises, router requests get early 429s, which routers treat as rate limiting rather than downtime.
equal	Router traffic competes with direct customers by limits alone.

The routers' onboarding guides change over time. Follow their current versions; denv does not register you with any router.