How Router works

Router gives applications one OpenAI-compatible connection to text models running across participating provider computers. Your application chooses the exact model edition. Router validates the request and its credit limit, reserves an allowed maximum, finds eligible capacity, and relays the response.

The request path

Illustration

Look insideSend a request

Exploded line drawing of the OptimAI Router artwork. Its parts are labelled with the five steps of a request's path through Router.

1. 1Your request arrivesAn authenticated request with an exact model ID and a request UUID.
2. 2Router checks itPaid key access, account and credit limits, request shape, and model limits.
3. 3Router selects capacitySaved prices for the exact revision; Auto or your chosen offer; a credit hold.
4. 4A provider runs the promptThe selected computer runs the model locally and returns ordered output.
5. 5Output returns, then settlesA complete response or event stream, then the final charge on the credit receipt.

1. Your application sends an authenticated request with an exact model ID and a caller-generated request UUID.
2. Router validates the API key's paid access, account and credit limits, request shape, and model limits.
3. Router checks eligible saved prices for the exact model revision. Auto selects the lowest conservative rounded reservation and rotates equal reservations; a manual selection binds one computer/model offer and its displayed pricing revision.
4. The provider runs the prompt locally and returns ordered output.
5. Router returns a complete response or an ordered event stream, then settles the final charge from accepted provider-reported usage and releases unused reserved credits.

What Router decides

Router selects eligible capacity for your exact model and provider choice. Auto ranks conservative credit reservations, rather than either displayed token rate alone. Manual selection never silently falls back to another offer or Auto. It tracks short-lived assignments, cancellations, leases, ordered output, and a durable credit receipt so the request and charge have one recoverable identity.

What your application decides

Your application chooses the model, provider routing choice, messages, output limit, sampling temperature, and whether to stream. Router does not automatically choose a model, silently substitute one, or keep requests in a waiting queue.

Failure stays explicit

If no matching provider is available within the spending limit, Router returns an error. If generation is interrupted, Router reports the interruption instead of combining partial text with another attempt. Accepted provider-reported usage after dispatch may still charge; check the saved receipt before sending another request.

Current trust boundary

Participating provider computers process request content and report token usage. Eligible enrolled devices may serve paid requests after ownership, model, pricing, and availability checks; no administrator approval is required. Reported token counts are the metering input and are not independently verified. A public profile is self-described identity, not verified reputation; use non-sensitive prompts.