KAT-Coder V2.5 Dev

Canonical model ID	kwaipilot/kat-coder-v2.5-dev
Context window	32,768 tokens
Max output	16,384 tokens
Streaming	SSE, with usage in the final chunk
Tool calling	OpenAI tools / tool_choice
Structured output	response_format: json_object and json_schema
Reasoning effort	none · medium · high (Webik extension)
License	Apache-2.0
Upstream weights	Kwaipilot/KAT-Coder-V2.5-Dev

Release identity

kwaipilot/kat-coder-v2.5-dev is the canonical ID — the name you put in model. Behind it, WebikAI serves exactly one release at a time: an immutable, dated build that fixes the weights, quantization, inference engine, chat template, tool-call parser, and context configuration. Release IDs look like webik/kat-coder-v2.5-dev-2026-08-w4a16-r1 (that one is an example of the form — the current stable release is always listed by GET /v1/model-releases).

Every response, streamed or not, tells you which release served it: the OpenAI-standard system_fingerprint field (wbk_ + 12 hex, unique per release) and the X-Webik-Model-Release header carrying the full release ID.

http

HTTP/1.1 200 OK
X-Webik-Model-Release: webik/kat-coder-v2.5-dev-2026-08-w4a16-r1
X-Request-Id: req_01j...

{
  "id": "chatcmpl-...",
  "model": "kwaipilot/kat-coder-v2.5-dev",
  "system_fingerprint": "wbk_8d3d0b9a7f2c",
  "choices": [ ... ],
  "usage": { "prompt_tokens": 1280, "completion_tokens": 412, "total_tokens": 1692 }
}

Pinning a release

If a build must never move under you — bisecting an agent regression, reproducing an eval — pin the release. Either send the release ID as the model:

json

{
  "model": "webik/kat-coder-v2.5-dev-2026-08-w4a16-r1",
  "messages": [ ... ]
}

or keep the canonical ID and pin through the webik.release extension, which stock OpenAI SDKs pass through unchanged:

json

{
  "model": "kwaipilot/kat-coder-v2.5-dev",
  "webik": { "release": "webik/kat-coder-v2.5-dev-2026-08-w4a16-r1" },
  "messages": [ ... ]
}

What may change behind the canonical ID

Operational placement: GPU type, compute provider, region, and serving performance (throughput, latency, queueing). None of these change tokens, so none of them mint a release.

What mints a new release

Anything that could change the tokens you get back: a different quantization, an engine upgrade with behavioral impact, a chat-template or tool-parser change, a context-configuration change, or new weights. Each becomes a new immutable release ID with its own fingerprint — the canonical ID starts pointing at it only when it is promoted to stable, and pinned traffic is never moved.

Deprecation policy

A stable exact release keeps serving for at least 90 days after its replacement ships.
Retirement comes with 30 days of dated notice, and pinned responses carry Deprecation and Sunset headers for the whole window.
After sunset, a pinned request fails with model_release_deprecated (410) — it is never silently rerouted.
A new upstream version (a V2.6, say) is a new canonical ID. The name you use today never becomes a different model.

Planned, not yet available: a webik/coder moving alias that tracks our recommended release across families — strictly opt-in, and separate from the canonical ID above.

Specifications

Pricing

Release identity

Pinning a release

What may change behind the canonical ID

What mints a new release

Deprecation policy