Guides
- Quickstart
- Authentication and keys
- Key protection
- Models, aliases and fallbacks
- Automatic model choice (silicon/auto)
- Chat completions
- Streaming
- Structured outputs and tools
- Logprobs
- Vision
- Responses, Claude and Ollama
- Embeddings, rerank, audio, images
- Files and batches
- Documents and search
- LoRA adapters
- Project tags and costs
- Prefix caching
- Headers, rate limits and spend caps
- Errors
- Privacy and retention
- Verifiable receipts
- Data residency
- Pricing
- Billing
- Pay per request (x402)
- On-chain oracle
- Agent credit (backed compute lines)
- Status
- SDKs
- Swift SDK
- Integrations
- Run a node
- Architecture
- Changelog
API reference
Guide
Automatic model choice (silicon/auto)
Send a request without choosing a model. The gateway picks one that is being served right now and can do what the request asks, and tells you which one answered.
The names
Put one of these in model on a chat surface (chat completions, Responses, Claude Messages, the Ollama chat and generate routes). Names are case-insensitive.
| Model | Picks |
|---|---|
| silicon/auto | The balanced tier: the cheapest model that meets the request's needs, from quality rank 30 up. Weaker models are tried only when nothing at or above the floor is being served. |
| silicon/auto:balanced | The same as silicon/auto. |
| silicon/auto:fast | The smallest model that meets the needs (fewest parameters used per token), then the cheapest. |
| silicon/auto:best | The strongest model that meets the needs (highest quality rank), then the cheapest. |
curl -si https://api.siliconnetwork.io/v1/chat/completions \
-H "Authorization: Bearer $SILICON_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "silicon/auto", "messages": [{"role": "user", "content": "Name three prime numbers."}]}'
HTTP/2 200
silicon-model: mlx-community/Meta-Llama-3.1-8B-Instruct-4bit
silicon-routed-from: silicon/auto
...
{"model": "mlx-community/Meta-Llama-3.1-8B-Instruct-4bit", "choices": [...], "usage": {...}}The model in that answer is an example: which one serves depends on what is loaded on the network at that moment.
How the model is chosen
Every request is matched again, against what is true when it arrives:
1. Being served
Only a model that is loaded on the network right now counts: on the platform's engine, or on an online operator node that serves it. A key pinned to regions, operators or attested nodes counts only what its pins allow. The choice is made from the table below and nothing else, so a model that is not in it is never picked, however cheap.
2. The request's needs
| Need | When the request has |
|---|---|
| Tool calling | A non-empty tools (or functions), unless tool_choice is none. |
| Image input | An image part (image_url, input_image, a Claude image block) or an Ollama images list. |
| JSON output | response_format of type json_object or json_schema, the Responses text.format, or the Ollama format. |
| Context | Always: the prompt as the gateway estimates it, plus your max_tokens (1024 when you set none), must fit the model's context length. |
The prompt estimate is deliberately high (about one token per three bytes of text, plus allowances for images and the chat template), so a model is skipped rather than sent a prompt it may not hold. Billing always uses the engine's actual token counts.
3. Price
Among the models that qualify, the price is each model's current per-token rate (the same rate it bills at, see the pricing page) applied to this request's estimated prompt and output tokens. The tier then orders them as above.
| Model | Family | Parameters | Active | Quality | Tools | Images | JSON |
|---|---|---|---|---|---|---|---|
| llama-3.2-1b | Llama | 1B | 1B | 10 | no | no | yes |
| llama-3.2-3b | Llama | 3B | 3B | 20 | no | no | yes |
| qwen3-vl-4b | Qwen | 4B | 4B | 25 | yes | yes | yes |
| llama-3.1-8b | Llama | 8B | 8B | 35 | yes | no | yes |
| gpt-oss-20b | OpenAI OSS | 21B | 3.6B | 50 | yes | no | yes |
| llama-3.1-70b | Llama | 70B | 70B | 58 | yes | no | yes |
| llama-3.3-70b | Llama | 70B | 70B | 62 | yes | no | yes |
| gpt-oss-120b | OpenAI OSS | 117B | 5.1B | 68 | yes | no | yes |
| qwen3-235b | Qwen | 235B | 22B | 75 | yes | no | yes |
| glm-4.7 | GLM | 355B | 32B | 80 | yes | no | yes |
| deepseek-v3.1 | DeepSeek | 671B | 37B | 80 | yes | no | yes |
| deepseek-v3.2 | DeepSeek | 671B | 37B | 84 | yes | no | yes |
| kimi-k2-thinking | Kimi | 1000B | 32B | 86 | yes | no | yes |
The quality rank is a rough editorial order of these models, not a benchmark score. Active is the parameters used per token, which differs from the total for a mixture of experts; it is what the fast tier ranks on. The two smallest Llama models are not offered for tool calls.
What the response says
The answer names the model that served it, never silicon/auto:
| Where | What |
|---|---|
model | The engine id of the model that served (the body field). |
| Silicon-Model | The same engine id, as on every served response. |
| Silicon-Routed-From | The silicon/auto name you sent, lowercased (silicon/auto, silicon/auto:fast, ...). |
| Silicon-Fallback-From | The first pick's engine id, when a later pick answered (see below). |
You are billed for the model that served, at its own price, exactly as if you had named it. The usage in your dashboard and the usage export name that model.
Fallback
The ranked list is the request's fallback chain: when the first pick cannot serve before any output reaches you (not loaded after all, no capacity, an upstream error or timeout), the next one is tried, up to 5 models in all. Only the attempt that answers is billed. A models array still works after it, for a fallback of your own:
from openai import OpenAI
client = OpenAI(base_url="https://api.siliconnetwork.io/v1", api_key="sn_live_...")
out = client.chat.completions.create(
model="silicon/auto:best",
messages=[{"role": "user", "content": "Summarise RFC 9110 in three lines."}],
extra_body={"models": ["llama-3.1-8b"]}, # tried after the automatic picks
)
print(out.model) # the engine id that answeredWith quality (economy, standard, max) each model is considered in that quantization, and only if that variant is being served. See Models, aliases and fallbacks.
Keys scoped to models
A key whose scope lists models is only ever served one of them: silicon/auto picks among the models the key may call, by catalog alias or full id. A scope that lists silicon/auto itself allows whatever it picks from the table. A key's region, operator and attestation pins apply as they always do.
Errors
| Status | When |
|---|---|
| 503 | No model in the table is being served right now (with Retry-After: 5). |
| 503 | Models are being served, but none meets the request's needs. The message names the need (for example image input, or the context the request needs) and lists what is being served. |
| 403 | The key's model scope allows none of the models that are being served and meet the needs. The message lists them. |
| 400 | An unknown tier (silicon/auto:cheap), or silicon/auto on a surface that is not chat (embeddings, rerank, audio, images): name a model there. |
In GET /v1/models
While at least one model in the table is being served, GET /v1/models lists silicon/auto and its three tiers, each with a description, its tier, the models it would try for a request with no particular needs (resolves_to, best first) and the one it would use now (serving). A request with tools, images, JSON output or a long prompt may be served by another model.
{
"id": "silicon/auto",
"object": "model",
"owned_by": "silicon-network",
"description": "Automatic model choice, balanced tier: ...",
"tier": "balanced",
"resolves_to": ["mlx-community/Meta-Llama-3.1-8B-Instruct-4bit", "..."],
"serving": "mlx-community/Meta-Llama-3.1-8B-Instruct-4bit"
}