ASI:One Models

ASI:One offers three models that share the same API surface, the same API key, and the same capabilities. They differ in how deeply they think, how fast they answer, and how much they cost. Switching between them is a one-line change.

The model field is the only thing that changes between them:

$
curl -X POST https://api.asi1.ai/v1/chat/completions \
>
  -H "Content-Type: application/json" \
>
  -H "Authorization: Bearer $ASI_ONE_API_KEY" \
>
  -d '{
>
    "model": "asi1",
>
    "messages": [
>
      {"role": "user", "content": "Help me plan a trip to Tokyo"}
>
    ]
>
  }'

Choosing a model

Start with asi1. Move off it only when you have a reason:

1. Is latency or cost your binding constraint? Use asi1-mini. If you find yourself wishing the answers were longer or more thorough, you have outgrown it for that workload.
2. Is the task hard enough that quality beats speed? Use asi1-ultra, and expect noticeably higher latency.
3. Otherwise use asi1.

Most applications end up using more than one: asi1-mini for the high-volume path, asi1 or asi1-ultra for the requests that need care.

Comparison

Everything not in that table is the same across all three: streaming, tool calling, reasoning (the budget differs, support does not), structured data, and OpenAI compatibility on both /v1/chat/completions and /v1/responses.

Planner mode is the exception: it runs on /v1/chat/completions, on all three models.

Latency and cost above are relative to each other rather than absolute. Your account’s usage and balance are in your ASI:One account.

Context windows

The context window is the combined budget for your input and the model’s output. A 250,000-token prompt to asi1-mini leaves only about 12,000 tokens of headroom for the response, so leave room for the answer you want.

There is no separate cap on output length. max_tokens bounds a single response if you set it, but the real ceiling is whatever the context window leaves after your input.

What each model is for

asi1

General chat and assistants, tool calling, and mixed workloads where you cannot tell in advance how hard any individual request will be.

asi1-ultra

Work where quality matters more than speed: deep research and synthesis, code and contract review, long multi-step runs, and strategic planning.

asi1-mini

Real-time chat and voice, classification and routing, autocomplete, and high-volume paths where each request is straightforward on its own. What you trade for the speed is depth and response length.

Switching models

Change one field. Everything else about the request stays the same.

1
  {
2
-   "model": "asi1",
3
+   "model": "asi1-mini",
4
    "messages": [...]
5
  }

The same API key works for all three, so you can route per request rather than per application. Two patterns worth knowing:

• Cascade. Send everything to asi1-mini first and retry on asi1 or asi1-ultra when the answer is not good enough.
• Route by request. Classify the incoming request and pick the model up front.

When you change models, A/B the workloads you care about and measure quality rather than assuming the more capable model is better for every task. On simple requests it is mostly slower.

Next steps

1. Chat Completions API - The default endpoint in full, including streaming
2. Reasoning - Turn reasoning on and control how much of it you pay for
3. Tool Calling - Let the model call your own functions
4. Planner Mode - Multi-step work against Agentverse agents