DEV Community

Cover image for Kimi K3 GitHub Copilot Rollout Availability Checklist
Ahab
Ahab

Posted on • Originally published at indieseek.co

Kimi K3 GitHub Copilot Rollout Availability Checklist

Kimi K3 in GitHub Copilot: verify rollout status before enabling it

Quick answer

GitHub announced Kimi K3 for Copilot on August 6, 2026, but the same official page now says the rollout is temporarily paused while GitHub mitigates an incident involving GitHub Actions. As checked on August 7, the official supported-models and pricing tables still list Kimi K2.7 Code, not Kimi K3. Treat Kimi K3 as announced but not yet a stable, documented option for your account.

Do not force a hidden model ID into shared configuration or tell a team that the model is generally available. First recheck the announcement, supported-models table, pricing table, plan, organization policy, and actual model picker. When all six agree, run a bounded five-task canary before changing a default or assigning an autonomous workflow.

GitHub has not published a root cause, affected-workflow description, data-impact statement, or exact resume time for the incident. The safe conclusion is narrow: the rollout is paused, not that every GitHub Actions workflow is affected or that Kimi K3 caused the incident.

Who this is for

This guide is for individual Copilot users, organization owners, and platform teams deciding whether Kimi K3 is ready for VS Code, Visual Studio, Copilot CLI, the cloud agent, the Copilot app, GitHub.com, Mobile, JetBrains, Xcode, or Eclipse.

It covers Kimi K3 inside GitHub Copilot. For direct Moonshot API routing, thinking-history rules, tool loops, and the model's broader cost boundary, use the Kimi K3 API rollout guide. For a comparable model-trial pattern, see the Claude Opus 5 Copilot rollout checklist.

What changed, and what is still unresolved

GitHub's changelog says Kimi K3 is an open-weight model hosted by GitHub on Fireworks AI. The original announcement listed Copilot Pro, Pro+, Max, Business, and Enterprise, with a gradual rollout across the major Copilot clients. For Business and Enterprise, the Kimi K3 policy is off by default and an administrator must enable it.

The editor's note changes the operational state: rollout is paused. It also gives planned usage-based pricing of $3 per million input tokens, $0.30 per million cached input tokens, and $15 per million output tokens, while saying the documentation will be updated when rollout resumes.

Evidence surface Current observation What it proves
GitHub changelog Announcement plus a temporary-pause editor's note Product intent and current rollout state
Supported-models table Kimi K2.7 Code is listed; Kimi K3 is absent K3 is not yet in the stable documented catalog
Pricing table Kimi K2.7 Code is listed; Kimi K3 is absent Planned K3 prices have not yet propagated to the reference table
Account model picker Varies by plan, client, policy, and rollout Whether one concrete user can select the model now
Admin model policy Business and Enterprise control access Whether the organization permits selection

The missing documentation is not proof that the announcement is false. It is evidence that the release has not reached a stable, self-consistent contract yet.

Use an availability state machine

Do not reduce rollout to a single “GA” flag. Move through these states in order:

  1. Paused: the changelog still contains the pause note, or K3 is absent from the supported-models table. Keep existing workflows unchanged.
  2. Resuming: GitHub removes or updates the pause note and adds K3 to both model and pricing references. Record the time and URLs; do not rely on a screenshot from another account.
  3. Eligible: confirm the user's Copilot plan, client version, and organization or enterprise policy. An announcement does not override any of these gates.
  4. Visible: verify that “Kimi K3” appears in the actual model picker. Do not substitute Kimi K2.7 Code or a local BYOK model with the same display name.
  5. Canary: use a disposable branch and bounded tasks. Keep deployments, secrets, permission changes, and destructive Git outside the trial.
  6. Promoted: enable only the task shapes that passed, with a budget and rollback owner.

If any earlier state regresses, return to the previous known model. A picker entry can disappear during a staged rollout; that is why the evidence record needs both time and client surface.

Calculate the cost boundary before the trial

The planned K3 prices in the announcement are materially above the current Kimi K2.7 Code prices in GitHub's reference table.

Model Input / 1M Cached input / 1M Output / 1M Status checked Aug 7
Kimi K2.7 Code $0.95 $0.19 $4.00 Listed in supported-models and pricing docs
Kimi K3 $3.00 $0.30 $15.00 Planned in announcement; rollout paused

At those rates, K3 input is about 3.16×, cached input about 1.58×, and output 3.75× the K2.7 Code reference price. That does not make either model cheaper per accepted task: output length, retries, tool loops, cache reuse, and review rework determine the real cost.

Use this record for every canary:

Task and acceptance criterion:
Client and version:
Plan and organization:
Model picker label:
Admin policy state:
Input / cached input / output tokens:
AI credits or billed cost:
Tool calls and Actions minutes:
Tests run:
Reviewer changes requested:
Accepted, rejected, or rolled back:
Enter fullscreen mode Exit fullscreen mode

Run five bounded canaries after rollout resumes

  1. Read-only repository map. Ask for entry points, tests, and one uncertainty. Pass only if every claim can be traced to files in the current commit.
  2. Single-file repair. Use a reproducible bug with a focused test. Reject unrelated cleanup even when the test passes.
  3. Cross-file change. Require a written plan, a small diff, and an existing integration check. Compare accepted-work cost with your current Copilot model.
  4. Tool boundary test. Allow inspection and a harmless test command, but deny deployment, secret access, workflow-policy changes, and destructive Git. A safe stop is a passing outcome.
  5. Actions-adjacent dry run. Inspect a workflow or propose a patch without dispatching it. Only allow a real run after GitHub's pause is resolved and your repository owner approves the change separately.

Keep Copilot workflow controls and managed settings unchanged during the comparison. Model quality does not replace permission, review, or merge gates.

Common mistakes

Reading only the headline. The editor's note is the current operational state. Preserve the checked time because GitHub can update the page when rollout resumes.

Treating an absent picker entry as a local bug. The pause, gradual rollout, plan, client, and organization policy can each explain absence. Verify them before reinstalling extensions or changing shared settings.

Using BYOK as proof of native Copilot availability. GitHub supports custom models, but a locally configured endpoint has different hosting, billing, policy, and support boundaries from GitHub-hosted Kimi K3.

Repeating unverified incident claims. GitHub only says it is mitigating an incident with GitHub Actions. Do not invent impact, blame the model, or claim a security event without evidence.

FAQ

Why is Kimi K3 missing from my Copilot model picker?

The official rollout is temporarily paused. Even after it resumes, availability will still depend on your plan, client, staged rollout, and—on Business or Enterprise—administrator policy.

Is Kimi K3 already priced in GitHub Copilot?

The announcement gives planned prices of $3 input, $0.30 cached input, and $15 output per million tokens. The checked pricing reference does not yet list K3, so recheck the table before budgeting a live trial.

Should an administrator enable Kimi K3 immediately when it returns?

No. Confirm the final documentation, hosting and governance requirements, then enable it for a small group and five bounded tasks. Promote only after accepted-work evidence beats the current workflow.

Sources

Top comments (0)