Sunday, 2nd August 2026
The July edition of my sponsors-only monthly newsletter is out. If you are a sponsor (or if you start a sponsorship now) you can access it here.
This month:
- Accidental cyberattacks by OpenAl and Anthropic models under test
- GPT-5.6 Sol, Terra, and Luna
- Claude Opus 5
- Kimi K3 and DeepSeek-V4-Flash-0731
- Open letters about Al development
- A fireside chat and a podcast
- Reigniting my interest in MCP
- Other model releases
- My projects
- What I'm using at the moment
Here's a copy of the June newsletter as a preview of what you'll get. Pay $10/month to stay a month ahead of the free copy!
Open letters about AI development
I wrote this summary of the past few weeks of open letters as a section of my sponsors-only newsletter but I've decided to share it here as well.
Open Weights and American AI Leadership was shepherded by Microsoft, dated July 24th, and signed by 235 AI-adjacent companies including NVIDIA (see Jensen's first ever tweet), Amazon, Y Combinator, The Linux Foundation, and (a later signer) OpenAI.
It's clearly an argument designed to counter any instincts by the current US government to ban or limit open weight models over "safety" concerns - a reasonable consideration given what happened to Claude Fable 5!
Relying solely on closed models is not inherently safe: they can be breached, misused, or fail in ways that outsiders cannot detect. And concentrating advanced AI capabilities behind a small number of closed models compounds that risk. It results in a small number of single points of failure, weakens competition, and leaves critical technology in the hands of a few providers. Open weight models, on the other hand, allow a broad community of researchers and developers to examine their behavior, identify vulnerabilities, develop safeguards, and improve them over time.
The one surprising note in the letter is that it comes out in support of distillation, where models train on output from other models:
In shaping this ecosystem, policymakers should be careful not to conflate legitimate model-development techniques with misappropriation. Distillation, or the practice of using one model’s outputs to help train or improve another, is a widely used technique for model improvement, evaluation, and validation. It reflects a long tradition of learning from, building upon, and improving existing technologies, a tradition that has helped drive innovation since the rise of the open-source software movement.
Notably absent from the signatures: Anthropic, who published their own response Our position on open-weights models three days later. CEO Dario Amodei doubled down on the risk of authoritarian governments building "AI models that are more powerful than those built by the US", and models being "misused to carry out cyberattacks or biological attacks", and called for "a crack down on industrial-scale distillation operations", while also stating that "Anthropic has never advocated for a ban on open-weights models".
Then on July 28th Pacing the Frontier was published, featuring signatures from "1,324 employees of frontier AI companies" - with names like Jakub Pachocki (Chief Scientist, OpenAI), Ilya Sutskever (Safe Superintelligence Inc, previously OpenAI), Dario Amodei (Anthropic), Jack Clark (Anthropic) and more. Their core message:
We request that the U.S. government support an international effort to develop the technical and governance tools needed to deliberately pace the frontier of automated AI development.
Their concern is intense competitive pressure combined with accelerated AI progress caused by automated AI research - and given that Anthropic produce 80% of their code with Claude Code, OpenAI had Sol reduce their end-to-end serving costs by 20%, and Kimi K3 designed a chip to serve a nano model built on its own architecture, you can see why people are taking that risk more seriously right now.
I'm trying to get braver at releasing 1.0 versions. This little library is a year and a half old now - I've applied some sensible and non-disruptive fixes and shipped the big 1.0 for it.
Here's an example of what it can do, lifted from the README:
{
"foo": {
"bar": {
"string": "This is a string with foxes in it",
"nested": {
"more": ["Here is a string", "another with foxes in it too"]
}
}
}
}Combine that with a replacements object:
{"1": "with foxes in it"}And condense_json(input_json, replacements) produces the following:
{
"foo": {
"bar": {
"string": {"$r": ["This is a string ", {"$": "1"}]},
"nested": {
"more": ["Here is a string", {"$r": ["another ", {"$": "1"}, " too"]}]
}
}
}
}It scans for strings or substrings that are present in that replacements object and replaces those with a special {"$r": ...} syntax in the output.
You can reverse the effect with uncondense_json(condensed, replacements).
The idea is to make it easier to store JSON that includes duplicated data from other related structures. I use it to save space in the SQLite logs generated by LLM - see PR #1586 for the latest iteration of that.