feat(models): add Kimi (Moonshot) provider with K2.6 and K2.7

[Tugser]

Summary

Adds Kimi (Moonshot AI) as a first-class, OpenAI-compatible provider with two vision-capable models: Kimi K2.6 (k2p6) and Kimi K2.7 Code (k2p7). Targets the Moonshot coding endpoint (https://api.kimi.com/coding/v1).

Both models are multimodal (text/image/video input), so consumers like Peekaboo can use them for screenshot/image analysis.

Changes

• Models/Model.swift: new LanguageModel.Kimi enum (k26, k27); vision + tools enabled; context 262144. New case kimi(Kimi) on LanguageModel; parse qualified (kimi/moonshot) and loose ids (kimi-k2.6, k2p7, ...); updated ==, hash(into:), description/modelId/provider/vision/tools/context switches.
• Core/Provider.swift: Provider.kimi (id kimi, MOONSHOT_API_KEY env + KIMI_API_KEY/MOONSHOT_KEY aliases, baseURL https://api.kimi.com/coding/v1, standardProviders, from(identifier:)).
• Providers/ProviderFactory.swift: .kimi → OpenAICompatibleProvider.
• Providers/Compatible/OpenAICompatibleProvider.swift: optional capabilities: parameter (mirrors AnthropicCompatibleProvider).
• Core/ModelCapabilities.swift, Utilities/UsageTracking.swift, Examples/AI-CLI: exhaustive-switch wiring + example.
• Tests: ModelParsingTests (parse + vision + context), LanguageModelCoverageTests list.

Test commands executed

swift build
swift test --filter "ModelParsingTests|LanguageModelCoverageTests"

31 tests pass (incl. new parse Kimi (Moonshot) model ids).

Notes

• Model ids (k2p6, k2p7) and the coding endpoint are taken from the OpenCode built-in kimi-for-coding provider definition; both models advertise modalities.input = [text, image, video], hence supportsVision = true.
• Pricing in UsageTracking is a placeholder estimate pending Moonshot's published rates.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 27, 2026, 6:07 PM ET / 22:07 UTC.

Summary
The PR adds a first-class Kimi/Moonshot OpenAI-compatible provider with K2.6/K2.7 models, provider factory wiring, capabilities, pricing, AI-CLI mapping, and focused parsing/coverage tests.

Reproducibility: not applicable. as a user bug reproduction; this PR adds a new provider feature. The PR blockers are source-reproducible from the unchanged ModelSelector fallback and ProviderTests provider-list contract, plus missing runtime proof in the PR body/comments.

Review metrics: 2 noteworthy metrics.

• Changed surface: 9 files, +158/-2. The diff crosses public model/provider enums, factory routing, capabilities, pricing, examples, and tests.
• Selection and provider-test gaps: 0 changes to ModelSelection.swift; 0 changes to ProviderTests.swift. Those existing contract surfaces still need updates for a first-class provider addition.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add redacted terminal output, logs, recording, or a linked artifact showing a real Tachikoma Kimi request; redact API keys, private endpoints, IPs, and other sensitive details.
• [P1] Wire Kimi through ModelSelector/default selection and add focused selector tests for kimi and moonshot inputs.
• [P1] Update ProviderTests and add mocked ProviderFactory/OpenAI-compatible request coverage for the Kimi endpoint.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body lists build and focused test commands, but no redacted terminal output, logs, recording, screenshot, or linked artifact shows a real Tachikoma Kimi request after the change. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] No redacted terminal output, logs, recording, or linked artifact shows a real Tachikoma Kimi request through the new provider path.
• [P1] Adding public Provider/LanguageModel cases plus kimi/moonshot aliases can affect downstream exhaustive switches and existing custom provider identifiers.
• [P1] Kimi-prefixed selections can still route through OpenRouter instead of the new provider, causing wrong model choice and credential selection.
• [P1] The Kimi model IDs, endpoint, vision/tools claims, max output tokens, and placeholder pricing need maintainer acceptance before becoming a first-class provider contract.
• [P1] The related open Peekaboo PR should wait for this provider surface to land on Tachikoma main before repointing its Tachikoma submodule.

Maintainer options:

1. Complete The Provider Surface (recommended)
   Update ModelSelector/default provider selection, ProviderTests, mocked request-path coverage, and add redacted live Kimi proof before merge.
2. Accept Built-In Alias Ownership
   Maintainers can explicitly accept that kimi and moonshot become reserved built-in identifiers instead of custom provider names, but that should be a deliberate provider-contract decision.
3. Defer To Custom Provider Setup
   If Kimi should not be first-class yet, pause or close this PR and document the existing OpenAI-compatible custom-provider path instead.

Next step before merge

• [P1] Human review and contributor action remain because missing live Kimi proof and maintainer acceptance of the provider/alias surface cannot be supplied by automation.

Security
Cleared: No concrete security or supply-chain regression was found; the diff does not change dependencies, workflows, install scripts, or secret logging.

Review findings

• [P2] Route Kimi selections through ModelSelector — Tests/TachikomaTests/Core/ModelParsingTests.swift:135-145
• [P2] Update the provider-list contract test — Sources/Tachikoma/Core/Provider.swift:165

Review details

Best possible solution:

Complete Kimi as a full first-class provider by wiring selection/help/default-provider/test surfaces, adding mocked provider-path coverage and redacted live proof, then land Tachikoma before dependent Peekaboo submodule changes.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a user bug reproduction; this PR adds a new provider feature. The PR blockers are source-reproducible from the unchanged ModelSelector fallback and ProviderTests provider-list contract, plus missing runtime proof in the PR body/comments.

Is this the best way to solve the issue?

No, not yet. The ProviderFactory shape follows nearby patterns, but the branch needs selection/parser/test coverage, mocked request-path coverage, real behavior proof, and maintainer acceptance of the new provider contract.

Full review comments:

• [P2] Route Kimi selections through ModelSelector — Tests/TachikomaTests/Core/ModelParsingTests.swift:135-145
  The added tests cover LanguageModel.parse, but CLI and agent surfaces use ModelSelector.parseModel. In the PR tree, ModelSelector.parseModel("kimi/k2p7") still falls into the unknown qualified-provider fallback and returns .openRouter(modelId:), bypassing the new .kimi provider and Moonshot credentials.
  Confidence: 0.91
• [P2] Update the provider-list contract test — Sources/Tachikoma/Core/Provider.swift:165
  This adds .kimi to Provider.standardProviders, but Tests/TachikomaTests/Core/ProviderTests.swift still asserts the exact old list without .kimi. A full provider test run will fail once this standard provider change is present, so update the provider tests alongside the new identifier, alias, env-var, and base-URL coverage.
  Confidence: 0.92

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against ae08789eea52.

Label changes

Label justifications:

• P2: This is a normal first-class provider feature with limited blast radius, but it has concrete proof and correctness blockers.
• merge-risk: 🚨 compatibility: The PR adds public enum cases and reserves kimi/moonshot identifiers, which can affect downstream exhaustive switches and existing custom provider names.
• merge-risk: 🚨 auth-provider: Current selector paths can route Kimi-prefixed inputs away from the new Kimi provider and Moonshot credentials.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body lists build and focused test commands, but no redacted terminal output, logs, recording, screenshot, or linked artifact shows a real Tachikoma Kimi request after the change. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its provider-consistency guidance applies to this provider PR. (AGENTS.md:1, ae08789eea52)
• Current main lacks Kimi source support: A current-main source/test/example search found no Kimi, Moonshot, k2p6, k2p7, MOONSHOT, or KIMI provider/model symbols, so the feature is not already implemented. (ae08789eea52)
• PR diff surface: The PR head changes 9 files with +158/-2, adding Provider.kimi, LanguageModel.Kimi, factory routing, capability override wiring, usage pricing, AI-CLI mapping, and focused tests. (ebcad414ffe3)
• Selector gap: In the PR tree, ModelSelector.parseModel still sends unknown qualified providers through the OpenRouter fallback, so kimi/k2p7 bypasses the new Kimi provider and Moonshot credential path. (Sources/Tachikoma/Models/ModelSelection.swift:74, ebcad414ffe3)
• Provider test contract gap: The PR adds .kimi to Provider.standardProviders, while ProviderTests in the PR tree still asserts the exact old provider list without Kimi. (Tests/TachikomaTests/Core/ProviderTests.swift:182, ebcad414ffe3)
• Proof status: The PR body reports build/focused tests only, and the existing ClawSweeper comment already requested redacted live Kimi runtime proof; there are no later human comments resolving that blocker. (ebcad414ffe3)

Likely related people:

• steipete: Git blame and GitHub commit metadata show recent work on the same provider/model catalog, ModelSelector, ProviderFactory, and ProviderTests surfaces. (role: recent area contributor; confidence: high; commits: 82c7aa095ff9, 7704018a475d, 63601973c6d0; files: Sources/Tachikoma/Core/Provider.swift, Sources/Tachikoma/Models/Model.swift, Sources/Tachikoma/Models/ModelSelection.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.