Anthropic Lists GPU Kernel Optimization Among Its Safety Measures — and the Internet Is Arguing

Anthropic has released new models, and what caught the attention of part of the community was not the benchmark table but a single line in the announcement. GPU kernel optimization appears there in the safety measures section, in the same row as biological threats and hacking. The author of the Telegram channel "Metaversishche i IIshche" retold this with understandable indignation. We rely on his retelling and his link to the announcement. The exact wording is worth reading in the primary source, not in someone's interpretation.

What exactly is being claimed

The main claim is this: if you ask the model to speed up computations on a graphics card, you won't see the familiar "sorry, I can't help with that." The model will answer, but, as described, it will do so worse than it is capable of. The author says this is not a filter on top of the answer but a result of training. That is why a classic jailbreak, which tricks a protective layer, is allegedly useless here: there is nothing to bypass, the skill is simply dulled.

The official explanation goes like this: it is dangerous to accelerate the development of AI itself. The more efficient the GPU code, the faster experiments and training proceed, including for those who build systems with no regard for safety.

Why this irritates practitioners

Kernels are not an exotic topic for research labs. Kernel work affects how many tokens per second you get on your own hardware. It determines whether a fresh local model fits into the memory of an old RTX 3090. For people who run LLMs themselves, this is an everyday tool, not a weapon.

The main problem is not the restriction itself but its form. You see a refusal immediately and go looking for another tool. A silently degraded answer looks like working code. You may spend a day debugging before you realize the model simply didn't try. A restriction that isn't disclosed at the moment of the answer undermines trust in everything else the model writes.

Safety or money

A version quickly appeared on social media that this is not about Skynet. If people optimize local models worse, they are more willing to pay for an API. Hardware is getting more expensive, data centers are buying up memory, and the argument looks plausible.

There is no evidence, and it's worth keeping that in mind. The safety version is also logical for a company that builds its reputation on caution. Choosing between these explanations is a matter of belief, not fact. What remains a fact is something else: the restriction stems from a vendor's decision, and the user cannot verify it.

What developers and product managers should do

• Check the wording in the announcement. Find out which tasks are meant: training frontier models or any work with kernels.
• Don't take code on faith. Profile and compare against a reference: timing measurements, throughput, correctness checks. This is necessary even without any restrictions, but now especially so.
• Compare models on your own task. Give the same kernel optimization prompt to several models, including open ones, and look at the difference in quality.
• Don't tie a critical pipeline to a single model. If low-level optimization is part of your product, keep a fallback.

The main takeaway is broader than a single release. Vendors increasingly tune models not only for what they refuse to do, but also for areas where they are deliberately weaker. For now this can only be suspected, not measured. That is why your own benchmarks on your own tasks are turning from a nice extra into a mandatory part of the work.