Usage Weighting

POST /chat/completions and POST /embeddings draw down your rate limit allowance at a per-model weight instead of a flat one unit per request. A request against a larger third-party model consumes more of your _per_day / _per_week allowance than the same request against a ThreatWinds self-hosted model.

The weight is charged in the usage event that decrements chat_completions_per_day / chat_completions_per_week (or the embeddings_per_* equivalents) — it does not change the limit values themselves. See Usage Limits for the per-tier allowance and Usage Tracking for monitoring consumption.

Which Endpoints Are Weighted

Endpoint Weighted? Notes
POST /chat/completions Yes Weight follows the requested model
POST /embeddings Yes Weight follows the requested model
POST /chat/count No Always 1 unit — a local tokenizer call, it never reaches a model backend
POST /audio/transcriptions No Limited per minute (audio_transcriptions_per_minute), unaffected by weighting
POST /audio/speech No Limited per minute (audio_speech_per_minute), unaffected by weighting
GET /models, GET /models/:id No Always 1 unit (models_per_minute)

Weight Table

Self-Hosted Chat — 1× / 3×

Model Weight
silas-1.6 1×
qwen-3.6 1×
silas-1.6-pro 3×
qwen-3.6-pro 3×

silas-1.6 and qwen-3.6 are the same underlying capacity, so they’re priced identically; the same is true of the two Pro variants.

Self-Hosted Embeddings — 1×

Model Weight
qwen3-embedding-8b 1×
qwen3-vl-embedding-8b 1×

Self-Hosted Audio

whisper-large-v3 (transcription) and kokoro-82m (speech) are priced at 1× for internal consistency, but that weight has no effect today — /audio/transcriptions and /audio/speech are not usage-weighted endpoints (see the table above). They remain governed entirely by audio_transcriptions_per_minute and audio_speech_per_minute.

Third-Party Generation — 10×

Family Models
Claude claude-opus-4, claude-sonnet-4, claude-opus-5, claude-sonnet-5
GPT gpt-5, gpt-5-mini, gpt-5-nano, gpt-5.4-nano
Gemini / Gemma gemini-3-pro, gemini-3-flash, gemini-3-flash-lite, gemma-4-31b-it

All of these are chat models (see Chat Completions).

Third-Party Embeddings — 4×

Model Weight
gemini-embedding-2 4

A third-party embedding call costs substantially less than a third-party generation, so it is not priced with it. Being third party is not on its own what sets a model’s weight — each model is priced individually for what a call against it actually costs.

What This Means For Your Allowance

The allowance itself did not change — only what it buys did. A Pro customer’s chat_completions_per_week limit is 24,000 units (see Usage Limits). At 1× that’s 24,000 requests to silas-1.6; at 3× it’s 8,000 requests to silas-1.6-pro; at 10× it’s 2,400 requests to a third-party chat model. Mixed usage draws from the same pool — e.g. 20,000 silas-1.6 calls (20,000 units) plus 400 Claude calls (4,000 units) uses the full 24,000-unit weekly allowance.

Embeddings are metered separately, against embeddings_per_day / embeddings_per_week. A Pro customer’s 24,000-unit weekly embedding allowance is 24,000 calls to qwen3-embedding-8b at 1×, or 6,000 to gemini-embedding-2 at 4×.

Rules

  • The weight follows the model you requested, not the one that served the request. model_id is set once, immediately after the request is parsed, and is never overwritten by a backend failover — even if ThreatWinds capacity forces your request onto a different pod. If our capacity forces a switch, that’s our cost to absorb, not yours.
  • Only chat completions and embeddings are weighted. Token counting (POST /chat/count) always costs exactly 1 unit — it’s a local tokenizer call and never reaches a model backend, so there’s nothing to weight. Transcription and speech keep their existing per-minute rate limits, untouched by this change.
  • A failed request is never charged. If the response status is 4xx/5xx, nothing is deducted from your allowance. A 503 model_warming_up — common, since inference pods scale to zero when idle — costs nothing; retry after the delay in the Retry-After header.
  • The one exception is a streaming response that fails mid-stream. Once the first SSE byte has been flushed to the client, the HTTP response is already committed to 200 OK; a later upstream failure is delivered as a trailing error event inside the stream (see Streaming Errors) rather than an HTTP error status — and the request is charged, because partial output was already delivered.

Example 

{
  "model": "claude-sonnet-5",
  "messages": [{"role": "user", "content": "Summarize this alert."}]
}

This request costs 10 units against chat_completions_per_day and chat_completions_per_week — the same weight as any other Claude, GPT, or Gemini/Gemma model, regardless of which upstream account or pod actually processed it.

{
  "model": "silas-1.6",
  "messages": [{"role": "user", "content": "Summarize this alert."}]
}

This request costs 1 unit — the same draw as a request made before model-aware weighting existed.