Retire Kimi K2.6 and K2.7 Code by timothyerwin · Pull Request #7 · memcode-ai/memcode

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin · 2026-09-03T04:10:51Z

Removes Kimi K2.6 and Kimi K2.7 Code from the model catalog. Kimi K3 stays as the Kimi offering.

Why the change is more than two deletions

Both models appeared in other models' declared fallback chains. A chain naming a model the catalog no longer contains resolves to nothing — it doesn't error, it just silently shortens the safety net that keeps a turn alive when a provider is unreachable. So the chains are repaired, not left dangling:

model	before	after
`glm-5p2`	`kimi-k2p7-code, terra`	`terra`
`kimi-k3`	`kimi-k2p7-code, terra`	`glm-5p2, terra`

kimi-k3 keeps a same-provider hop that still exists rather than falling straight off Fireworks on its first failure.

The kimi-k2p7 pricing family is removed along with the model it was written for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of dropping to the $3/$15 defaults.

What happens to someone pinned to one of them

Nothing breaks. A model id outside the catalog is refused by the /model picker and by policy validation, and the pin resolver falls through to the next scope — workspace, then user, then the default_model seed.

Verification

gofmt, go vet, go test -race ./..., staticcheck — the full CI gate, clean
All four models.json copies verified byte-identical after go generate ./catalog and the sync script
A structural check that every remaining fallback entry resolves to a model still in the catalog

Note

The first attempt at this used index arithmetic over the JSON text and removed the wrong entry — qwen3p8-2p4t-a95b instead of kimi-k2p6. Caught by diffing the parsed catalog against HEAD rather than trusting the edit. Redone as a structural edit after verifying a JSON round-trip is byte-identical to the original file.

The matching www and gateway changes (catalog sync, FAQ, marketing model list, test fixtures) go direct to main in memcode.ai.

Both leave the catalog. Kimi K3 stays as the Kimi offering. Two other models named kimi-k2p7-code in their declared fallback chains, so those are repaired rather than left dangling — a chain naming a model the catalog no longer has resolves to nothing, which silently shortens the safety net instead of announcing itself: glm-5p2 kimi-k2p7-code, terra -> terra kimi-k3 kimi-k2p7-code, terra -> glm-5p2, terra kimi-k3 keeps a same-provider hop that still exists rather than going straight off Fireworks. The kimi-k2p7 pricing family is removed with the model it existed for. The generic kimi row stays as the floor, so a stale pin to a retired id still meters at roughly its real rate instead of falling to the defaults. A stale pin is otherwise harmless: an id outside the catalog is refused by the picker and by policy validation, and the pin resolver falls through to the next scope.

catalog/models.json and models.json: resolved onto main's post-#7 catalog as the base, so both retired Kimi rows stay gone, then re-applied the 14 cross-vendor chains on top. Resolved structurally against the parsed catalog rather than by editing conflict text — the file round-trips byte-identically through json, so the rewrite touches only the fallback arrays. policy_test.go: a comment-wording conflict only; took main's phrasing. No chain references a retired model, and TestFallbackFirstHopLeavesTheVendor still passes: every first hop changes vendor.

timothyerwin mentioned this pull request Sep 3, 2026
Fix the Gemini tool-replay 400, and stop it from costing 12 minutes of silence #8
Merged

timothyerwin merged commit a0e29a0 into mainSep 3, 2026
2 checks passed