InstaRoute documentation

InstaRoute is an AI inference gateway and LLM router. Your apps send requests to one endpoint that works like OpenAI's or Anthropic's API. For each request, InstaRoute picks the best model from the providers you've connected, based on cost, speed and quality. It sends the request there, switches to another model if that one fails, and records exactly how much you saved.

1. 1

   Create your account

   Register with your email. A workspace is created for you with a 7-day free trial of the Developer plan, with no card required. When the trial ends it moves to Free unless you choose a plan.
2. 2

   Connect at least one provider

   Go to Dashboard → Providers, pick a provider (e.g. OpenAI or OpusMax), paste its API key and click Test to check it works. Keys are encrypted (AES-256-GCM) and only the last 4 characters are ever shown. Use Update key to rotate one. Connect several providers to give the router more options.
3. 3

   Create an API key for each app

   In Dashboard → API Keys, create a key named after the app (e.g. "InstaBizIntel"). Copy the sk-inf-… secret now, because it is shown only once. One key per app gives you per-app logs, filters and budgets.
4. 4

   Point your app at the gateway

   Set the base URL to https://your-instaroute-host/v1 (OpenAI SDKs) or https://your-instaroute-host (Anthropic SDK / Claude Code) and use your sk-inf-… key in place of the provider key.
5. 5

   Send requests with model: "auto"

   Use auto or another routing goal. Then open Logs and click any request to see which model was chosen, why, and how much it saved.

Any OpenAI- or Anthropic-compatible SDK, framework or tool works. Change the base URL and the key; nothing else in your code needs to change.

Environment variables (most apps)

# Most apps that already use OpenAI only need two settings changed:
OPENAI_BASE_URL=https://your-instaroute-host/v1
OPENAI_API_KEY=sk-inf-...        # InstaRoute key, NOT your OpenAI key
OPENAI_MODEL=auto                # or a goal / model id

Python: OpenAI SDK

from openai import OpenAI

client = OpenAI(
    base_url="https://your-instaroute-host/v1",
    api_key="sk-inf-...",          # your InstaRoute key (one per app)
)

resp = client.chat.completions.create(
    model="auto",                  # or a goal: "cheapest", "coding", ... or a model id
    messages=[{"role": "user", "content": "Summarise this in one line: ..."}],
)
print(resp.choices[0].message.content)

# Routing metadata (provider, model, cost, savings) is on the raw response:
print(resp.model_extra.get("instaroute"))

Node.js / TypeScript: OpenAI SDK (streaming)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://your-instaroute-host/v1",
  apiKey: process.env.INSTAROUTE_API_KEY, // sk-inf-...
});

const resp = await client.chat.completions.create({
  model: "auto",
  messages: [{ role: "user", content: "Hello!" }],
  stream: true,                         // streaming (SSE) works as usual
});
for await (const chunk of resp) process.stdout.write(chunk.choices[0]?.delta?.content ?? "");

cURL

curl https://your-instaroute-host/v1/chat/completions \
  -H "Authorization: Bearer sk-inf-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "Explain recursion simply."}],
    "instaroute": { "deny": ["gpt-5.5-pro"] }
  }'

Anthropic SDK

The /v1/messages endpoint speaks Anthropic's format, so Claude-format requests can be served by any connected provider. Keys work in either the x-api-key or the Authorization: Bearer header. For Claude Code, see Use with Claude Code.

# Anthropic SDK (Python)
from anthropic import Anthropic
client = Anthropic(base_url="https://your-instaroute-host", api_key="sk-inf-...")
msg = client.messages.create(
    model="auto",                 # or "coding", or "claude-sonnet-5-5"
    max_tokens=1024,
    messages=[{"role": "user", "content": "Refactor this function ..."}],
)
print(msg.content[0].text)

OpenAI Responses API

resp = client.responses.create(       # OpenAI SDK client from above
    model="auto",
    instructions="You are a concise assistant.",
    input="Give me three taglines for a coffee shop.",
)
print(resp.output_text)

Embeddings

emb = client.embeddings.create(
    model="text-embedding-3-small",       # pin a model for anything you store
    input=["first document", "second document"],
)
print(len(emb.data[0].embedding))

Claude Code, Anthropic’s coding agent, can send all of its requests through InstaRoute. Every request is then logged with its cost, counts against your key’s budget, and can be routed to a cheaper model. Claude Code talks to POST /v1/messages (streaming and tool use) and /v1/messages/count_tokens, both of which InstaRoute serves.

Before you start

• Connect Anthropic or OpusMax under Providers so Claude models are available. Other providers are used only if you turn on auto (below).
• Create a gateway key under API Keys, named for example “Claude Code”, so its usage shows separately in Logs. Give it a monthly budget if you want a hard spending limit.

1. Point Claude Code at InstaRoute

Use the base URL without /v1. ANTHROPIC_AUTH_TOKEN sends your key as Authorization: Bearer and takes priority over a saved claude.ai login immediately; you do not need to log out. (ANTHROPIC_API_KEY also works, but Claude Code asks you to approve it once.)

# 1. Point Claude Code at InstaRoute (add to ~/.bashrc or ~/.zshrc to keep it)
export ANTHROPIC_BASE_URL=https://your-instaroute-host
export ANTHROPIC_AUTH_TOKEN=sk-inf-...            # your InstaRoute gateway key
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1  # no telemetry or update checks

# 2. Start Claude Code as usual
claude

Or set the same values in a settings file, which applies even when you start Claude Code from an IDE:

// ~/.claude/settings.json (all projects) or .claude/settings.local.json (one project)
{
  "env": {
    "ANTHROPIC_BASE_URL": "https://your-instaroute-host",
    "ANTHROPIC_AUTH_TOKEN": "sk-inf-...",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  }
}

2. Choose how models are picked

# Default: Claude Code asks for Claude models by name and InstaRoute serves them
# from your Anthropic or OpusMax connection.

# Let InstaRoute choose the model for every request:
export ANTHROPIC_MODEL=auto

# Or pin what Claude Code's model aliases map to:
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

# Keep one repository on one model so the prompt cache stays warm:
export ANTHROPIC_CUSTOM_HEADERS="x-instaroute-session-id: my-repo"

With auto, Claude Code prints a one-line “unrecognized model” notice and carries on; InstaRoute picks the model. Claude Code depends heavily on tool calls, so if you allow non-Claude models, restrict auto to tool-capable ones with a routing rule or the allow list.

3. Check it is connected

• In Claude Code, run /status. It should show Anthropic base URL set to https://your-instaroute-host and the auth token coming from ANTHROPIC_AUTH_TOKEN.
• Open Dashboard → Logs and filter by the “Claude Code” app. Each step Claude Code takes appears as a request with model, routing reason, tokens and cost.

4. Test the integration

Run these three checks from any project folder. Each should finish without an error and appear in Logs.

# Test 1 - connection: one prompt, no tools
claude -p "Reply with the word ready"

# Test 2 - tool use: Claude Code must read a file and answer from it
echo "The launch code is BLUE-42." > note.txt
claude -p "What does note.txt say? Read the file."

# Test 3 - routing: let InstaRoute pick the model
ANTHROPIC_MODEL=auto claude -p "Summarise what this folder contains"

Troubleshooting

All inference endpoints need a gateway key: Authorization: Bearer sk-inf-… or x-api-key: sk-inf-….

The model field accepts three kinds of value:

The full live list (ids, providers, context windows, prices) is returned by GET /v1/models and shown in the dashboard Playground model picker.

Send embeddings to POST /v1/embeddings in the OpenAI format, with the same gateway key. The model field takes an embedding model, not a chat model or routing goal:

emb = client.embeddings.create(
    model="gemini-embedding-001",
    input=["Refund policy for damaged items", "How to update a GST number"],
    dimensions=768,                      # only for models marked "adjustable"
)
print(emb.instaroute["dimensions"], emb.instaroute["cost_usd"])

How an embeddings request is handled

1. Authenticate. The gateway key identifies your workspace and app, checks the plan quota and the key’s monthly budget, and applies its rate limit.
2. Resolve the model. A named model is used as is. auto takes the default model of your first connected provider (fixed order), and cheapest takes the lowest price. If the model’s provider is not connected, the request stops with a message listing the models you can use.
3. Call the provider with your own key (BYOK), at the provider’s embeddings endpoint. The input (one string or a batch) and optional dimensions are passed through unchanged.
4. Return OpenAI-format vectors in input order, plus an instaroute object with the provider, model, vector size, cost and latency.
5. Log metadata only: token count, cost, latency and status appear in Logs and in your spend totals. The text you embedded is never stored.

Typical retrieval (RAG) setup

1. Pick one embedding model and write its id in your config.
2. Embed your documents in batches (send a list in input) and store the vectors in your vector database.
3. Embed each user question with the same model and search the database.
4. Send the question plus the matching passages to /v1/chat/completions with model: "auto"; the chat side is routed for cost as usual.

Available models

The gateway did not report any embedding models. Update the gateway to the latest version.

• Vectors from different models cannot be compared. If you change model, re-embed your stored documents. For the same reason an embeddings request is never failed over to another model.
• The model’s provider must be connected under Providers. Ollama models must be pulled on your Ollama server first (for example ollama pull nomic-embed-text).
• dimensions works only on models marked adjustable; other models return 400 if you send it.
• Every call is logged with its cost under Logs (goal “embeddings”). The response adds instaroute with the provider, model, dimensions, cost and latency. Gemini does not report token usage on this endpoint, so its tokens are estimated (usage_estimated: true).
• Try it without code in Dashboard → Playground → Embeddings.

Goals with a required capability (coding, reasoning, vision, long_context, local_first) only consider models tagged with it. Requests that contain images, tools or very long inputs are automatically limited to models that support them, whatever the goal.

Add an optional instaroute object to the request body to control routing for that one call. All fields are optional.

{
  "model": "auto",
  "messages": [{ "role": "user", "content": "..." }],
  "instaroute": {
    "provider": "opusmax",               // only route to this provider
    "allow": ["claude-sonnet-4-6", "gpt-5.4-mini"],  // choose only among these
    "deny": ["gpt-5.5-pro"],             // never use these
    "no_cache": true,                    // skip the exact + semantic response cache
    "no_jev": true,                      // heuristic scorer only for this call
    "deferrable": true,                  // OK to wait: use the ~50% cheaper flex tier
    "session_id": "chat-8271"            // keep this conversation on one model (prompt cache)
  }
}

The same options work on /v1/messages and /v1/responses (add the instaroute object to the body), or as headers:

# Clients that can set headers but not body fields (e.g. Claude Code):
x-instaroute-deferrable: true
x-instaroute-session-id: chat-8271

# Claude Code example
export ANTHROPIC_CUSTOM_HEADERS="x-instaroute-session-id: my-repo"

Every response, including the final streamed chunk, carries an extra instaroute object. Standard SDK fields are left unchanged.

"instaroute": {
  "provider": "openai",
  "model": "gpt-5.4-mini",
  "requested": "auto",
  "router": "heuristic",
  "reason": "simple task (complexity 0.18) — best value among 12 candidates",
  "attempts": 1,
  "cached": false,
  "latency_ms": 812,
  "cost_usd": 0.000214,
  "baseline_usd": 0.004650,
  "savings_usd": 0.004436,
  "service_tier": "standard",
  "savings_breakdown": {
    "routing": 0.004436,
    "prompt_cache": 0,
    "tier": 0,
    "response_cache": 0
  }
}

Errors follow the OpenAI shape { error: { message, type, code } }. On /v1/messages they follow the Anthropic shape { type: "error", error: { type, message } }.

Limits: 20 requests/second per key, with bursts up to 40. Monthly request quota depends on your plan (see Plans).

Each request goes through these steps, in order:

1. 1

   Guardrails (if enabled)

   Optional prompt-injection and secret-leak screening, which can block or flag a request. Off unless the server enables it.
2. 2

   Key settings

   If the request says "auto" and the API key has a goal override, that goal is used. If the key has used 85% of its monthly budget, goal routing is switched to cheapest.
3. 3

   Find candidates

   Only enabled, priced models on your connected providers. Models that lack a needed capability (vision, tools, context size) and providers marked down are dropped, and the request's allow / deny / provider options and the key's provider allow-list are applied.
4. 4

   Measure complexity (auto)

   The prompt is scored 0–1 (simple / moderate / complex) from its length, structure, code, maths and reasoning cues. Simple tasks weight cost; complex tasks weight quality.
5. 5

   Score & rank

   Each candidate gets a score from cost, latency and quality using the goal's weights. Explicit model ids skip this step.
6. 6

   Routing rules

   If one of your enabled rules matches, its preferred models move to the front. The decision is logged as router "rule".
7. 7

   Sticky conversation (prompt cache)

   If this conversation's previous turn ran on a model that is still eligible, and the prompt is large enough for provider caching, it stays there unless moving is cheaper even after losing the cache, or the task got harder.
8. 8

   JEV (optional)

   If JEV is on for the workspace, it reviews the top 5 and picks one. If it isn't confident enough or is slow, the heuristic pick is used.
9. 9

   Call & fail over

   The request goes to the chosen model. On 408/409/429/5xx or a network error it moves to the next best model, up to 4 attempts in total.
10. 10

    Measure & log

    Actual cost (from the provider's token counts), baseline cost, savings, latency and the decision reason are logged. Prompt text is not stored.

Send any chat request to POST /v1/route/explain to see how it would be routed, without calling a model or paying for tokens. It goes through the same steps as a real request (your connections, key limits, budget, routing rules and benchmark scores) and returns:

• chosen and failover: the model that would be tried first and the order after it.
• candidates: every eligible model ranked by score, with its 0–1 cost, speed and quality components, price, latency and quality (and whether that quality came from your benchmark scores).
• weights, goal and complexity: how much cost, speed and quality counted for this request.
• rejected: every other model with the reason it was ruled out (provider not connected, key or request restrictions, missing vision or tools, context too small, provider down).

curl https://your-instaroute-host/v1/route/explain \
  -H "Authorization: Bearer sk-inf-..." -H "Content-Type: application/json" \
  -d '{"model": "auto", "messages": [{"role": "user", "content": "Summarise this contract"}]}'

The same view is in Playground → Explain routing. JEV is not consulted in an explanation (it would cost a call), so in a JEV workspace a live request may pick a different one of the top five.

JEV (by TypeSafe AI) is a decision model. It reads the request's task profile and picks the best model from the router's top-5 shortlist. Turn it on per workspace in Dashboard → Settings → JEV routing.

JEV is always optional and never blocks a request. If it times out, errors, or its confidence is too low, the heuristic choice is used and the log shows why. Use no_jev: true to skip it for a single call. Only owners and admins can change this setting.

Rules let you enforce your own policy, e.g. "coding goes to Claude Sonnet" or "requests with images go to GPT-5.4 mini". Manage them in Dashboard → Routing rules (owners and admins).

POST /api/routing/rules          (dashboard → Routing rules does this for you)
{
  "name": "Coding goes to Claude Sonnet",
  "priority": 10,
  "match":  { "goal": "coding" },
  "prefer": ["claude-sonnet-4-6", "gpt-5.4-mini"]
}

Savings Autopilot is a set of cost levers InstaRoute runs on your traffic. Switch them in Dashboard → Settings → Savings Autopilot (owners and admins). Every saving is recorded per request and summed on the Overview under Savings by lever.

• Caches are per workspace, so two customers never share entries.
• Requests that use tools, images or several choices are not answered from the response cache.
• Add "instaroute": { "no_cache": true } to always get a fresh answer.
• The semantic index lives in the gateway process, so it starts empty after a restart. Only vectors and answers are kept, never prompt text.

Connect providers in Dashboard → Providers. Each connection has a label, the encrypted key, an optional custom base URL, an enabled switch and a live health status (up / degraded / down, re-checked every few minutes). Use Test to check a key before or after saving, and Update key to rotate it without losing settings.

The number of providers you can connect depends on your plan. Only connected and enabled providers are used. Providers marked degraded are ranked lower and providers marked down are skipped.

Providers added in October 2026 (OpenRouter through Cloudflare in the table) come with their most-used models pre-priced. Their other models are priced only when the id matches the price list exactly, because these hosts sell variants of one model at different prices (for example gpt-oss-120b and gpt-oss-120b-Turbo). Anything else waits in Admin → Models for review.

Connect any OpenAI-compatible API, such as vLLM, LM Studio, NVIDIA NIM, Hugging Face TGI or your own gateway, as the Custom endpoint provider. Enter its base URL including the version path (for example https://llm.example.com/v1), an API key if it needs one, and the models it serves with what each costs you per 1M tokens (0 for self-hosted). Fetch models from endpoint fills the list from its /models route.

# id, input $/1M, output $/1M, context window, capabilities
meta-llama/Llama-3.3-70B-Instruct, 0, 0, 131072, tools
qwen2.5-coder-32b, 0.2, 0.6

• The models are available only to your workspace, as custom:<id> (or by their own id), and take part in auto and goal routing like any other model.
• Prices you enter are used for cost, routing and savings. A model priced at 0 counts its full baseline as savings, as local Ollama models do.
• For security the endpoint must be a public https:// host; private, loopback and cloud-metadata addresses are refused and redirects are not followed. Self-hosted operators can allow private hosts with ALLOW_PRIVATE_ENDPOINTS=1.
• One custom endpoint per workspace. Use Edit models on its card to change the list.

• Every model has a price per 1M input / output tokens, plus cached-input, cache-write and flex-tier prices where the provider offers them, taken from the providers' price lists. These prices drive routing, cost and savings. Long-context surcharges (e.g. above 200K tokens) and time-of-day discounts are not modelled yet.
• Premium tiers (e.g. OpenAI *-pro, o1, o1-pro) are listed but disabled for auto-routing by default so they never surprise you on cost. You can still call them by explicit id once an admin enables them.
• Weekly auto-discovery checks each connected provider for new models. New models matching a known price are priced and enabled automatically; others wait for admin review.
• Platform admins can review, price, enable or disable any model in Dashboard → Admin → Models, and can run discovery on demand.

Create one key per app in Dashboard → API Keys. The page's Connect your app card has ready-to-copy settings. Each key has:

Dashboard → Logs lists every request with time, app, requested goal / model, chosen model, router, tokens, cost, savings, latency and status.

Filters

• Time: last hour, last 24h, last 7 days, last 30 days, last 90 days, or a custom from–to date range.
• App: filter by API key.
• Status: success or error.

Export

Export CSV downloads every request that matches the current filters (up to 50,000 rows) with tokens, cost, baseline and savings by lever. Export FOCUS gives the same data in columns aligned with the FinOps Foundation FOCUS spec (BilledCost, ChargePeriodStart,ServiceCategory …, plus x_ extension columns for baseline and savings) for cost tools such as CloudZero, Vantage or Finout. API: GET /api/logs/export?format=csv|focus&range=30d.

Request detail popup

Click any row to see:

• Scenario: a metadata-only summary of the task (e.g. "Chat request — 3 messages, ~1200 input tokens, 2 tools, difficulty: moderate.").
• Routing decision: the baseline (top) model, the model actually used, the router, JEV confidence, complexity score / band, and the reason.
• Cost & savings: cost if the top model had been used, the actual cost, the amount and percentage saved, and where the saving came from (routing, prompt cache, flex tier, response cache).
• Request details: tokens in / out, cached and cache-write tokens, latency, app, goal, router, service tier, prompt-cache optimiser, response cache (with semantic similarity and spot-check agreement), and the error code if it failed.

How far back logs go depends on your plan's retention period.

Savings are measured per request from real numbers:

baseline cost = price of the MOST EXPENSIVE model that could have served this request
                × the actual input / output tokens of the request
actual cost   = price of the model actually used × the provider-reported tokens
                (at the tier it was served, with cache reads/writes priced separately,
                 plus any embedding cost for the semantic cache)
savings       = max(0, baseline cost − actual cost)

savings by lever (they add up to baseline − actual):
  routing         baseline − chosen model at standard price
  prompt_cache    chosen model without vs with the cache reads InstaRoute produced
                  (net of the one-time cache-write cost, so a write turn can be negative)
  tier            standard price − flex price (a priority-tier request counts negative)
  response_cache  the chosen model's cost avoided by a cache hit, minus embedding cost

Example: a request uses 2,000 input and 500 output tokens. The most expensive suitable model costs $5 / $25 per 1M tokens, so the baseline is 2,000×5/1M + 500×25/1M = $0.0225. The router picked a model at $0.40 / $1.60, so the actual cost is $0.0016. Savings = $0.0209 (93%).

Totals (Overview, Billing and the success fee) are net for the period: the sum of baselines minus the sum of actual costs, never below zero. A request that cost more than its baseline, such as a first Claude turn that pays to write the prompt cache, lowers the total instead of counting as zero, so the total always equals “Spend vs. baseline” and the sum of the levers.

Only models that meet the request's capability needs and your restrictions count toward the baseline. Cache discounts are credited only when InstaRoute produced them (sticky routing or the cache breakpoints it added). Caching a provider does on its own is applied to the baseline too, so it is never counted as an InstaRoute saving. Explicitly requested models are logged with their real cost.

• Overview: requests, spend, baseline, savings, cache hit rate, average latency and error rate for the selected range, savings by lever (routing, prompt cache, flex tier, response cache, with prompt-cache tokens, flex requests and semantic spot-check agreement), breakdowns by provider, model and router, and monthly quota usage.
• Playground: send a test prompt with any goal or model and see the response with its provider, model, router, confidence, latency, cost and savings.
• Settings: workspace name, default routing goal (used when a request asks for auto), JEV routing and Savings Autopilot.

Get notified before costs surprise you. Configure in Dashboard → Alerts (owners and admins edit; others can view).

Each threshold fires at most once per month. Recent alerts are listed on the page. Webhook URLs are hidden from non-admins.

Every model has a built-in quality score (0–100) that routing weighs against cost and latency. In Dashboard → Benchmarks you can import your own scores, for example from your evals, and they replace the built-in score for your workspace only. Included from the Team plan up; owners and admins import.

model,score,source
gpt-5.4-mini,82,support-evals-2026-10
claude-sonnet-5-5,94,support-evals-2026-10
deepinfra-deepseek-v4-flash,85,support-evals-2026-10

• CSV (model,score[,source], header optional) or JSON ([{"model": "...", "score": 82}]).
• Models can be catalog ids or provider model ids. Unknown models and scores outside 0–100 are skipped and listed.
• New scores merge with existing ones; tick Replace to start over. Changes apply within 15 seconds.
• When a scored model is chosen, the routing reason in Logs says the quality came from your benchmark scores.

Try a model on real traffic before switching to it. In Dashboard → Experiments, pick a candidate model and a sample rate (up to 20%). After a request succeeds and its answer has been returned, InstaRoute sends the same request to the candidate and compares the two. Your users always get the original answer. Included from the Business plan up.

Invite teammates in Dashboard → Team. You get an invite link to share. It works once, expires after 7 days, and must be accepted by the invited email address (new users register through it). How many members you can have depends on your plan.

Dashboard → Audit log records who changed what: providers connected, updated or removed; API keys; routing rules; benchmark imports; experiments; invites, joins, role changes and removals; workspace, Savings Autopilot and alert settings; and log exports. Owners and admins can view it on every plan, filter by area and time, and click a row for details. CSV export is included from the Team plan up.

Secrets are never recorded: provider keys and webhook URLs appear only as “set” or a key's last four characters.

You always pay AI providers directly with your own keys. InstaRoute charges a flat plan price, and paid plans add a small success fee on measured savings: if you don't save, you don't pay it. Manage your plan in Dashboard → Billing.

See the pricing section on the homepage for current plans.

Monthly savings statements are under Billing for owners and admins: spend, baseline and net savings for any month, split by cause, day, model and app, with the success fee. Open one to print or save it as PDF, or download it as CSV. API: GET /api/statements/2026-10?format=html|csv|json.

Every new workspace starts with a 7-day free trial of the Developer plan: no card, and no success fee on savings during the trial. When it ends the workspace moves to Free unless you choose a plan. Routing then uses only as many providers as the plan allows (the earliest connected ones). Higher plans add benchmark import, audit export, shadow experiments, white-labelling and priority support. The success fee is calculated from the same per-request savings shown in your logs.

• No prompt storage: prompts and responses are never written to logs or the database. Logs keep metadata only (model, tokens, cost, latency, a non-content scenario summary).
• Encrypted provider keys: BYOK keys (and your JEV key) are encrypted at rest with AES-256-GCM and never returned by the API.
• Hashed gateway keys: sk-inf-… keys are stored as SHA-256 hashes.
• Tenant isolation: data and cache entries are scoped to each workspace.
• Webhook safety: alert webhooks must be HTTPS and are checked so they can't target internal addresses.
• Local option: use the local_first goal with Ollama to keep data entirely on your own hardware.

For operators running their own InstaRoute server (Docker Compose). Set these in infra/.env; never commit secrets to git.

docker compose -f infra/docker-compose.yml --env-file infra/.env up -d --build

Users listed in PLATFORM_ADMIN_EMAILS see an Admin section with:

• Platform totals: workspaces, users, requests, spend, savings, plan MRR and success-fee revenue.
• All workspaces with owner, plan, usage and projected fee. Change plans or suspend a workspace.
• Models: the full catalog with price, quality, context, capabilities and status. Enable / disable or edit pricing, and run discovery now.