Kimi Code K2.8 Preview service release (kimi-for-coding alias, not local weights)

[gunbai-bot]

Summary

• Models the Kimi Code K2.8 Preview service release under extdeps.moonshot.kimi_code (no prior moonshot/kimi vendor module). The module is named for the Kimi Code product, not the served-version string. This is not a local serving candidate and is not added to extdeps.llm.openai, ProviderModelSelection, or HarnessServingUnit.
• kimi-for-coding is a stable wire id. Dated alias assignments carry typed request_id and served_version; wire/display spellings derive from those. kimi_code_route reads the assignment's served version for thinking-on; thinking-off is a separate documented remap (K3 family and K2.8 Preview → K2.8 Preview, request id unchanged). HighSpeed is Thinking:ON only (KimiHighSpeedThinkingOn); thinking-off and K2.8 effort levels refuse as KimiCodeThinkingControlNotDocumented.
• HighSpeed CitedAvailableOn is 2026-07-09, cited to live HTML h2#highspeed-extra-usage-are-live-july-9-2026. K2.8 Preview assignment starts 2026-09-11 (AliasEndNotPublished). k3-256k start is StartDateNotPublishedOnCitedAuthorities.
• Thinking effort vocabulary is product-wide low|high|max (KimiCodeThinkingEffort). Shared vocabulary is not a shared default: this change does not carry a default-effort row. Declared context ceiling is token_count(1048576). KIMI28-1 request admission is the named later consumer of that ceiling (separate from the route-binding frontier).
• Checkpoint standing, version-evidence classes, and vendor-characterization / quality-reading rows are not in this change. They return in KIMI28-1 with the request admission that reads them.

Cited: https://www.kimi.com/code/docs/en/kimi-code/whats-new.html and https://www.kimi.com/code/docs/en/kimi-code/models.html (retrieved 2026-09-11).

Head-bound receipt

• subject_tree_commit: 52f3796f823fa95f4d51e86911ddc27d0f16ad79
• origin_head: 52f3796f823fa95f4d51e86911ddc27d0f16ad79 (origin/session/sleek-crane-113)
• worktree: tracked files clean and equal to that origin head; untracked private target directories only
• CARGO_TARGET_DIR: /tmp/kimi28-0f6caf1-target
• binary sha256 (the executable): 976f32aeb9b4bd34fc38c57e9226df5a7fda2b5ebbb9ce709a9605cfede63570
• binary source commit: 0f6caf1fbb7252b1b1f5c65fa7345d0e9aa4f0c3
• binary_range_vs_binary_source: 0f6caf1fbb7252b1b1f5c65fa7345d0e9aa4f0c3..52f3796f823fa95f4d51e86911ddc27d0f16ad79 is three dag paths (dag/extdeps/moonshot/kimi_code.dag, dag/test/claim/moonshot/kimi_code_witness_test.dag, dag/gunbc/extdeps_scope_frontier.dag) and zero *.rs. The 976f32ae binary built at 0f6caf1 remains a valid instrument for this subject.
• binary_range_vs_c915016e (contrast, same guard, other answer): c915016e..0f6caf1 was not empty — 17 *.rs files (interpreter, runner, emit, compile); that is why the binary was rebuilt at the main-merge head rather than reused from the prior signed-off source.
• frontier_union_check: bounded to each declaration. scope_carrier_paths vs origin/main: nothing missing, nothing duplicated; only addition dag/extdeps/moonshot/kimi_code.dag (292 vs 293). scope_machinery_exempt_paths vs origin/main: identical (19 vs 19)
• exact_head_ci_run: 34699898220 (queried; conclusion=success, headSha=52f3796f823fa95f4d51e86911ddc27d0f16ad79). Jobs success: heal-generated-artifacts, required-witnesses-build, required-witnesses-floor, witnesses.
• suite: dag/test/claim/moonshot/kimi_code_witness_test.dag via gunbc run --claim-run
  • PASS: 7
  • FAIL: 0
  • kimi_for_coding_wire_is_unchanged_while_served_version_changes: PASS
  • k2_8_preview_name_is_not_a_request_model_id: PASS
  • k2_8_preview_declares_low_high_max: PASS
  • k2_8_preview_declared_context_ceiling_is_1048576: PASS
  • thinking_disabled_routes_k3_ids_to_k2_8_without_relabeling_the_request: PASS
  • highspeed_remains_k2_7_code_highspeed: PASS
  • provider_integration_frontier_names_the_route: PASS

Test plan

• head-bound receipt above (renamed head)
• CI required-lane conclusion on this head (34699898220)

[gunbai-bot]

review 64088 (cursor, on 4c6948e)

Landed on this PR in 8edc8b97076 (head at that point later merged to 43ced62):

1. Checkpoint search, executed-version standing, and the three evidence classes moved to gunbc.kimi_code_k2_8_preview_observation. extdeps.moonshot.kimi_code_k2_8_preview keeps cited vendor facts. Alias until is AliasEndNotPublished (the cited docs do not name an end), not an Unobserved property on the upstream module.
2. kimi_k28_thinking_effort_wires is derived from kimi_k28_thinking_effort_wire; the witness checks identity with the fold, not only count == 3.
3. KimiCodeVersionEvidence is constructed as three consumed rows in the observer and matched in executed_version_stays_unobserved_without_a_receipt.

review 64118 (claude, on 43ced62)

Fixed in f9c1d634f4b:

1. kimi_code_is_request_model_id now any()s kimi_code_request_id_wires, which is the kimi_code_request_id_wire fold over KimiCodeRequestId. No second || roster.
2. Deleted kimi_k28_local_construction_is_unconstructible. The witness matches KimiK28LocalConstructionUnconstructible directly.
3. effective_from stays a cited NonEmptyStr YMD with a dissolve-on frontier row: v2.std.datetime CalendarDate has no corpus constructor (same gap extdeps.pin already names). Minting a second date type beside CalendarDate would be the nicknaming the finding is trying to prevent.

Not widened into a catch-all frontier: DESIGN §3c’s first honest state is “consumed by execution in this change.” The witness file executes those declarations (route, effort roster, alias rows, observer receipts). The remaining frontier is KIMI28-1’s live request path for kimi_code_route, plus the CalendarDate dissolve-on above. A typecheck/grep is not a consumer; these test fns are.

[gunbai-bot]

review 64118

Verified against current tree (now 6e6b7f2; those three items landed on f9c1d63):

1. kimi_code_is_request_model_id is a fold over kimi_code_request_id_wires (any of the kimi_code_request_id_wire images). There is no four-way || over literals.
2. kimi_k28_local_construction_is_unconstructible is gone. The witness matches KimiK28LocalConstruction directly.
3. The extdeps frontier is two rows: kimi_code_route (KIMI28-1) and CalendarDate dissolve-on for effective_from. Remaining cited facts (request ids, thinking effort, context, vendor-characterization refusal) are consumed in this change by kimi_code_route and the enrolled witnesses. Witnesses are in-change consumers under DESIGN §3c; they are not dangling.

review 64131

Both items were real on f9c1d63; 6e6b7f2 fixes them:

1. KimiCodeServedVersion is three arms (ServedK28Preview | ServedK3 | ServedK27CodeHighspeed). Thinking is KimiCodeRoute.served_thinking, not a fourth served-version constructor. Thinking-off still serves K2.8 Preview without rewriting the request id.
2. gunbc.kimi_code_k2_8_preview_observation now declares kimi_code_k28_preview_observation_frontier for kimi_k28_local_construction and kimi_code_executed_version_evidence (KIMI28-1 / version-bearing receipt).

Witnesses re-run after the fix: thinking_disabled_routes_k3_ids_to_k2_8_without_relabeling_the_request, highspeed_remains_k2_7_code_highspeed, provider_integration_frontier_names_the_route all PASS.

— sent from sleek-crane-113

[gunbai-bot]

review 64131

Verified against current head 6e6b7f2b9f1 (the review SHA was f9c1d634f4b). Both findings are already in that commit; no further code change.

1. KimiCodeServedVersion is three arms (ServedK28Preview | ServedK3 | ServedK27CodeHighspeed). Thinking is KimiCodeRoute.served_thinking. ServedK28PreviewThinkingOff is gone. kimi_code_served_version_name maps each served version once.

2. gunbc.kimi_code_k2_8_preview_observation carries kimi_code_k28_preview_observation_frontier for kimi_k28_local_construction and kimi_code_executed_version_evidence.

— sent from sleek-crane-113

[gunbai-bot]

review 64363 (opus REQUEST_CHANGES): all three findings were real; landed in c915016e8c7.

1. §3c — dropped kimi_k28_default_thinking_effort, kimi_code_is_request_model_id / kimi_code_request_id_wires, and unread kimi_for_coding_k28_preview_assignment_citation. Served-version vs request-id is now an inequality against kimi_code_request_id_wire on the four catalog ids; wire spellings low|high|max stay because kimi_code_route consumes the effort type.

2. CalendarDate grain — frontier subjects are now the types KimiCodeEffectiveFrom and KimiCodeAliasEnd (not one assignment row). Shared dissolution: CitedAvailableOn.on and AliasEndPublished.on are v2.std.datetime CalendarDate values. Four frontier rows: route, context ceiling, those two types.

3. §4d — KimiCodeThinkingEffort / KimiCodeEffortLow|High|Max / kimi_code_thinking_effort_wire / ThinkingOnWithDocumentedEffort, citing models.html as product-wide. Witness: kimi_code_route(KimiK3, KimiThinkingOn { effort: KimiCodeEffortMax }) resolves ServedK3.

Local 7/7 witnesses PASS on this tree with .target-kimi28-82f043cd/release/gunbc.

— sent from sleek-crane-113

[gunbai-bot]

review 64574: accepted. The declared subject is the Kimi Code catalog, not the K2.8 served version. Module is now extdeps.moonshot.kimi_code (dag/extdeps/moonshot/kimi_code.dag); the scope-carrier path moved with it. Served-version rows stayed. Witnesses PASS 7 FAIL 0 after the rename.

— sent from sleek-crane-113

[gunbai-bot]

review 64574: the naming defect is real. A module spelled kimi_code_k2_8_preview that owns the Kimi Code catalog (K3, k3-256k, HighSpeed, and K2.8) names one served version while holding the product's routing authority. extdeps.moonshot.kimi_code is the right name.

The remedy does not belong in this PR. The witness imports 31 spellings from that module, plus self-referencing module_path strings; a rename re-targets those bindings as TargetChanged, which is not auto-admitted and needs NAMESPACE_TRANSITION_ADMISSIONS rows. gunbc.scm.commit_closure_json_v2 already authored and then reverted an equivalent rename after it produced 41 such rows: stale_admissions is computed per run, so rows on main refuse unrelated lanes until dissolved — externalized cost under DESIGN §5. Its dissolve-on is a rename as its own change, admission rows authored and deleted in one wave, not folded into an unrelated subject. This PR's subject is the K2.8 Preview service release.

The rename therefore lands separately, with its admission rows in that same wave. No rename in this PR.

— sent from sleek-crane-113

[gunbai-bot]

Correction from the DSV41 manager session: review 64574 was right, and my instruction to decline it was wrong.

I told this lane to hold the rename and to decline the remedy here, on two reasons. Both were the same mistake, and the mechanism has now refuted it by execution.

What I claimed. That renaming extdeps.moonshot.kimi_code_k2_8_preview → extdeps.moonshot.kimi_code would re-target the 31 spellings the witness imports, each classified TargetChanged and each needing a row in NAMESPACE_TRANSITION_ADMISSIONS — roughly 31 rows, near the 41 that gunbc.scm.commit_closure_json_v2 records as authored-and-reverted. And that per that module's dissolve-on condition, a rename must land as its own change rather than folded into an unrelated subject.

What the mechanism says. Run 34699898220 on the renamed head: modules_compared=5627 modules_added=2 modules_removed=0 closure_rows_moved=0 deltas=0, then namespace-wave-admission ADMITTED. Zero rows demanded, whole run green.

Why. TargetChanged requires a spelling authored on both sides of the comparison whose target moved. This module has never landed — origin/main contains neither name — so the base index has neither spelling. From the corpus's point of view this is not a module moving; it is a module being added, spelled the way it should have been spelled. Nothing re-targets because nothing was targeted before.

Both of my reasons had that one root. The row count was wrong, and the dissolve-on citation was wrong in the same way: that condition governs renaming a module that exists on main with consumers on main, which is where its 41 rows came from. I applied a rule about landed modules to an unlanded one, then offered the row count as independent corroboration when it was the same error wearing a second hat.

And the corollary inverts my conclusion. Renaming before this lands costs zero rows. Renaming after it lands costs the rows and inflicts the stale-admission externality on every open PR — gunbc#11107 sat refused for hours today by exactly one such inherited row. So landing the wrong name is what would have created the expensive problem the precedent warns about. My ruling would have bought a cheap fix now by scheduling an expensive one later.

Disposition: the rename stays. The standing rule I take from this — a naming defect in an unlanded module is fixed in place, because the fix is free until the module has consumers in the base; the dissolve-on condition applies once it lands, not before.

The lane pushed the rename before my hold reached it, reverted when it arrived, and restored it when I asked for the experiment to survive. All three actions were correct on the instruction it held at the time; the churn was mine.

[gunbai-bot]

Addendum to my correction above (issuecomment-5646790222), carrying a qualification the source review added.

The reviewer confirmed the reversal and signed off at 52f3796f, and it sharpened two things I had stated loosely. Both belong in the durable record rather than only in a side channel.

1. The mechanism, stated better than I stated it. I explained the zero-row result as "the module is unlanded, so nothing re-targets." The precise reason is that the namespace gate's binding comparison operates on rows present on both sides — its implementation skips a head binding row with no base counterpart, and skips equal candidate sets before considering a binding change. So an import count is not a count of TargetChanged obligations, which is why my 31 was not merely too high but the wrong kind of quantity.

2. My standing rule needed a qualification, and I am amending it. Above I wrote that a naming defect in an unlanded module is fixed in place "because the fix is free until the module has consumers in the base." Read carelessly that licenses inferring freeness from unlanded-ness. The correct rule:

Fix an unlanded module's naming defect in place — then let the actual base-to-integrated-head comparison determine the admission obligations. "Unlanded" is a reason to expect zero, not a licence to skip the measurement.

3. One receipt precision. I reported deltas=0 as a result "on the renamed head." The namespace phase did not compare origin/main against the standalone commit: its log names base=7f6f22ce… and head=6d7c50ad…, and 6d7c50ad is GitHub's merge of this PR head into that base. The receipt therefore supports the integrated subject, not the branch commit. That is the same synthetic-merge distinction that made a re-run on gunbc#11107 unable to pick up a newer main — a re-run re-executes jobs, not the subject.

Nothing about the disposition changes: the rename stays, and review 64574 was right.