Qortex

DOCUMENTATION / QORTEX

Your models. One API.

Connect your own provider credentials, choose the models allowed for each workload, and call Qortex using an application key. Qortex routes model requests; your application owns its conversations and tools.

1. Get started

  1. Register, sign in, and choose a Qortex subscription. Your workspace activates after checkout is confirmed.
  2. In Provider keys, add a supported provider or custom OpenAI-compatible endpoint. The connection is verified before activation. Your provider bills you for inference.
  3. In Routing, create a policy and assign a primary model for each effort level. Add tier backups and a final fallback if needed.
  4. In Application keys, create a Qortex key for your app. Keep provider keys on the server; never put either kind of key in browser code.
  5. Use the API example below. Start with an explicit model or policy while validating your setup, then enable automatic routing.

2. Make a request

Qortex accepts an OpenAI-compatible chat-completions request at POST https://qortex.app/v1/chat/completions. Replace the placeholder key. The example uses a policy and effort to make its choice predictable.

curl https://qortex.app/v1/chat/completions \
  -H 'Authorization: Bearer YOUR_QORTEX_APPLICATION_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qortex/auto",
    "stream": false,
    "messages": [{"role":"user","content":"Summarize this note."}],
    "qortex": {"policy":"auto","effort":"auto","session_id":"conversation-123"}
  }'

model can be qortex/auto, a saved policy alias such as qortex/coding/high, or a provider model ID for direct selection. Policy aliases reflect your saved policies; they are not a fixed hard-coded catalog. The qortex object also accepts explicit policy and effort. A missing or ambiguous policy is rejected rather than guessed.

3. Understand routing

Automatic routing chooses a saved workload policy and one of five effort levels: low, medium, high, max, ultra. Your policy maps each level to a model. An explicit provider model bypasses policy selection. A rule or session command can override the automatic choice. If a provider attempt fails before output is exposed, an eligible backup may be tried within your attempt and capacity limits. Qortex does not silently switch models after streamed content has reached your app.

Automatic first turns commonly dispatch one router call plus one answer call. Explicit model calls and eligible sticky continuations skip the router. Fallbacks and retries add calls. Inspect the request trace to see the actual route source and outbound attempts.

4. Keep conversations and tools stable

Send the same qortex.session_id on turns that belong to one conversation. Qortex can also recognize a full-history continuation without it, but a stable ID is more reliable if your client truncates earlier messages. After a successful routed answer, Qortex pins the provider and model for the continuation when eligible. This avoids an extra router call and helps preserve prompt-cache locality; it does not guarantee a cache hit. Continue sending the messages your model needs—Qortex is not a conversation store.

If the model returns a tool call, execute it in your application, append the assistant tool call and tool result to your conversation, and send the next request with the same session ID. Do not re-route every tool step deliberately unless you want to change models. A provider failure may still require an explicit recovery decision.

5. Optional command controls

Enable commands for a specific application key in Command controls. The default prefix is Q/. Complete user messages such as Q/effort high, Q/policy Coding, Q/status, and Q/auto can adjust session routing. Commands are off by default and require a stable session ID except Q/help. They never execute your tools or change your billing. See the dashboard for key-specific configuration.

6. Capacity and billing

Starter is $10/month for 250,000 outbound provider calls; Growth is $25/month for 1,000,000. Additional 1,000,000-call capacity is opt-in at $20. Every dispatched router, answer, retry, or fallback attempt counts as an outbound call, including a cached call. Waiting or pre-dispatch rejected requests do not count. Provider inference is charged separately to your BYOK provider account.

The Capacity controls limit simultaneous outbound calls and bound waiting requests and deadlines. A full queue or exceeded deadline returns an error; it is not an unlimited background job. These limits do not increase your provider quota. Manage the subscription in Billing.

7. Read the measurements

Requests shows each Qortex decision and provider attempt. Input, cached-input, and output token counts are shown only when measured or reported; unavailable is not zero. Provider cost and the overview savings comparison require usable cost and pricing data. The savings figure compares the same measured token mix against the highest-cost answer model actually used in your workspace, includes router overhead in actual cost, and is a cost comparison—not proof that answer quality was equal.

Operational metadata and prompt retention are separate. Check Privacy before enabling content retention. Hidden reasoning is never collected. Provider-side data retention follows your BYOK provider’s terms. Rotate a compromised Qortex application key or provider key immediately.

8. Troubleshooting

No model appears
Check that the provider key is verified and enabled, then refresh the model registry. A provider’s catalog may change.
A call failed
Open its request trace. Check the provider attempt, model ID, capacity, provider quota, and application-key permissions. Use the request ID for support.
Cache usage is unavailable or zero
Keep model, provider and prompt prefix stable; send the full needed history. Cache support and thresholds belong to the provider, so Qortex cannot promise a hit.
Unexpected call count
Count router, answer, retry and fallback attempts separately. Tool execution in your app is not a Qortex model call.