Why resale
- You already pay for capacity at a hosted LLM provider that has spare headroom.
- You want exposure to MOR earnings without operating GPUs.
- You can stack on top of subscription plans (e.g. Venice Diem) and arbitrage between subscription cost and per-second MOR pricing.
Why not resale
- You are bound by the upstream provider’s TOS — many forbid resale; check first.
- Your margins depend on upstream pricing changes and rate limits.
- You cannot offer TEE attestation guarantees (see TEE overview) because you do not control the backend.
How it works mechanically
- You run a normal proxy-router (containerized or bare-metal) — see Container P-Node.
- In your
models-config.jsonyou setapiUrlto the upstream’s chat completions endpoint andapiKeyto your upstream account key. - You register your provider, model, and bid on chain — same as a standard full provider, just without the
teetag. - Consumer prompts arrive on
:3333, get routed to your proxy-router on:8082, which forwards to the upstreamapiUrl. Upstream responses stream back the same way.
Things to watch for
- Concurrency. Set
concurrentSlotsinmodels-config.jsonto a value your upstream account actually supports — over-promising leads to dropped sessions and reputation damage. - Latency. Resale adds two extra hops vs a colocated backend. Bid pricing should reflect this.
- API compatibility. The proxy-router speaks OpenAI-shaped requests; your upstream should as well. Mappings exist for Anthropic and Prodia. See models-config.json.
Next steps
Container P-Node
Stand up a proxy-router container.
Reselling Venice
Concrete example: Venice Diem capacity.
Registering a bid
Bid pricing for resale economics.
On-chain registration
Same flow as a full provider (without
tee).
