Cerver routes each session to the right compute provider.
Your app creates sessions. Cerver chooses the local or remote compute provider that fits each session, then returns output, routing, and metrics through one path.
Your app
Creates a session and keeps talking to that session.
Matches the session to the right provider
Cerver keeps the app-facing session stable while choosing the compute provider underneath it.
Available providers
Local bridges and hosted providers both appear as compute providers Cerver can choose underneath the session.
Different session types need different providers
The same app can open very different session types, and Cerver can route each one to a different provider.
Fast preview provider
A short preview session wants a provider that starts quickly and can expose a preview right away.
Persistent coding provider
A long coding session wants a provider that can stay warm, keep state, and survive longer loops.
Local provider
A repo-local or auth-heavy session may want the user’s own machine instead of hosted compute.
The three questions Cerver answers
This is the practical flow the product should answer every time.
What type of session is this?
Preview, coding loop, browser run, local task, or something else. Cerver uses that session type as the first signal.
Which provider fits that work?
Cerver chooses the local or remote compute provider that best matches the session, or honors the provider you pinned.
How did that provider perform?
Cerver reports startup, latency, output, uptime, and cost back through the same session.