wren6991

It's all above board though, as you, the user, agreed to the terms & conditions for installing said app.

I have an LG TV, about 6 years old now. For a while it was connected to the internet. Every time I turned it on, after a ~20s delay, it would pop up asking me to install an update and I would press RIGHT + OK to select the "No" button because it worked fine and previous updates just made it slower, added ads etc.

Eventually, the remote dropped the button press for RIGHT, and just got the OK. Or maybe I just pressed the buttons too fast -- the interface is laggy and I'd developed muscle memory. This started the software update with no way to cancel from the UI. Once it updated, it made me accept a new EULA just to continue using the TV in the way I already used it (which was mostly as an HDMI display). There was no way to even get to the settings dialog to perform a factory reset without accepting the EULA. The device was held hostage until I said "Accept."

This is the level of consent implied by accepting the EULA on a TV: none. It's bullshit. Computers should never have been put in TVs, and a smart TV should never be connected to the internet.

I'm not sure about the proprietary inference engines, but in the open source ones tokenization is done before looking up if a text sequence is present in the KV-cache

Is this necessary? Tokenisation is deterministic, so for a hit/miss check you can lookup on (a hash of) the source text instead of the tokens. You only need the tokens once you're seeking for the exact token index having determined there is a hit. That means tokenisation can proceed in parallel with your cache query, and since these caches are distributed in production systems I imagine the query itself could be slow.

I'm not trying to undermine the utility, and this is obviously excellent work. Being able to tokenise faster on the client also seems useful (precise token counts for context pruning heuristics, instead of `chars / 4`), and on a phone your work translates directly to energy savings. I'm just curious about the cache lookup point.

I like the explicit and imperative style of this prompt. Makes me feel like LLMs are just weird Turing machines and CoT is their tape.

Having watched Qwen kill its own llama-server instance to free up a port, I think this is a bold presumption and you should test it at your earliest convenience.

Title is editorialised. Here is one editorialised in the opposite direction, for balance: "OpenAI model breached HF, meanwhile OpenAI model safeguards refused to help HF's defense."

Author here. Just wanted to say: thank you for posting this. You've given me something to think about, and I regret writing this post the way that I did.

It felt unreasonable when I was using it at midnight and had to wait 10 minutes to refill the KV cache on my local GPU :-)

A simple solution here would be to evaluate the date once per session, or once each time the `opencode` binary is launched (to avoid old, long-running sessions getting stuck in the past).

Replying inline because this hit max depth:

You are confusing CPU-level security with filesystem-level security.

I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?

W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.

Here: https://en.wikipedia.org/wiki/W%5EX

This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.

The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.

This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.

I mean, ideally enforce W ^ X, and enforce stricter permissions on executables where the agent has flipped the W to X. My broader point is we should be using operating system primitives instead of regex and wishful thinking.

Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).

This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.

Yeah, this is one of the weaker parts of the post because I didn't really make my position clear: that sandboxing should be a first-class integral part of every harness, not an afterthought that risks putting something you care about on the same side of the trust boundary as the LLM.

Some of my own frustrations with bad Docker deployments leaked through. I did snip some of them out way back when I posted this, but maybe not enough.

Prefix caching is inherent in how global softmax attention works. Modifying the prefix invalidates the suffix because the suffix's cached KV projections are a function of the hidden state after the model has evaluated the prefix.

There have been some attempts to approximately stitch KV blocks without full re-evaluation (see: CacheBlend on arxiv), but the results aren't promising.

You mentioned HiCache: as far as I can tell this is a prefix tree cache that efficiently shares prefixes across related histories. If you change the prefix, everything after the change still misses the cache and needs to be prefilled again.

Yeah, I don't think that line quite landed. My point was that LLMs are inherently adversarial (read, "relentlessly proactive") and sandboxing should be a first-class integral feature of your harness, not an afterthought. The problem with dev containers is you still tend to end up with something you care about on the same side of the trust boundary as the LLM.

yes, and they could all be closed by the stale bot

If you don't know what OpenCode is, imagine a dark and stormy night.

Currently this is still just going to Moonshot, since they didn't release the weights yet (scheduled for 27th).

Is there any good reason to believe there is a lot of headroom or there is not?

It's hard to answer quantitatively, but for example Qwen3.5 -> 3.6 was a significant step in capability, arising from continued post-training of the same models. If we were at the end of low-parameter-count scaling then that would be a surprising datapoint.

Cryptography *2*? We're still over here trying to implement Cryptography 1 without side channels, and they went and invented a new one?

LLMs are hopelessly confused about which model they are. Ask DeepSeek V4 Flash which model it is, and it's 50/50 between "I am DeepSeek (深度求索)" and "I am part of the GPT-4 series developed by OpenAI." Ask Claude, it'll say Claude. Ask Claude in Chinese, it'll sometimes say DeepSeek.

It's incredibly funny, but I don't know whether it's related to distillation; it's probably quite rare for a distilled trace to mention which model it came from. (I'm not saying distillation doesn't happen, just that it's possibly unrelated.)

For your specific example, the internet is full of "As a large language model developed by OpenAI, I can't..." due to people pasting chatbot output without reading it. Seems reasonable for that to surface as part of the CoT for your question about model capabilities.

$230 for a macropad with an exposed PCB and no washers under the Allen screws.

I'm not sure what the joystick is for, and neither are they apparently: the only example they give is something that could just be a keybind.

The fact that RLVR rewards successful trajectories.

Notice I didn't use the word motivation, which you decided to use. The reason LLMs use a technique is simply because it works, and that comes straight from training (specifically RLVR post-training).

Crashing instead of raising an exception or bubbling a return code sounds like a legitimate bug ticket IMO.

One reason I'm in favour of handling capabilities in the OS is so we can stop having trivial symlink traversal and /.. traversal bugs in path filters (or indeed more complex bugs in the face of FS-specific linking primitives).

You're right to push back on this. The honest take is it's not a smoking gun -- that's a sharp critique.

It tends not to improve things. Besides the generally bland and muddied style, and the low-fidelity reinterpretation of your points, they also have a habit of randomly deleting sentences that didn't spark joy for them but were actually important.

I've found them useful to review docs for factual consistency and potential sources of confusion, but the correct workflow from that point is IMO to correct the draft yourself and then say "better now?"

Right, reasoning models are almost more notable for what they don't do, which is: try to generate the first token of the response from a single forward pass through the weights.

Non-reasoning models were still surprisingly good at generating working programs. I think it makes sense when you consider that it's still iterative; it doesn't have to generate the entire import block in a single pass, for example, more like decide at the end of each line whether there are more libraries it should import or whether to move on to the body of the program. It's less surprising that a single forward pass is able to make that type of decision IMO.

Taking Python as an example, you see LLMs use a lot of scoped imports and I think this is partly because it makes the output more resilient against failure to think forward at the start. Even a reasoning model will write out (the first iteration of) an entire file in one tool call, so once it starts generating it still has to keep going until it finishes, no pausing for breath.

Also it's interesting that non-reasoning models can still do quite well in a harness that lets them test and fix up their code. Like you said, it gives them the ability to iterate.

...by inferring both the imports and the script body from the same context? I think you're suggesting there's some kind of information flow from the anticipated body of the script back up to the imports, but I don't see why that would be necessary. Infer imports from context, infer body from context + imports. All strictly causal.

I think you hit the nail on the head here. Having subagent dispatch in the loop for RLVR is something we've already seen in open models, like Kimi K2.5 and later, so it's no great stretch to assume OpenAI are doing it too.

If you keep RL'ing the dispatch then the prompts are likely to keep diverging from the type of prompt a person would write (like CoT becoming increasingly incomprehensible), and that divergence is part of their competitive advantage.

rather a latent space representation of the conversation

Student/teacher models derived from the same checkpoint convey a lot of latent information through token choice, as in: https://techxplore.com/news/2026-04-ai-chatbot-student-owls....

I wonder if this is something they can take advantage of by training on compaction inside of the RLVR loop?

What effects provide beyond DI is entirely in their ability to abort (resume zero times) or (in the case of multi-shot effects) resume multiple times

Thanks, this answers my question and does sound handy. Also I do see the value in having more problem-shaped versions of a general construct.

Generally excessively verbose and failing to account for LLM failure modes. Example: when dispatching a subagent with an instruction prompt, I see the agent refer to "phase 5 of the plan" without actually pointing to the plan file it's referencing. The subagent says something to the tune of "phase 5, sure thing boss" and goes and generates garbage because it never reads the plan to find out what "phase 5" entails.

If I ask an agent to maintain agent-facing docs like AGENTS.md then similarly it ends up with low information density and not really saying what I want it to say. Something I thought was unequivocal ends up leaving the agent with far too much scope for interpretation and judgement calls.

Perhaps I'm just Prompting It Wrong (TM) but I do find LLMs lack the theory of mind to realise that other LLM instances don't know the things that the current instance knows, and make poor calls on what to include and what not to include. It's a bit hand-wavey, but I was wondering if the same issue might transfer to language design.