I'm talking more about text like:

  > # Why It Can't Fully Work
  > # Wall 2 — EMDF keyed authentication (the decisive one)
  > coregraft = a real Dolby core + our metadata → Dolby Surround. The metadata is rejected too, and we traced it to the EMDF emdf_protection field, which is a keyed authentication code, not a computable checksum:

  > EMDF container (ETSI TS 102 366 Annex H) — wraps OAMD (id 11) + JOC (id 14) with the emdf_protection field, carried in the E-AC-3 audio-block skip field exactly where real Dolby streams put it (recomputing frmsiz + crc2).

I was hoping to read about what exactly these ‘heat pump radiators’ look like, but I guess ultimately they’re going to be lasers or flashlights or some such thing.

A relativity course question I recall from my youth asked how long an astronaut stranded 1km from a ship would need to point the flashlight away to return to the ship based on the mass of the photons leaving the light — spoiler - this can work in time to save an astronaut’s life — double spoiler: if you’re really accurate, it’s better to throw the flashlight if you’re in a hurry.

As I write this I realize my physics model is super weak, because I’m not sure what percent of the energy used to make a photon turns into the photon’s mass (and therefore is pushing against the laser), and what is in light and therefore just, you know, carries on for billions of years until it hits something else.

They seem to contain a mix of subject matter expert jargon and often some words that are created during the course of coding and end up encapsulating concepts, but it makes reading the documentation liminal — it’s like reading a tech spec from an alien. And I suppose it is, after all, a tech spec from an alien.

I think what I find both interesting and difficult and annoying (and, and, and) about them is that they fail to have a theory of mind for the reader — they are essentially the slightly manic notes one leaves for oneself after a 4 day coding binge, tarted up in markdown and published.

I’ve been experimenting with asking for documentation that specifies a reader and requests a theory of mind about that reader being applied to documentation, and it’s very helpful, but I don’t think I quite have it nailed yet. And I don’t think I understand why it is that these models, which have ingested an immense amount of technical documentation, still write like this.

I’m willing to bet internally they thought this was a good plan from the beginning - from engagement, requests for reg oversight, Mythos PR, silently nerfing AI engineering quality, and now this “pulling the model” stunt. It’s frustrating, I generally like using the Claude models, but I don’t think I’ve ever been a customer of such a user-hostile company before.

It would be nice if they slid on over to a more typical presentation in the market — but I think they’ll need to experience a fair amount more pain to really change behavior - it’s embedded in their minds as proper, safe and ethical, and they’re currently sitting on tons of cash.

As per usual super interesting, thank you for the write up and work!

If this current building spree ends in massive solar and other power generation being overbuilt and cutting energy costs, we've had a really good outcome.

The hard part is not distilling a frontier model down into a specific use case when you have hundreds of millions of users, the hard part is (apparently) re-architecting your mobile OS to work with such a model rather than fight it. Those architectural benefits accrue to apple, as will future datasets and expertise, and the benefit of having some distillation working 24/7 on prem.

Anyway, where I think you're going to be grumpy in two years is that switching the underlying model is going to require a jailbreak, and that you wish they'd made the os much more deeply open for agentic interaction, not that it's gemini - it's just not the valuable part of the story for Apple or for users.

Probably most interesting is just throwing down a bunch of strategies that are provably better than tit for tat in rule constrained environments, and showing that some more complicated form of tit for tat doesn’t win as you get more space than your opponents - better is to manipulate simpler opponents into predictable behavior.

Anwyay, this particular Wolfram essay was devoid of name dropping, and full of interesting (if occasionally hard to parse) dense infographics, I enjoyed it and learned something.

None of the companies needs an IPO right now, with the possible exception of oAI — I haven’t looked at their financials recently. But SX is cashflow positive as of today, and Anthropic is able to become so without giving up much on their R&D program. So for those two, it’s a matter of timing.

Like a video game release schedule or a film release, SX has carved out a window and is going first, and regardless of messaging, all the teams are going to be watching it VERY VERY carefully. If it goes well, I’d expect Anthropic to jump next.

If that goes well, oAI would likely go right after. If it goes mid, oAI may wait to improve their financial story or fundraise private at worse valuations for a while, or, or, or.

Agreed that the dream for the next guys down the road is to pick up some recycled capital gains from sx and of course some new capital. If SX is a flop, then these IPO dreams will slow down for a minute.

I’m not clear how much crossover demand there is between SX and Anthropic/oAI — that seems like the more interesting question. I’m guessing if we had Anthropic/oAI launching at the same time we’d see some pretty interesting capital dynamics.

It strikes me as kind of wild that good evals can drive tens to hundreds of millions of dollars of compute deployment in the wild — there’s something new and collaborative and competitive about the eval / frontier model race that’s quite interesting..

In this case “shorter actually mergable patches that open source maintainers would accept” feels like a great thing to deliver to the world.

I didn’t deep dive into good and bad patches, but I wonder if swyx or others on the team have predictions on saturation. Both when, and how useful will it be? That is, do you guys think this test is broad enough as written to get better behavior out of models, and if there is saturation on this test, will we see generalized better patch / coding behavior?