Kimi K3-256k

Kimi K3-256k is a new configuration of the open-weight Kimi K3 model that caps context at 256k tokens while promising identical quality within that range, cutting quota and infrastructure costs roughly in half compared to the 1M-token version. Commenters see this as a practical way to trade extreme context length for cheaper, more efficient usage—especially for coding and agent workflows that rarely exceed 256k—while noting capacity constraints, waitlists, and the growing role of third‑party providers hosting the model. The launch also feeds into a broader view that large language models are becoming commoditized, with context management, pricing, and hosting location increasingly driving user choice.

Nature of k3-256k vs k3 (1M)

  • Most commenters see k3-256k as the same Kimi K3 model with a different configuration (shorter max context), not a new model.
  • One comment cites the technical report: K3 was trained up to 1M tokens via staged context extension (8K → 64K in pretraining, then 256K → 1M later).
  • Several point out that context limits can be set at inference time (e.g., in vLLM), so reducing the window does not require retraining.

Pricing, quota, and cache behavior

  • Official docs (as quoted) say: k3 (1M) uses about twice the quota of k3-256k; within 256k context they should perform the same.
  • Users infer k3-256k is effectively cheaper if you don’t need >256k tokens.
  • A key detail: switching from k3-256k to k3 (1M) supposedly does not invalidate the cache, allowing users to start “cheap” and only pay the 1M premium when needed.

Availability, capacity, and waitlist

  • Multiple users report a real waitlist for Kimi subscriptions, attributing it to high demand and limited hardware (exacerbated by export bans).
  • Some prefer this capacity gating over silent throttling or hidden quantization; others are frustrated they cannot pay to get access.

Open weights, third‑party hosting, and quantization

  • K3 is open-weights, and several third-party providers (including via OpenRouter) already host it.
  • Concern: some providers might secretly quantize; others note many providers are reputable and/or explicitly list formats (e.g., MXFP4, FP8).
  • One comment notes K3 is natively trained in MXFP4, so that specific quantization should not reduce quality.
  • Self‑hosting is seen as challenging: full K3 reportedly needs ~1.5 TB VRAM; extreme 1‑bit quantization cuts this but with heavy quality loss, especially on long context.

Context window usefulness and compaction

  • Many say 256k is enough for most coding and knowledge work; 1M is “luxury” for very long-running agents or whole-book analysis.
  • Some argue needing huge context is often a “skill issue” and that good compaction makes 256k feel ample.
  • Codex (a harness using K3) is praised for “masterful” compaction; Claude’s compaction is criticized as causing abrupt amnesia when windows fill.

Infrastructure and economics

  • Comments note that shorter max context reduces KV cache size and VRAM per session, increasing concurrency and lowering cost.
  • Offering two SKUs (256k and 1M) is seen as a pragmatic way to expose the nonlinear cost of long context without overly complex pricing.

Competition, outages, and geopolitics

  • Several users compare Kimi favorably to Anthropic/OpenAI, especially amid reported Anthropic outages and silent limit changes.
  • Some see open‑weight Chinese models as accelerating commoditization; others debate whether the US/EU could restrict such models, with differing views on feasibility.