Dedicated capacity, by application.
Steady volume, or agents that need their own lane.
You run inference or sandbox jobs at a steady rate and want capacity sized to it, or you run agents that shouldn't share a pool with anyone else. Start on the shared API in both cases, and apply once your usage history backs up the request.
Apply, talk it through, keep the same API.
Send your workload
DM x.com/provn with what you run and an estimate of volume. There is no signup form.
Hear back from a person
Provn tells you whether it can serve the workload and on what terms. Some applications get a no.
Call the endpoints you already use
If Provn takes the workload on, you reach the capacity through the same gateway, keys and receipts.
The gateway rules come with it.
Metering at the gateway
Tokens for inference and CPU milliseconds for sandboxes. The receipt shows the billed figure.
Caps per key
Spend caps, model allowlists, expiry and delegation bind dedicated traffic the same way they bind shared traffic.
Prepaid ETH balance
Usage draws down the balance you fund with ETH on Robinhood Chain.
Signed receipts
Each call returns a receipt with metadata and a fingerprint of the request, and none of its content.
Standard privacy tier
The host serving your model still processes prompts in plaintext. Dedicated capacity adds no confidential tier.
Stated before you apply.
No marketplace
No third-party operator serves Provn traffic, and a dedicated arrangement doesn't change that.
No self-serve
No button spins up capacity. A person answers each application.
No machine access
You get metered API access. Provn doesn't hand out VMs or SSH logins.
Put this in your DM.
The more you include, the faster Provn can give you a straight answer.
Inference, sandbox runs, or both.
Rough volume: requests or CPU time per day, and how bursty it gets.
The models you need, or what your sandbox code does.
Latency targets, and whether you need receipts for an audit.