I am not arguing that Kimi did not distill Opus or Sonnet (which they almost certainly have, as opposed to Fable or Sol). I am arguing that even if they did not distill, the model could still identify itself as Opus or Sonnet.
That being said, I'd like to point out a few things:
- The second link (to claude-sonnet-4-2025051) had 17k matches, not just 3k.
- grep.app does not index the entirety of GitHub, so the real number of occurrences of model identifiers is even higher. SourceGraph has a larger index, but the number is so high that it exceeds their result limit of 10k: https://sourcegraph.com/search?q=claude-opus-4-5-20251101&pa...
- 1000 occurrences are already plenty for memorization. Here is a paper that shows over 80% "extractability" with 1000 occurrences for a 6B model. It also shows that extractability scales with model size: https://arxiv.org/pdf/2202.07646
- LLMs have a "mosaic memory", which means that they can combine information from different parts of the training data. https://arxiv.org/pdf/2405.15523 For example, one piece of training data might mention "I am Opus", another might mention "Opus (claude-opus-4-5-20251101)" and another 10000 "claude-opus-4-5-20251101", where the later occurrences strengthen the generation probability of "I am Opus".
- RL can change the model identity easily, so all of the above may not matter at all.
Adding count:all to the Sourcegraph query, I get 55,911 results
Your theory doesn't hold up against the data.
While model identifiers like "claude-opus-4-5-20251101" appear thousands of times across GitHub and other code sources, so do "gpt-4o-2024-08-06", "gpt-4.1-mini-2025-04-14", and "gemini-1.5-pro-002" in similar amounts. I clicked your links and examined the GitHub configuration files. There are hundreds of other model names that all appear in these config files at comparable frequencies.
If your theory were right, GitHub's model name frequency distribution should match K3's self-identification distribution. But that's not what happens.
K3 only identifies itself using API model identifiers for specific Claude models. It strongly prefers claude-opus-4-5-20251101 and claude-sonnet-4-5-20250929 over others. And it only does this for Claude. Prefill K3 with "I am GPT" or and you get "GPT-5.2". Prefill with "I am Gemini" and you get "Gemini 3 Pro".
Your web exposure theory cannot explain why this only happens for Claude models and not others. Furthermore, this only happens for Kimi K3; other models trained on the same web dataset (GPT, GLM, DeepSeek, Claude) do not exhibit this strange behavior.
But what could explain this behavior? An obvious one is that Claude model identifiers occurred at high frequency in K3's training data, which would happen if K3 were trained on (inadequately filtered) distilled output from those specific Claude models.
There is a section in the analysis I linked that directly addresses this: https://github.com/rgreenblatt/which_claude_is_k3/blob/main/...
Under prefill, K3 reproduces Claude's deployment identifiers — better than Claude does
Prefilled "I am Claude", Kimi K3 emits Claude's exact claude-<model>-<YYYYMMDD> identifiers: claude-opus-4-5-20251101 (12×), claude-sonnet-4-5-20250929 (4×), and more. Across the sweep it emits 24 Claude-formatted dated ids (18 of which are genuine Anthropic strings), all under prefill (0 in direct chat), and 0 ids for any non-Claude lab. Among controls essentially none appear (Qwen 0, both GPT refs 0, DeepSeek 1 — itself a Claude id). Dated ids for every lab are web-documented, so the evidence is this cross-model asymmetry under identical prefill, not the strings alone.