I'm also out of the loop, but from my reading, I guess some people didn't like Tim Peters and his positions on some culture war stuff, and didn't like that people were generally focusing on his positive contributions to the project right after his death, rather than his views on race or whatever.
Oh, that's even weirder. So the drama was that people were saying nice things about somebody who had just passed?
Then I'm more confused than before about why the original commenter on this branch would suggest this security feature release is a "diversion". A diversion from what? The fact that people weren't talking about something?
The problem is that you didn't even attempt to build a proper box (a sandbox that prevents the AI from running bad stuff by design). It's an extraordinarily hard problem. Only OpenAI Codex is actually trying to do it, and they suck at it too. They keep breaking permissions, their own AI can't troubleshoot it, their defaults give read to the whole filesystem (go ahead, slurp my ssh keys), and their "manual approval" escape does not seem to work.
I agree actually. We built an open source agent-agnostic sandbox that we are landing improvements to, much more to come: https://github.com/anthropics/sandbox-runtime. That said the sandbox is not perfect, and any sandbox needs holes punched otherwise it is not useful in practice (at least for inference and MCPs, and almost certainly more). We will be doing much more in this area.
That’s good to hear, it’s a much better approach than expecting humans to read commands and approve them or just trust that the LLM can set the proper horizons for its world itself while working.
Making a sandbox both fully secure and fully useful are contradictory requirements. If you want the agent to do any real work, you have to leave gaps.
With SOTA agents that’s a real bind, because they’re very likely to find those gaps. Whether they exploit them, close them, or leave them alone then becomes a prompting challenge yet again.
I don't think this means don't sandbox at all. You can prevent a lot of small and medium accidents by locking down or gating access to hidden files, ssh, sudo, etc.
Right! That was the standard view until fairly recently. But I'm pointing out something else.
This year we've learned that If a SOTA LLM decides that the sandbox is standing between it and its current objective: well, it has the ability, the time, and literally nothing better to do all day. Odds are, if you've configured the sandbox for anything useful, you've also provided a crack it can use to get out.
Again, doesn't make a sandbox entirely useless. Does mean you can't just put it in a really tight box and call the job done. If anything, the strict sandbox might even hurt, because it's more likely to get in the way.
(By analogy: consider the safety issues posed by a dam without a spillway.)
This is much more of a problem if you're attempting to run at a massive scale, beyond what humans can audit. When I'm doing "artisanal" agentic programming, I'm still in the loop in the sense that I'm watching what it's doing and ready to hit Esc if it is doing something dumb. If the AI trips over the sandbox, I can cancel it and do whatever it wants me to do before it starts trying to engineer its way around.
One might imagine the replacement of carbon arc lamps by Laser Excited Phosphor (LEP) bulbs as used in some car headlights or some odd enthusiast flashlights. Or perhaps just a bunch of LEDs.
I'm reminded of the poor human moderator of that German wiki that OpenAI agents hijacked as a message board, who spent hours reverting edits and removing slop pages created by the AI.
IMO it's just like using an anti-spam filter in your email. An AI agent should never decide "Yes, this is awesome" but it surely can decide "No, this is obvious trash". Sometimes the simplest rules are best - "Did they follow the PR template? No? Ok, auto-close with a message saying that AI submissions are not allowed"
There are a number of reasons that you might not want to build your inference stack on a Chinese origin model even if you're running it entirely in house.
For one, you might not trust that the weights do not contain ideological biases (e.g. ask DeepSeek about tibet) or that the methods used to impose these biases may not have contaminated the model in some other way.
For another, you might not trust that the code the model generates won't be backdoored or attempt to leak information through your sandboxes.
For a third, you may not want to build your stack on a partner who you feel is a supply chain risk, who might become unaligned with your interests.
By far the biggest though, is that many industries will be forbidden from doing so by the government in an attempt to protect the US model industry (and thus create the demand for some model like this one).
I'm always excited to see new entrants to this open-models race, no matter why they're running.
There are zero reasons to have any less concerns about ideological biases, side effects of the mechanisms used to implement ideological biases, or code backdoors in a US model, and a supplier of open (as opposed to hosted) model weights is not an active ongoing partner with whom the idea of supply chain risk from possible future divergence of interests is coherent, so that concern is either invalid or, if the “partner” is the model itself, simply a restatement of the ideological bias in the model weights concerns which, again, is not diminished by the model having a US origin.
And your speculation about future protectionist regulation is just that, not an actual fact.
>There are zero reasons to have any less concerns about ideological biases, side effects of the mechanisms used to implement ideological biases, or code backdoors in a US model
If you are a US based critical infrastructure provider, I'd argue that you have already accepted a baked-in threat of ideological misalignment from the US, but you have not accepted it from farther away countries like China.
>a supplier of open (as opposed to hosted) model weights is not an active ongoing partner with whom the idea of supply chain risk from possible future divergence of interests is coherent
I disagree. Models are improving so quickly that you'd probably not want to freeze yourself on an older model forever. You likely want to continue to upgrade models. The best way to do this is to build a sufficiently powerful and representative benchmark that you can confidently move to _any_ model, but you might expect that future models from the same providers that you accepted before will show less divergence than totally new providers. Similarly, if you build your inference around one of their custom tools (e.g. DeepInfer rather than vLLM), you might find substantial switching costs in moving away to another provider.
>And your speculation about future protectionist regulation is just that, not an actual fact.
It's not a done deal for sure, but you can already see a lot of signs of this in recent actions from the government. I can tell you based on personal experience that some customers will automatically rule out any Chinese models.
I think the only point being is that if you see US as homogeneous and you are from the US then it’s okay to use an US model because it’s values will be signed with yours. But that is pretty weak anyway.
> For another, you might not trust that the code the model generates won't be backdoored or attempt to leak information through your sandboxes.
I don't disagree with you on the severity of the concerns, but given the vast amounts of code that must have been generated in the past six months by the likes of GLM5.2, GLM5.3, deepseek v4 flash 0731 and newer, qwen 3.5-122, 3.6 and 3.8 series models, I would like to see any concrete examples of it building backdoors/intentional vulnerabilities/phone-home-to-china or similar unprompted. If it's been doing this and anyone with even a modicum of a clue has been watching it, surely someone has caught a model doing this? At least once?
Surely a model doing something like writing intentionally obfuscated code that obscures its actual purpose from a code reviewer, in the service of something malicious/backdoor-like, would have been seen and noticed by now.
Can this be made to work offline, without a cloud server? I wouldn't want my words to be passed through an API, but run locally on device. I don't mind buying fast GPUs for this.
When we launch, no, it will be cloud inference, but will be processed with encryption in hardware isolation and only retained and used for anonymized training with your consent. At some point in the future we may make models available for local inference though.
Then I'll purchase at some point in the future. Local processing is make or break for me, as this is the exact kind of data (idle mouth movements) that feels the most prone to mining, and the most prone to accidentally leaking something important in. I hope you reconsider offline use before they ship; these are really exciting to me and I'd love to use them.
In my opinion, the core concept is simple: China is a big market that's getting wealthier and BYD makes cheap and innovative cars.
Owning a vehicle is going from a luxury for wealthy people in China to a more every-day thing, driving huge volumes. Meanwhile the rest of the world (US excluded for now) is trying to electrify personal transportation, and China is meeting that demand better than any other country.
Hah was wondering if someone else had read that announcement/ finding.
Coupled with this https://www.theatlantic.com/international/2026/10/chinese-co... (lots of dead companies being propped up artificially by the govt and not allowed to fail so people stay employed) the strategy of cornering every global export market until complete dominance seems to be very a much make it or break it approach here. So the US blocking one important industry with likely lots of subsidies does make more sense under that light.
That is a big part of what drove down the price of lab diamonds in the world. The China-domestic market bought a ton of them for engagements, then they stopped getting engaged after the real-estate crash, and now there is a supply glut.
reply