I'd suggest to use ssh keys inside the secure enclave on macOS that require your fingerprint for every new session [0]. That way agents cannot initiate anything, and you will always be aware when a new ssh connection is being made.
Reading these comments I'm also curious about this.
I'm currently using some custom bwrap scripts (like [1]) to isolate projects with their own vscode /w claude extension
The desktop app I wonder if is worse because your web chat is accessible. In my bwrap sandbox, obviously some claude auth token is approved for using claude code, which I could be wrong but assume is limited and can't reach into web session history.
> Try to keep context shoved in a conversation thread under a token limit to save tokens.
For big tasks/features, I'm always creating a new git worktree and I'm using a "status repo" skill that creates a sibling status git repository where everything is recorded.
It works quite well whenever I have to revisit something. It's quite token hungry but I have the full trace of what happened in the past.
Another approach I want to explore is using https://github.com/netdata/netdata (disclaimer, I work at Netdata) to send all OTel logs/traces of LLMs to it. The idea is to replace the status repo skill with something that will allow LLMs to retrieve the history of a given task/feature. It will probably require some "checkpointing" to make this more efficient.
But man will people harp on an io-uring or KSMBd cve for years, decades. Even if no one suffers any consequences, the sense of wrongness, the zeal flew feel when we can point the finger: it's overpoweringly strong!
You can be right in the time that something isn't quite ready. But generally these people don't ever stop their flamethrowering. Years latter, and there is still the same incindearies being thrown about. Even after things have proven great, even as they are massively expanding capabilities.
Don't let conservatism into your heart, don't position yourself against progress. Have some willingness to allow things forwards. Thank you Yegge for Notes from the Mystery Machine Bus for helping impress this lesson on me long ago. Eventually the progressive types, if they aren't too encumbered by others, will usually find their will! The anti-willing though will steal as much oxygen as they can, the whole time. https://gist.github.com/cornchz/3313150
Here's a JS bookmarklet I use to apply dark mode to any website. It tries to preserve colors and avoids inverting graphics. Add a new bookmark to your toolbar and paste in that JS in place of the link. I hope you find it useful!
This is the sort of skill which is worth building specifically for your corporate style and under your sales team's guidance.
I have one[1] for my demos, which uses computer use + ffmpeg used the way I like it to be.
Whenever my team goes out to a conference or other sales event, they carry with them a "booth" package [2] made out of the demos. The companies and use-cases are pulled the weekend before.
I should do a write-up but my Claude Code and Pi have been personalised to assume the persona of Jean-Luc Picard for almost a year. I find the output generated to be more useful and of a higher "quality".
I also enjoy the occasional salted phrase that is included in generated out e.g. "Tea, Earl Grey, hot!", when I have been Claude'ing too much.
Here is a gist of my Claude.md file if anyone is interested:
Here's what Abliterated GLM 5.3 says. I asked it not to say anything that would explicitly list a weakness, and I stress that every issue it found within the time I spent looking was non-exploitable. That doesn't mean that further analysis wouldn't have found anything. As an FYI, in case you think I shouldn't paste this: anyone with access to this model could reproduce all the findings in a couple of hours. And also, GLM 5.3 is wrong sometimes.
If you don't have a check in function A, but multiple functions away in the stack there is a check, I guess that could be a compiler-enforced thing. But it doesn't feel like one to me. Maybe compilers have just gotten better since I wrote C++/C code, and now that sort of pattern can be enforced.
I’d like to take a moment to appreciate how horrible (but crafty) this patch is. Calls to setTimeout globally are patched to check to for this code before being honoured or discarded.
There’s something reassuring about seeing the true hacker spirit still at work here.
Claude Code's (CC) status summaries used 16.4% of our token spend in a week! We have investigated a source of overhead in CC: it's an agent_summary query that calls your current session/subagent model approximately every 30 seconds for a few words in CC’s status line.
Our DRIM system flagged the anomaly in CC's OTEL traces. Grouping requests by query_source showed that over one measured week agent_summary accounted for: 16.4% of total estimated spend (versus 15.7% for the main conversation), and 19.7% of all API requests with approximately 9,000 input tokens per output token.
Most requests reuse the prompt cache, but repeatedly reading a large cached transcript still has a cost. Longer contexts and more concurrent agents increase the overhead.
We couldn’t find a supported setting that disables only these summaries while preserving background agents and forks. Disabling those capabilities also stops the summaries, but changes the workflow we want to keep.
Our workaround is a small Bun preload that intercepts the summary timer without modifying the CC binary. It identifies the timer callback by source-text anchors and leaves other timers alone.
In controlled tests on Linux (from ver 2.1.257 to 2.1.312), the same workload produced five summary calls without the hook and zero with suppression enabled. On our current production setup, agent_summary calls remained at zero with the hook enabled. Background agents and forks continued running. The only visible change was that their generated status summaries stopped updating.
The workaround depends on implementation details. An update can break the callback matching and silently restore the requests. macOS and Windows are untested. If someone could help us with testing there, it would be much appreciated.
That seems like an overly negative caricature of Google’s corporate culture, and unlikely to be the case here, given the stakes and enormous investments in AI.
It’s more likely what the grandparent was saying, I’m reminded of Steve Yegge’s rant from 15 years ago and it seems like not a lot has changed.
Yes. All you need is a formal grammar that defines the syntax of the text being generated. The llama.cpp repo has a decent writeup on the way that grammar-constrained decoding works in general [0], and it includes a bit of a simplistic example for generating syntactically-correct C code [1]. No reason this couldn't be extended to other things -- I personally have run experiments with generating syntactically-correct SQL statements when doing text-to-sql [2], and I think it's pretty cool.
An “image ladder” is the same image resampled at several widths. It’s not a standard term; MDN calls the technique “resolution switching”.
A srcset lists those versions, and the browser picks the one that fits the current viewport and screen density. https://responsiveimages.org/ has details.
I like the idea of VictorTaelin's UniiChat [1] which summarizes every message into a single line and on top of that a binary tree of lines combined from lower levels. The context is then a view of that tree with more detail in recent messages and less detail in historical messages, plus a `zoom` tool that enables the agent to navigate the tree and read messages.
There was some discussion about this in the Goose discord a few days ago.
One idea that came up was this: you could define a particuda function name as the "landing pad" for handling particular error kinds. Then you "wrap" calls to the library in a function with this name. Here's a part from a larger worked example:
I've been iterating on this writing clarity prompt. The term we came up with was "Asyndetic parataxis with referential ellipsis and repeated rhetorical closure." It doesn't fully describe the exact issue I have with modern AI writing, but it's close.
The Qwen3.8-Flash-Next model is ok for reverse engineering. It can definitely solve simple tasks, but it gets easily confused, and burns tokens like crazy.
(As an aside: I think representing tools for AI as virtual SQL tables is much better than traditional MCP servers, and that this approach deserves a lot more attention. Props to Elias Bachaalany for thinking out of the box and putting it together).
The results of the benchmark are below. It's sorted by cost, but I added notes about each AI model for myself. The notes try to talk about intelligence, speed, and cost. Intelligence is a subjective measure which I assign to each model by reading its thinking tokens and watching its tool calls. You can definitely tell which models are more intelligent, even on this small benchmarks, by their tool use, false starts, and how easily they fall for the simple misdirection in the crackme.
+----------------------------------+--------------------------------------------------------------------------------+-----------------+-----------------+-----------------+
| Model / route | Experience / outcome | Total tokens | Output tokens | Cost |
+----------------------------------+--------------------------------------------------------------------------------+-----------------+-----------------+-----------------+
| Xiaomi MiMo v2.6 Flash | Incredibly fast and intelligent; solved. | 225,291 | 3,281 | $0.005 (0.5c) |
| GLM 5.3 Flash / OpenRouter | Least intelligent group but cheapest; solved. | 340,006 | 11,205 | $0.01 |
| ChatGPT Luna Latest | Very fast, concise, token-efficient, intelligent, and cheap; solved. | 401,837 | 5,119 | $0.01 |
| Qwen 3.8 Flash | Initially confused and failed, then eventually solved. | ~418,000 | 16,676 | $0.02 |
| Qwen 3.8 27B | Fast; one wrong answer, then quickly self-corrected. | ~774,784 | 12,658 | $0.02 |
| DeepSeek Flash / direct API | Fast, cheap, and accurate; solved. | 369,334 | 9,089 | $0.03 |
| DeepSeek Flash / OpenRouter | Fast and intelligent; solved in 76 seconds. | 371,689 | 13,888 | $0.03 |
| Claude Haiku 5.5 | Fast and surprisingly intelligent, but overly thorough and token-heavy. | 662,346 | 26,244 | $0.03 |
| Thinking Machines Inkling | Low intelligence; good speed and relatively token-efficient; may loop. | N/A | N/A | $0.03 |
| Xiaomi MiMo v2.6 Pro | Overthought the task and wandered into tangents. | ~420,644 | 13,638 | $0.05 |
| GLM 5.3 / OpenRouter | Cheap and intelligent but behind DeepSeek; solved in about 2m 20s. | ~702,473* | 11,879 | $0.08 |
| GPT Sol Latest (Sol 6.1) | Slow, but highly intelligent and extremely token-efficient; solved in ~89s. | 294,957 | 1,406 | $0.15 |
| MiniMax M3 | Least intelligent comparison; many wrong turns and repeated small mistakes. | 4,546,552* | 116,804 | $0.20 |
| GPT Terra Latest | Very fast, very smart, and token-efficient; solved. | 229,888 | 2,342 | $0.20 |
| Mistral Large 4.0 | Medium speed; small mistakes but reached the solution. | 303,687 | 4,041 | $0.21 |
| Kimi K2.7 Code | Less intelligent, slow, expensive; not worth using. | 100,740 | 8,938 | $0.22 |
| Claude Opus 5.5 | Highest intelligence and token efficiency; pretty fast; cheaper than Sonnet. | 312,837 | 1,862 | $0.24 |
| Qwen 3.8 Max 0902 | Fast and intelligent, better than Kimi K3, but token-hungry. | 1,305,241 | 26,390 | $0.25 |
| Kimi K3 / OpenRouter | Faster and cheaper than direct K3, but still very expensive. | 750,064 | 5,922 | ~$0.32 |
| Meta Muse Spark Open | Intelligent and medium speed, but among the more expensive runs. | 872,850 | 10,284 | $0.35 |
| Gemini 4 Argon | Extremely fast and intelligent; strong value for capability. | 384,046 | 2,870 | $0.35 |
| Grok 4.7 | Very fast and intelligent, but expensive. | 655,648 | 4,217 | $0.46 |
| Meta Muse Glimmer 30B | Fast but low intelligence and token-inefficient; cancelled unsolved. | N/A | N/A | ~$0.50 wasted |
| Claude Sonnet 5.5 | Smart and fast but very token-inefficient and expensive. | 1,243,285* | 20,381 | $0.57 |
| Kimi K3 / direct API | Intelligent but not notable; extremely slow and far too expensive. | 205,710 | 3,215 | $0.72 |
| ChatGPT Astra Latest | Medium speed, token-efficient, highly intelligent; cost similar to Fable. | 278,603 | 1,536 | $0.83 |
| Claude Fable 5.1 | OK speed, very expensive, medium token efficiency; solved in ~53s. | 397,806* | 2,857 | $0.85 |
| Gemini Flash | Refused the reverse-engineering task. | N/A | N/A | Not reported |
| Thinking Machines Inkling Small | Got stuck immediately and was terminated. | N/A | N/A | Not reported |
+----------------------------------+--------------------------------------------------------------------------------+-----------------+-----------------+-----------------+
```
The latest Deepseek-Flash model was the most impressive of the open models. Intelligent, fast, cheap. What more do you want? I think the Xiaomi MiMo - Flash model did well, but it might be a fluke, given how poorly the Xiaomi MiMo Pro model performed (it wandered off on a million side quests).
What's also interesting is how competitive Luna is to the lower end Chinese models. It's quite a bit more intelligent, burns a lot less tokens, is plenty fast and very cheap. After doing this experiment, I don't think it's a foregone conclusion that the American AI labs will be having the bottom of the market eaten away by the Chinese models. It seems they (at least OpenAI) can compete on the bottom end as well.
Finally, the benchmark's results reinforce a few things people have been saying about Sonnet and Terra, namely, they're not competitive for a range of tasks. For easier tasks, Haiku/Luna are plenty capable. For harder tasks, Opus and Sol are so much more intelligent, that they can get them done quicker and cheaper. Maybe there is a place for them in the "Opus designs and Sonnet implements" workflows, but in that case, why not "Opus designs and Deepseek implements?"
PS Code harness used was Claude Code. $20 in openrouter credits was used to access the models. Kimi K3 and Deepseek were also accessed directly via the API and then compared to Openrouter. Kimi K3 specifically was much faster on Openrouter, and the difference in output tokens to get the same results for Deepseek/Kimi makes me think the Openrouter providers are hosting significantly quantized versions of the model. Goes to show that Moonshot.ai's acceptance testing of providers is a useful thing, otherwise your model might look artificially bad when it's hosted as heavily quantized by providers who dont care about quality, just top-line cost and speed.
Junie is an agent. The AI Assistant is the UI for agents (typically in a sidebar). You can switch to other agents if you want (such as Codex or Claude Code), and there are actually a ton that you can add with just a few mouse clicks.
The "Install From ACP Registry ..." allow you to use pi, OpenCode, Kilo Code, Cline, Cursor, Copilot (and a ton of other agents that I've never heard of) if you want.
GTA games are, as far as I know, mostly built by Rockstar North studio (formerly DMA Design), which is located in Scotland. Obbe Vermeij, former Rockstar North employee, has written some interesting blog posts about the development of GTA from 3 through San Andreas, which can be found archived here: https://gist.github.com/WillPresley/d57d48b3d5f7f7b4bde4a2a3... (he has taken the blog down). It seems that, at least in that era, Rockstar New York was mostly handling the story and voice acting.
The one part that sort of surprises me is he says "The second thing we are missing is that the Model has not in fact found a way of obtaining
a program with g < m. (Moreover, Fable tells me this is impossible, but I do not follow the argument yet.)"
I'm not sure what argument fable gave him, but this part seems not horribly difficult to prove. I'm sure i'm missing something since i'm not that great at this kind of math.
The short reason is that each slice call can at most double the number of nonzero entries, but a transform that would enable g < m must turn a single nonzero entry into (2^m) nonzero entries in a single call.
Since the permutes can't generate non-zero entries (since they only move things around), you actually need exactly m slice calls in the initial 2-instruction model given (where you can only do slices and permutes) precisely because of the need to create 2^m non-zero entries where each individual slice op can only double the number (and permutes do nothing)
In my Slim PHP application container, the only way I could reproduce the PHP2SHELL behavior was by adding `index.php` and `upload.php` from the attached gist to the webroot.
As others have said, there are probably other ways to reproduce it, but it requires a lot of prior knowledge of the app environment, or at least a good guess.
Excellent article. This incoherence is a side-effect of a system built far faster than it is consolidated and thought about from an external behavioral standpoint.
I've created a skill that the agent runs after significant codebase work has been done: https://gist.github.com/scroobius-pip/adb87dffca64b11bad3dd1...
[0]: https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...