I want to tell you about the moment I stopped trusting AI tool announcements.
It was March 19th. Cursor had just launched Composer 2. The benchmarks were extraordinary — 61.7% on Terminal-Bench 2.0, beating Claude Opus 4.6 at one-tenth the price. The announcement called it their "first continued pretraining run" and "frontier-level coding intelligence."
I had been using Cursor for months. I was excited. I shared the announcement with my team. I wrote it into our tooling evaluation notes.
Less than 24 hours later, a developer named Fynn was inspecting Cursor's API traffic.
And he found something that nobody at Cursor had mentioned.
The model ID in the API response was: accounts/anysphere/models/kimi-k2p5-rl-0317-s515-fast
Not a Cursor internal name. Not an abstract identifier. A near-literal description of exactly what Composer 2 was built on — Kimi K2.5, an open-source model from Beijing-based Moonshot AI, fine-tuned with reinforcement learning.
Cursor — a $50 billion valuation company — had announced a "self-developed" breakthrough model. And hadn't mentioned that the foundation of that model was built by someone else entirely.
That was the moment I stopped taking AI tool announcements at face value. 🧵
What Actually Happened — The Full Story
Let me tell you exactly what unfolded, because the details matter.
On March 19, 2026, Cursor launched Composer 2 with bold claims. The announcement described it as a proprietary model built through "continued pretraining" and "reinforcement learning" — language that implied Cursor had built something from scratch. The benchmarks were real. The performance was real. But the origin story was incomplete.
Within hours, Fynn had decoded the model ID:
kimi-k2p5 → Kimi K2.5 base model (Moonshot AI)
rl → reinforcement learning fine-tuning
0317 → March 17 training date
fast → optimized serving configuration
The post got 2.6 million views. Elon Musk amplified it with three words: "Yeah, it's Kimi 2.5."
Moonshot AI's head of pretraining ran a tokenizer analysis. Identical match. Confirmed.
Cursor's VP of Developer Education responded within hours: "Yep, Composer 2 started from an open-source base!" Cursor co-founder Aman Sanger acknowledged it directly: "It was a miss to not mention the Kimi base in our blog from the start."
Less than 24 hours. From "frontier-level proprietary model" to "we should have mentioned the Chinese open-source foundation we built on."
The Number That Made This a Legal Story
Here's where it gets more serious than a PR stumble.
Kimi K2.5 was released under a modified MIT license — permissive for most uses. But it contains one specific clause:
Any product with more than 100 million monthly active users or more than $20 million in monthly revenue must "prominently display 'Kimi K2.5'" in its user interface.
Cursor's publicly reported numbers: annual recurring revenue exceeding $2 billion — roughly $167 million per month.
That's more than eight times the licensing trigger.
Moonshot AI's head of pretraining initially confirmed the violation publicly before deleting the post. Two Moonshot AI employees flagged the issue before their posts disappeared. The situation evolved — Moonshot AI's official account eventually called it an "authorized commercial partnership" through Fireworks AI, and congratulated Cursor.
Whether there was a technical violation depends on exactly how the partnership was structured. But the attribution was absent from the announcement. And that absence wasn't an accident.
The Part Nobody Is Talking About
Here's what I find more interesting than the legal question — and more important for every developer reading this:
A $50 billion company chose a Chinese open-source model over every Western alternative. Not as a cost-cutting measure. Because it was genuinely the best option.
Kimi K2.5 is a 1-trillion-parameter mixture-of-experts model with 32 billion active parameters and a 256,000-token context window. Released under a commercial license. Competitive with the best models in the world on agentic coding benchmarks.
The Western open-source alternatives? Meta's Llama 4 Scout and Maverick shipped but severely underdelivered. Llama 4 Behemoth — the frontier-class model — has been indefinitely delayed. As of March 2026, it has no public release date.
So when Cursor needed a foundation model capable of handling complex multi-file coding tasks across a 256,000-token context window — the best available option was built in Beijing.
That's not a scandal. That's a signal.
Chinese open-source AI is now global infrastructure. The tools powering your favorite Western AI products are increasingly built on foundations from DeepSeek, Kimi, Qwen, and GLM. Often quietly. Sometimes without disclosure.
This wasn't a one-off mistake. It's a pattern.
What This Means For You As a Developer
I've been thinking about this for a week. Here's what actually changes.
Your AI tools are not what they say they are.
The model running behind your coding assistant, your autocomplete, your "proprietary" AI feature — you don't actually know what it is. You know what the marketing says. The reality is a layered stack of base models, fine-tuning runs, and inference optimizations that you'll never see directly.
This was true before Cursor's disclosure. It's just more visible now.
What the announcement says:
"Frontier-level proprietary coding intelligence
built with continued pretraining and RL"
What it might mean:
Open-source base model (origin: anywhere) +
Fine-tuning (vendor's compute) +
RL training (vendor's data) +
Inference optimization (third-party provider) +
UI wrapper (vendor's product)
Every layer has its own provenance, its own license, its own data practices. And you're usually told about none of them.
Your code may be going somewhere you didn't agree to.
This is the security implication that most coverage isn't emphasizing enough.
Kimi K2.5 is from Moonshot AI — backed by Alibaba and HongShan. It processes data through infrastructure that falls under Chinese data governance frameworks. If your organization has data sovereignty requirements — GDPR, HIPAA, government contracts, anything that restricts where data can be processed — you need to know where your AI tools are actually sending your code.
"We're compliant" from a vendor doesn't tell you where your prompts go. It doesn't tell you which base model processes them. It doesn't tell you which inference provider handles the compute.
The Cursor/Kimi situation exposed that most developers have no idea what actually processes their code — and that the companies building on these models don't always tell you.
Open-source attribution is now a trust signal.
Before this week, most developers didn't think much about which open-source models their tools were built on.
After this week, they should.
A company that openly discloses its model lineage — base model, fine-tuning approach, inference provider — is making a verifiable commitment to transparency. A company that describes its model as "self-developed" without mentioning the open-source foundation it was built on is asking you to trust marketing over evidence.
The Cursor situation is actually a good outcome in one sense: the community caught it in 24 hours. A developer with a debug proxy and thirty minutes exposed what a $50 billion company's PR team didn't mention.
That's the open-source ecosystem working. But it only works if developers ask the questions.
The Honest Assessment of Cursor
I want to be fair here, because this story is more nuanced than "Cursor lied."
Cursor's VP of Developer Education said that only 25% of Composer 2's compute came from the Kimi K2.5 base — 75% was Cursor's own reinforcement learning training. That's a meaningful investment. The model that shipped is genuinely different from the base model it started from.
The technical compliance question is complicated by how the partnership with Fireworks AI was structured. Moonshot AI ultimately endorsed the relationship as legitimate.
And Kimi K2.5 is genuinely excellent — a Chinese open-source model that outperforms many Western proprietary alternatives on the benchmarks that matter for coding tasks. Using it isn't a shortcut. It's sound engineering.
The problem isn't that Cursor built on Kimi K2.5. The problem is that they didn't say so. And they didn't say so because "we built a frontier model" sounds better for a $50 billion valuation than "we fine-tuned the best available open-source model."
That's a marketing decision with trust consequences.
What Should Change
I don't think this situation calls for outrage. I think it calls for higher standards — from developers and from vendors.
What developers should start doing:
Ask your AI tool vendors: What base model does this run on? What inference provider processes my code? What data governance framework applies?
If they can't answer clearly — that's information.
What vendors should start doing:
Model cards. Transparent lineage documentation. Clear disclosure of base models and fine-tuning approaches in product announcements. Not because the law requires it in every case — because trust requires it.
What the industry needs:
A norm that treats base model attribution the way software treats dependency attribution. You wouldn't ship a product without acknowledging the open-source libraries in it. The same principle should apply to the models inside the product.
The Real Story Here
The Cursor/Kimi situation isn't really about one company's disclosure failure.
It's about a structural reality of AI product development that most developers haven't fully absorbed:
The AI tools you use daily are almost certainly built on a complex, layered stack of models, training runs, and infrastructure that you've never been told about.
Chinese open-source models are increasingly the foundation of Western AI products — not because of geopolitics, but because they're technically excellent and openly licensed. That's the open-source ecosystem working as intended.
But "working as intended" requires attribution. It requires transparency. It requires the companies building on these foundations to say so — clearly, publicly, at the time of announcement.
Cursor committed to crediting base models upfront in future releases. That's the right outcome.
The question is whether the industry adopts that standard voluntarily — or waits for the next API debug session to expose the next foundation model nobody mentioned.
Are you thinking differently about your AI tools after this? Have you audited where your code actually goes when you use an AI coding assistant? Drop your thoughts below — this is a conversation the developer community needs to have. 👇
Heads up: AI helped me write this.The trust question, the analysis, and the opinions are all mine — AI just helped me communicate them better. Transparent as always because that's the whole point. 😊
Top comments (4)
Great write-up. The attribution problem you outlined is real and it goes beyond just model lineage.
Supermemory pulled something similar recently, but on the benchmark side. They published results claiming to lead in AI memory benchmarks, and it turned out the numbers were fabricated as a marketing stunt. Not a misrepresentation. Not a gray area. Straight up fake results designed to generate buzz and position themselves as a category leader.
Delve recently getting caught faking reports and putting major companies at complete compliance risk. Same playbook: manufacture credibility and hope nobody checks the math.
The pattern is the same whether it is model attribution (Cursor) or benchmark fraud (Supermemory): companies in the AI space are betting that developers will not verify claims. And when the claims are technical enough, most people do not. They just share the announcement and move on.
That is exactly why the standard you are calling for matters. Transparency should not be optional, and it should not only apply to model provenance. It needs to extend to benchmarks, evaluations, and any performance claim a company uses to earn developer trust.
If you are faking your benchmarks, you are not a competitor. You are a liability to every developer who builds on your platform trusting those numbers.
Thanks for reading and for adding these examples. 🙂
I hadn't come across the Supermemory situation that's even worse than misattribution. Straight-up fabricated benchmarks is a whole different level of bad faith.
And you're absolutely right: the pattern isn't just about model lineage. It's about a broader trend where companies in the AI space are treating developer trust as something they can temporarily borrow with marketing stunts, rather than earn through transparency.
The point about benchmarks really hits home. If a company is willing to fake numbers, what else are they cutting corners on? Data handling? Security? Compliance? Developers building on those platforms are unknowingly taking on that risk.
Really appreciate you calling this out. This is exactly the kind of conversation the community needs to have not just about Cursor, but about the standards we should expect from any AI tool vendor. 🙌
This issue points at something that's going to become a real structural problem as AI tooling matures: the implicit contract between a developer tool and its users about what's running under the hood.
The thing is, Cursor's value proposition is partly "we've curated the best models for your workflow." When they silently swap in a model users haven't consented to — especially one with different data handling characteristics — they're not just breaking trust, they're making a security and compliance decision on behalf of their users. For anyone in a regulated environment (fintech, healthcare, enterprise with data residency requirements), that's not a UX problem, it's a policy violation.
The harder version of this question: should developer tools be required to expose model provenance at the API level? Something like an X-Model-Used: kimi-k2.5-v1 response header so audit logs can capture what actually processed a given request? That would be trivially cheap to implement and would make a lot of these silent-swap situations immediately visible.
I don't think it's necessarily malicious on Cursor's part — benchmark-chasing under cost pressure is a real dynamic. But the solution isn't intent, it's disclosure by default. What's your take on whether the community can push toolmakers toward that standard?
This is an excellent point, and I really appreciate you framing it this way.
You're absolutely right this isn't just a transparency issue, it's a security and compliance issue. When a tool silently swaps models, they're making a data governance decision on behalf of every developer using it. For anyone in fintech, healthcare, or any regulated industry, that's not an inconvenience it's a potential policy violation.
I love the API header idea.
X-Model-Usedwould be trivially cheap to implement and would make audit logging actually meaningful. It shifts the burden from trust us to verify us which is exactly where it should be. If every AI tool vendor added that one header, half the problems in this space would become immediately visible.To your question: can the community push toolmakers toward that standard? I think yes, but it requires a few things:
The fact that developers are now inspecting API traffic and asking these questions is the first step. The community caught the Cursor situation in 24 hours. If we start treating model provenance as a non-negotiable requirement like we do with open-source licenses or API security vendors will adapt.
Really appreciate you adding this lens. The API header idea is something I hadn't thought through, and it's genuinely one of the best practical suggestions I've seen in this whole conversation. 🙌