01
See the GPU state.
Read queue depth, active requests, memory pressure, and cache availability directly from the serving stack. Know where another request can fit.
CAPACITY, NOT GUESSWORK THE PRICE OF AVAILABLE COMPUTE.
Inference,
priced by
the second.
GPU capacity changes every second. Inference prices should, too.
We’re building a network that reads GPU load, updates model prices, and sends requests where there’s room. The goal: lower costs, shorter waits, and providers that stay within their limits.
In development / Seeking design partners
THE CAPACITY SIGNALSIMULATION
Selected output rate / 1M tokens
—
CAPACITY AVAILABLESAMPLE 000
RECENT QUOTES1 SECOND / SAMPLE
GPU poolLoadOutput / 1MRouting
Move the slider to explore capacity and pricing.
Illustrative pools and prices, not live offers. Output rates shown; production quotes would price input, cached input, and output separately. No inference runs here.
A MARKET THAT MOVES WITH THE MACHINES
Spare capacity. Better prices. Room to run.
01 / THE CONTROL LOOP
Read the load.
Find the room.
A price is only useful if the capacity behind it is available. We’re designing pricing and routing as one continuous loop.
02
Price the headroom.
Refresh offers every second as capacity changes. Spare room can mean a lower quote, within each provider’s minimum price and your maximum rate.
SECOND-BY-SECOND OFFERS03
Route within limits.
Admit work only when a provider has room. Lock the accepted rates for that request, and stop sending new work when capacity runs out.
HARD LIMITS. LOCKED RATES.02 / BOTH SIDES BENEFIT
Idle GPUs cost money.
Busy queues cost time.
Bring the work to the available compute. Give both sides control over the trade.
A price that fits.
A request that moves.
Use the model your workload needs. Set a spending ceiling and response-time preferences. Let available capacity determine which provider gets the next request.
- Choose a maximum token rate
- Keep accepted rates for the whole request
- Decide whether unmatched work waits or stops
Fill the gaps.
Protect the service.
Make spare serving capacity available without committing your whole fleet. Define your price floor, concurrency cap, and the headroom your existing customers need.
- Set minimum rates for each model
- Stop new admissions at capacity limits
- Withdraw offers when telemetry goes stale
Pricing helps balance demand. Admission limits protect the provider, even when demand arrives all at once.
03 / PREDICTABLE WHERE IT COUNTS
A moving market.
A clear agreement.
- 01
The quote changes. Your rate doesn’t.
New requests see new offers. Once a request is admitted, its accepted input, cache, and output rates stay fixed until it finishes.
- 02
Full means full.
Price alone can’t prevent overload. Capacity reservations, concurrency limits, and fresh telemetry must decide whether work is admitted.
- 03
Measure the completed work.
A cheaper token is only a win if quality and latency hold up. Our pilots will compare cost per successful task, response times, and provider load.
HELP BUILD A BETTER MARKET.
Have work to run?
Have room to spare?
We’re looking for teams with inference workloads and providers with spare GPU capacity. Help shape the first pilot.
Create a brief on your device. No account needed.
MORE USEFUL WORK FROM EVERY GPU.IN DEVELOPMENT / 2026
A FEW DETAILS
Before you plug in.
Can I use Odasher today?
Odasher is in development. This site demonstrates the proposed pricing and routing experience; it does not connect to GPUs, run inference, or sell capacity. The pilot planner creates a local brief for a future discussion.
Does “by the second” mean GPU-hour billing?
It describes how often model token-price offers can refresh. The proposed service bills for token usage at the rates accepted when a request starts. It is not a GPU rental service, and a request’s rates would not change halfway through generation.
Will it always be cheaper and faster?
That’s the goal when spare capacity is available, not a guarantee. Results depend on the model, demand, cache reuse, and workload. There are no measured Odasher savings or performance benchmarks yet.
What happens when every provider is full?
The proposed router stops admitting new requests. Customers could choose a bounded wait or an immediate capacity response. It would not silently exceed a price ceiling or send work into an overloaded pool.
Which models and providers are available?
There is no live catalog yet. Initial pilots will focus on open-weight language models and providers able to share serving telemetry and enforce capacity reservations. The pools in the demo are fictional.