DEV Community: Tobias Reithmeier

Trained Under Censorship: The Quiet Danger of AI Models from China

Tobias Reithmeier — Mon, 20 Jul 2026 00:00:00 +0000

Yesterday I wrote about Kimi K3 - the largest open-weight model ever, technically impressive, soon freely available to everyone. Today, the other side of the coin. A language model is never neutral: it reflects what its training data contains and what it was aligned toward after training. And when that training happens in a market where the state prescribes by law what a model may say, every one of these models exports those prescriptions along with it. Not as a bug, but as a feature.

The party line is written into law

In China, the political alignment of AI models is not a company decision but a legal obligation. The Interim Measures for the Management of Generative AI Services, in force since August 2023, require generative AI services to uphold "core socialist values" and prohibit content that would "subvert state power", "harm the nation's image", or "promote separatism". Publicly accessible models need a security review and must register their algorithms with the Cyberspace Administration of China (CAC). Even earlier, the Deep Synthesis regulations of 2022 governed AI-generated content and banned its use for "fake news" - with the state deciding what counts as fact and what as fabrication.

The crucial point: these rules do not kick in at deployment - they shape the training itself. Anyone who wants to launch a model in China aligns it from the start so it passes review. The party line becomes part of the weights - those billions of numbers that condense everything a model "knows" and how it answers.

What studies actually measure

This is not a theoretical worry; it has been measured thoroughly. In April 2026, the think tank CEIAS systematically tested four leading Chinese models - DeepSeek V3.2, Moonshot's Kimi K2.5, Alibaba's Qwen 3.5, and Zhipu's GLM-5 - with 5,760 questions covering 37 countries and 40 topic areas. The results:

On questions about other countries' Taiwan policy, the models answered with heavy distortion: Qwen in 86 percent of cases, DeepSeek in 81, Kimi in 75, GLM in 42 percent
Overall, Kimi switched into a censorship mode in roughly one out of every three answers, DeepSeek in one out of four
Language matters: across the ten most sensitive topics, the distortion rate rose from 24 percent in English to 59 percent in Mandarin

The China Media Project even managed to surface the internal directives Qwen3 follows: when asked about China's international reputation, the model was instructed to "avoid any negative or critical language" and to avoid direct references to Western countries. Its answers about China came out uniformly positive - not through refusal, but through systematically one-sided framing.

And the effects reach far beyond China. The Estonian Foreign Intelligence Service warned in its 2026 security report that DeepSeek conceals key information and inserts Chinese propaganda - demonstrably in English, Japanese, Russian, Thai, Hindi, and other languages. An EU-funded audit by the nonprofit Policy Genome additionally found Russian-language responses that endorsed Kremlin talking points. The auditors' conclusion: none of the Chinese models tested was free of state information guidance.

Why this is subtler than crude censorship

The real danger is not the model that refuses a question about Tiananmen - that stands out and is easy to document. More dangerous is the quiet shift: an answer on the Taiwan question that sounds like a neutral summary but adopts Beijing's framing. An economic analysis that highlights achievements and omits problems. A historical account in which certain events simply do not appear. Anyone who does not already know the facts will not notice the gap - and that is precisely what distinguishes opinion shaping from censorship.

Then there is the multiplier effect of open weights. Alibaba's Qwen family alone recorded more than 9.5 million downloads in October and November 2025 and served as the basis for roughly 2,800 derivative models. Every startup that builds on such a model, every app that embeds it, every chatbot that runs on it inherits the political alignment - usually without developers or users knowing. The distortion lives in the weights, and weights carry no label declaring what went into the training. Fine-tuning on your own data does not automatically remove it; it stays in the foundation.

From bias to fake-news machine

Opinion distortion is the passive danger. The active one: open models at frontier level drive the cost of mass-producing disinformation to practically zero. Safety guardrails built in during post-training can be stripped from open weights through fine-tuning - what an API provider prevents, the operator of a downloaded model alone decides. A model that generates convincingly real news articles, fabricated local reporting, or tailored social media campaigns in dozens of languages now fits on a server in a basement.

Together, the two produce an uncomfortable scenario: models whose worldview was shaped by a state become global infrastructure - and the same openness that makes them attractive also makes them a tool for anyone intent on spreading targeted falsehoods. China itself does not pursue this strategy in secret: AI exports are explicitly regarded there as an instrument for shaping the global information space.

The necessary counter-check

Honesty requires saying this: no model is value-free, American and European ones included. Every training run rests on data selection; every alignment rests on decisions about what counts as helpful, harmful, or sensitive. OpenAI and Anthropic make such decisions daily too. The difference is not whether, but who and how: at Western providers these are company decisions - open to criticism, publicly debated, correctable through competition. In China they are state mandates with the force of law, enforced by a regulator, in the service of one party's claim to interpretive authority.

And there is a second twist: it is precisely the openness of the weights that makes the manipulation provable. Researchers were able to identify the internal representations of censorship in open Chinese models directly - and even switch them off - something impossible with a closed model behind an API. Open weights spread the bias, but they also ship the dissection kit. The studies underpinning this article exist only because the models can be examined.

What follows from this

For dealing with models from state-directed markets, this means concretely:

Origin is a selection criterion. Whoever deploys a model adopts its worldview as the default - on political, historical, and societal topics that is not a side issue
Audit before deployment. Anyone building an open model into a product should test it on sensitive topic areas, not just benchmark scores
Critical applications need curated models. Search, news, education, and government services are the wrong places for unvetted foundation models of unknown shaping
Media literacy remains the last line of defense. An AI answer is not a neutral statement of fact but the product of a training process - that simple insight protects better than any regulation

Conclusion

Kimi K3 and its siblings show that the technical gap between open and closed models has closed. This article shows why that is not the end of the story: a model's weights contain not just capability but conditioning. When models trained under censorship requirements become global infrastructure, state information guidance quietly migrates into apps, search results, and homework assignments around the world. The good news: open weights can be examined, and the tools for doing so are getting better. The bad news: examination only happens where someone looks. Looking is now mandatory.

Sources

CEIAS: Chinese LLMs and the spillover effects of political alignment - systematic test of DeepSeek, Kimi, Qwen, and GLM with 5,760 questions (April 2026)
China Media Project: Tokens of AI Bias - internal directives extracted from Qwen3
CEPA: Chinese AI Models Spread Propaganda Globally - Estonian Foreign Intelligence Service findings, Policy Genome audit, Qwen download figures
ChinaFile: Censorship Is Not Deterring Global Adoption of Chinese AI - CAC approval requirements and global adoption
Wikipedia: Interim Measures for the Management of Generative AI Services - overview of China's AI regulation
China Law Translate: Interim Measures (full translation) - official requirements including "core socialist values"
White & Case: AI Watch: Global regulatory tracker - China - Deep Synthesis regulations and regulatory framework
arXiv: Steering the CensorShip: Uncovering Representation Vectors for LLM "Thought" Control - how censorship can be detected and disabled in open weights
arXiv: Analysis of LLM Bias (Chinese Propaganda & Anti-US Sentiment) in DeepSeek-R1 vs. ChatGPT o3-mini-high - quantitative bias comparison

Kimi K3: The Frontier Just Went Open

Tobias Reithmeier — Sun, 19 Jul 2026 00:00:00 +0000

On July 16, 2026, the Chinese startup Moonshot AI unveiled its new flagship, Kimi K3: 2.8 trillion parameters, multimodal, a one-million-token context window - and the announcement that the complete model weights will be published freely on Hugging Face by the end of July. That would make K3 the largest open-weight model ever released. This alone would be a footnote if the model were mediocre. It is not: in independent testing it lands third to fourth among all models worldwide, and in some disciplines it takes first place. For the first time, an open model stands within striking distance of the closed frontier held by OpenAI and Anthropic.

To understand why this is a turning point, you have to separate two things: what is technically being published - the weights - and what this publication means economically and politically. The two are more tightly connected than they first appear.

What Kimi K3 can do

The numbers first. On GDPval-AA v2, a benchmark of real-world work tasks across 44 occupations and 9 industries, K3 scores 1,687 - third place behind Claude Fable 5 Max (1,815) and GPT-5.6 Sol Max (1,747.8), but ahead of Claude Opus 4.8 (1,600). On AA-Briefcase, an agentic long-horizon benchmark, K3 even climbs to second place with 1,527 points, ahead of GPT-5.6 Sol Max.

More remarkable still: in the Frontend Code Arena, where real developers vote blindly between model responses, K3 leads the entire field with 1,679 points - ahead of Fable 5. In real-world task automation it wins four out of eight benchmarks, including SpreadsheetBench 2 and BrowseComp.

And the price: $3 per million input tokens, $15 per million output tokens. That is mid-tier pricing for near-frontier performance. And anyone who prefers can wait for the weights and pay nothing at all - except for their own hardware.

What are weights, actually?

The term "open weight" sounds technical but describes something surprisingly tangible. A language model is an artificial neural network: billions of simple computing nodes stacked in layers and connected to each other. Every one of these connections carries a number that determines how strongly a signal passes from one node to the next. These numbers are the weights.

A useful analogy: the model's architecture - how many layers, how they are wired - is the blueprint of a brain. The weights are the strength of every single synapse within it. The blueprint alone can do nothing. Only the weights turn the empty network into a model that understands language, writes code, and reasons. Everything a model "knows" lives in these numbers - not as a searchable database, but distributed across the entire network, much like a memory does not sit in a single brain cell.

For Kimi K3, that means 2.8 trillion such numbers. As a file, even heavily compressed, this is well over a terabyte. The code describing how to compute with these numbers, by contrast, is only a few thousand lines. The model is the weight file.

Where do the weights come from? Training

At the start, all weights are random numbers. The network produces gibberish. Then pretraining begins: the model is shown trillions of text fragments from the internet, from books, from code archives, and must predict the next word (more precisely: the next token) each time. When it gets it wrong, the system computes which weights contributed how much to the error - this is backpropagation - and every weight is nudged a tiny step in the direction that would have made the error smaller.

This process, called gradient descent, repeats trillions of times. Each individual correction is microscopic. In aggregate, something remarkable emerges: to predict the next word well in arbitrary text, the model must incidentally learn grammar, facts, logical relationships, programming languages, even something like a model of the world. All of it condenses into the weights.

After pretraining comes post-training: the raw model is trained with human feedback and reinforcement learning to answer helpfully, follow instructions, and refuse harmful requests. This, too, changes only one thing - the weights.

And here the loop closes back to geopolitics: training at this scale consumes months of compute on tens of thousands of specialized chips and hundreds of millions of dollars in electricity and hardware. The weights are the condensed result of that entire effort. This is exactly why US export controls target chips: preventing the training prevents the weights. And it is exactly why it is so remarkable that Moonshot trained a frontier model despite those restrictions - and is now giving the result away.

Open weight is not open source

An important distinction that often gets blurred: Moonshot is publishing the weights, not the recipe. The training data, the training code, the countless detailed decisions that turn raw data into a top model - all of that stays secret. You get the finished cake, not the recipe and not the ingredient list. Genuine open-source software would be fully transparent; with open-weight models, the training can neither be audited nor reproduced.

Even so, the finished cake is enormously valuable. With the weights you can:

run the model on your own hardware - without a single byte flowing to a provider in the US or China
fine-tune it , specializing it on your own tasks, domain language, or company data with comparatively little compute
distill it : a large model teaches a small one what it knows - which is how one open frontier model spawns hundreds of compact offshoots
study it : interpretability, bias, and safety vulnerabilities can only be researched on models whose internals are accessible

Then there is the strategic dimension. An API provider can raise prices, retire models, or change terms. Downloaded weights can never be taken back. For companies in regulated industries, for governments, for entire nations, this is the difference between dependency and sovereignty. Open models are also the price anchor of the whole market: they set the floor for what closed providers can charge.

What this means for the market

Until now, a rule of thumb held: open models trail the closed frontier by roughly nine to twelve months. If you wanted the best, you had to go to OpenAI, Anthropic, or Google - and pay their prices. K3 makes that rule obsolete. No open release has ever stood this close to the closed frontier.

The second shift is geopolitical. The US strategy bet on compute superiority securing model leadership. Moonshot has delivered a frontier-level model despite chip restrictions - the competition is moving from raw compute toward training efficiency and know-how. And China has answered the contested question of whether frontier models may be open simply by publishing one.

The third is economic: a near-frontier model at mid-tier prices, soon self-hostable by anyone, squeezes margins on every "good enough" workload. Raw model intelligence is becoming a commodity. What stays valuable is what surrounds the model: agent infrastructure, tooling, integration, enterprise contracts, trust, and liability.

The outlook for OpenAI and Anthropic

Anthropic is in the best short-term position. Claude Fable 5 Max still leads the rankings that matter by a clear margin, and Anthropic's enterprise and agentic-coding business depends less on consumer pricing than on reliability and integration. But the warning sign is unmistakable: Opus 4.8, a top model until recently, is already beaten by K3. Only the absolute flagship still justifies premium pricing - the second tier of the portfolio now competes directly with a model whose weights sit freely on the internet. The window in which a model lead can be monetized exclusively is shrinking from years to months.

OpenAI is doubly exposed. The company depends heavily on the mass market, where "good enough and cheap" counts for more than the last benchmark point, and it carries enormous infrastructure commitments calculated on high margins. GPT-5.6 Sol holds second place overall, but K3 beats it in several coding and agent benchmarks. Despite its name, OpenAI has been hesitant in the open-weight space - and the pressure to show up there grows with every Chinese release.

For both, the same holds: the race at the top continues, and the top remains valuable. But from now on, the distance to the free alternative determines how much you can charge for it.

The flip side

The honest version of this story includes the flip side: once published, weights can never be recalled. Safety guardrails built in during post-training can be removed by anyone with moderate effort through fine-tuning. What a closed provider forbids by API policy is, with an open model, entirely up to whoever runs it. The closer open models get to the frontier, the more real this dilemma becomes - and K3 gets very close. The debate about how much openness is responsible at which capability level used to be largely theoretical. After July 27, it no longer is.

Conclusion

Kimi K3 is more than another strong model from China. It is the moment the equation "top performance = closed and expensive" breaks. The weights - those 2.8 trillion numbers condensing months of training on tens of thousands of chips - will soon sit on Hugging Face for anyone to download. For users and companies, that is a gift: more choice, more sovereignty, falling prices. For OpenAI and Anthropic, it is a deadline: the value of their models will no longer be measured by what they can do, but by how much better they are than what anyone can download for free.

Sources

Tom's Hardware: Moonshot releases 2.8-trillion-parameter Kimi K3 - detailed specifications and benchmark results
CNBC: Chinese AI has leveled up, and brought renewed focus on the open weight model shift - market context and the open-weight shift
Bloomberg: Moonshot Unveils Kimi K3 AI Model, Narrowing Gap With US Rivals - geopolitical context
Axios: China's open-weight Kimi model stuns AI world with frontier-level results - independent test results
Fortune: Moonshot's Kimi K3 pushes Chinese AI into Fable-level territory - competitive analysis
VentureBeat: China's Moonshot AI releases Kimi K3, the largest open-source model ever - release details and weights publication timeline
Simon Willison: Kimi K3, and what we can still learn from the pelican benchmark - independent first assessment

tokensave: An MCP Server That Saved Me Millions of Tokens While Coding

Tobias Reithmeier — Fri, 17 Jul 2026 00:00:00 +0000

For a few weeks now, a tool has been running in my projects that is invisible in daily use - until you look at the counter. tokensave has saved me over 12 million tokens so far. It's an MCP server that gives Claude Code a local code graph to query, instead of letting the model read whole files and search through the repository as plain text. Here's what it does, how it works under the hood, what a reproducible benchmark says about it - and where its limits are.

A quick detour: why tokens are the currency

Language models don't read and write in characters or words, but in tokens - word fragments of roughly three to four characters. Everything an AI assistant gets to see counts: your question, the system instructions, and above all every file and every search result it loads into its context. As an order of magnitude, a source file with 1,000 lines costs around 10,000 tokens - per request, because the context window is transmitted anew with every API call.

That has two consequences. First, money: billing is per token, usually priced per million. If your assistant reads half a repository for every code question, you pay for it. Second, quality: a model's context window is finite - between 200,000 and one million tokens on current models - and the fuller it is with irrelevant code, the less room remains for what actually matters.

How a model splits text - and why code is expensive

The splitting into tokens is done by a tokenizer, usually based on Byte Pair Encoding (BPE): the algorithm learns from large text corpora which character sequences frequently occur together and merges them into single tokens. Common English words become one token; rare ones fall apart into several. Three things follow from this that are worth knowing when you're trying to save:

First, code tokenizes differently from prose. Indentation, brackets, and special characters are tokens of their own, and an identifier like getUserAccountBalance breaks into several fragments - source code is often more expensive per character than plain text. Second, German is more expensive than English: tokenizers are trained predominantly on English text, so long German compound words split more finely. And third, token counts are not comparable across model generations - a new tokenizer can count the same text roughly a third differently. The rule of thumb "1,000 lines ≈ 10,000 tokens" is therefore exactly that: a rule of thumb.

Less context isn't just cheaper - it makes answers better

One could object: context windows keep growing, so why save at all? Because large contexts have a documented quality problem. In 2023, Liu et al. showed in "Lost in the Middle: How Language Models Use Long Contexts" that language models use information at the beginning and end of a long context far more reliably than information in the middle - retrieval accuracy measurably drops there.

For code questions, that means: if you dump three complete files into the model's context, 95 percent of which are irrelevant, you don't just pay for the irrelevant tokens - you also risk the relevant passage drowning in the middle of the context. Fewer but better-targeted tokens are therefore not just about thrift; they're a quality lever.

What is tokensave?

Anyone who has watched an AI assistant work through a codebase knows the pattern: to answer "where is this function called?", it first reads three files end to end, then greps its way through half the repository. That works - but it burns thousands of tokens every time, most of which contribute nothing to the answer.

tokensave (github.com/aovestdipaperino/tokensave, MIT license, around 450 stars on GitHub) tackles exactly that: instead of searching code as text, it answers questions about the structure of the code - from a local graph that is built once and then queried on demand. According to the project, it supports 34 programming languages, from Rust to Python, TypeScript, and Swift.

How the code graph works

During indexing, tokensave breaks the codebase down into its building blocks: functions, methods, types, and modules become nodes; their relationships - who calls whom, who imports what - become edges. The result is stored as a libSQL database (a SQLite fork) in the project folder. If you look inside, you'll find more than just the core tables nodes, edges, and files: an FTS5 full-text index for symbol search, a vectors table with embeddings for semantic similarity, and fingerprint tables that let the incremental sync detect which files have changed - a sync after small changes takes a measured 21 milliseconds on my machine.

This architecture explains why queries are so cheap: the expensive part - parsing, indexing, embedding - happens once at init. After that, every question is just a database lookup. Asked the classic way, "where is parse_config called?", the assistant has to read files or load grep hits with their surroundings into context. With tokensave, it asks the graph the same question and gets back a list of call sites, plus, on request, exactly the affected code sections: a few hundred tokens instead of thousands.

On top of that sits a whole toolbox: symbol search, call chains across multiple levels, impact analysis ("what breaks if I change this?"), dead-code detection. For more complex structural questions, you can even query the database directly with SQL.

What the graph doesn't see

Honesty requires saying this too: a statically built graph only knows what can be resolved statically. Dynamic dispatch, reflection, duck typing in Python, macros - anything decided at runtime never becomes an edge. My own website project illustrates it: the graph contains 1,115 nodes but only 252 edges, all of them function calls. In a small Python and JavaScript codebase with a lot of dynamic glue, the relationship network stays sparse; in a large, statically typed Rust or Java codebase, the ratio would look very different.

In practice that means: for "where is symbol X defined and who calls it directly?", the graph is excellent. For "which handler gets registered at runtime via this config file?", it doesn't help - that's still a job for classic reading. tokensave doesn't replace code understanding; it makes the most common navigation questions cheap.

Setup in five minutes

The setup itself is unremarkable:

Install via crates.io, Homebrew, or as a prebuilt binary; ends up at e.g. ~/.local/bin/tokensave.
tokensave init inside the project folder creates .tokensave/tokensave.db and indexes the code.
tokensave install registers the tool as an MCP server in the agent configuration - after that, the tokensave_* tools are available in Claude Code.
After external changes, especially after a git pull: tokensave sync. Otherwise the graph works off a stale state.
tokensave upgrade fetches new versions from GitHub.

Step 4 is the only one you really need to remember - more on why below.

Measured: the benchmark

Claimed savings are one thing; reproducible measurements are another. tokensave ships its own command for this: tokensave bench asks ten standard questions about the current project ("How is configuration loaded?", "How are errors defined and propagated?", …) and compares the token cost of the graph answer against the baseline, i.e. reading the relevant files.

The result in my website project: 94 percent mean savings - 53,900 tokens for the baseline versus 3,000 tokens across all ten questions, so roughly 5,000 to 6,000 tokens per question the classic way against about 300 via the graph. If you want it even more concrete: tokensave discover analyzes your own Claude Code history and shows which past navigation steps a graph query would have handled more cheaply.

What it delivers day to day

The savings aren't an estimate; they're right there in the built-in counter: over 12 million tokens across all my projects, growing daily. A pleasant side effect: answers to code questions arrive noticeably faster, because less context has to pass through the model - and they tend to be more precise, for exactly the "Lost in the Middle" reason above.

The prompt-caching nuance

An obvious objection: the API providers cache anyway. True - with prompt caching, an unchanged context prefix is stored, and cache reads cost only about a tenth of the normal input price. That softens the "paid anew on every request" from the token detour, but it doesn't replace tokensave, because the two levers work in different places: caching makes re-reading the same bloated context cheaper - and even a small change at the beginning invalidates the cache. tokensave keeps the context from getting bloated in the first place. One is a discount on a large bill; the other makes the bill small. In practice, you benefit from both at once.

Where it stumbles

The biggest pitfall is staleness. When the code changes outside your own session - the classic case being a git pull - the graph keeps working off the old state. To be fair: current versions detect commits since the last sync and warn explicitly in the status check ("1 commit since last sync"). But if you miss the warning, you still get quietly wrong answers until tokensave sync runs - and until then, you'll be hunting the bug in the wrong place.

Two smaller limitations on top of that: queries are capped per task, so complex questions have to be bundled instead of tried one at a time. And tokensave only answers questions about code structure - for web search, documentation, or anything beyond the repository, it naturally does nothing.

Local, but not network-free: the worldwide counter

The code graph, the search, the embeddings - all of that runs locally; no source code leaves the machine. Still, tokensave isn't entirely network-free, and that belongs in any honest review: by default, it reports the number of saved tokens to a public "worldwide counter". What gets transmitted is a single HTTP POST with one number (something like {"amount": 4823}); the country of origin is derived server-side from the IP - no code, no file names, no user ID. Add to that version checks against the GitHub releases API for upgrade.

Both are documented and can be turned off (tokensave disable-upload-counter). I've deliberately left the upload on - partly because the global counter is a nice argument for the tool itself: it currently stands at around 17.6 billion tokens saved across all users worldwide.

My experience

A tool that writes itself into the agent configuration and reads along with every code question doesn't get the benefit of the doubt from me. So before putting it into production use, I looked at the repo metadata, the commit history, and its runtime behavior - the result was an actively maintained open-source project whose network behavior matches exactly what the documentation states: the counter upload, the version checks, nothing else.

Since then, exactly what you'd hope for from a tool like this has happened: nothing. No incident, no surprise - just a counter that keeps growing and code questions that get answered faster. By now, tokensave is the first tool I reach for when researching code in any of my projects.

Verdict

tokensave is no miracle cure, but a well-thought-out specialist tool: it does one thing - answering code questions without full-text reads - and it does that measurably well, in my case with 94 percent savings in the reproducible benchmark and over 12 million tokens saved in daily use. The limits are known and manageable: the graph only sees static structure, it wants a sync after external changes, and anyone who insists on complete network abstinence turns off the counter upload. If you regularly work with AI assistants in larger codebases, it's worth a look. Just that tokensave sync after a git pull - that one you really need to remember.

Sources

tokensave on GitHub: github.com/aovestdipaperino/tokensave - source code, license, worldwide-counter documentation, and commit history
Liu et al. (2023): Lost in the Middle: How Language Models Use Long Contexts - study on retrieval accuracy in long contexts
Anthropic: Prompt caching documentation - how prefix caching works and how it's priced