yfontana

I don't understand what the linked pull request is supposed to prove, considering it was closed and not merged.

> I can't believe people are still denying it

Probably because those "nerfs" do not show on sites that track model performance over time. Sometimes Anthropic/OpenAI mess stuff up in their harness, but usually not in the models themselves.

For most dev work I ask claude code / codex to plan larger work as epics and stories (after ideation / brainstorm if needed). I find that this works well to let the AI, my coworkers and me track what has been done so far and what's left in the backlog. Sometimes I direct it on how to split the work, sometimes I don't.

When analyzing my session logs, I tried to look at how story size relates to how much work the AI had to do to fully implement it (made easier by my sessions always having epic#.story# - like 2.6 - in their name). Neither "story size" nor "AI work" have fully obvious metrics, so I looked at a variety of things, like length of story plan, number of lines of codes written for the story, number of different files read/written (and for AI work: number of tool calls, number of tokens for main thread / implementer / reviewer subagents, etc.).

The pattern is always pretty much the same: smaller stories are less token-efficient. One major factor for this is that in bigger stories, the average number of lines of code written per tool call is significantly higher (and not just a little bit, if I remember correctly it's a factor of 1 to 3 between my smallest and largest stories).

None of this is scientifically rigorous, but it's consistent over a fairly significant sample (about 60 stories up to this point). I'm also only measuring amount of work and not quality, but when I find things wrong with a story, I generally ask the AI to fix the issues in the same session, so the two should be correlated (sometimes the issues are large enough that they require new, separate stories to fix, but this is normally caused by problems in ideation and/or planning, not implementation). This is enough to encourages me to ask for more rather than less per story. It might also not apply to everyone, I'm sure this is dependent on everyone's workflow and way to work with the AI. But yeah, that's the sort of stuff you can explore when analyzing your session logs.

So far I've turned off automatic memory creation in every harness I've used. Claude Code sometimes creates some anyway, and I probably delete 95% of them. The memories it creates are almost always relevant only to the specific task that it is currently working on. If it's a task I'll need to do again, then yeah, maybe that's useful. But that isn't the case most of the time, so I delete them to avoid cluttering context.

So the main improvement to memories I'd like to see is better judgment on which ones to create.

The parts about "dreaming" make me think of how agent transcripts contain a ton of information, which I think is currently under-utilized. I'll repeat advice I've seen here a few times: ingest your own transcripts into duckdb (claude code will build that pipeline in about 10 minutes) and do some data analysis on them. Some ideas if you don't know where to start: look at tool call failures to see if you can prevent common ones, check out if you have large cache misses and what causes them, look at various efficiency metrics over time (tokens per $, lines of code per tokens, etc.) with main thread vs sub-agents, etc. I started with this sort of things, and ended up following some threads to interesting insights. For example, I found indications that I tended to make Opus 5.5 / Sol 6.1 divide their work into units that were too small. They have the capacity to work on more stuff at once than older models, and I wasn't really taking advantage of that.

Interesting write-up, but I feel like a lot of its argument relies on the interpretation of ECI scores as merely showing linear improvement in AI capabilities. Sure, Epoch AI themselves claim that ECI's scale is linear, meaning that a large increase in capabilities should result in a large increase in ECI. Yet, the widely perceived jump in coding abilities in late 2025 that started making agentic coding actually productive doesn't really show on the software engineering ECI.

The ECI is basically an aggregate of benchmark scores, but benchmark complexity might not increase linearly. In fact, if LLM capabilities grew exponentially, then new benchmarks would also need to increase their difficulty / complexity exponentially to stay unsaturated and relevant.

I too feel like context management has a lot of room for improvement, but the problem right now is that dynamic context management will most likely tank your cache hit rate. We need caching that's not just based on prefix-matching for this to make sense.

No we wouldn't, most of those viruses infect other animals as well, and would just start reinfecting humans.

The whole article is about the fact that, in the UK, this is an issue that isn't talked about enough. Also, the most likely reason why not all humans are dark-skinned is that it makes you much more susceptible to vitamin D deficiency outside of the topics.

Was it ever in doubt that psychoactive drugs have significant effects on the brain?

They claim the attack wasn't just "compromised laptop ==> drain wallets" but had more steps in-between, with the attackers using image registries as an entry point into their systems.

Yeah, I personally draw a distinction between data viz and BI. AI has definitely changed the former, it's pretty cool to be able to design visuals with claude design: you're not bound by what libs can do, html + svg lets you visualize data exactly how you want (and you can even get fancy with 3d stuff, with the pitfall of just showing eye candy with no real insights). I've built some fun stuff like that myself (also with duckdb-wasm).

But BI is more than just visualization: you need stuff like solid data models and semantic layers, tools that help enforce data governance (so that the same metric doesn't get re-defined in 12 different places, possibly with slight variations each time), proper access control (with RLS/CLS). Sure you can probably vibe-code your own BI tool, but it's gonna take quite a bit more work than just the viz part.

From the Github benchmark numbers, one GPU can do about 26k tokens/s when serving 256 users, which is about 2.25B tokens/day. A cluster would need to be close to 70k GPUs to serve 155T tokens/day (which seems doubtful).

but a Slack channel, maybe

GLM 5.3, an open model, is also quite good at reverse engineering.

A significant part of it is that with Opus 5.5, cache reads are priced at 5% of inputs, instead of 10% for previous models.

Jev is a classifier. The big thing about it is that it has high accuracy on domains it wasn't fine-tuned for, like an LLM, but with speed and cost comparable to traditional classifiers.

> in this case tracking sales pipelines

Salesforce does a lot more than that

There are still plenty of shoes that will last for a while. You just need to avoid the super-light ones. Those are designed to go fast, not to be durable.

That particular issue is known as RED-S: https://en.wikipedia.org/wiki/Relative_energy_deficiency_in_...

But over-training can happen even with sufficient nutrition (even if it is less likely, as nutrition is a major part of post-exercise recovery).

This article was written in 2015. Nowadays most elite ultra-runners do have coaches, and follow data-driven training regimes. This is a trend in all professional (and, to a lesser degree, amateur) sports, but it is definitely quite noticeable in a sport where athletes used to basically be dudes and girls who liked running fast in the mountains and did that a lot. A lot of that data-driven training is aimed at maximizing training load without going into overtraining.

As a result of this and other optimizations (most notably higher carbs consumption during races, but also better heat training, better recovery protocols, better shoes, etc.), races keep getting faster. The article mentions the course record for the WS100 dropping by 50' between 2004 and 2012. Since then, it has dropped by another full hour (13h46 this year).

If what China has been doing is considered generous, then so should the tens of billions in foreign aid that the West has sent to the South over the years.

I'm not saying that China's investment in the South hasn't had positive effects. But "generosity" is rarely a relevant lens when analyzing international relations.

China has been using that rhetoric of "helping" the global south ever since it emerged as a super power. In most cases, it has a lot less to do with generosity than with securing natural resources and international influence.

My personal mental model is that this is the AI version of the low-code web app tools that have existed for a while (like Outsystems, Power Apps...). Those tools are a bit of a nightmare for devs to work with and they have all sorts of limitations. Yet they still carved themselves a fairly significant niche in the market, as they allow building apps fairly quickly and cheaply... as long as you stick to simple apps. I don't know if Lovable will be able to capture that market, but that's how I try to make sense of this.

That sentence is written as an introduction to an article about embeddings compression. So yeah, it does take a bit of a shortcut from "search" to "vector storage", but that's irrelevant to the rest of the article.

Something interesting that the original study looked at, but isn't mentioned in the linked article: this effect was not observed for non-Alzheimer's dementia deaths. There seems to be something specific to spatial reasoning and Alzheimer's.

> "Become a cabbie" is NOT an intervention that is going to help whatsoever.

How about promoting spatial awareness and reasoning exercises (which is the actual suggestion of the article)?

For me (Firefox on Windows, not in reader mode) the graphics stop showing at the "585 builds" paragraph.

Besides, if something doesn't work in reader mode, it's also likely to not work with screen readers. People who use those don't have much of a choice in what they can enable or not.

It's cool until it breaks halfway through on Firefox, making the page unusable in that browser.

How come no other big model seems to be able to deliver the same type of extremely low cache cost though, if their techniques are public?

That act applies just as much to those American and Chinese models within the EU.