[FEATURE]: kimi k2.6 integration

[Acters]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Please add the new Kimi K2.6 and K2.6-code-preview model that is currently available for the code plans.
It is possible that these are two distinct models because the K2.6 consistently reponds differently from the "code preview" version
Kimi-for-coding is likely not respecting the ID parameter. it is just whatever kimi offers on the kimi-for-coding api.

Temporary json config implementation:

Do not use the provided JSON. the way that models.dev works DOES NOT give you k2.6, the API key path is strictly k2.5 only. Read more in the comments, along with a "plugin" that another user claims to correctly implement the OAuth path that the kimi-cli has that will give access to the k2.6 model.

opencode.json

To disable thinking, change enabled to disabled. source: #12090 (comment)

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kimi-for-coding": {
      "models": {
        "kimi-for-coding": {
          "id": "kimi-for-coding",
          "reasoning": true,
          "attachment": false,
          "limit": {
            "context": 262144,
            "output": 32768
          },
          "modalities": {
            "input": ["text", "image", "video"],
            "output": ["text"]
          },
          "options": {
            "interleaved": {
              "field": "reasoning_content"
            },
            "thinking": {
              "type": "enabled",
              "budgetTokens": 16000
            }
          }
        }
      }
    }
  }
}

Images (non-thinking)

---

---

---

---

[xihuai18]

hurry

[Acters]

I tested this a few minutes ago, but the ID k2.6-code works, which makes it a different model from base k2.6 and the k2.6-code-preview model.
It might be better than the preview model and likely the one that will be part of the full release. (updated the top thread comment with this new model id)

[Acters]

anomalyco/models.dev#1441 (comment)

In the above issue, one of the users tested the API endpoint and confirmed that the kimi-for-coding API endpoint will only direct users to the kimi-for-coding model

I am mistaken that these IDs are respected. We should reflect the behavior that kimi-cli has:

[entrptaher]

There is a clear difference in the thought process between the various models in the list.

[brianwk]

Try changing the model name to kimi-k999, I think it will still respond on the Kimi for Coding API. What you may be seeing is based on the temperature that Kimi Code CLI is using?

Also if you do a curl request and list the models using your API key it will show only one model and that model is called only "kimi-for-coding"

❯ python3 check_kimi.py
Model(id='kimi-for-coding', created=1761264000, object='model', owned_by=None, created_at='2025-10-24T00:00:00Z', display_name='Kimi For Coding', type='model', context_length=262144, supports_reasoning=True, supports_image_in=True, supports_video_in=True)

import openai

# Configuration for Kimi Coding API
client = openai.OpenAI(
    api_key="XXX", # API KEY HERE
    base_url="https://api.kimi.com/coding/v1",  # Official Kimi Coding URL
)

# List all models
models = client.models.list()
for model in models.data:
    print(repr(model))

I don't believe that a LLM can respond deterministically, which is what the test provided assumes. Is there any evidence you actually have the ability to change the model you're using on Kimi for Coding?

[Acters]

https://www.reddit.com/r/LocalLLaMA/comments/1sno8ba/comment/ogopmzi/?context=1

New findings by another user on reddit:

Fair concern, and it's one I had too before digging into how Moonshot's backend actually routes.

Short version: for kimi-for-coding specifically, the model isn't selected by the id string in the request body. It's selected by the auth token type. Static sk-kimi-... API keys land you on K2.5. OAuth JWTs with scope: kimi-code (what Kimi CLI uses) land you on K2.6. The model field on the wire is basically cosmetic, the backend decides from the token.

That's also why the models.dev kimi-for-coding entry behaves the way it does. That one's wired to a static KIMI_API_KEY on an Anthropic-compatible path, which is the K2.5 code path. Different auth, different model, same id string. Easy to conflate.

The plugin I'm building does the OAuth device flow the same way Kimi CLI does, so by construction it's on the K2.6 path. It also hits GET /coding/v1/models at login and on every token refresh and rewrites the wire model field to whatever the server hands back (mirrors kimi-cli's refresh_managed_models). The X-Msh-* headers and UA match kimi-cli exactly. If any of that drifts the backend 403s with access_terminated_error rather than silently downgrading, which is actually the nicer failure mode.

What nobody can control from the client side is whether Moonshot quietly swaps the weights behind kimi-for-coding or does traffic-shaping to something cheaper during peak hours. Kimi CLI is in the same boat. That's a Moonshot trust question, not an opencode one. The only real signal is eval drift over time, which is roughly what SanityHarness is already measuring anyway.

TL;DR: the id gets respected in the sense that K2.5 vs K2.6 is determined by your auth, and the OAuth plugin puts you on the K2.6 path deterministically. Whether Moonshot's K2.6 endpoint stays pointed at the same weights forever, can't promise that, and neither can they.

I have the plugin built now, and so far seems to be working well. This ended up being more work than I expected, but it's done now, and I stamped out the bugs I came across. This is a little bit more than just a "get k2.6" plugin, I aimed for kimi cli parity because the /coding endpoint has Kimi-specific extensions on top of the OpenAI-compatible shape that kimi cli actually uses, and I wanted those wired through properly instead of half-supported. That means the seven X-Msh-* headers and UA are pinned to kimi cli's exact values (anything off-spec there gets you 403'd as a non-coding-agent client), the reasoning effort switch maps to the thinking and reasoning_effort body fields the same way kimi cli maps them, prompt_cache_key is forwarded so multi-turn sessions actually hit the server-side cache, and the model id discovery/refresh dance matches refresh_managed_models so token refresh and account-type changes don't strand you on a stale id. Basically the goal was: if it works in kimi cli, it should work here, with the same wire behavior. https://github.com/lemon07r/opencode-kimi-full/

[noel-debug]

anomalyco/models.dev#1441 (comment)

In the above issue, one of the users tested the API endpoint and confirmed that the kimi-for-coding API endpoint will only direct users to the kimi-for-coding model

I am mistaken that these IDs are respected. We should reflect the behavior that kimi-cli has:

kimi-for-coding is the correct model to use. the same is used by the kimi cli

[Shell1500]

+1

[brianwk]

Does anyone know if we actually need to use this OAuth Kimi for Coding plugin? Or is the "default model" already Kimi K2.6? I will say that when I use the OAuth plugin the model answers differently when I ask what model it is or what the knowledge cut off date is.