kgeist

>This misses the point: AIs will get better and better, and containment will be harder and harder.

Containment is hard when you give an AI agent access to a whole VM with a huge attack surface.

And it's pretty trivial when you give it only a small whitelist of manually curated/reviewed/tested primitives.

I remember our infosec person instructing us to verify we don't use log4j in our system written in PHP. Well, we didn't :)

I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?

It says 46 tok/sec for Qwen3.6-27b 4 bit on RTX5090, but I get 60-70 tok/sec on a small context like that (5 bit weights with 8 bit KV cache), although it does slow down to 40 tok/sec on large contexts. If I add ngram speculation, then it can increase to 100+ tok/sec on code.

There are many knobs to tweak to make it faster, which the site ignores.

>they'd be gambling that NATO doesn't launch things into Russia

The official discourse in Russia is that NATO is already helping Ukraine launch things into Russia. So there's no gamble; for them, it's already a fact. Except, currently, it's just a proxy war where Ukraine has to jump through hoops to get military aid and targets approved, and it can only fire from Ukraine's territory. With a direct confrontation, there's no doubt that far more would be launched into Russia.

How would a direct war with NATO on several fronts help Russia win in Ukraine? Russia isn't ready for it in the slightest. As I said, if they wanted to go all in (full mobilization instead of partial, martial law, converting all industry to military production, etc.), it would be more logical to focus first on that 1 country they want to defeat, rather than immediately triggering Article 5 and fighting 32 countries at once. It just doesn't make any sense, and judging by the Kremlin's decisions over the last 4 years, I don't think they're that stupid.

Attacking a NATO country would mean total war for Russia. Currently there are no signs that Russia is ready for total war, or willing to have one. Russia has been fighting a war of attrition in Ukraine for 4 years, without a moving frontline, exactly because it wants to win by slow attrition.

Total war (all money going to the war, millions of mobilized workers, etc.) would result in an economic collapse, which Russia is trying to avoid. Aside from "inconveniences" like Yandex AI not working after a data center hit, Russia's everyday life is largely unaffected by the war (at least compared to Ukraine's) - exactly because it is avoiding total war.

If Russia were desperate enough to finally go all in and have full mobilization (millions of conscripts, all industry working around the clock building nothing but drones and missiles, etc.), why would it start by attacking random EU countries instead of Ukraine itself? So I think it's very unlikely that anything is going to happen to Europe other than sabotage here and there. Remember that Putin is a KGB agent, and they're more about targeted tactical operations than strategic chess play.

The whole "special military operation" thing was itself just a way to quickly coerce Zelensky into signing an agreement by threatening force, without total war, but it fell apart, so they had to go this war-of-attrition route

A very naive take from someone who clearly lives in a place where people have real choices, economic freedom, freedom of movement, and a government that protects them. "Just shut it down, bro" risks destroying your livelihood and leaving your family financially stranded, and yourself incarcerated or sent to the war zone. And it's not like Yandex develops weapons of mass destruction, you probably assume it's a collaboration even if Yandex simply hosts the Defense Ministry's websites. No sane parent will put their family at risk for this kind of stuff. "I'm going against the government for abstract ethical reasons" is something very few people/countries can afford.

And you can't shut it down anyway. The government will just nationalize it and keep it running. As long as you're the one in charge, you can at least throw a few hidden obstacles in the way, like dragging out legal processes.

AI models can multitask/use parallel subagents just fine; the issue is with harnesses that don't make it a priority via the default system prompt.

I run an LLM server with Qwen 3.6 in the office, and OpenCode, which the OP mentioned, usually defaults to sequential TODO lists, and it works fine with our little LLM server with 3-4 parallel users. But I noticed that once in a while the LLM got overloaded with requests in the queue, and you couldn't do anything for 20-30 minutes. My investigation led me to an employee who used QwenCode. I tried it myself then, and indeed, it immediately launched something like 6 parallel subagents, where OpenCode would have sequential TODOs with the same model by default.

So in the end, I had to detect QwenCode on the server side and serialize all its parallel requests into a single request queue, because it made life miserable for other OpenCode users :)

Their management decisions are strange, right. They had a nice tool called Upsource, we used it for code reviews. Then they sunset it and told us to use JetBrains Space instead. After we migrated to JetBrains Space, they said, oh wait, we sunset it too. So we had to migrate to GitLab. And now, with AI-assisted coding, I don't even need their IDE anymore, because I mostly look at diffs. And that kinda brings us back to Upsource. That thing could have been grown to support AI-assisted development, like, get rid of all the heavy IDE stuff, and just have a place for code reviewing agents' output and merging things. Somewhat like GitLab Lite but fully agentic-oriented. I think it would have covered 99% of our use cases.

I heard rumors JetBrains started going downhill around 2022-2023 because they severed ties with employees in Russia's St. Petersburg, which housed their R&D and all (although many employees were relocated but who knows).

I do look at the code and have to correct Claude most of the time, but I've noticed that with AI-assisted coding, I mostly look at the diffs when i'm inside IntelliJ. I don't need a pricey full-fledged IDE to just look at files and their diffs.

Wikipedia says: "in the United States, infections occasionally occur in rural areas, where the bacteria are believed to circulate among rodents." A few years ago a boy in Russia contracted the plague after interacting with a wild marmot, he was treated successfully without any problems. I think this news is overblown, because everyone immediately pictures 14th century Europe

It's not clear if she even died from plague. The Russian-language version of the article lists various "versions" of what happened, and her breaking a test tube is only listed as one of the versions. Sounds like random rumors but at the same time, you can't trust the government either (which says no one has tested for plague positively). What's clear is that an employee at an "anti-plague' institute suddenly died from pneumonia-like symptoms, which certainly sounds suspicious but interpreting it as evidence of a plague infection may also be an overreaction

Well, I have experience writing and deploying LLM inference engines, and seeing how the whole thing easily collapses when something goes slightly wrong doesn't instill confidence either that you can just hook it up to arbitrary tools and then expect it not to do random silly stuff ("emergent behavior," heh).

It's not only about some ML theory about RL or AI safety; just silly numerical bugs, caching bugs, etc. in the inference layer can already make it do unexpected "unaligned" things, and the whole thing is just hacks upon hacks to make a silly text autocomplete look somewhat semi-intelligent. Most "post-trained" models are pretty much as useless as base models without harnesses that do the heavy lifting. Have an extra space in the chat template and intelligence goes to zero - here's your "AI" :)

Of course, they learn to generate "tool calls" to achieve "goals" instead of random prose, but at the end of the day, it's still a text autocomplete engine masquerading as an AI. In the happy path, on a known task, the text generator generates a sequence of "tool calls" you expect it to generate, but move off the happy path slightly and all bets are off, there's a non-zero chance it will do something totally random you never expect, because at that point it just throws random stuff at the wall until it succeeds, thanks to brute force with pre-learned heuristics masquerading as intelligence (which is especially the case with "agent swarms," as in the HuggingFace incident).

"Emergent behavior" in this case really is, imho, "we didn't think through all the edge cases carefully enough". You know, a non-AI system can also accidentally wipe out all data or do some other real harm (see the Knight Capital's stock exchange bug) simply because the developers didn't catch the edge cases earlier, and no one calls that emergent behavior. It's just a buggy system.

"AI" systems can do greater harm because they are usually run in loops until they finish, and they are given "tools". A non-AI system could technically accomplish the same too, via sheer brute force/fuzzing, the advantage of LLMs is that they can take shortcuts and do it much faster, thanks to certain things already being in the training data, a sort of brute force with statistics-based heuristics.

LLMs at the core are just text autocomplete engines, and they literally have randomization applied during token selection to make outputs "more creative" so that models search for more unexpected solutions by trial and error (temperature > 0). Not to mention compression is lossy as well. So it's understandable from the start that the outputs of an LLM cannot be 100% stable and guaranteed. With this in mind, if a researcher takes this obviously unpredictable system and gives it tools without a well-thought sandbox, I don't see any difference in principle, from a developer writing "if rand() == 13 { launch_nukes() } If someone wrote such a function, and it did launch nukes, no one would argue that the rand function is dangerous and will kill us all. The fault is in the author of the code who attaches dangerous tools to an obviously unstable/unpredictable system, doesn't think it through, and then cries "rand will kill us all" when something goes awry fully removing all responsibility from himself. It's not "AI" doing harm but people at OpenAI and Anthropic with their irresponsible behavior.

This seems to be a thin wrapper around libllama, what's the point? Llama.cpp already ships a web server. I don't see anything in the README that llama.cpp doesn't already support.

>Do we have to reinvent MMUs for LLMs

MMUs are already emulated in engines like vLLM (paged attention).

>This allows the model to learn what is most important to maintain in context

DeepSeek's Lightning Fast Indexer already does something similar, although without context compaction. It identifies which tokens are most important to attend to, which allows the model to skip irrelevant ones. A similar idea could be used to remove unnecessary tokens from the context altogether, while somehow strengthening the representation of the important ones (increasing their attention weight, merging information from discarded tokens into them, or creating compressed summary representations)

That's the problem with etching a model onto a chip: by the time you've designed the chip, manufactured it, tested it, shipped it, and deployed it, the model will be hopelessly outdated (with the current improvement rates). And when you want to update, you have to buy new chips instead of just uploading a new model file like now. When Taalas announced their chip, the model was already 1.5 years old (stone age by current standards). It's their first chip, so maybe they can streamline it, but the problem of having to update hardware every few months to keep up with the industry is not going anywhere.

>wine

It could be an original Proto-Indoeuropean word as well, because Greek has ὑιήν "grapewine" (< *wih₁-ēn), which follows PIE ablaut (weyh₁-ō ~ wih₁-ēn), which doesn't usually happen if it's just a borrowing of a foreign word. And the same root is found in Latin vitis "vine", Russian vit'sa "to twist (often about vines)" etc.

>Words borrowed from a Pre–Indo-European language into Mediterranean languages

> [...] Greek μύρμηξ mýrmēx ‘ant’, Latin formica

Must be an error:

  Proto-Celtic *morwos
  Proto-Balto-Slavic: *marwis
  Proto-Indo-Iranian: *marwiš
  Proto-Germanic: *mauraz
  Old Armenian: mrǰimn

Greek murmēx could be an assimilation murw- => murm-, and Latin had dissimilation morm- => form- (although not clear what came first, maybe morm- was the original and morw- came later). Sanskrit also has vamra "ant", which makes it look like the whole thing is a tabooistic distortion of *wr̥mis "worm".

In any way, it doesn't look like it must be borrowed. Historically, some words once labeled Pre-Indoeuropean turned out to have pretty mundane PIE origins.

I have a similar approach where I optimize kernels and find numerical differences between the CPU oracle and CUDA kernels using an automated AI agent in a feedback loop. Usually it solves numerical problems easily (it compares outputs of every layer and finds where they diverge), but so far no matter how many different SOTA models I throw at it, and even show it reference code from other inference engines, they aren't able to much the speed (my engine has a modification which is not found in reference code, although a lot of stuff is similar). Either I'm doing something wrong, or z.ai's Infra Agent is actually an agent swarm, i.e. a bruteforce with heuristics. My project is 2 weeks old so maybe I just need more time.

Judging by the leaks, OpenAI and Anthropic already train reasoning traces to use fewer tokens (they deliberately omit articles and prepositions, use very short sentences, etc.), even though you pay per token. So it wouldn't make sense to do that if the only incentive was "make them pay for as many tokens as possible per task."

It's more subtle than that. If a user has to wait longer for a solution/pay more, they'll be less satisfied and may switch to a competitor. More unnecessary tokens also means more unnecessary compute. Longer sessions are increasingly more expensive to serve than shorter sessions.

And there's always the Jevons effect: as a resource becomes cheaper, demand often increases, and so does net resource consumption.

So, imho, frontier labs have every incentive to reduce token usage per task (while also making you use AI for more and more tasks in your daily life)

The technique looked dubious from the start, because LLMs were trained to expect certain outputs from common bash tools. If the output is not what it expects, an LLM may issue more tool calls than before, because it will assume the tool is broken, the arguments passed to it were wrong, or it's a newer/older version of the tool etc => more tokens. Sounds like just adding to the prompt to use `grep` and `tail` extensively will do the trick without any special tooling.

>What stops them <..> simply use cheaper model for every Nth request.

That would trigger a full prefill (context recompute) every Nth request because cached tokens aren't interchangeable between models, and that would require way more compute than just staying on Astra.

To avoid full recompute, you could prefill a cheaper model's context incrementally by always feeding it Astra's outputs in the background (and vice versa), but then that would require 1.5-2 more VRAM for each session + the complexity of keeping them in sync.

If the rumors are true that Astra is a looped transformer, a more practical approach would be to dynamically adjust the loop count during peak hours.

The web UI's system prompt is also probably in Chinese

They mention it here: https://github.com/argonautlabsai/deltafin/blob/main/k3-publ...

>device bytes read during the prefill window, all four drives (arm csv) 8,977 GB at 24.1 GB/s aggregate

I.e. low memory bandwidth.

There's a tendency to cite only decode speeds, but in practice, an LLM generates far fewer tokens than it has to read (unless you ask general knowledge questions). So the effective performance is much slower than the decode rate suggests, because a 512-token prompt already takes 6 minutes to load

Do those reports require Kimi K3 though? Qwen3.6+ could probably do the same in a few seconds with similar quality.

On their Agentic Index, GPT-6 Astra (both max/xhigh) has the same result as Qwen3.8-27b. Weird.