Provider and private model routing

Hyperoru separates model choice from evidence access and action authority. A workspace route selects how a bounded role is executed; it does not expand the evidence that role can retrieve or the actions it can perform.

Three reasoning tiers

Owners and Admins choose a routing posture, route each tier, set an optional reasoning budget, and decide whether a private-endpoint failure may fall back to the platform gateway.

LLMGateway routes

The model catalogue is retrieved server-side with the platform credential and returned without secrets. A selected model carries an explicit provider namespace, model identifier, capability metadata, and published token pricing where available. Production usage records the actual model, token counts, cache use, provider request identifier, latency, and measured cost.

Private endpoints

A private endpoint must be HTTPS and OpenAI Responses API compatible. The workspace supplies a name, base URL, allowlisted model identifiers, and write-only API key. Hyperoru encrypts the credential using the platform envelope key with workspace and endpoint associated data. The key is decrypted only inside the worker for a selected run and is never returned by the API or exposed to the operator plane.

If fallback is disabled, an unavailable or invalid private route fails closed. If fallback is explicitly enabled, the run may use the configured platform tier and records that route decision.

Policy and audit history

Routing is versioned inside the workspace policy. Private routes must reference an active endpoint and an allowlisted model. Every endpoint creation, credential rotation, activation change, and routing-policy update creates an immutable audit event.