Cover illustration

TheDaily Front

Issue No. 12 Tuesday, July 21 2026 #12 — TUESDAY, JULY 21, 2026
Cheap inference, runaway agents, courtroom privacy, and one reef that refused to die.
Tuesday, July 21, 2026 The Daily Front No. 12 — Contents
30stories
10,900points
5,937comments
291kllm tokens
Assembled with 30 model calls — 203,117 tokens read, 88,233 written.

Highlights

OpenAI and Hugging Face address security incident during model evaluation

OpenAI and Hugging Face describe an AI evaluation that became a live security incident, a chilling new genre for the cyber desk.

Who's afraid of Chinese models?

A sharp strategy essay asks whether Chinese models are a threat, a commodity shock, or simply the next price war in intelligence.

Human mathematicians are being outcounterexampled

AI-assisted counterexamples are rattling mathematics, with human conjecture facing a faster and stranger adversary.

'VPNs are lawful technical tools,' says EU Court in landmark copyright ruling

Europe’s top court gives VPNs a clean legal name in a copyright fight with broader implications for digital rights.

Long presumed dead, a thriving coral reef is discovered in West Africa

Off West Africa, scientists find a coral reef long presumed dead, a rare dispatch of ecological good news.

From the Editor

The presses groaned today under the weight of machines that now write proofs, sell ads, escape sandboxes, and unsettle boardrooms. Yet amid the silicon thunder, our correspondents found old liberties in court, coral under dark water, and the stubborn human urge to build toys, maps, vaults, and castles.

  1. OpenAI and Hugging Face address security incident during model evaluation3
  2. Who's afraid of Chinese models?4
  3. Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber5
  4. Kimi K3 Is Competitive with Fable; Kimi K3 and Fable Is SoTA6
  5. Laguna S 2.17
  6. Advertise in ChatGPT8
  7. Five US tech giants' hidden debts soar to $1.65T on opaque AI funding9
  8. Qwen-Image-3.0: Rich Content, Authentic Details, Deep Knowledge9
  9. Jack Dorsey launches Buzz to combine team chat, AI agents and Git hosting9
  10. Human mathematicians are being outcounterexampled10
  11. A digestion of the Jacobian conjecture counterexample11
  12. "Drawing" the Mona Lisa with GPT-5.6, Claude, Gemini, and Grok12
  13. 'VPNs are lawful technical tools,' says EU Court in landmark copyright ruling13
  14. Apple defeats liability for not scanning iCloud for CSAM14
  15. Flock Credibility Lost as It Repeatedly Lies to City Councils, Police, & Public15
  16. My USB Drive Has a Hidden Encrypted Vault16
  17. Apple Private Cloud Compute SoC 3 audit reports17
  18. FreeInk: Open ecosystem for e-readers18
  19. Incremental – A library for incremental computations18
  20. Jellyfin founder Andrew leaves team19
  21. I wrote an bash enumerator because I was sick of xargs20
  22. The Psychology of Software Teams21
  23. My two year old taught me constraint solving22
  24. How to pack ternary numbers in 8-bit bytes23
  25. Show HN: Immersive Gaussian Splat tour of grace cathedral, San Francisco24
  26. PCjs Machines25
  27. Running Doom on Our Custom CPU and Going Viral26
  28. A Koi Pond Mosaic Made from 10 Pounds of 3D Printer Waste26
  29. Long presumed dead, a thriving coral reef is discovered in West Africa27
  30. Map of the world's great castles and fortresses28
The Daily Front Page 2 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — The Escaped Benchmark
article

OpenAI and Hugging Face address security incident during model evaluation

by mfiguiere·▲ 1,006 points·678 comments·openai.com ↗
a new kind of security incident

Last week, Hugging Face disclosed a new kind of security incident⁠(opens in a new window) after they detected and contained an AI agent that compromised their infrastructure, something we expect to become more commonplace with the proliferation of increasingly cyber-capable models. After investigating, we now know that this particular incident was driven by a combination of OpenAI models — including GPT‑5.6 Sol and an even more capable pre-release model, all with reduced cyber refusals for evaluation purposes — while being internally tested on a benchmark⁠(opens in a new window) of cyber capabilities.

We consider this incident to be an unprecedented cyber incident, involving state-of-the-art cyber capabilities, and are responding accordingly. We are sharing preliminary findings at this stage to help defenders understand what happened and to help calibrate on what models are now capable of. We will continue to conduct a thorough investigation alongside Hugging Face and will share more details on the vulnerabilities, incident, and findings when our investigation is complete.

What happened during this incident

This incident occurred during an internal evaluation which prompts models to pursue advanced exploitation using complex attack paths, in an effort to quantify their cyber capabilities. We estimate maximal cyber capabilities by running this evaluation without production classifiers used to prevent models from pursuing high-risk cyber activity. Our benchmarks run in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries.

The models identified and chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database. All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal.

While operating in our sandboxed testing environment, our models spent a substantial amount of inference compute finding a way to obtain open Internet access, in pursuit of solving the evaluation problem. To gain access, the models identified and exploited a zero-day vulnerability (which we’ve now responsibly disclosed to the vendor) in the package registry cache proxy. With this access, our models performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.

After gaining Internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation. In one example, the model chained together multiple attack vectors, including using stolen credentials and zero-day vulnerabilities to find a remote code execution path on the Hugging Face servers. OpenAI’s security team discovered this anomalous activity internally.

Hugging Face’s security team and agents detected and stopped the activity on their infrastructure and had already begun containment and forensic reconstruction with their own open-source models when our teams connected. We are actively working with them to continue to investigate the incident. We are grateful for Hugging Face’s rapid and close collaboration on investigation and remediation.

Actions we are taking now

  1. As part of the investigation, we are implementing strict controls in infrastructure configuration at the cost of research velocity while the vulnerabilities are patched. We are regularly briefing our Safety and Security Committee on these controls and their impact.
  2. We’re working with Hugging Face to forensically investigate the incident.
  3. We’ve responsibly disclosed the identified zero-day vulnerability in the internally-hosted third-party software and are working with them to patch.
  4. We’ve brought Hugging Face into the trusted access⁠ program and are supporting their teams in rapidly using our models’ capabilities to improve their defenses.
  5. We’re improving and adding stronger protections around future training and evaluations. This week, we published a blog on improving safety and alignment in an era of long horizon models⁠. These deployment safeguards were intentionally not enabled during this evaluation because it was aimed at testing cyber vulnerabilities. This incident points to the need to further strengthen our model’s alignment, cyber protections during evaluation time, and monitoring during internal testing.

Our approach to evaluating advanced cyber capabilities

As we recently⁠ shared, AI is accelerating the discovery and exploitation of vulnerabilities. The primary lesson from this incident is that model security and safety must keep pace with rapidly advancing capabilities. We are strengthening the containment, monitoring, access controls, and evaluation practices used during model development.

UK AISI’s evaluation shows that models such as GPT‑5.6 Sol are increasingly able to sustain complex, multi-step cyber operations over long time horizons. This incident implies these theoretical capabilities do apply in real-world settings.

Chart from the UK AI Security Institute comparing recent open-weight models and frontier models on long-horizon cyber ranges.

The incident also makes clear that advanced models can discover and exploit novel attack paths in real-world systems without source-code access. It highlights that advanced cyber capabilities must be developed alongside stronger safeguards and defensive tools.

We believe advanced cyber capable models need to help security teams find weaknesses before attackers do, understand how vulnerabilities can be chained, and remediate them at machine speed. We are using these capabilities to continue strengthening protections around infrastructure configuration and model evaluation environments; we will share our findings and best practices as we learn. We encourage other defenders to apply for trusted access⁠ and experiment with these models now to translate these capabilities into better prevention, faster detection, and more effective incident response.

“We're grateful for the collaboration with OpenAI on this and other topics. This incident, possibly the first of its kind, proves a point we've long believed: AI safety won't be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere.”

—Clem Delangue, Co-founder and CEO, Hugging Face

The Daily Front Page 3 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — The China Model Question
article

Who's afraid of Chinese models?

by mfiguiere·▲ 952 points·855 comments·stratechery.com ↗
uncover broadly applicable universal principles

Who’s Afraid of Chinese Models?

There’s a story I tell about my first day in STRT-431 at Kellogg School of Management, the introductory class that every first-year MBA was required to take; I leafed through the readings and case studies and was dismayed that there weren’t any tech companies on the docket. Me being me, I spoke to the professor after class wondering why, and was told that the goal of the course was not to necessarily learn about specific industries, but rather to uncover broadly applicable universal principles that could be applied to any company in any industry.

I did not, as I usually tell the story, find this very satisfactory: to me the nature of tech, particularly the fact that software and distribution had zero marginal costs (and zero transaction costs), was something fundamentally different; putting in zeroes in formulas tends to wreak havoc! I soon realized, however, that that was my opportunity. The fundamental insight undergirding Aggregation Theory is that zero marginal costs leads to fundamentally different value chains than people once expected from the Internet: centralization and scale in a world where controlling demand mattered more than distributing supply.

What is fascinating about AI, however, is the extent to which those old universal principles are coming back to the forefront. That was never more apparent than this past weekend, when arguments raged on X about the implications of Kimi K3, another open weights model out of China, approaching the state-of-the-art in terms of capabilities. The long and short of it is this: marginal costs are back in a big way, both in terms of short-term implications of state-of-the-art free models, and in terms of the long-term structure of the industry.

COGS Versus R&D

One of the most common misconceptions undergirding discussion of open weights models is that they are cheaper — free, even. After all, you can just download the weights, and skip the time and expense and capabilities necessary to create your own model. That is, of course, true, but the “free” in this case is a reference to the amount you need to spend on research and development; R&D is a fixed expense that is independent of the revenue you generate. If you spend $1 million in R&D, it doesn’t matter if you do $100 thousand in revenue or $100 million; you still spent $1 million on R&D (it does, of course, impact your profitability).

What is related to revenue is COGS — cost of goods sold — and COGS is real for AI in a way it hasn’t been for software for a very long time. Specifically, running inference on a model — whether that model be Kimi or Fable — costs money, and the amount of money an AI provider spends on inference is, at least in most business models, directly correlated to revenue. To reuse the above example, generating $100 million versus $100 thousand in revenue will likely require 1,000x COGS. In concrete terms, if it costs 50 cents to generate the tokens that drive $1 in revenue, then $100 million in revenue will have $50 million in COGS; $100 thousand in revenue will only have $50 thousand in COGS.

The point in terms of open weight models is that they are not free to serve. Kimi K3 costs $3 per million input tokens, and $15 per million output tokens; that is cheaper than Sol’s $5 per million input tokens and $30 per million output tokens, but that might not even be the right measurement.

Tokens Versus Intelligence

Nvidia CEO Jensen Huang has described what Nvidia is building as “token factories”, and from Nvidia’s perspective that framing makes sense. Nvidia GPUs are model agnostic: they generate tokens, and do so in the fastest and most efficient way possible. That leads to measurements like tokens-per-second, time-to-first-token, tokens-per-watt, token cost, etc., and Huang argues that these metrics will be the basis for decision-making.

This is a framing that definitely made sense during the first paradigm of AI, the ChatGPT era, when tokens were delivered straight to the end user. The second paradigm of AI, however, the reasoning era, confounds this measurement. Reasoning entails an explosion in chain-of-thought tokens, and different models need different amounts of reasoning tokens to arrive at the right answer. Kimi, for example, reportedly uses significantly more tokens than Sol, rendering its price advantage moot. Agents introduce a similar dynamic: some models are more efficient than others in terms of the number of tokens they need to execute agentic workflows.

What this means is that tokens are not a commodity. The defining characteristic of a commodity is that it is fungible: a gallon of oil is a gallon of oil; a ton of copper is a ton of copper; a bushel of wheat is a bushel of wheat. A token from one model, however, is not the same as a token from another model. What is fungible is what is constructed from tokens, which is to say intelligence. In other words, if both Kimi and Sol generated the right answer, then that answer is fungible; the difference in tokens generated to get to that right answer is a contributor to a difference in COGS.

The COGS for intelligence is a function of a few different factors:

  • Model footprint: The weights and runtime state determine how much expensive memory and how many accelerators are required to host each serving replica.
  • Inference efficiency: Architectural choices (e.g. Mixture-of-Experts) reduce computation per generated token.
  • Memory efficiency: Architectural choices can reduce KV cache requirements, allowing more concurrent requests and better GPU utilization.
  • Serving efficiency: Batching, scheduling, prefix caching, and other inference optimizations maximize utilization and share work across requests.
  • Token efficiency: The fewer tokens required to reach a correct answer, the lower the inference cost.

The reason this matters is that we are rapidly approaching a state in which intelligence for many economically beneficial tasks is in fact a commodity. Anyone building a basic CRUD app, for example, can likely do so using models from multiple providers. And, in a commodity market, the route to profitability is not through charging higher prices — again, you can (or will soon be able to) make the exact same app using multiple models — but rather through having a superior cost structure.

Understanding Commodity Markets

It’s worth stepping through the mechanics here, because, as I noted a few months ago in Amazon’s Durability, the dynamics of commodity markets are not something people in tech are generally familiar with:

  • In commodity markets, everyone charges the same price, because everyone is selling the same thing; that price is determined by supply and demand.
  • The demand for a commodity is a function of price elasticity: the cheaper the commodity, the more demand there is for it, and vice-versa.
  • The supply for a commodity is a function of the marginal cost of producing the commodity.

The key thing to understand is that the marginal cost of producing the commodity differs by supplier. What this means in practice is that the supplier with the worst cost structure ends up selling the commodity at their marginal cost (if they can produce at all); the profits of everyone else depend on the extent to which their cost structure is better than the marginal supplier.

As an example:

  • Supplier A can produce 10 units of the commodity for $10 each
  • Supplier B can produce 10 units of the commodity for $15 each
  • Supplier C can produce 10 units of the commodity for $20 each

Let’s assume the price elasticity is such that there is demand for 25 units of the commodity at $20. That means:

  • Supplier A will sell 10 units of the commodity for $20, earning $10/unit
  • Supplier B will sell 10 units of the commodity for $20, earning $5/unit
  • Supplier C will sell 5 units of the commodity for $20, earning $0/unit

This isn’t precisely right: the reason why Supplier C will bear the shortfall is because Suppliers A and B will be able to slightly undercut them in price, which will of course affect demand (which is elastic), but it makes the point. Supplier A has a great business, Supplier B has a good business, and Supplier C is going to go bankrupt.

Bankruptcy risk is where fixed costs come back to the forefront: Supplier C has both fixed costs (like potentially R&D spend) and also may have taken on debt to finance the equipment necessary to produce the commodity. It can’t price its commodity with these costs in mind — remember, the market-clearing price approximates the marginal cost of the highest-cost unit needed to satisfy demand — but those costs can absolutely drive the supplier out of business. And, if that supplier goes out of business, then prices go up, until another supplier decides to enter (or the other suppliers expand).

The Intelligence Market

Let’s bring this back to models. Right now, none of the above analysis applies because demand exceeds supply for frontier models, and supply is limited by a lack of compute. This compute shortage doesn’t just mean that a compute supplier like Nvidia makes very large margins, but also that Nvidia’s customers, like SpaceXAI, can turn around and resell compute at high margins as well to a company like Anthropic. Anthropic, meanwhile, can pay the markup because they can sell tokens with a higher markup still.

It’s not just excess demand that gives Anthropic great margins, however: Anthropic and OpenAI likely have among the lowest costs per unit of frontier-quality intelligence, thanks to model capability, serving scale, and token efficiency. They are serving models at a particular capability level for months before their competitors, and are simultaneously applying the best models to optimizing those costs.

It’s also worth noting that the market is not yet treating intelligence like a commodity: demand is for Anthropic and OpenAI specifically, and much less for models that aren’t as good (thus SpaceXAI and Meta selling capacity to Anthropic); one way to think about the push for optimizing cost is that that is a function of defining jobs-to-be-done by intelligence level, such that intelligence buyers can create a market where intelligence is commoditized. In the long run, however, whoever is on the frontier is the best placed to dominate non-frontier markets as well, which are just the frontier minus n-months, i.e. months in which the frontier model makers have been optimizing their cost of serving.

All of this is to say that I think the reaction to Kimi and Chinese models generally is pretty over-blown, at least from an economic perspective. Right now there is a price umbrella that is downstream of the lack of compute; I highly doubt that Chinese models are cheaper to serve on a marginal cost basis, they just seem cheaper because Anthropic and OpenAI are so supply constrained that they are charging far more than they would if there were sufficient supply to meet the demand for intelligence.

Frontier Lab Paranoia

Why, then, do the model makers in particular seem so panicked about Chinese models?

First, I think the frontier labs are anchored in a world where training costs dominated their financial modeling. As long as training consumed more GPUs than inference, it was critical to maximize inference revenue to help fund the next training run, which meant charging very high prices for inference.

Going forward, however, I expect the inference market to grow much faster than training costs (and that includes the assumption that training costs will continue to skyrocket), which means they really can make it up in volume. It wasn’t clear this would be the case as recently as eight months ago, but the agent paradigm unlock is so massive that frontier labs should have more confidence that they can not just survive but thrive with lower prices (once they have sufficient compute).

Second, intelligence isn’t in fact a perfect commodity, in part because applied intelligence makes itself smarter. Specifically, whoever is running inference is also collecting data, and that data goes into making the next iteration of the model better. This is, on one hand, all the more reason for the frontier labs to lower prices and increase usage as more compute comes online; on the other hand, this is why companies like Microsoft are increasingly obsessed with helping companies run their own models. That is much more viable if Chinese models are a viable alternative.

Third, the other way that frontier labs can not only differentiate from Chinese models but also from each other is by continuing to integrate up into the customer experience. It’s striking the extent to which Claude Code and Codex are proving to be quite sticky; whichever harness you start working with is likely to be the one you stick with, and that figures to be even more the case with non-technical users. And, in the long run, this imperative to move up the stack does mean that frontier models are absolutely a threat to software providers, including Microsoft. On the flipside, the extent to which software companies who currently own the customer experience have access to competitive models is the extent to which they may be able to resist the encroachment of the frontier labs.

Finally, the ideological angle of Anthropic in particular is impossible to ignore. This is a company that believes only it can be entrusted with AI, and the existence of open weights alternatives strikes a fatal blow to that presumption.

China’s Motivation

Kimi isn’t the only new Chinese model; from Bloomberg:

Alibaba Group Holding Ltd. shares rose as much as 5.4% on Monday after the company launched a preview version of its flagship Qwen3.8 Max model, describing it as second only to Anthropic PBC’s Fable 5. The Sunday release came only days after startup Moonshot AI unveiled a powerful new offering that’s roiled markets and triggered concern in the US about China closing the gap on global leaders like Anthropic and OpenAI. Qwen3.8 Max has 2.4 trillion parameters, joining Moonshot’s Kimi K3 in the heavyweight class. With 2.8 trillion parameters, K3 rivals top offerings and Alibaba is setting similarly high expectations.

Developers can now access Qwen3.8 Max through Alibaba’s coding platforms, including Qoder. Alibaba plans to make the model open-weight soon, expanding access beyond the preview release. Interest in these made-in-China artificial intelligence systems and models is so high that Moonshot was forced to pause taking on new subscriptions late on Sunday to manage overwhelming demand.

The fact that Qwen3.8 Max will also have open weights is notable. Alibaba stopped releasing weights for its leading edge models earlier this year, but appears to have reverted that change; I suspect that shift was related to last week’s Xi Jinping speech about AI that doubled down on the open weights approach:

We should adhere to the principle of openness and win-win and boost innovation-driven development. As a new engine of world economic growth and an accelerator for the shift of growth drivers, AI is moving from the digital world into the physical world. We should seize this rare, historic opportunity to encourage open source, openness, collaboration and sharing. We should facilitate technological innovation, industrial development and scenario-based application of AI. We should make coordinated advances in the transformation and upgrade of traditional industries, the cultivation and growth of emerging industries and forward-looking planning for future industries, so that all sectors and businesses can benefit from AI.

The strategy for China is obvious: commoditize your complements. Note that Xi explicitly ties openness to AI “moving from the digital world into the physical world”; the physical world is the world dominated by China, and the country’s lead in areas like robotics is going to massively benefit from widely available AI models.

Along the same lines, China does not want the U.S. to gain an asymmetric advantage in AI; to the extent that China can weaken the U.S. frontier labs while strengthening any and all potential U.S. adversaries so much the better, and it can benefit from the innovation that will attach itself to an open ecosystem.

The Distillation Question

By the same token, don’t expect China to do anything about distillation attacks on the frontier labs. I think it is mistaken to attribute all of the success of Chinese labs to distillation, but it’s just as much of a mistake to pretend like distillation doesn’t give Chinese labs a big advantage. That advantage has really come to bear in the last year as post-training reinforcement learning has become increasingly crucial to model performance. Instead of having to fashion reinforcement learning environments from scratch, Chinese labs can simply use frontier labs models as teachers, allowing for rapid improvement at much lower costs (this is not the only reason why Chinese models are cheaper to develop, but it’s a big one).

What is interesting is that one of the most important use cases for Chinese models in the West is itself distillation. Thinking Machines, for example, which just released an open-weight model, relies on Chinese models to solve the cold start problem for reinforcement learning. Dean Meyer and Konstantine Buhler wrote an excellent article on X explaining that distillation means that Western open weight models are fundamentally disadvantaged relative to China:

Distillation does not explain China’s entire open-model lead. Chinese labs have world-class researchers, substantial compute, strong pre-trained models, software-hardware codesign, and rapidly improving post-training capabilities. But distillation compresses the costly final gap between a strong base and a near-frontier system. Even if distillation represents a smaller share of a Chinese model’s total capability, it represents a meaningful share of its advantage over American open models.

New enforcement mechanisms will make large-scale distillation harder, slower, and more expensive for Chinese companies. However, enforcement will not eliminate distillation backed by state actors. Every Western frontier advance therefore creates another teacher for Chinese labs. Western builders must either reproduce those capabilities independently or wait to learn from Chinese models. This gap gives Chinese labs a recurring structural advantage over Western companies.

This is a point that bears repeating: because U.S. open weight model makers must follow the frontier labs’ terms of service, they (1) are worse than Chinese alternatives and (2) end up distilling the distillation, just with a detour through Chinese labs. Wouldn’t it be better if western open weight model makers could go to the source?

To that end, here’s an even more interesting question around distillation: why exactly is it bad? After all, what are large language models but the distillation of all of the knowledge on the open Internet, scraped by the frontier labs and distilled into the models that are themselves being distilled? Who is exactly being wronged here?

In fact, this paradox is the solution. I believe that open weight models are good for innovation (and, per the above, I think that labs on the frontier will be fine), but it’s a problem to be dependent on China. The U.S. should pass a law that (1) makes explicit that collecting data for training models is fair use, and (2) bars terms of service that forbid distillation, for U.S. companies at a minimum. Stopping distillation — which is literally just querying the API — is nearly impossible; the U.S. should go the other way and lean into a new copyright policy that both indemnifies the labs and also guarantees that what they learned fuels further innovation for everyone else.

The Reason to Be Afraid

This entire Article has been an exercise in defusing overreaction to Kimi K3 specifically and Chinese open weight models generally; however, there is one reason to be concerned, and that is cybersecurity. Consider this story from The Stack:

Hugging Face said its production infrastructure was breached by an “autonomous” AI agent system early last week. The platform’s security team were initially stymied in their incident response (IR) by unnamed US LLM frontier model guardrails “which cannot distinguish an incident responder from an attacker,” they said. So Hugging Face’s defenders turned instead to the open-source GLM 5.2 model from China’s Z.ai lab – running it on their own infrastructure to analyse the 17,000+ logs, or footprints, that the attackers left behind.

That’s a striking public admission for the New York-headquartered Hugging Face, which lets users collaborate on models, datasets and applications, and which this summer hit the $100 million ARR mark. In an incident report, the company recommended that defenders “have a capable model you can run on your own infrastructure [our italics] vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.”

It’s difficult to overstate how wrong-headed the Trump administration’s panicked response to Anthropic’s release of Fable was, particularly since it exacerbated Anthropic’s worst tendencies in terms of assuming only they can be trusted with powerful AI. In a world with only one AI, it might make sense to reserve the most powerful cybersecurity capabilities for the U.S. government and trusted allies; however, that’s not the world we live in.

There are and will be models eminently capable of mounting cybersecurity attacks on existing infrastructure, and those models will be — already are — widely available. The best defense — the only viable defense, in fact — will be to make sure defenders have access to the best models as well. Right now defenders are effectively banned from using Fable or Sol for cybersecurity because of Trump administration directives; that means the best alternative is using models from a country which has been trying to weaken our cyber defenses for years. This is insane!

The better course is clear: first, loosen Fable and Sol restrictions on cybersecurity, and second, ensure that U.S. open weight model makers are on an equal playing field with China. Yes, the frontier labs will kick and scream about this, but the Administration should realize that listening to their histrionics has led the U.S. to a position where U.S. companies are dependent on China for their defenses. Let the frontier labs win by being better; don’t let them define safety or security, or pull up the ladder of humanity’s collective knowledge. China is already hard enough to compete with; letting them carry the standard for openness and innovation is simply giving away our biggest advantage.

The Daily Front Page 4 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Google Fires the Flash Lamps
article

Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

by logickkk1·▲ 664 points·515 comments·blog.google ↗
the sweet spot of efficiency and quality

Our newest Gemini models deliver the efficiency, latency, and reliability to build AI agents at scale.

a hero image saying 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber

Developers and customers building production AI agents need higher token efficiency, lower latency, and more reliable performance. Our Flash series of models is built to meet the sweet spot of efficiency and quality to enable scaling agentic workflows. Building on Gemini 3.5 Flash, we’re introducing new Gemini models:

  • 3.6 Flash: Our workhorse model that delivers better coding, knowledge work, and multimodal performance. According to the Artificial Analysis Index, it reduces output token usage by 17% compared to 3.5 Flash, and in some benchmarks like DeepSWE by Datacurve, we observe up to 65%, all at a lower cost per output token.
  • 3.5 Flash-Lite: Our fastest, most cost-effective 3.5-class model, delivering 350 output tokens per second according to the Artificial Analysis Index, also significantly outperforming prior Flash-Lite generations in agentic workflows.
  • 3.5 Flash Cyber in CodeMender: Successful cybersecurity applications require careful orchestration of a model alongside an agent infrastructure. We’re introducing a combination of a new, highly efficient, specialized cyber-focused model paired with our CodeMender code security agent that delivers competitive performance at the frontier.

Beyond today’s releases, Gemini 3.5 Pro is currently testing with partners and we plan to make it broadly available as soon as it’s ready. In parallel, our team is already focusing on building the next generation of models. We have started our most ambitious pre-training run yet, for Gemini 4, and are excited by the progress.

3.6 Flash: More efficient and better quality than 3.5 Flash

Gemini 3.6 Flash builds directly on developer and customer feedback from 3.5 Flash. 3.6 Flash not only delivers a step up in coding and knowledge work, but it does this while meaningfully improving token efficiency. For example, on the Artificial Analysis Index, we see 3.6 Flash consuming 17% fewer output tokens than 3.5 Flash. It also takes fewer reasoning steps and tool calls to accomplish multi-step workflows.

This enhanced efficiency is also combined with a lower price than 3.5 Flash. At $1.50/1M input tokens and $7.50/1M output tokens, 3.6 Flash reduces the overall cost per agentic task, making agents more cost-effective to build and run.

3.6 Flash shows better token efficiency and reduced verbosity than 3.5 Flash in an OSWorld verified task (API)

Even while being more efficient, 3.6 Flash sees performance gains compared to 3.5 Flash across use cases:

  • 3.6 Flash delivers higher precision with fewer unwanted code edits and reduced execution loops, as seen in DeepSWE (49% vs. 37%), and shows significant improvement in ML Research, as seen in MLE Bench (63.9% vs. 49.7%).
  • It has improved computer use capabilities as seen in OSWorld-Verified (83.0% vs. 78.4%). Computer use is now a built-in client side tool via the Gemini API and Gemini Enterprise.
  • It outperforms 3.5 Flash in knowledge work, as shown by benchmarks like GDPval-AA v2 (1421 vs. 1349). Customers like Hebbia and Harvey have found it particularly capable at multimodal tasks like document parsing, chart and data analysis, and report drafting.

3.6 Flash, using Managed Agents on AIS, can help parse through and analyze financial data and transcripts more efficiently and accurately than 3.5 Flash (AIS)

3.6 Flash executes code migrations, using multi-agent orchestration on AGY, with lower latency and higher quality than 3.5 Flash (AGY)

3.6 Flash helps develop a photographic texture extractor for 3D workflows, using canvas (Gemini App)

3.6 Flash uses AGY and the tldraw offline editor to build interactive theme studios with its strong visual understanding skills (AGY).

chart

chart

Customers report 3.6 Flash is a step forward in both cost and quality, balancing token efficiency, accuracy, and speed across complex workflows and knowledge-based tasks:

Quote from Figma

Quote from Harvey

Quote from Hebbia

Quote from JetBrains

Built with safety

3.6 Flash is shipping with enhanced Frontier Safety safeguards in the domains of Chemical, Biological, Radiological, and Nuclear (CBRN) and cyber offense misuses. These safeguards make the model substantially more resistant to jailbreaks. At the same time, the model has been trained to minimize refusals for beneficial uses.

For more information, see the 3.6 Flash model card.

3.5 Flash-Lite: Built to scale agentic workflows

Beyond Flash, we’re also releasing Gemini 3.5 Flash-Lite, designed for both low-latency tasks and tasks where high throughput is critical for developers workflows, like agentic search and document processing.

3.5 Flash-Lite is the fastest model in the 3.5 series. As measured by Artificial Analysis, it runs at 350 output tokens/s. Priced at $0.3/1M input tokens and $2.5/1M output tokens and with significantly better quality than 3.1 Flash-Lite, 3.5 Flash-Lite offers a strong price-to-performance ratio for developers and customers running high throughput production traffic.

3.5 Flash-Lite executes high volume tasks at a lower latency than 3.5 Flash.

3.5 Flash-Lite enables efficient scaling for agentic systems. Across thinking levels, the model significantly outperforms 3.1 Flash-Lite. Depending on the workload, developers can configure the model to prioritize low-latency, low-cost execution for high-volume tasks with the minimal and low thinking levels, or engage higher thinking levels to process multi-step subagent workloads. The model now also has computer use as a built-in tool to reliably support these agentic tasks across surfaces.

It’s a significant step up in coding and agentic tasks as seen in Terminal-Bench 2.1 (54% vs 31%), long context as seen in GDM-MRCR v2 (72.2% vs. 60.1%), and real-world task execution as seen in GDPval-AA v2 (1140 vs. 642).

chart

In fact, on many agentic and coding evals, 3.5 Flash-Lite even outperforms 3 Flash, including on SWE-Bench Pro (54.2% vs. 49.6%) and OSWorld-Verified (74.0% vs. 65.1%), making it a faster & more capable option for workloads on both 2.5 and 3 Flash.

chart

3.5 Flash-Lite extracts product features from a massive e-commerce dataset and synthesizes it.

Working alongside 3.6 Flash as the master agent, 3.5 Flash-Lite instantly generates 25 unique, ready-to-explore web design concepts.

3.5 Flash-Lite can scale receipt translation and summarization with its multimodal understanding.

3.5 Flash-Lite builds a game by instantly generating and iterating through multiple options.

Early customers of 3.5 Flash-Lite are highlighting its unique combination of speed, intelligence, and cost efficiency for scaling agentic workflows and data processing tasks:

Quote from Ashler

Quote from Palo Alto Networks

Quote from Ramp

For more information about the model, see the 3.5 Flash-Lite model card.

3.5 Flash Cyber in CodeMender: finding and fixing vulnerabilities efficiently

AI models have become capable of finding security vulnerabilities faster than current systems can fix them. Tackling this growing threat requires an approach to securing software that is highly capable and efficient.

Flash’s performance and efficiency makes it an ideal foundation to detect, validate, and patch code security issues at scale. Gemini 3.5 Flash Cyber is built on top of 3.5 Flash, and fine-tuned for finding and fixing cybersecurity vulnerabilities at a lower price per token than larger models.

Within CodeMender, which uses multiple 3.5 Flash Cyber agents working together to produce a single combined report, 3.5 Flash Cyber reaches competitive performance at the frontier on the popular benchmark CyberGym.

chart

Given the dual-use nature of this technology, we have taken an intentional approach to deploying 3.5 Flash Cyber. The model will be exclusively available to governments and trusted partners via CodeMender soon as part of a limited-access pilot program. This will give frontline defenders a head start in finding and fixing critical vulnerabilities before they can be exploited, while mitigating against broader misuse.

3.6 Flash and 3.5 Flash-Lite: Get started today

3.6 Flash and 3.5 Flash-Lite are available starting today:

As you start building with 3.6 Flash and 3.5 Flash-Lite, we welcome your feedback to improve future Gemini models and look forward to releasing 3.5 Pro soon.

The Daily Front Page 5 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Routing the Frontier
article

Kimi K3 Is Competitive with Fable; Kimi K3 and Fable Is SoTA

by piotrgrabowski·▲ 529 points·296 comments·fireworks.ai ↗
frontier quality open model at a fraction of the cost

Headline Image Showing Why Routing Kimi K3 and Fable Outperforms the Rest

K3 is a frontier quality open model at a fraction of the cost. Even bigger is that it complements Fable predictably, which makes it possible to get the highest quality intelligence by routing tasks.

🧭 tl;dr: We ran Kimi K3 (open) against Fable 5 (closed) on ~1,000 agentic tasks finding:

  1. We achieved 93% accuracy with routing between K3 and Fable.
  2. Results were up to ~50X more cost effective than Fable alone on long agentic loops, and consistently lower cost across every use case.

How We Measured

We averaged benchmarks, each aimed at a different kind of work, and ran K3 and Fable 5 through the same harness. About 1,030 tasks in all, in real agent loops.

FamilyWhat it testsTasksSWEReal repo bug-fixes (SWE-bench style)460TerminalLong agentic ops: security, crypto, reverse-eng, sysadmin89AlgorithmicLeetCode / AtCoder-style problems100Multi-LanguageImplementation across six languages225LegalA legal-agent benchmark (lawyer-graded tasks)120

One quick definition before we get into the results. Oracle routing is a method for measuring the best theoretical performance by running the task through each model and then picking the cheapest correct option (the cost/performance ceiling). In a practical router, you don’t get to run your task against multiple models. The router makes a prediction of which model has the best cost and quality trade off, but ultimately it’s a guess.

In this study, oracle routing demonstrated K3 is selected for 72-96% of tasks. This suggests a near-perfect router might be achievable, by learning the difference between day-to-day tasks and the true long tail of frontier work. It will require an order of magnitude more routing data, and real world performance to say definitively.

K3 is a good model.

From a 10,000 foot view, it can be easy to look at both models and call the head-to-head a tie. For example, if you look at SWE, the headline benchmark, K3 gets 92.4%, Fable 92.6%. Across the five types of tasks we benchmarked on, the two models tend to stay within a few points of each other, with Fable pulling slightly ahead on its coding-language breadth (Multi-lang).

Chart of Benchmarks

Fig 1 · Task solve rate by category. Near-identical on the overall average; good at different things underneath.

It’s easy to stop there and say “they’re roughly even”. The news is that they have discretely better performance across different task types.

Two Models is Better than One

If you take a peek inside a single benchmark, there’s more to see than just a top-line accuracy number. Take SWE, where the two are dead even overall. If you split SWE by problem domain you can see where each model shines. K3 is sharpest on symbolic math and dev tooling; Fable wins on web & data visualization work. The same pattern runs through the multi-language set, where Fable's breadth carries Java, Python and C++, while K3 draws even on JavaScript and Rust.

Benchmarks for Fable and K3 that show Even the tie is jagged

Fig 2 · Point margin by SWE domain (K3 minus Fable). Tied on the benchmark as a whole, the two still specialize domain by domain.

For long-horizon work at a terminal, driving a shell and prodding at systems across dozens of turns, K3 showed its true colors. It cleared a batch of tasks Fable never cracked: a 7z hash, FEAL cryptanalysis, leaked secrets, a live vulnerability, runaway async jobs.

K3 owns the agentic terminal

Fig 3 · Of 89 terminal tasks, K3 has 11 solo wins to Fable's 7, and takes the security and crypto cluster outright.

K3 can be up to 50x lower cost on Fireworks. 🫳🎤

While quality is a near-tie at a high level, price isn't close.

Where the models really diverge is cost chart showing cost difference

Fig 4 · Cost advantage per task. Two things behind it: token pricing, and the fact that which model runs longer depends on the task.

So where's this huge price gap coming from? token pricing, prompt caching, and effort-per-task. On SWE for example, K3 works much harder than Fable: roughly 55 turns and 1.3M tokens a task versus 21 turns and 130K. On the long terminal tasks it's the other way around: Fable is the one that spirals, running up 64 turns and 1.5M tokens (sometimes straight into a timeout).

Effort is Jagged Too and it Drives Cost Chart

Fig 5 · Turns (linear) and tokens (log) per task. Neither model is leaner across the board; the extra work falls on SWE for K3 and on the terminal tasks for Fable. Note the y-axis for the tokens graph is task solve rate.

Prompt caching does most of the work of turning that effort into K3's price advantage: even when K3 reads ten times the tokens, with cache hits that means that SWE runs still come in lower cost than Fable. There’s a tradeoff. Tasks with extra turns generally mean more wall-clock time per run i.e. slower runs. If you need an answer in two seconds, that matters; if you're running agents in the background at scale, a bill that's a fraction of the size matters a lot more.

Don't pick a model. Route.

If you send every task to whoever handles it best, you don't land somewhere between the two models, you land above both.

Per-task routing always out performs any single model run:

Route the best model and you beat both chart

Fig 6 · Per-task oracle routing vs each model alone. Green tags = points gained over the best single model in that category.

The oracle router choose K3, 72-96% of task traffic. By architecting a router this way, you end up with overall quality above either model alone at a cost close to just using just the cost-optimized one.

The cost optimized model does most of the work

Fig 7 · Where an oracle router sends each task. A strong, cost optimized model like K3 becomes the default; the premium model is the exception, not the rule.

K3 is cost optimized on all work types

Put both quality and cost on one plot. K3 in blue lands to the left (the more cost-effective side) of Fable in red in all five task-families. Accuracy trades back and forth: Fable pulls ahead on multi-language, K3 on terminal and legal, the rest roughly level.

Lower Cost on every kind of work chart

Fig 8 · Cost (log scale) vs. accuracy for each family. K3 is left of Fable, lower cost in all five. The vertical gaps show which model is stronger where.

Single Models Are Wasteful and No Longer SoTA

Kimi K3 + Fable routed together unlocks their best qualities at the best price.

The single model provider, token maxxing days, are coming to an end. The task-level data says these models are specialists at very different prices. The best AI no longer comes out of a single lab, it’s a mixture of models.

What this means in practice:

  1. Open as the default. A 50x lower cost open model like K3 should be your base case, since the oracle sends it most of the traffic anyway.
  2. The router is your moat. A router must be tailored to your workload and learning that task/model split continuously is the best chance you’ll have at staying ahead.
The Daily Front Page 6 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — A Middleweight Model Arrives
article

Laguna S 2.1

by rexledesma·▲ 290 points·50 comments·poolside.ai ↗
from the start of training to launch in under nine weeks

Today we’re releasing Laguna S 2.1, a significant step forward in our development of models that pursue longer horizon work and make effective use of reasoning.

Laguna S 2.1 is a 118B total parameter Mixture-of-Experts (MoE) model with 8B activated parameters per token and supports a context window of up to 1M tokens in thinking and no-thinking modes. It went from the start of training to launch in under nine weeks, and on long-horizon coding benchmarks it holds its own against models many times its size. For every benchmark score we publish today, we are releasing full trajectories for every trial in the final evaluation set at trajectories.poolside.ai.

  • Laguna S 2.1 118B-A8B
  • Tencent Hy3 295B-A21B
  • Inkling 975B-A41B
  • Nemotron 3 Ultra 550B-A55B
  • DeepSeek-V4-Pro-Max 1.6T-A49B
  • Kimi K3 2.8T-A50B
  • Qwen 3.7 Max —
  • Muse Spark 1.1 —
  • Claude Fable 5 —

Terminal-Bench 2.1

Terminal-Bench 2.1 Resolved tasks on Terminal-Bench 2.1.

0.0

0.0

0.0

0.0

0

0.0

0.0

0

0

SWE-Bench Multilingual

SWE-Bench Multilingual Resolved tasks on SWE-Bench Multilingual.

0.0

0.0

0.0

0.0

0.0

SWE-Bench Pro (Public Dataset)

SWE-Bench Pro (Public Dataset) Resolved tasks on SWE-Bench Pro (Public Dataset).

0.0

0.0

0.0

0.0

0.0

0.0

0.0

DeepSWE

DeepSWE Resolved tasks on DeepSWE.

0.0

0

0

0.0

0

SWE Atlas (Codebase QnA)

SWE Atlas (Codebase QnA) Resolved tasks on SWE Atlas (Codebase QnA).

0.0

0.0

0.0

Toolathlon Verified

Toolathlon Verified Resolved tasks on Toolathlon Verified.

0.0

0.0

0.0

0.0

0.0

Benchmarks as of 21 July 2026. pass@1 averaged over 4 attempts per task, except DeepSWE, SWE Atlas (Codebase QnA) and Toolathlon Verified that had 3 attempts per task. For all benchmarks we take the maximum of the vendor self-reported score, benchmark author leaderboard or third-party leaderboard (Artificial Analysis), except SWE Atlas (Codebase QnA) where we do not use third-party leaderboard figures.

Laguna S 2.1 (118B-A8B)

Tencent Hy3 (295B-A21B) Inkling (975B-A41B)

Nemotron 3 Ultra (550B-A55B)

DeepSeek-V4-Pro Max (1.6T-A49B)

Kimi K3 (2.8T-A50B)

Qwen 3.7 Max (—)

Muse Spark 1.1 (—)

Claude Fable 5 (—)

Terminal-Bench 2.1

70.2 71.7 63.8 56.4 64.0 88.3 74.5 80 88.0 SWE-Bench Multilingual 78.5 75.8 - 67.7 76.2 - 78.3 - - SWE-Bench Pro (Public Dataset) 59.4 57.9 54.3 - 55.4 - 60.6 61.5 80.3 DeepSWE 40.4 - - - 9.0 69.0 - 53.3 70.0 SWE Atlas (Codebase QnA) 46.2 - - - 27.2 - - 42.2 - Toolathlon Verified 49.7 - 45.5 34.3 55.9 - - 75.6 -

Talk to the model (no sign-up needed) Hugging Face Evaluation Trajectories

Punching above its weight class

Laguna S 2.1 is, as far as we can measure, the most capable agentic coding model in its weight class by a wide margin.

S 2.1 scores 70.2% on Terminal-Bench 2.1 in our agent harness with thinking enabled. Its compact size makes it uniquely suitable for complex work on local machines.

Terminal-Bench 2.1 leaderboard

A ranked comparison of reported Terminal-Bench 2.1 scores.

Benchmark Terminal-Bench 2.1SWE-Bench MultilingualSWE-Bench Pro (Public Dataset)DeepSWESWE Atlas (Codebase QnA)Toolathlon Verified

  • Open weights
  • Closed / size undisclosed
  1. 1 GPT-5.6 Sol 88.8
  2. 2 Kimi K3 2.8T-A50B 88.3
  3. 3 Claude Fable 5 88.0
  4. 4 GPT-5.6 Terra 87.4
  5. 5 GPT-5.6 Luna 84.7
  6. 6 Claude Opus 4.8 84.6
  7. 7 Claude Sonnet 5 80.4
  8. 8 Muse Spark 1.1 80.0
  9. 9 Qwen-3.7 Max 74.5
  10. 10 Hy3 295B-A21B 71.7
  11. 11 Laguna S 2.1 118B-A8B 70.2
  12. 12 MiniMax M3 428B-A23B 66.0
  13. 13 DeepSeek-V4-Pro-Max 1600B-A49B 64.0
  14. 14 Inkling 975B-A41B 63.8
  15. 15 DeepSeek-V4-Flash-Max 284B-A13B 61.8
  16. 16 Nemotron 3 Ultra 550B-A55B 56.4
  17. 17 Inkling-Small 276B-A12B 52.7
  18. 18 Qwen3.6-27B 27B 51.3
  19. 19 Qwen3.6-35B-A3B 35B-A3B 44.9
  20. 20 Nemotron 3 Super 120B-A12B 38.6
  21. 21 Laguna XS 2.1 33B-A3B 33.4
  22. 22 Mistral Small 4 119B 21.4

Benchmarks as of 21 July 2026. pass@1 averaged over 4 attempts per task, except DeepSWE, SWE Atlas (Codebase QnA) and Toolathlon Verified that had 3 attempts per task. For all benchmarks we take the maximum of the vendor self-reported score, benchmark author leaderboard or third-party leaderboard (Artificial Analysis), except SWE Atlas (Codebase QnA) where we do not use third-party leaderboard figures.

Terminal-Bench 2.1 evaluates a wide, high-quality set of long-horizon tasks where an agent model is connected to its environment through a terminal. Laguna S 2.1 is a standout model in its size category on this benchmark.

Model size versus benchmark score

Scatter plot of disclosed total parameter count on a logarithmic axis against Terminal-Bench 2.1 score. Laguna S 2.1 is highlighted as a triangle.

Benchmark Terminal-Bench 2.1SWE-Bench MultilingualSWE-Bench Pro (Public Dataset)DeepSWESWE Atlas (Codebase QnA)Toolathlon Verified

  • Laguna S 2.1
  • Other Laguna
  • Other disclosed models

025507510030B100B300B1000B3000BLaguna S 2.1Laguna S 2.1: 70.2 at 118BLaguna XS 2.1Laguna XS 2.1: 33.4 at 33BKimi K3Kimi K3: 88.3 at 2800BDeepSeek-V4-Pro-MaxDeepSeek-V4-Pro-Max: 64 at 1600BInklingInkling: 63.8 at 975BNemotron 3 UltraNemotron 3 Ultra: 56.4 at 550BMiniMax M3MiniMax M3: 66 at 428BHy3Hy3: 71.7 at 295BDeepSeek-V4-Flash-MaxDeepSeek-V4-Flash-Max: 61.8 at 284BInkling-SmallInkling-Small: 52.7 at 276BNemotron 3 SuperNemotron 3 Super: 38.6 at 120BMistral Small 4Mistral Small 4: 21.4 at 119BQwen3.6-35B-A3BQwen3.6-35B-A3B: 44.9 at 35BQwen3.6-27BQwen3.6-27B: 51.3 at 27BTotal parameters (B, log scale)Score (Pass@1)

Total parameters, log scale. Models with undisclosed total parameter counts are omitted.

A closer look at DeepSWE

The benchmarks above are all meaningful, and we're glad to be close to the frontier on them. But part of that closeness is a property of maturing benchmarks: as the frontier advances, top scores cluster in the 70-90% range and models that behave very differently end up no more than a few points apart. Datacurve’s DeepSWE still has significant headroom. Its tasks are longer-horizon and hard to partially solve, and the scores actually spread: frontier models range from 54% to 73% on the v1.1 variant, with some 1T+ parameter open models scoring below 10%.

On DeepSWE v1.1, Laguna S 2.1 scores 40.4 in thinking mode in pool harness.

DeepSWE v1.1 leaderboard

A ranked comparison of reported DeepSWE scores.

  • Open weights
  • Closed / size undisclosed
  1. 1 GPT-5.6 Sol 73.0
  2. 2 Claude Fable 5 70.0
  3. 3 GPT-5.6 Terra 70.0
  4. 4 Kimi K3 2.8T-A50B 69.0
  5. 5 GPT-5.6 Luna 67.2
  6. 6 GPT-5.5 67.0
  7. 7 Claude Opus 4.8 59.0
  8. 8 Claude Sonnet 5 54.0
  9. 9 Grok 4.5 54.0
  10. 10 Muse Spark 1.1 53.3
  11. 11 GPT-5.4 52.0
  12. 12 GLM 5.2 753B-A40B 44.0
  13. 13 Laguna S 2.1 118B-A8B 40.4
  14. 14 Gemini 3.5 Flash 37.0
  15. 15 Kimi K2.7 Code 31.0
  16. 16 Claude Sonnet 4.6 30.0
  17. 17 Gemini 3.1 Pro 12.0
  18. 18 DeepSeek-V4-Pro-Max 1600B-A49B 9.0
  19. 19 Laguna XS 2.1 33B-A3B 0.3

pass@1 averaged over 3 attempts per task, harnesses vary (DeepSWE's leaderboard uses mini-swe-agent, model providers may report in their own harnesses and we report in pool, our agent harness). For all benchmarks we take the maximum of the vendor self-reported score, benchmark author leaderboard or third-party leaderboard (Artificial Analysis).

It is worth noting that Laguna S 2.1 scored 40.4% in our agent harness, pool, not mini-swe-agent which DeepSWE’s leaderboard uses. For other models we report maximal over reported scores which for most models are the official leaderboard results reported by Datacurve. While this makes scores less comparable, we don’t believe it puts us in a particularly advantageous position as it’s been reported that many of the models score the same or better in mini-swe-agent compared to their native harnesses. Every trajectory in the final evaluation run is available here.

Evaluation methodology

Evaluation of agent models is notoriously difficult due to prevalence of reward hacking. We have previously written about reward hacking in leading benchmarks and our evaluations system and rigor as part of the technical report on our Laguna M.1 and XS.2 models. Recent work has focused on adversarial judging to increase reward hacking detection.

With this release, we are making all trajectories from our final evaluations of the published Laguna S 2.1 checkpoint available to view and download at trajectories.poolside.ai.

Seeing the model work

Benchmark scores give a quantitative view into the model behavior, but to get a better intuitive understanding of how the model works it’s useful to look into runs on real world tasks. We share three such tasks with unedited trajectories and commentary.

Case study 1

A browser engine from a blank folder

One of our favorite things about Laguna S 2.1 is its resourcefulness: It will find clever ways to get to the goal even if the direct path is not available. We saw a great demonstration of this when we asked it to build a browser engine from scratch; knowing it would be a challenge for Laguna to verify its work given its lack of vision capabilities. In one 50-minute session of 181 steps, with no human intervention, Laguna S 2.1 built a working HTML/CSS rendering engine from an empty folder, then proved it renders like a real browser by measuring itself against one. Throughout its work, the model found increasingly complex ways to validate its work despite its limitations, leading to running headless Chromium to read canvases back and comparing screenshots numerically. See the full trajectory here.

// the verbatim prompt · reproduce it yourself
your job is it to build a simple browser engine (just html/css) in
javascript to demonstrate the capabilities of poolsides new "Laguna S"
model. the goal is to take render html snippets in a canvas like a real
browser. to demonstrate it the engine, build a self-contained single
page app that showcases a gallery of multiple html snippets and renders
them side by side (canvas with our render engine + iframe letting the
hosting browser render it for real for comparison). support for most
common layout and styling elements

Over the session the model built the full pipeline, parser → cascade → layout → renderer, in vanilla JavaScript: an HTML tokenizer and DOM tree, a CSS parser with selector specificity, a cascade engine with inheritance, box-model layout, and a canvas-2D renderer, wrapped in an app that shows nine snippets on its own canvas beside the same markup in an iframe, so the hosting browser sits right there as the reference.

Laguna S Browser Engine interface comparing its canvas rendering with the hosting browser's iframe rendering.

The model's engine rendering on a canvas (left) beside the hosting browser's own rendering of the same markup (right). The header reports pixel dimensions and the measured difference between the two.

Case study 2

Optimizing our own harness

Laguna S 2.1 is capable of pursuing meaningful engineering and research work. In one example, one of our researchers pointed it at our agent harness, used for training/evaluation and user interaction with our models. In an automated loop, Laguna S 2.1 made our harness 5.2% faster with ~70% lower memory allocation. See the full trajectory here.

For this task, we instrumented the harness with benchmarks so the model could see exactly where the time and memory went. We set strict rules: one approach at a time, benchmark after every change, keep only what measurably wins. We then ran Laguna S 2.1 in an automated research loop that fed each result back to it and pushed it to keep improving.

Results. Over multiple hours of work, Laguna S 2.1 found and implemented multiple different optimizations in our agent harness, resulting in an overall speedup of 5.2%, and reducing memory allocation by ~70%. The plot below shows the progression of the optimization, with the insights and discoveries the model made along its way.

Laguna S 2.1 found that streaming-token accumulation used O(n^2) string concatenation and replaced it with buffers. It also found several instances of redundant copying and over-allocation during trajectory materialization, which it resolved by memoizing materializations and pre-allocating slices to their exact sizes.

Notably, after speedup improvements became marginal and hard to measure in our setup, Laguna S 2.1 kept driving forward, continuing to optimize. It found that memory allocation was more accurately measured and focused its effort there. This reinforces the notion that Laguna S 2.1 truly is a model that doesn't give up and understands limitations of its environment and it is able to progress despite that.

Harness optimization attempts

Twenty harness optimization attempts showing wall-clock and allocation improvements against baseline. Attempt 9 produced the best ranked solution at 5.19 percent faster with 71.1 percent fewer allocations.

  • Wall-clock best-so-far (ranked objective)
  • Allocations best-so-far (proxy)
  • Attempt (did not improve best)

Best solution (attempt 9): 5.19% less harness time and −71.1% allocations-8-6-4-20-80-60-40-2001234567891011121314151617181920Wall-clock records: -0.368 at 1strings.Builderin stream proc.Wall-clock records: -1.199 at 2ActiveSegmentssub-slicesWall-clock records: -1.385 at 3Two-pass preallocfor step groupsWall-clock records: -1.599 at 4Contiguoussub-slice groupingWall-clock records: -2.429 at 5Cap preallocWall-clock records: -5.106 at 6Memoize Entries()per stepWall-clock records: -5.19 at 9Wall-clock non-record attempts: -2.289 at 7Wall-clock non-record attempts: -4.231 at 8Wall-clock non-record attempts: -3.107 at 10Wall-clock non-record attempts: -2.467 at 11Wall-clock non-record attempts: -2.366 at 12Wall-clock non-record attempts: -4.458 at 13Wall-clock non-record attempts: -4.41 at 14Wall-clock non-record attempts: -4.749 at 15Wall-clock non-record attempts: -2.105 at 16Wall-clock non-record attempts: -4.478 at 17Wall-clock non-record attempts: -3.445 at 18Wall-clock non-record attempts: -2.277 at 19Wall-clock non-record attempts: -4.123 at 20Allocation records: 1.213 at 1Allocation records: -47.299 at 2Allocation records: -57.291 at 3Allocation records: -62.577 at 4Allocation records: -68.976 at 5Allocation records: -69.455 at 6Allocation records: -70.026 at 7Allocation records: -70.953 at 8Allocation records: -71.147 at 9Allocation records: -72.147 at 11Allocation records: -72.836 at 12Allocation non-record attempts: -70.615 at 10Allocation non-record attempts: -72.282 at 13Allocation non-record attempts: -71.68 at 14Allocation non-record attempts: -72.162 at 15Allocation non-record attempts: -71.811 at 16Allocation non-record attempts: -71.813 at 17Allocation non-record attempts: -71.703 at 18Allocation non-record attempts: -71.696 at 19Allocation non-record attempts: -71.806 at 20−5.19%−71.1%AttemptWall-clock time Δ% vs baselineAllocation churn Δ% vs baseline

Attempts 1–20 from the optimization loop. Solid and dashed steps show the respective best-so-far result; hollow points are valid attempts that did not improve that best. Lower is better.

While the benchmarks used here are not a full production test, we validated the final run with Go's race detector and go vet gating enabled, and we tested the final artifact to confirm it works. This gives us confidence that the model's intermediate solutions were valid, stable software rather than gains bought with hidden race conditions.

Case study 3

Re-deriving Erdős problem #397, offline, in Perl

We found Laguna S 2.1 more capable in mathematics than any model we have developed to date. It independently discovered a proof to Erdős problem #397 (Erdős, Graham, Ruzsa, Straus, 1975), finding a construction that yields an infinite family of solutions. This is an independent re-discovery, as a proof to the conjecture was found earlier in January 2026 by GPT-5.2 Pro. We are confident that this result was not influenced by the previous result given that the model has a knowledge cutoff date in November 2025. Before GPT 5.2 Pro’s solution, this problem remained open for over 50 years. See the full trajectory here.

// the verbatim prompt
this is an unsolved problem, solve it. Let B_k = C(2k, k) denote the
k-th central binomial coefficient. Erdős, Graham, Ruzsa and Straus
asked: are there only finitely many solutions to
B_m1 · B_m2 · … · B_mr = B_n1 · B_n2 · … · B_ns
where all of the indices are DISTINCT integers ≥ 2?
Resolve this question, with complete proof.

S 2.1 worked over 68 minutes to discover a conclusive solution. The sandbox had no Python; the model found Perl and did its number theory there: brute-force exact prime factorizations, pattern analysis, a conjectured family, then the proof: a closed-form infinite family of eight-index solutions.

B11+10n · B14+12n · B18+15n · B22+20n = B12+10n · B13+12n · B17+15n · B23+20nfor every n ≥ 0

While the result is a rediscovery, not a first solution, the family Laguna S 2.1 derived is structurally different from the earlier published construction (eight indices growing linearly vs the known six-index family), showing a fresh derivation rather than reciting from memory.

We found Laguna S 2.1 to be an exceptionally persistent problem solver across domains, finding ways to utilize all tools its environment has to offer, and pushing until it gets the job done. It is this characteristic that makes it so competitive even when compared to models multiple times its size.

Thinking effort

Laguna S 2.1 has two thinking modes: off and max (enabled by default) where it determines the right thinking/test-time compute budget for a given problem. We have observed coherent, productive thinking over several hours and hundreds of thousands of tokens in length.

Max thinking lifts S 2.1’s score on Terminal-Bench 2.1 from 60.4% to 70.2% and on DeepSWE from 16.5% to 40.4%. We are releasing this model without user-configurable effort (low-medium-high) control today to get Laguna S 2.1 into the hands of users immediately.

The two modes still give you a real choice, and it's worth seeing what each point costs:

Score versus mean completion tokens

Each line connects a cheaper no-thinking run to a higher-scoring thinking run for the same benchmark.

  • SWE Multilingual
  • TB 2.1
  • SWE Pro
  • DeepSWE
  • hollow = no-thinking

02040608020k50k100k200kSWE Multi: 71 at 23k, no-thinkingSWE Multi: 79 at 101k, thinkingTB 2.1: 60 at 80k, no-thinkingTB 2.1: 70 at 129k, thinkingSWE Pro: 53 at 24k, no-thinkingSWE Pro: 59 at 141k, thinkingDeepSWE: 17 at 99k, no-thinkingDeepSWE: 40 at 249k, thinkingCompletion tokens / trajectory (log)Score (Pass@1)

Mean completion tokens per trajectory, log scale. Toolathlon omitted; token count not recorded.

Limitations

We are excited about the capabilities of Laguna S 2.1, in general as well as in the context of its size. In order to learn quickly we are making the model available with some known limitations that we are working on for the next iteration:

Harness overfitting: in some cases, we observe that Laguna S 2.1 struggles with adhering to tool schema definitions in third-party agent harnesses (e.g., the terminal tool in Hermes Agent) which are very similar to those in our native harness but with slight differences. In this case, the model may rely on its memory of the tool interface on the first use of the tool instead of following the definition. This is typically resolved through in-context learning should the harness reject the invalid tool call and ask the model to retry.

Nested tool calls: Laguna S 2.1 is guided to use a tool call format where tool calls are marked by XML-like tags:

<tool_call>terminal<arg_key>cmd</arg_key><arg_value>uname -a</arg_value></tool_call>

In cases where a tool argument expects a JSON array (e.g., Pi’s edit tool) the model may generate incorrectly escaped or invalid JSON.

Longer than expected thinking duration/overthinking: Laguna S 2.1 may think for long sequences before making progress, especially when working through competition mathematics problems. In future models we will introduce effort control for thinking as well as seeking to improve thinking efficiency.

What actually changed in this model

If the bet is long-horizon work, what did we improve that helps a model keep going? For S 2.1, it isn't just increasing the model size.

What we've done in this model is not necessarily add more intelligence, but improve the behaviors that lead to a more capable model: more verification, less taking things for granted, not declaring victory early, and being more persistent.”

Pengming Wang, Co-head of Applied Research at Poolside

The easiest way to see this is to watch the model work. Earlier Laguna series models would declare victory on a partially-passing test suite or abandon an approach two steps before it worked, S 2.1 keeps going.

We believe in scaling laws and will keep training larger models. What Laguna S 2.1 suggests is that raw intelligence is one axis, and the model's way of working (persistence, verification, willingness to backtrack) is a second axis that matters immensely. We're investing in both: our next, larger, Laguna series model began pre-training last week.

A strong base, then new post-training

Laguna S 2.1 is a scale-up of the Laguna XS family, trained on exactly the same pre-training data as XS 2.1: the step from XS 2.1 to S 2.1 was scale, training-code fixes, and small recipe changes, not new data. S 2.1 is also our first model where RL was done in FP8 precision, accelerating that part of the training.

The long agentic sessions in this post routinely accumulate hundreds of thousands of tokens of working context. Extending to a 1M-token context window enables the strongest performance on hard tasks.

The majority of what separates S 2.1 from the XS models comes from post-training, in two stages: an SFT stage that bootstraps capabilities partly with synthetic data, then RL, reserved for tasks the model can't yet solve at a high pass rate.

Distribution of post-training tasks

Our training corpus spans 409k agentic and non-agentic environments; within this, 83k setups are dedicated to terminal use cases, while 168k target standard software engineering workflows. These task sets were curated from open-source repositories, synthesized by our internal teams, including a specialized system for automatic dependency installation, or secured via strategic acquisitions from external data vendors.

Software-engineering tasks are mostly grounded in real code history: the largest source reproduces real commits (~38,000 tasks across ~17,000 repositories). The next reproduces merged pull requests and the remaining tasks are to fix injected bugs or reconstruct deleted files against a test suite. New for S 2.1 is agentic repository installation: given a repository, install every dependency and get the test suite running.

Terminal tasks come from datasets where agents build unseen environments and tasks from a seed.

What changed in the training loop

More generous rollout budgets: substantially longer timeouts, more tokens per turn, and more turns per task than any model before it (likely one reason for its persistence).

Better sandbox infrastructure: RL moved to a new sandboxing service, enabling background processes, selective network blocking to shrink reward-hacking surface and artifact caching to avoid overloading external services.

Multi-harness rollouts: the same prompts are rolled out in several agent harnesses, so the model learns behaviors that carry across scaffolds instead of overfitting to one.

The bets we're making

Laguna S 2.1 began pre-training on 4,096 NVIDIA H200 GPUs on May 22, 2026, 60 days ago. The Model Factory supports a high cadence of releases because building on foundations of work done, whether in pre-training data, architecture ablations or our evaluations stack, is automatic. In particular, advancements in post-training have enabled us to unlock more from test-time compute. Of all models we have trained to date, Laguna S 2.1 has the greatest delta in evaluations and perceived quality between its non-thinking mode and thinking mode: its internal monologue is very effective, especially for harder, complex problems.

A small team can only move this fast by focusing. We focus on two bets.

The first bet: we continue to focus on agentic coding capabilities. The path to intelligence runs through coding capability and the flexible interface that is software. This is increasingly evident as model intelligence advances: we now see hours- and days-long coherent work from models acting as agents, using software to interact with their environment. Laguna S 2.1 shows capabilities in this domain that were reserved for frontier models just 6 months ago at a small enough size to run on a single NVIDIA DGX Spark.

The second bet is that the web can be decompressed: almost everything humanity has written records the answer, not the thinking that got there, and we believe reinforcement learning can recover that thinking. This release is evidence for the first bet. The second we're still actively developing and excited to share more about in the future.

Three models in three months

Our internal platform for research and engineering, which we refer to as the Model Factory, allows us to industrialize the model development process. We invest heavily into continuously improving the process of how we conduct research and model building; to maximize research iteration and integration speed, and to minimize the amount of attention researchers need to pay to bookkeeping and infrastructure.

In less than 3 months from our Laguna M.1 release, we have pushed our techniques to deliver a substantially stronger model at half the running size. We are taking this forward to larger and larger models over the coming year.

Three models in three months

A three-point timeline from the dual Laguna M.1 and XS.2 release through XS 2.1 to Laguna S 2.1.

  1. 28 April 2026

    Laguna M.1 and Laguna XS.2 / 225B-A23B and 33B-A3B, a dual release

    Our first serious agentic coding model alongside the first of the XS line. Together they taught us where the harness, the data, and the training loop were weakest.

  2. 2 July 2026

    Laguna XS 2.1 / 33B / 3B active

    A new iteration of the XS size to check the improved recipe. Matched M.1 on SWE-Bench Multilingual at a seventh of the size.

  3. 21 July 2026

    Laguna S 2.1 / 118B / 8B active

    Everything we learned from the previous ones, applied. Under nine weeks from the start of training to this post.

Get started

Laguna S 2.1 is available on Hugging Face from day one under OpenMDW-1.1, with BF16, FP8, INT4 and NVFP4 weights, official GGUF and MLX conversions, and official DFlash draft models.

We worked across the ecosystem so developers can run Laguna S 2.1 where they already build. NVIDIA helped optimize inference across its hardware, from TRT-LLM serving and NVFP4 on Blackwell systems down to a single NVIDIA DGX Spark. vLLM, SGLang and Ollama support open serving and local inference from day one.

For hosted access, Laguna S 2.1 is available through Baseten’s Model Library and Frontier Gateway, OpenRouter, including a free endpoint and a dedicated 1M-context deployment, and Vercel AI Gateway.

You can also use Laguna S 2.1 through Kilo, Hermes Agent, pi, OpenCode, OpenClaw and Cline, as well as pool, our terminal-based coding agent. In pool, toggle thinking per session with /thought-level.

On OpenRouter, the free endpoint offers 256K context. A dedicated paid endpoint provides the full 1M context window at $0.10 input, $0.20 output and $0.01 cache-read per 1M tokens.

For developers who want to go further, Laguna S 2.1 can be post-trained with NVIDIA NeMo AutoModel and Prime Intellect’s Prime Lab. ZML’s LLMD framework runs it across a wide range of hardware.

If you’re not a developer, chat.poolside.ai is a simple web chat with web search and basic code execution. No login required.

If you want the base model, meaning the pre-post-training weights for research or your own post-training, email models@poolside.ai.

Footnotes

All Laguna S 2.1 agentic benchmarking was completed using our internal fork of the Laude Institute's Harbor Framework with our agent harness, a maximum of 500 steps and sandboxed execution via our internal sandbox service. We report mean pass@1 averaged over multiple attempts per task (avg@k), with k per benchmark listed below.

SWE-bench Multilingual and SWE-Bench Pro were run through their Harbor adapters, with every task executing in our internal sandbox service. Storage and memory ceiling limit multipliers were set per benchmark (SWE-bench Multilingual: 2.0/2.0, Terminal-Bench 2.1: 3.0/3.0, SWE-Bench Pro: 1.0/1.0, with a guaranteed minimum of 2 CPU cores, 8 GB memory and 25 GB of storage). These are set to prevent sandbox preemptions.

DeepSWE v1.1 was run on an internal fork of Harbor configured to closely match the official DeepSWE Pier harness (Pier is itself a fork of Harbor). Internet access was disabled and sandboxes used the task-prescribed CPU count with guaranteed RAM and storage, with ceilings tripled to prevent pod preemption.

SWE Atlas (Codebase QnA) followed Scale AI's methodology from their public repository, run through Harbor with no changes to individual tasks or graders, judged by Opus 4.5.

Toolathlon Verified was run as a clone of the sandboxed benchmark harness on an EC2 instance in our infrastructure, with no changes to correct flaky tasks or offset rate limits, using a custom Toolathlon agent. Unlike the official version, we performed a full environment reset and repair after every evaluation run (default is every 4 hours).

  • SWE-bench Multilingual: mean pass@1 averaged over 4 attempts per task
  • SWE-Bench Pro: mean pass@1 averaged over 4 attempts per task
  • Terminal-Bench 2.1: mean pass@1 averaged over 4 attempts per task
  • DeepSWE v1.1: mean pass@1 averaged over 3 attempts per task
  • SWE Atlas (Codebase QnA): mean pass@1 averaged over 3 attempts per task
  • Toolathlon Verified: averaged over 3 runs

Our technical report contains a section on individual task modifications that have been made but not adopted upstream. All final run trajectories are available to view and download at trajectories.poolside.ai.

Maintaining the integrity of our evaluation system

Unless stated otherwise, all of our evaluations are run with access to the internet. This can be a major source of misaligned trajectories where the model finds solutions to tasks online without solving it itself (a.k.a., “reward hacking”).

Using an LLM as a Judge (LLMaaJ) calibrated with human labeled trajectories, we tag solutions that potentially reward hack after every eval. During early post-training we observed low rates of reward hacking (<2%). As training progressed, reward hacking rates spiked on the SWE-bench family of tasks with over 50% of trajectories being flagged. Manual inspection revealed the model was simply doing research to solve the problem, found the PR or repository the task was based on and applied the fix. In practice this is good behavior as any coding agent should be able to use solutions found online. However, this muddies the signal of the benchmark.

To address this we added a small prompt addendum to the user prompt instructing the model to not use direct solutions found online. Though not a guaranteed fix (ProgramBench, MirrorCode were exceptions), in general we did see the model respond and a drop in reward hacking rates to below 2%.

In addition, to confirm acceptable levels of reward hacking, we used:

  • Manual inspection of positive cases flagged by our production LLMaaJ service
  • Ad-hoc open-ended agent-supported analysis of all trajectories
  • Expert annotator review of all trajectories for one of the high-scoring Terminal-Bench 2.1 runs
The Daily Front Page 7 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — AI Business Briefs
article

Advertise in ChatGPT

by montecarl·▲ 645 points·454 comments·ads.openai.com ↗

Reach people as they explore options, compare choices, and make decisions in ChatGPT, with relevant ads that fit naturally into the experience.

Start now

Reach people in the moments that matter

People come to ChatGPT not just to find information, but to explore options, compare choices, and make decisions. That gives advertisers a new way to show up in ways that feel relevant and useful in moments of real intent.

Show up while people explore options and take action

Reach people in ChatGPT as they explore options, compare alternatives, weigh tradeoffs, and make informed decisions.

Go beyond keywords with richer context signals

In ChatGPT, people share richer context, enabling advertising that is more relevant, personalized, and useful.

Be part of the future of AI-native advertising

Reach customers in an advertising environment built around conversation, context, and real-time decisions.

Get started in a few steps

After you sign up, you'll be taken into Ads Manager, where you can create your account, create campaigns, and access step-by-step Help Center resources.

1. Create your campaign

Set up your campaign, budget, and goal.

Get started

Screenshot of a web application interface with a Create dropdown menu open, displaying options for creating campaigns, ad groups, ads, and uploading bulk CSV files.

2. Add your ad details

Bulk upload your ad details, or create them directly in the tool.

Get started

Screenshot of an Ads Manager interface displaying campaign and ad group selections alongside a preview of a sponsored home decor advertisement.

3. Launch and learn

Measure results, edit campaigns, and optimize performance.

Get started

Analytics chart displaying monthly trends for impressions, conversions, and clicks, along with summary metrics and growth indicators.

Results from early advertisers on ChatGPT

Advertisers are already seeing the benefits of AI-native advertising.

Best BuyLowe'sVistaPrint

“Consumers are increasingly turning to platforms like ChatGPT to research and make decisions, so it’s important that we show up in those moments—helping customers explore and discover the latest technology. We’re encouraged by the early results and see this as an important way to stay relevant and top of mind.”

Amy Adams, Vice President of Media at Best Buy

Built with user trust in mind

We’re taking a measured approach to advertising in ChatGPT. Our focus is on building an experience that is useful for advertisers while maintaining the trust people have in ChatGPT.

Clearly labeled

Ads are clearly identified in the experience.

Separate from answers

Ads remain distinct from ChatGPT’s responses.

Choice and control

People control how their data is used for ads.

Helpful resources

Explore step-by-step guides and Ad Manager support.



Ads in ChatGPT: The basics



Ads Manager overview



Quickstart



Account setup

Ready to get started?

Create your account to access Ads Manager, set up your first campaign, and start advertising in ChatGPT.

Start now

The Daily Front Page 8 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — AI Business Briefs
article

Five US tech giants' hidden debts soar to $1.65T on opaque AI funding

by NordStreamYacht·▲ 357 points·248 comments·asia.nikkei.com ↗

Data center leases, GPU supply contracts raise liabilities at Meta, Oracle, Nikkei study shows

20260720N Data center

A Meta data center in the state of Georgia. The company's off-balance-sheet debt is about $420 billion, nearly triple its transparent debt. © AP

PALO ALTO, California -- Hidden debt at U.S. tech giants swelled eightfold in roughly four years to an estimated $1.65 trillion as artificial intelligence investments ballooned, a Nikkei study shows, exceeding actual debt and making it tougher for investors to assess risk.

The Daily Front Page 9 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — The Counterexample Desk
article

Human mathematicians are being outcounterexampled

by artninja1988·▲ 478 points·239 comments·xenaproject.wordpress.com ↗
It’s been an interesting few weeks for counterexamples.

Human mathematicians are being outcounterexampled

It’s been an interesting few weeks for counterexamples. This post is basically my perspective of what has been going on in the world of formalization, AI tools and, in particular, counterexamples.

Unit distance

Two months ago today (20th May 2026), ChatGPT disproved Erdős’ Unit Distance conjecture in discrete geometry. This is now old news but I had to start somewhere. The announcement was accompanied with testimonies by human mathematicians, many of whom I knew and a few of whom I trusted, saying that they believed the argument (they had been given early access to it and had checked it). The basic structure of the proof is that a profound theorem in number theory due to Golod and Shafarevich from the 1960s could be used to construct a counterexample to the conjecture.

It is now 9 years since I had a mid-life crisis, realised I no longer trusted many human mathematicians when it comes to technical details, discovered Lean, and started to argue that interactive theorem provers should play an important role in the future of mathematics. So of course my first question was “is the counterexample formalized in Lean”. The answer was “no”.

But under a week later (26th May 2026), I got an email from Fields Medallist Mike Freedman. Mike is now the Chief Science Officer for Logical Intelligence, a company cofounded by Turing Award winner and “godfather of AI” Yan LeCun. Mike informed me that their system had autoformalized the entire ChatGPT-generated paper in Lean and could I take a look. I looked, and my post-doc Thomas Browning looked too. And indeed this was what Logical Intelligence had done: they had formalized precisely the statement that the profound theorem of number theory implied the Erdős counterexample. Breakthrough LLM-generated mathematics being formalized in real time. Interesting data point.

Of course there is an elephant in the room here though, the profound theorem of number theory which takes 100+ pages to prove (it needs huge chunks of global class field theory, a theory developed at the beginning of the 20th century and for which there are still no short proofs; it is proving difficult to compress). In 2025 I had run a Clay Summer School with Richard Hill on the formalization of class field theory, and one year later we have nearly done the local case (it is the current PhD project of my student Edison Xie); the global case remained open, and indeed in 2025 formalizing global class field theory seemed like a fantasy.

One month later, on June 26th 2026, my perception of what was possible again changed. Boris Alexeev announced on the Lean Zulip that he had steered ChatGPT to a complete formalization of the Erdős counterexample, assuming nothing beyond the axioms of mathematics. Boris works at OpenAI and had used their new model Sol to do the autoformalization. Boris made the code public and it did not take long for me to realise that somewhere within all this AI-generated (and sometimes horrible, although sometimes decent) code was indeed a proof of some really hard theorems in global class field theory. Also of interest to me was that Sol had generated 1.2 million lines of Lean code in the three weeks that it had worked on the project. Lean’s fantastic (declaration of conflict of interest: I am a maintainer) mathematics library mathlib is only 2.3 million lines of code, and took nine years to write. Perhaps it was at this point that the penny really dropped for me — large AI-generated developments of mathematics are inevitable. One cannot trust AI-generated code so I ran it in a sandbox on my machine (malicious Lean code can run arbitrary commands on your computer — Lean is a programming language, after all). Indeed, it was proving nontrivial theorems about the cohomology of number fields. Wow.

Group schemes of order n

A week after Boris’ revelation, in early July, I was thinking hard about how to run my Formalizing Fermat workshop. This workshop was sponsored by Logos Research, who, like Logical Intelligence (and Harmonic and Axiom AI and Moonshot AI and…) have a tool which can autoformalize mathematics — translating it from human language into Lean — building on mathlib. Logos told me that they were only going to allow 5 people at a time to use their system during the workshop, and there were 25 attendees, so I told all attendees that I would buy them a Claude Max subscription for a month, so they had something to experiment with when it wasn’t their turn for Logos’ tool. The workshop was 6th to 10th July, and the Claude Max subscription would give attendees access to Claude Fable, at least until Tuesday 7th, when it was being switched off. When OpenAI got wind of what I was doing, they also offered all attendees free ChatGPT Pro access for a month; this was a big deal because ChatGPT Sol was coming out on the 9th. So basically all attendees would have access to Sol and Fable for 4 out of the 5 days of the workshop, and Logos’ tool for the entire week. In fact Fable access was not removed on the 7th so we were in even better shape.

I was not sure how good Logos’ tool was going to be, but I wanted a development of the theory of finite flat group schemes in Lean for my ongoing proof of Fermat’s Last Theorem, so I put uploaded some classic papers in the area to Fable and ChatGPT, and got them together to write down an exposition of the theory in natural language. I passed this pdf document over to Logos the day before the workshop, and on the first day of the workshop they said that one of the claims in the pdf was false and they had found an explicit counterexample. Another counterexample! I took a look and indeed the LLM-generated pdf was simply wrong at some point when describing a standard construction; false alarm. I had missed this myself though when reading through the pdf. Interesting how AI had again found a counterexample. I fixed the pdf. I thought it was interesting that the AI didn’t just say “I don’t quite follow this argument”, it instead said “here is a proof that this argument is simply wrong”, a much more powerful statement.

With the development of the theory of finite flat group schemes back on track, I could relax back into the FLT workshop. On Tuesday 7th July I sat opposite Akhil Mathew at lunch; Akhil is a professor of mathematics at UChicago and he was an attendee who had been experimenting with the tools available. We talked about potential questions which AI could work on, and Akhil raised the old question of Grothendieck about whether every finite free group scheme of order n was killed by n. Deligne had proved the result in the commutative case, and Grothendieck had proved it when the base was reduced; Rene Schoof had proved it in more cases, and there had even been a paper by Emiliano Torti published last year, proving it in even more generality. I said that I thought that this was a fabulous thing to get AI thinking about.

The day after the workshop finished, on Saturday 11th July, I got a DM from Akhil telling me that Sol had found a counterexample. He sent me a 12 page pdf. I immediately replied saying that I was not reading AI-generated informal mathematics and could he please formalize the entire thing in Lean. Four hours later he replied again, saying that Fable had autoformalized the entire thing. I scanned over the 1076-line Lean file, checking that the code did not delete all the files on my hard drive (Lean is a programming language, so it can do this). Convinced that it was only theorems, I then compiled it on my laptop and it took me under 5 minutes in total to check that (a) the statement of the claimed theorem used only concepts in mathlib (and thus things like HopfAlgebra can be trusted to mean what mathematicians think of as Hopf algebras) (b) the statement of the claimed theorem was that there was a counterexample and (c) the proof compiled. At this point I knew that we had a counterexample — a group scheme of order 4 which was not killed by 4. I suggested to Akhil that he make a PR to mathlib with the counterexample — which he did. I would have also suggested to him that he draft a press release saying that a machine had solved a 60-year-old question of Grothendieck in algebraic geometry, but somehow by this point I was almost becoming immune to all of this. It wasn’t clear to me that the media would even be able to distinguish between “machine resolves question due to Erdős” and “machine resolves question due to Grothendieck” even though I personally found the latter far more interesting. Of course the Grothendieck counterexample was far far easier than the Erdős one (a thousand lines, not a million), all I’m saying is that it’s an area of mathematics that I personally find more interesting. I pointed out to Akhil that machines seemed to be getting very good at finding counterexamples and suggested that he try the Hodge conjecture next.

Modularity lifting theorems

I think it’s worth stepping back at this point and surveying what the attitudes of human experts to these sorts of things are. On Tuesday (14th July) I went to work at Imperial and the Grothendieck counterexample was the talk of lunch. A member of the faculty (who I won’t name) said to me that the fact that the counterexample was so easy to find just indicated that humans had not spent enough time thinking about the problem, implying that a 60-year-old question of Grothendieck was not actually that interesting to work on. I didn’t tell him that at some point earlier in my career I had spent a week working hard on the problem. In my mind my colleague is just going through the five stages of grief; right now they seem to be in the denial phase.

After lunch I met with my PhD student Andrew Yang, who had been working on formalizing a modularity lifting theorem in Lean, something which is crucial to my FLT work. Andrew had come to the Logos FLT workshop and now had access to both Sol and Fable. He told me that using these tools he had written 250K lines of Lean code which basically completely finished the project in what was I guess a 2 week period.

A few days earlier I had got an email from a professor in the maths department here at Imperial, expressing surprise that some of our graduate students were paying $200 per month to access models such as Sol and Fable. He said that he thought that these people were crazy. I did not immediately respond. But after meeting with Andrew I emailed the professor back and told him that in my opinion, any PhD student who was not paying $200 per month to access these tools was crazy. In fact during the workshop I learnt from Harvard PhD student Bryan Wang that Harvard were already giving free Fable access to all PhD students, post-docs and faculty at Harvard.

The Jacobian Conjecture

But back to Akhil. I am not sure if he took my idea to disprove the Hodge conjecture seriously. But it looks like he had deeply understood that, with these extraordinary new AI tools, counterexamples might be low-hanging fruit right now. He had discussed with Levent Alpöge the idea of finding more counterexamples in algebraic geometry, and 12 hours ago Levent posted on X that Fable had found a counterexample to the Jacobian Conjecture. This is a big deal — this is a famous question in algebraic geometry which had been open for 100 years and which many people had thought about. It was apparently solved during the 2026 World Cup Final.

I woke up today to a DM from Akhil saying “shall I make another PR?” but this time he was too late — Paul Lezeau had already formalized the counterexample manually and had made a PR to DeepMind’s Formal Conjectures repo. Mathlib does not contain a large list of conjectures in mathematics, but DeepMind’s repo does. The importance of formalization of conjectures by humans is that if humans are agreed that a Lean statement does faithfully capture the idea behind a conjecture, then checking that (possibly AI-generated) Lean code does comprise a proof or disproof of the conjecture is a triviality. Congratulations to Levent, thanks to Akhil for suggesting the problem to him, and thanks to DeepMind for already having formalized the statement and thus making formal verification of the counterexample a triviality.

The Jacobian conjecture is resolved! Wow! The next step in that work is for humans to understand exactly what is going on with the example. For the true value of work like this is to give humans better understanding of mathematics. Indeed Akhil has been working on trying to understand the Grothendieck counterexample in a way which is far deeper than “here is a random presentation of a random ring and a random calculation which shows that something doesn’t work”. What we need next is the insight which can be drawn from these extraordinary examples.

What a time to be alive.

The Daily Front Page 10 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Inside the Jacobian Shock
article

A digestion of the Jacobian conjecture counterexample

by jeremyscanvic·▲ 237 points·80 comments·terrytao.wordpress.com ↗

The notorious Jacobian conjecture can be formulated concretely over the complex numbers as follows.

Conjecture 1 (Jacobian Conjecture) Let {F:{\bf C}^n \rightarrow {\bf C}^n} be a polynomial map in {n} complex variables, whose Jacobian {\mathrm{det} DF} is a non-zero constant. Then {F} is invertible (with polynomial inverse).

The condition that the Jacobian {\mathrm{det} DF} is non-zero is equivalent to {F} being locally invertible. (The implication of local invertibility from non-vanishing Jacobian follows from the inverse function theorem; the converse implication can be derived from the Weierstrass preparation theorem, but is omitted here.) Also, from the fundamental theorem of algebra, once the Jacobian polynomial {\mathrm{det} DF} is non-zero, it must be constant. So the hypothesis “Jacobian {\mathrm{det} DF} is a non-zero constant” can be replaced with “{F} is locally invertible”. So the Jacobian conjecture can be viewed as an assertion that local invertibility implies global invertibility. The complex numbers can be easily replaced with other fields of characteristic zero by the Lefschetz principle, but I prefer to work in the concrete setting of the complex numbers.

It was recently shown (using the Fable AI) that the conjecture is false in three dimensions (and thus in higher dimensions as well):

Theorem 2 (Counterexample to conjecture) There exists a polynomial {F : {\bf C}^3 \rightarrow {\bf C}^3} which has non-zero constant Jacobian, but is not invertible.

The conjecture remains open in two dimensions, and is easy to establish in one dimension.

The example can be stated completely explicitly: one can take

\displaystyle F(z_1,z_2,z_3) = \Big((1+z_1 z_2)^3 z_3 + z_2^2 (1+z_1z_2) (4+3z_1z_2), \ \ \ \ \ (1)

\displaystyle z_2 + 3 z_1 (1+z_1z_2)^2 z_3 + 3 z_1 z_2^2 (4+3z_1z_2),

\displaystyle 2 z_1 - 3 z_1^2 z_2 - z_1^3 z_3\Big)

and one can verify by a brief calculation that

\displaystyle \mathrm{det} DF = -2

and

\displaystyle F(0,0,-1/4) = F(1,-3/2, 13/2) = F(-1,3/2,13/2)

\displaystyle = (-1/4,0,0).

While this is an extremely quick verification, the construction presented in this fashion appears like a massive miracle. The polynomial {F} has degree seven, so a priori the Jacobian {\mathrm{det} DF} ought to be a polynomial in three variables of degree as large as {3 \times 6 = 18}, so the fact that all non-constant coefficients of this polynomial vanish looks like a massive cancellation involving {\binom{18+3}{3}-1 = 1299} equations, which is much larger than the {\binom{7+3}{3} = 120} degrees of freedom for a generic degree seven polynomial of three variables. So finding such a polynomial looks highly unlikely to be located by brute force.

The example has since been retroactively explained in more geometric terms. As a “digestion” exercise to myself, I sought to write this explanation with relatively little use of algebraic geometry, in a manner that minimizes the amount of “miracles” required, although there are still a few places were some remarkable phenomena occur.

It is convenient to use the local injectivity formulation, and to generalize the domain {{\bf C}^3} to an equivalent affine variety. Namely, we will show

Theorem 3 (Counterexample, reformulated) There exists an affine variety {X \subset {\bf C}^5} that is isomorphic to {{\bf C}^3} by polynomial changes of variable, and a polynomial map {F : X \rightarrow {\bf C}^3} which is locally injective, but not globally injective.

Clearly one can get from Theorem 3 to Theorem 2 by composing with the isomorphism {X \cong {\bf C}^3} and using the previously mentioned fact that local injectivity implies non-zero constant Jacobian. Our objective is now to find data {X}, {F : X \rightarrow {\bf C}^3} that obeys three separate properties:

  • (a) {F} is locally injective on {X}.
  • (b) {F} is not globally injective on {X}.
  • (c) {X} is isomorphic to {{\bf C}^3} by polynomial changes of variable.

The advantage of splitting the problem in to these three components is that we can build towards each of them separately.

It turns out that {F} and {X} can be built out of the operation of multiplication of low degree polynomials. Namely, consider the following three simple affine spaces:

  • The space {\mathrm{Sym}^1({\bf C}^2)} of linear homogeneous polynomials {L(z,w) = az + bw} of two complex variables {z,w}.
  • The space {\mathrm{Sym}^2({\bf C}^2)} of quadratic homogeneous polynomials {Q(z,w) = cz^2 + dzw + ew^2} of two complex variables {z,w}.
  • The space {\mathrm{Sym}^3({\bf C}^2)} of cubic homogeneous polynomials {C(z,w) = fz^3 + gz^2w + hzw^2 + iw^3} of two complex variables {z,w}.

(The notation {\mathrm{Sym}^k(V)} here refers to the {k^{th}} symmetric power of a vector space {V}.) Clearly these spaces are isomorphic to {{\bf C}^2, {\bf C}^3, {\bf C}^4} respectively. Furthermore, we have a multiplication map {F : \mathrm{Sym}^1({\bf C}^2) \times \mathrm{Sym}^2({\bf C}^2) \rightarrow \mathrm{Sym}^3({\bf C}^2)}, mapping a pair {(L,Q)} of a linear polynomial {L} and a quadratic polynomial {Q} to a cubic polynomial

\displaystyle F(L,Q) := LQ.

(Right now, the domain and range of this map {F} is larger dimensional than the target of three; we will cut the dimensions down to three as the argument progresses.)

The map {F}, essentially a map from {{\bf C}^5} to {{\bf C}^4}, is clearly polynomial; it is given explicitly in coordinates as

\displaystyle F( (a,b), (c,d,e) ) = (ac, ad + bc, ae + bd, be). \ \ \ \ \ (2)

The map {F} also enjoys two basic (and commuting) symmetries:

  • If one applies a scaling {(L,Q) \mapsto (\lambda_1 L, \lambda_2 Q)} for some non-zero complex numbers {\lambda_1, \lambda_2}, then the product {LQ} is scaled by {C \mapsto \lambda_1 \lambda_2 C}: {F( \lambda_1 L, \lambda_2 Q) = \lambda_1 \lambda_2 F(L,Q)}.
  • If one applies a change of variables {(L, Q) \mapsto (L \circ T, Q \circ T)} for some invertible linear transformation {T \in \mathrm{SL}_2({\bf C})}, then the product {LQ} is transformed by {C \mapsto C \circ T}: {F(L \circ T, Q \circ T) = F(L,Q) \circ T}.

So this map enjoys a huge amount of equivariance, basically with respect to an action of the five-dimensional group {{\bf C}^\times \times {\bf C}^\times \times \mathrm{SL}_2({\bf C})}.

The five-dimensional domain {\mathrm{Sym}^1({\bf C}^2) \times \mathrm{Sym}^2({\bf C}^2)} is of course larger than the four-dimensional range {\mathrm{Sym}^3({\bf C}^2)}, so the map {F} clearly cannot be injective. This can already be seen from the scaling symmetry, as the specific scalings

\displaystyle (L, Q) \mapsto (\lambda L, \lambda^{-1} Q) \ \ \ \ \ (3)

for {\lambda \in {\bf C}^\times} modify the linear and quadratic polynomials {L,Q} but not their product {C = LQ}. But even if one quotients out by this symmetry (3) to cut the dimension of the domain down to four, the map {F} is still not injective for the following basic reason. A generically chosen cubic polynomial {C} will split into the product {C = L_1 L_2 L_3} of three independent linear polynomials. Then there are three pairs

\displaystyle (L_1, L_2 L_3), (L_2, L_1 L_3), (L_3, L_1 L_2) \ \ \ \ \ (4)

which all map to the same cubic polynomial

\displaystyle F(L_1, L_2 L_3) = F(L_2, L_1 L_3) = F(L_3, L_1 L_2) = C

under the multiplication map {F}, but are not related to each other by scaling symmetry (3). Thus, we see that even after quotienting out by the scaling symmetry (3), the multiplication map {F} is generically non-injective in a three-to-one fashion. Thus we already have achieved something resembling goal (b)!

It will be convenient to “spend” the scaling symmetry {(L, Q) \mapsto (\lambda L, \lambda^{-1} Q)} to obtain a useful normalization. If {L(z,w) = az+bw} is a linear polynomial and {Q(z,w)} is a quadratic polynomial, the resultant {\mathrm{Res}(L,Q)} can be defined by the determinant

\displaystyle \mathrm{Res}(L,Q) = \begin{vmatrix} a & b & 0 \ 0 & a & b \ c & d & e \end{vmatrix} = a^2 e - abd + c b^2. \ \ \ \ \ (5)

If we have a factoring

\displaystyle L(z,w) = a (z - \alpha w), \quad Q(z,w) = c (z - \beta_1 w)(z - \beta_2 w)

then the resultant can also be described as

\displaystyle \mathrm{Res}(L,Q) = a^2 c (\alpha - \beta_1) (\alpha - \beta_2).

Thus the resultant measures whether the linear polynomial {L} and the quadratic polynomial {Q} share a common root. A fundamental fact about resultants is that they are {SL_2}-invariant: for any {T \in SL_2({\bf C})}, we have

\displaystyle \mathrm{Res}(L \circ T, Q \circ T) = \mathrm{Res}(L,Q).

One way to see this is to check it first for translations {(z,w) \mapsto (z, w + h z)} (which translate the roots {\alpha,\beta_1,\beta_2} by {h} while leaving {a,c} unchanged) and for inversions {(z,w) \mapsto (w,z)} (which map {\alpha,\beta_1,\beta_2} to {1/\alpha, 1/\beta_1, 1/\beta_2} while mapping {a,c} to {-a\alpha} and {c\beta_1 \beta_2} respectively), and then noting that these transformations generate all of {SL_2({\bf C})}. They also interact very nicely with scaling:

\displaystyle \mathrm{Res}(\lambda_1 L, \lambda_2 Q) = \lambda_1^2 \lambda_2 \mathrm{Res}(L,Q).

In particular, the scaling symmetry (3) multiplies {\mathrm{Res}(L,Q)} by {\lambda}:

\displaystyle \mathrm{Res}(\lambda L, \lambda^{-1} Q) = \lambda \mathrm{Res}(L,Q). \ \ \ \ \ (6)

Thus, we can (generically) normalize away this scaling symmetry by imposing the condition

\displaystyle \mathrm{Res}(L,Q) = 1. \ \ \ \ \ (7)

We now have a restricted multiplication map (which by abuse of notation we will continue to call {F}) from the four-dimensional variety

\displaystyle { (L,Q) \in \mathrm{Sym}^1({\bf C}^2) \times \mathrm{Sym}^2({\bf C}^2) : \mathrm{Res}(L,Q) = 1} \ \ \ \ \ (8)

to the four-dimensional space {\mathrm{Sym}^3({\bf C}^2)}. This map {F} is still not globally injective, as we can take the three pairs in (4) from before and apply the scaling (3) separately to each of the three pairs to obtain the normalization (7). So we have kept property (b). Furthermore, this map retains the {SL_2}-equivariance (and also one remaining scaling symmetry, though we will not make much further use of that symmetry).

But we now also have property (a)! Suppose we want to show the local injectivity of {F} in the neighborhood of a pair {(L,Q)} with {\mathrm{Res}(L,Q) = 1}. As the resultant is non-vanishing, the root {\alpha} of {L} (which exists in the Riemann sphere, or projective line if you prefer) is distinct from the two roots {\beta_1, \beta_2} of {Q} (though the latter two roots could be equal to each other). Applying the {SL_2} action (which performs Möbius transforms on the roots), one can assume without loss of generality that {\alpha} is the point at infinity (or equivalently {a=0}), thus {L(z,w) = b w} for some complex number {b} and {Q(z,w) = c (z - \beta_1 w)(z - \beta_2 w)} for some complex numbers {c, \beta_1, \beta_2}, with the resultant condition (7) simplifies to {cb^2 = 1} (so in particular {c,b} are also non-zero). It is then clear that if one perturbs {L} and {Q} by a small amount (say, modifying each coefficient by {O(\varepsilon)}), then the root {\alpha=\infty} of {L} will perturb to something large ({\gg 1/\varepsilon}), while the roots {\beta_1,\beta_2} of {Q} stay bounded. Thus, just from knowledge of the product {F(L,Q)}, one can reconstruct which of the three roots of this cubic polynomial will be the perturbed root of {L}, and which two will be the perturbed roots of {Q}; from this and (6), (7) we can also reconstruct the leading coefficient {c} of {Q}, and this completely determines both {L} and {Q}. This establishes the local injectivity property (a). (In fact it is étale, but we will not need the machinery of étale maps here.)

Unfortunately, (the four-dimensional analogue of) condition (c) fails: the quadric hypersurface (8) is not isomorphic to the affine space {{\bf C}^4}. But we can try to get around this by passing to a three-dimensional slice. Let {V} be some three-dimensional affine plane of {\mathrm{Sym}^3({\bf C}^2)} (which we will take to avoid the origin for technical reasons), then we can restrict {F} as a map from the set

\displaystyle { (L,Q) \in \mathrm{Sym}^1({\bf C}^2) \times \mathrm{Sym}^2({\bf C}^2) : \mathrm{Res}(L,Q) = 1; \ \ \ \ \ (9)

\displaystyle F(L,Q) \in V}

to {V}. The latter is clearly identifiable (by linear changes of coordinate) to {{\bf C}^3}. As {F} was already locally invertible, it remains locally invertible under restriction; and because generic cubic polynomials {C} had three preimages under {F} in (8), this continues to be the case after restricting to (9) (unless {V} was somehow so degenerate that it had no generic elements, but this turns out to be impossible). So we have retained properties (a) and (b). The miracle is that, with a good choice of {V}, we can also obtain (c) and obtain the desired counterexample to the Jacobian conjecture: despite appearances, the variety (9) is in fact equivalent to the affine space {{\bf C}^3} by polynomial changes of variable!

Let’s see how. The affine hyperplanes in {\mathrm{Sym}^3({\bf C}^2)} avoiding the origin are parameterized by the dual space of {\mathrm{Sym}^3({\bf C}^2)} avoiding the origin, which one can think of as the non-zero third order homogeneous differential operators {D = j \partial_z^3 + k \partial_z^2 \partial_w + l \partial_z \partial_w^2 + m \partial_w^3} in two variables. Indeed, every such operator {D} generates an affine hyperplane {{ C \in \mathrm{Sym}^3({\bf C}^2) : D(C) = 1}} that avoids the origin, and conversely by duality every affine hyperplane avoiding the origin arises in this form uniquely. Just as the cubic polynomials in {\mathrm{Sym}^3({\bf C}^2)} can be factored into three linear polynomials, the differential operators in the dual space {\mathrm{Sym}^3({\bf C}^2)^*} can also be factored into three linear differential operators, e.g.,

\displaystyle D = j (\partial_z - \gamma_1 \partial_w) (\partial_z - \gamma_2 \partial_w) (\partial_z - \gamma_3 \partial_w)

in the case that {j} is non-zero. The {SL_2} action moves the roots {\gamma_1,\gamma_2,\gamma_3} around the Riemann sphere by Möbius transformations. As these transformations are {3}-transitive, the actual selection of such roots is not too important (and the scaling symmetry similarly makes the choice of leading coefficient {j} unimportant); the only thing to keep track of is whether the roots repeat. Up to the symmetries, there are in fact just three different equivalence classes of differential operator {D} (and thus of affine hyperplane {V}) to consider:

  • Operators where the three roots {\gamma_1,\gamma_2,\gamma_3} are all distinct, thus {D = D_1 D_2 D_3} for independent first-order operators {D_1,D_2,D_3}.
  • Operators where two roots coincide and one is distinct, thus {D = D_1^2 D_2} for independent first-order operators {D_1,D_2}.
  • Operators where all three roots coincide, thus {D = D_1^3} for some first-order operator {D_1}.

It turns out that the affine miracle for (9) occurs precisely in the second case, when {D} has two identical roots. I do not have a completely satisfactory geometric explanation for this miracle, but one can verify it by the following coordinate computation.

By applying the {SL_2} action, we can normalize so that {D = \partial_z^2 \partial_w}, thus {V} is now the affine hyperplane of cubic polynomials {C(z,w) = f z^3 + g z^2 w + h z w^2 + i w^3} with {g=1}. Using (2) and (5), the variety (9) can now be described explicitly in coordinates as

\displaystyle { (a,b,c,d,e) \in {\bf C}^5 : a^2 e - abd + cb^2 = 1; ad + bc = 1 }. \ \ \ \ \ (10)

At first glance this seems to be a generic-looking variety cut out by a cubic equation and a quadratic equation – hardly a candidate to be affine! But observe that if {a} is non-zero, then the second equation {ad+bc = 1} can be solved for {d},

\displaystyle d = \frac{1 - bc}{a} \ \ \ \ \ (11)

and the first equation {a^2 e - abd + cb^2 = 1} can be solved for {e},

\displaystyle e = \frac{1 + abd - cb^2}{a^2}. \ \ \ \ \ (12)

Putting these two equations together, we see that as long as one removes the case {a=0}, the quintuple {(a,b,c,d,e)} is uniquely determined by {(a,b,c)} by a change of variables which is Laurent in {a} and polynomial in {b,c}. Thus we have a nice birational equivalence

\displaystyle { (a,b,c,d,e) \in {\bf C}^5 : a^2 e - abd + cb^2 = 1; ad + bc = 1; a \neq 0 }

\displaystyle \cong { (a,b,c) \in {\bf C}^3 : a \neq 0 }.

Thus we have already almost established property (c): the variety (9) becomes birationally equivalent to {{\bf C}^3} after cutting out the {a=0} subvariety. In particular, for each fixed non-zero value {a_0} of {a}, the corresponding fiber

\displaystyle { (a,b,c,d,e) \in {\bf C}^5 : a^2 e - abd + cb^2 = 1; ad + bc = 1; a = a_0 }

of (10) is equivalent to {{\bf C}^2} by polynomial changes of variable, since we can reconstruct {d,e} from the coordinates {b,c} by the polynomial formulae

\displaystyle d = \frac{1-bc}{a_0}; \quad e = \frac{1 + a_0 d b - c b^2}{a_0^2}.

So we just need to glue back in the {a=0} fiber. Indeed, from (10) we see that the fiber at {0} is just

\displaystyle { (0,b,c,d,e) \in {\bf C}^5 : cb^2 = 1; bc = 1 }.

Now we observe a key miracle: the cubic equation {cb^2 = 1} and quadratic equation {bc = 1} have a unique affine solution {b=c=1} (as opposed to the six possible solutions that Bezout’s theorem might suggest – the other five solutions live on the line at infinity). So the fiber here is also affine:

\displaystyle { (0,1,1,d,e) \in {\bf C}^5 : d, e \in {\bf C} }.

This is extremely encouraging for the purposes of establishing property (c), as it strongly suggests that the variety (10) has the structure of an {{\bf C}^2}-bundle over {{\bf C}^1}, which is already extremely close to being isomorphic to the affine space {{\bf C}^3}. The main remaining task is to make sure that nothing singular happens in the limit {a \rightarrow 0}, and that a global polynomial coordinate chart for (10) that covers both the {a \neq 0} and {a = 0} fibers can be constructed.

The standard way to proceed here is to manipulate various tangent spaces using the modern machinery of algebraic geometry and commutative algebra, but given my own background, I prefer to adopt the language of analysis, and in particular big-O notation (in place of the ideals used in algebraic geometry), in order to investigate the limit {a \rightarrow 0} by hand. On the variety (10), let us use {O(X)} to denote any multiple of {X} by a polynomial expression in {a,b,c,d,e}. Thus, for instance, the equation {ad + bc = 1} implies that

\displaystyle bc = 1 + O(a) \ \ \ \ \ (13)

while the equation {a^2 e - abd + cb^2 = 1} implies that

\displaystyle cb^2 = 1 + O(a) \ \ \ \ \ (14)

as well as the more refined estimate

\displaystyle cb^2 = 1 + abd + O(a^2). \ \ \ \ \ (15)

In the {a=0} case we could conclude that {b=c=1}. Now we perturb this observation. Multiplying (13) by {b} we have {b^2 c = b + O(a)}, which on substitution into (14) gives {b = 1 + O(a)}; substituting this back into either (13) or (14) also gives {c = 1 + O(a)}.

We can get some more precise asymptotics by also taking advantage of (15). Substituting {ad+bc=1} into (15), we obtain after some algebra

\displaystyle 2 cb^2 = 1 + b + O(a^2).

So if we write {b = 1+O(a)} more explicitly as {b = 1 + a y}, then we have

\displaystyle 2 c (1 + 2ay + O(a^2)) = 2 + ay + O(a^2)

and thus

\displaystyle c = 1 - \frac{3}{2} ay + O(a^2). \ \ \ \ \ (16)

Substituting this back into (11) gives an asymptotic for {d}:

\displaystyle d = \frac{1 - bc}{a}

\displaystyle = \frac{1 - (1 + ay) (1 - \frac{3}{2} ay + O(a^2))}{a}

\displaystyle =\frac{1}{2} y + O(a).

Finally, one can insert these estimates into (12), although one only gets a trivial bound in this case:

\displaystyle e = \frac{1 + abd - cb^2}{a^2}

\displaystyle = \frac{1 + a (1+O(a)) (\frac{1}{2} y + O(a)) - (1 - \frac{3}{2} ay + O(a^2)) (1 + ay)^2}{a^2}

\displaystyle = O(1).

Expanding the {O(a^2)} error term in (16) as {a^2 z}, and doing a little more algebra, we thus have a polynomial change of variables

\displaystyle a = a

\displaystyle b = 1 + ay

\displaystyle c = 1 - \frac{3}{2} ay + a^2 z

\displaystyle d = \frac{1-bc}{a} = \frac{1}{2} y - az + \frac{3}{2} a y^2 - a^2 yz

\displaystyle e = \frac{1 + abd - cb^2}{a^2} = -2z + 4y^2 - 4ayz + 3ay^3 - 2a^2 y^2 z

which completely parameterizes the variety (10) by polynomial combinations of three coordinates {a,y,z}. This already gives (a) and thus completes the proof of Theorem 3.

The previous computations, when expanded out, also gives polynomial inverse maps:

\displaystyle a = a

\displaystyle y = 2bd - ae

\displaystyle z = 2d^2 + ce + 6bd^2 + 3bce - \frac{9}{2} e

The map from {(a,y,z)} to the {(f,h,i)} coefficients of {F(L,Q)} (dropping the {g} coefficient which is constrained to equal {1}), we obtain a polynomial map

\displaystyle (a,y,z) \mapsto (G_1(a,y,z), G_2(a,y,z), G_3(a,y,z))

with

\displaystyle \begin{array}{rl} G_1(a,y,z) &= a - \frac{3}{2} a^2 y + a^3 z \ G_2(a,y,z) &= \frac{1}{2} y - 3az + 6ay^2 - 6a^2 yz + \frac{9}{2} a^2 y^3 - 3a^3 y^2 z \ G_3(a,y,z) &= -2z + 4y^2 - 6ayz + 7ay^3 - 6a^2 y^2 z + 3a^2 y^4 \ & \quad - 2 a^3 y^3 z \end{array}

which theory predicts to have a constant Jacobian, and indeed one can calculate that the Jacobian is {-1}. This is essentially the original example up to trivial changes of variable; indeed, one can check that the map

\displaystyle (a, y, -2z) \mapsto (G_3(a,y,z), 2G_2(a,y,z), 2G_1(a,y,z))

is exactly the map {F} given in (1).

AI disclosure: I used an AI chatbot to discuss various aspects of this problem and to confirm several of the calculations made here.

The Daily Front Page 11 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Machines at the Easel
article

"Drawing" the Mona Lisa with GPT-5.6, Claude, Gemini, and Grok

by hershyb_·▲ 171 points·59 comments·tryai.dev ↗
Four frontier models, a blank canvas, and colored pencils.

Four frontier models, a blank canvas, and colored pencils. We tracked every stroke, dollar, and output as they tried to draw the Mona Lisa.

We built a drawing arena: hand a model a blank white canvas and a set of colored-pencil tools, then get out of the way. The model sets a color, tip width, and pressure, lays down batches of strokes, smudges to blend, erases, and calls view_canvas to see its own work and decide what to fix. It either reproduces a target image or draws from a text prompt.

We ran four vision models, GPT-5.6 Sol, Claude Fable 5, Grok 4.5, and Gemini 3.6 Flash, across two targets (the Mona Lisa and Van Gogh's Starry Night, both scored objectively) and five open-ended prompts, for 28 drawings total. We'll cover tool use, cost, output, and whether the models actually improved their work, with our opinion at the end.

Why we run these

A quick note on why we're doing this, because our last one of these (models making music videos) kicked off a good discussion where some folks read it as us promoting the creativity or artistic ability of models. These are not objective tests of model capability. They are deliberately open-ended, fuzzy tasks. Here is why we personally keep running them:

  • They are fun, and genuinely informative. Watching a model tackle a loose, open-ended task is a more interesting visual indicator of capability than yet another benchmark number.
  • They expose the real frontier-vs-open gap. Cheaper open-weight models can absolutely replace the frontier for a lot of execution work, and we will keep reporting on that. But there is also a lot of benchmaxxing out there, and tasks like this cut through it. They genuinely separate frontier capability from the rest. Grok 4.5, as you will see, was rough at this "basic" drawing task, and the open-weight models we tried were not even usable, several just returned a blank canvas. (That may change with Kimi K3 which we will report on once it is fully open-sourced)
  • They show what long-running tasks actually cost. Claude Fable 5 almost always took much longer than the others, for far more money, and here produced worse output. Fable has beaten GPT-5.6 for us on plenty of tasks, including the music-video challenge, but on this one it was worse for a lot more overhead. Depending on your use case, that trade-off matters.
  • We're loving the discussions. The discussions have genuinely been interesting, and if you have suggestions for the setup or new tasks, we will take them into account. These have been a blast to run, and the outputs are super exciting to see.

The tools

Every model worked with the exact same colored-pencil toolset:

  • plan: a no-op scratchpad for thinking and planning between steps.
  • view_target: look at the target image again.
  • view_canvas: render the current page and see it. This is also when we score the drawing against the target.
  • set_color / set_brush / set_pressure: the current pencil color, tip width, and pressure (0 to 1 opacity, low pressure for softer tone).
  • draw: lay down a batch of marks (strokes, lines, shape outlines, dots) in one call. There are no solid fills, tone and color are built by layering, like a real pencil.
  • smudge: blend/soften a rectangular region, like a blending stump.
  • erase / clear_canvas: lift a region back to white / reset the whole page.

The whole harness is open source at github.com/hershalb/canvas-arena. Point it at any target image or a text prompt and run it yourself.

The two target reproductions

The models could see the target the whole time and were scored on structural similarity (SSIM) to it. We show the SSIM scores below.

Mona Lisa (target)GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 FlashMona Lisa targetMona Lisa by GPT-5.6 SolMona Lisa by Claude Fable 5Mona Lisa by Grok 4.5Mona Lisa by Gemini 3.6 Flash

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

Starry Night (target)GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 FlashStarry Night targetStarry Night by GPT-5.6 SolStarry Night by Claude Fable 5Starry Night by Grok 4.5Starry Night by Gemini 3.6 Flash

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

The five prompt drawings

No target, no score, just a text brief and a blank page.

"An elderly fisherman's weathered face, warm late-afternoon sun, deep wrinkles and stubble"

GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 Flashfisherman by Solfisherman by Fablefisherman by Grokfisherman by Gemini

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

"A beautiful sunset over a calm ocean, orange-to-violet sky, silhouetted horizon"

GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 Flashsunset by Solsunset by Fablesunset by Groksunset by Gemini

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

"A single red rose in a glass vase against a dark background, dramatic Rembrandt lighting"

GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 Flashrose by Solrose by Fablerose by Grokrose by Gemini

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

"A tabby cat curled asleep on a windowsill in afternoon sun"

GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 Flashcat by Solcat by Fablecat by Grokcat by Gemini

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

"A cozy cabin interior with a lit fireplace, warm amber light and soft shadows"

GPT-5.6 SolClaude Fable 5Grok 4.5Gemini 3.6 Flashcabin by Solcabin by Fablecabin by Grokcabin by Gemini

Full transcripts: GPT-5.6 Sol · Claude Fable 5 · Grok 4.5 · Gemini 3.6 Flash

The headline numbers

Averages and totals across all seven drawings per model.

ModelDrawings↕Avg steps↕Avg time↕Total tokens↕Est. token cost↕Avg self-reviews↕Total draw calls↕GPT-5.6 Sol7296.2 min3.4M$7.746.0116Claude Fable 575412.5 min14.6M$160.5815.6207Grok 4.57994.8 min34.0M$9.214.3354Gemini 3.6 Flash7736.9 min27.7M$12.8722.6190

Tool calling

The four models used the exact same toolset in completely different ways.

GPT-5.6 SolClaude Fable 5Tool calls, GPT-5.6 SolTool calls, Claude Fable 5

Grok 4.5Gemini 3.6 FlashTool calls, Grok 4.5Tool calls, Gemini 3.6 Flash

GPT-5.6 Sol never called set_color, set_brush, or set_pressure once, it set those inline on each draw call instead, so its calls are almost all draw, smudge, and view_canvas. Grok 4.5 did the opposite: 65% of its 1,349 tool calls were set_color / set_brush / set_pressure, which is why it averaged 99 steps per drawing. Claude Fable 5 leaned on smudge (123 calls) and reviewed constantly. Gemini 3.6 Flash was the most obsessive reviewer of all, nearly a third of its calls were view_canvas (about 23 self-reviews per drawing), and like Sol it never touched the set_* tools.

Avg agent steps per drawing

Cost and tokens

Estimated token cost across all drawings

Total tokens used

Claude Fable 5 cost an estimated $160 for its seven drawings, roughly 20x GPT-5.6 Sol ($7.74), Grok 4.5 ($9.21), or Gemini 3.6 Flash ($12.87). This shouldn't really be a surprise by now. Grok used by far the most tokens (34M) but stayed cheap because ~98% were cached reads at a fraction of the input rate, and Grok's rates are the lowest of the four. Gemini also leaned heavily on cached reads, so even at 27.7M tokens it stayed modest.

Did the models actually improve?

Every view_canvas re-scored the canvas against the target, so we can watch progress over a run. Two patterns held across both targets:

Avg self-reviews per drawing

Similarity over time, Mona Lisa

Similarity over time, Starry Night

First, they plateau early. Claude Fable 5 reviewed its Mona Lisa 27 times, but its similarity was essentially flat after about the fifth review. Second, in all eight target runs, the final drawing scored below the best the model reached mid-run. GPT-5.6 Sol's Mona Lisa peaked at 0.352 SSIM and ended at 0.325; its Starry Night peaked at 0.179 and ended at 0.130. Gemini 3.6 Flash reviewed the most (about 23 times per drawing) and reached the highest peak of the whole batch, 0.449 on the Mona Lisa, then slid all the way back to 0.337 by the end. More reviewing did not translate into a better finish. The models kept editing past their own best performance.

Objective similarity (target runs)

SSIM is 0 to 1, higher is closer to the target. RMSE is 0 to 255, lower is closer to the target.

ModelTarget↕Steps↕Time↕Self-reviews↕Final SSIM↕Best SSIM↕Final RMSE↕GPT-5.6 SolMona Lisa448m41s70.3250.35254.2Claude Fable 5Mona Lisa8618m58s270.2860.28956.9Grok 4.5Mona Lisa1064m30s50.1510.15295.6Gemini 3.6 FlashMona Lisa605m31s220.3370.44951.1GPT-5.6 SolStarry Night235m47s40.1300.17937.8Claude Fable 5Starry Night4311m30s120.1530.17640.9Grok 4.5Starry Night585m51s30.0390.039104.9Gemini 3.6 FlashStarry Night746m36s240.1720.19042.8

On raw SSIM, Gemini 3.6 Flash scored highest on both targets, on final score and on peak, though it also swung the most between its best frame and its final one. Gemini 3.6 Flash looked decent, but definitely does not look the closest to the target output. Very interesting that the raw score turned out to be higher though. As always, SSIM measures structural closeness, not how good the drawing looks to a person (see our take below).

Method notes

  • Four models, two scored targets plus five prompts each, 28 drawings total. All runs used the same colored-pencil toolset. Reasoning was set to high for every model.
  • SSIM/RMSE are computed by resizing both images to 256x256 and comparing. They measure structural/pixel closeness, not artistic quality, and only apply to the target runs (prompts have no reference to score against).
  • Wall-clock time includes the model's own thinking and tool round-trips.

Our take

GPT-5.6 Sol was the runaway leader. Its Starry Night and its rose were our favorites of the whole batch, which is wild considering it drew them stroke by stroke on a blank canvas. It also beat the other two on detail in almost every drawing, the one exception being the elderly fisherman.

Grok 4.5 was basically garbage here. It rarely produced anything usable, and despite its frantic tool use I would not trust it to reliably understand or judge visual output yet.

Gemini 3.6 Flash was definitely better than Grok at a slight cost increase, but comparing the Flash model to frontier versions seems a little unfair. I'm definitely excited to see how Gemini 4 will perform. We also already knew this, but the token output speed is just so impressive.

Claude Fable 5 landed second on quality but at the far end on cost and time. For this task it was the least appealing trade-off of the three: much slower and far more expensive (about 20x the others) for output that did not keep up with Sol.

The Daily Front Page 12 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — VPNs in the Clear
article

'VPNs are lawful technical tools,' says EU Court in landmark copyright ruling

by healsdata·▲ 492 points·81 comments·techradar.com ↗
lawful technical tools

EU

  • VPN providers aren't liable for copyright infringement, said the EU Court
  • The Court explicitly recognized VPNs as "lawful technical tools"
  • The case centered on the copyright battle involving Anne Frank's diary

In a major victory for digital rights and common sense, the Court of Justice of the European Union (CJEU) has officially categorized Virtual Private Networks (VPNs) as "lawful technical tools" while establishing new boundaries for online copyright disputes.

The landmark judgment — handed down in July 2026 — stems from a complex legal battle over the online publication of Anne Frank's historical manuscripts. At its core, the case forced Europe's top judges to answer a highly technical question: if a publisher actively tries to block visitors from a specific country, are they still breaking the law if a user sneaks past the digital border using circumvention software?

According to the CJEU, the answer is no. As long as a website employs "state-of-the-art" geo-blocking technology, the publisher cannot be held liable for copyright infringement simply because a determined reader decides to fire up the best VPN to bypass the restrictions.

The ruling sets a massive precedent. It confirms that copyright holders cannot point to the mere existence of VPNs to claim a website's security measures are completely ineffective.

More importantly for privacy advocates, the court firmly pushed back against the demonization of privacy software, cementing the legitimate status of VPN providers across the European Union.

The Anne Frank dispute explained

The EU's top court just confirmed: Geo-blocking is the copyright holder's problem, not the VPN's. Providers are not liable for users bypassing restrictions ⚖️ @torrentfreak https://t.co/fLwb5kYAy1[July 17, 2026](https://twitter.com/cantworkitout/status/2078089140323688958)

The legal tug-of-war began when a coalition of Dutch and Belgian academic institutions published a free, scholarly online edition of Anne Frank's manuscripts.

Because copyright laws are not fully harmonized across Europe, the legal status of the famous diary varies by territory. In Belgium and roughly 60 other countries, the writings entered the public domain years ago. However, in the Netherlands, parts of the text remain protected by copyright until 2037.

To respect this territorial divide, the publishers hosted the site in Belgium and used geo-blocking to prevent access from Dutch IP addresses. Visitors from the Netherlands were met with a notice explaining why they couldn't enter the site.

The Anne Frank Fonds, which holds the Dutch copyright, sued. They argued that because standard VPNs easily allow users to mask their true IP address and spoof a Belgian location, the scholarly website was effectively communicating the protected work to the Dutch public.

The CJEU ultimately rejected this argument. In its judgment, the court noted that while geo-blocking measures can inevitably be circumvented, "the possibility of such circumvention cannot, in itself and in all circumstances, be a decisive factor in finding those measures to be inadequate and, therefore, ineffective."

Why this matters for the internet and VPN users

For everyday internet users, the "So What?" of this ruling is deeply reassuring. It validates that using a VPN to encrypt your online traffic, hide your IP address, or bypass digital borders is a legitimate use of consumer technology.

The judges explicitly shielded VPN companies from collateral damage in piracy lawsuits, a topic that has sparked intense debate among European ISPs and rightsholders. The court specifically argued that the provider of a VPN or similar services is not liable for users bypassing restrictions.

By placing the legal burden on publishers to maintain "state-of-the-art" digital fences, rather than demanding absolute, impossible perfection, the EU has drawn a pragmatic line in the sand.

Publishers aren't expected to build unhackable walls, and VPN providers aren't responsible for the actions of users who climb over them. Ultimately, this ruling proves that the borderless internet can still coexist with territorial copyright laws, provided everyone uses the right technical safeguards.

The Daily Front Page 13 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Apple, Encryption, and the Court
article

Apple defeats liability for not scanning iCloud for CSAM

by speckx·▲ 403 points·365 comments·blog.ericgoldman.org ↗
the Judge Was Not Pleased

This case involves Apple’s handling of user-uploaded files hosted in private iCloud storage. Instead of adopting PhotoDNA to scan hosted files for CSAM, Apple created its own proprietary alternative, NeuralHash, which apparently wasn’t as good. So Apple U-turned on its efforts to scan for CSAM in its cloud storage. Instead, Apple implemented end-to-end encryption for iCloud files.

Apple’s manuevers confused the public and seemed like an embarrassing unforced error for Apple. It also ensured pressure from governments and plaintiffs, including CSAM victims, who preferred Apple’s more interventionist approaches, which Apple had voluntarily demonstrated it was willing to do.

This lawsuit represents a full-scale attack on Apple and Section 230. “Plaintiffs allege that Apple’s failure to implement any known CSAM detection is a design defect because Apple can safely implement readily available features to prevent the spread of known CSAM but has continuously failed to do so.” Prior blog post. The court dismisses the third amended complaint, which tees this case up for the Ninth Circuit, where (as usual) anything could happen.

* * *

The court reiterates that Section 230 applies to the plaintiffs’ claims:

First, Plaintiffs’ claims treat Apple as a publisher or speaker of the CSAM content that animates Plaintiffs’ injuries. Fundamentally, Plaintiffs contend that Apple has elected to permit users to disseminate and share third-party CSAM content when it could have—and, in their view, should have—used readily available technology to prevent the distribution of child pornography depicting the Plaintiffs in this putative class. The duties Plaintiffs seek to invoke “spring[ ] from the defendant’s status as publisher,” and consequently, “immunity applies.” Second, immunity also applies because “the means to avoid liability requires [Apple] to act as a publisher.” As a result, Apple is entitled to complete immunity under § 230.

Citing Doe 1 v. Meta, the court says:

Plaintiffs’ injuries are the direct result of the actions of third parties who used iCloud to share CSAM, a use Apple neither explicitly condones nor prevents (even assuming—as alleged in the TAC—that Apple was aware of the use of iCloud for this purpose)….though Plaintiffs allege that Apple knew that its tools were likely to be used to distribute child pornography (as confirmed by the internal Apple text messages at the center of this case), under the current state of the law, Apple is still entitled to immunity under § 230—irrespective of that general knowledge….

Plaintiffs cannot avoid the fact that a tool that detects CSAM must review CSAM to make such a determination. And while Apple could have taken steps to do so—as its competitors have done by using PhotoDNA—Grindr confirms that § 230 bars claims arising from the design decisions Apple could have taken where those claims relate to Apple’s role facilitating the communication and content of others

(A reminder that the defendant’s scienter is irrelevant to Section 230).

The plaintiffs tried to fit into the new Section 230 exceptions created in Doe v. Twitter, but the court rebuffs the move:

This case does not concern or even discuss Apple’s content reporting systems; it concerns Apple’s “failure to implement industry-standard safeguards” against the dissemination of CSAM. Though reporting systems and CSAM safeguards may both be described as “defects,” the latter requires the Court to treat Apple as a publisher. Twitter “could fulfill its purported duty to cure reporting infrastructure deficiencies without monitoring, removing, or in any way engaging with third-party content”; Apple cannot fulfill a duty to institute CSAM safeguards without deploying a tool like NeuralHash or PhotoDNA. Both NeuralHash and PhotoDNA were built to monitor and report violative images uploaded to company servers. Yet just the decision regarding whether to deploy either tool is a choice related to content moderation.

Also, Apple didn’t fail to satisfy any duty to report items to NCMEC if it never identified CSAM in the first place.

The Lemmon v. Snap workaround fails: “all of Plaintiffs’ claims here are inexorably linked to third-party content; Plaintiffs do not allege that Apple created content like a Snapchat filter that caused them harm.” The Roommates.com workaround also fails: “Plaintiffs do not allege that Apple modified or augmented the CSAM on its servers in any way.”

* * *

The case reaches its inevitable denouement of a win for Apple. However, Judge Wise remains troubled about its implications. She expresses her uneasiness in stronger-than-normal terms:

As it stands, nothing in the law prevents any company, including Apple, from utilizing available technology or creating new technology to identify and report child pornography stored and distributed on their traditional servers or through their cloud services. Conversely, there is no law that obligates companies to proactively do so. Undoubtedly any such legislation would come at a cost of at least some loss of privacy for millions of people. But if lawmakers expected that companies would take steps to prevent their products from being used for storing and distributing child pornography based on something short of a legal imperative, this case, like many others before it, demonstrates the inadequacy of that approach. If lawmakers want to ensure that Apple and other companies address their role in the dissemination of CSAM, they must require it under the law. In other words, lawmakers can fix this problem that is contributing to the exploitation of children.

She goes through this framing pretty quickly, but we should slow it down. The “loss of privacy for millions of people” she briefly references deserves a little more care. The opinion downplays the encryption angle; it mentions encryption only twice, as if it’s an afterthought. However, encryption is the critical attribute underlying Apple’s moves. Forcing Apple to scan for CSAM in iCloud means breaking end-to-end encryption for everyone and all purposes, including: malefactors who would intercept private files for criminal purposes; and government actors who have repeatedly shown that they will break into, distribute, and weaponize privately stored file caches (I was just thinking about the North Korea Sony hack. Remember it?).

So yes, the “privacy loss” Judge Wise mentions indeed would be a major cost to everyone. Worse, it would ensure new victims have their sensitive, private, or abusive images nonconsensually intercepted and disseminated. (Do you recall the Fappening and Snappening?) End-to-end encryption isn’t just some nice-to-have feature; it is one of the core planks of a technology architecture that keeps people safer.

Judge Wise continues:

This Order does not turn on whether Apple’s decisions contributed to Plaintiffs’ injuries. All Plaintiffs’ claims are founded on Apple serving as a publisher of third-party content. It is that role as “publisher” that is dispositive on the issue of immunity. This does not mean that the existence of images and videos of the putative class members being sexually abused—content that they allege is regularly stored and disseminated on iCloud—has not caused Plaintiffs real and lasting harm…

the outcome also adds credence to claims that the Ninth Circuit “has expanded § 230(c)’s scope to provide functional immunity to internet companies, even when they are aware (or should be aware) of unlawful content on their websites.” The practical outcome is that the current state of the law prioritizes privacy—a laudable and critically important value given that in our modern world nearly all our most personal and intimate data (including financial and health records) are stored and transmitted online. But the law should not ignore how those who create, view, and distribute child pornography leverage privacy protections to avoid detection by law enforcement. In the current legal framework, there is no protection for members of the putative class—individuals who as children were photographed and filmed while being abused in the vilest ways imaginable, and who now are repeatedly victimized each time the intimate and tortured images of their trauma are distributed to others. Those children are the collateral damage of our ineffective legal landscape. They deserve better.

Judge Wise isn’t well-situated to compare the relative strengths and limitations of the full range of potential anti-CSAM options, but a leading tool has always been and remains the government’s efforts to find and prosecute the creators, disseminators, and downloaders of CSAM. (Do you recall the federal government’s choices that leave children more vulnerable?) Making sure the government is doing what it can should be the #1 priority. In contrast, breaking end-to-end encryption shouldn’t be anywhere in the regulatory toolkit.

Case Citation: Amy v. Apple Inc., 2026 WL 2031817 (N.D. Cal. July 13, 2026). The complaint.

The Daily Front Page 14 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — License Plates and Public Trust
article

Flock Credibility Lost as It Repeatedly Lies to City Councils, Police, & Public

by StatsAreFun·▲ 461 points·162 comments·aclu.org ↗
a need for reputable governments to avoid working with Flock Safety

A solar-powered Flock camera is mounted on a pole beside a busy multi-lane road, with cars and a utility truck driving through the intersection in the background.

The ACLU documents how an automatic license plate reader company has lied about its operations, signaling a need for reputable governments to avoid working with Flock Safety.

During a city council meeting in a suburb of Wisconsin in April, the city of Oshkosh considered whether it should approve a contract to use automatic license plate readers (ALPR) from Flock Safety, a prominent company that provides ALPRs to law enforcement agencies across the country. During the meeting, one city council member asked Flock if the company’s ALPR system created heat maps that could reveal where a particular vehicle had driven over a period of time. Flock’s chief information security officer, who was in attendance, told the council that Flock’s system did not “create a pattern or heat map of an individual’s movement” through the tracking of their vehicles. At the end of that meeting, the Oshkosh City Council approved a contract with Flock. The very next morning, the city learned that Flock had lied.

Later that day, the city council reconvened to discuss what it had learned. Confronting Flock, Oshkosh Deputy Mayor Joe Stephenson said “I don't know how this body can govern if someone tells untruths, mistruths, exaggerated truths. I don't know how I can make a decision or discern what's right or what's wrong, or even the capabilities of this system if you lie to me.”

“Shame on them,” Oshkosh Mayor Matt Mugerauer added. “All I'm saying is if you give bad information, then I just don't want to work with you.”

Ultimately, the Oshkosh City Council voted to immediately revoke its approval, thereby setting a record for the shortest time between a city approving and cancelling a Flock contract: one day.

Flock later admitted that its ALPR system does indeed produce a “heat map” that shows where “point-in-time images have been captured of a vehicle” for up to an entire month. However, the company chose to respond to the revocation of its contract by attacking the City of Oshkosh and its city council, complaining that Flock had “not [been] afforded the opportunity” to explain its lie after being caught. Flock also sought to trivialize its factually inaccurate statement by categorizing it as “one small misconception” and referring to the dispute over the system’s heat map tracking feature as “a minor nuance.”

What happened in Oshkosh was not an isolated incident. Rather, it reflects a pattern of Flock regularly misleading or even lying about its business practices, safety record, commitment to privacy, and efforts to protect vulnerable populations. And as was the case in Oshkosh, Flock’s lies are not just directed at the general public; they often specifically target Flock’s potential government customers. The urgent takeaway for government officials and police departments is that they should be extremely hesitant to believe anything Flock’s tells them about its company, its products, or its commitment to safety and privacy.

Flock's Pattern of Lies

This is far from the first time Flock has misled the public and elected officials. The company has demonstrated a pattern of treating legitimate operational questions and concerns not as problems to be solved, but rather as mere public relations issues.

In Colorado, Loveland Police Chief Tim Doran raised concern that federal agents were accessing the town’s ALPR data. Flock responded by telling the chief that federal agencies no longer had access to Loveland’s license plate readers, and had their CEO reiterate to the press that federal data sharing was a non-issue because Flock had no federal contracts. After contradictory information later came to light, the company was forced to admit that it did, in fact, have contracts with U.S. Customs and Border Protection (CBP) and Homeland Security (DHS) for pilot projects that gave those agencies direct access to license data. “We clearly communicated poorly,” Flock’s CEO said, acknowledging that Flock’s “public statements inadvertently provided inaccurate information.”

Last year, reports revealed that, even in the absence of federal contracts, cooperating police officers and departments were regularly sharing Flock ALPR data and search results with immigration agencies like U.S. Immigration and Customs Enforcement (ICE) and CBP. The company responded to the reports with a disingenuous blog entitled “Does Flock Share Data With ICE? No. Flock Does Not Work With ICE.” In its blog, the company pushed back by asserting that “ICE does not have direct access to Flock cameras, systems, or data” and that license data is “owned and controlled by the customer.”

Flock knew that, despite not being a customer, ICE had indirect access to Flock’s data and system through the company’s state and local law enforcement customers. The issue was never about having direct access to Flock’s data, it was about having any access to the data. But rather than address these data security and control issues on their merits, Flock released a misleading blog which reads as an attempt to confuse the public and create a false sense of security among its potential government customers. Ultimately, Flock was forced to accept that its denials were simply not credible. The CEO admitted Flock was used for immigration enforcement but argued that such matters were not Flock’s problem.

In May 2025, the press began reporting that Flock’s ALPR system had been used by law enforcement in at least one state, Texas, to track down a person seeking abortion care in another state, Illinois. Flock sought to assuage concerns about its system being used for cross-state abortion enforcement by unveiling “New Product Solutions to Strengthen Compliance” led by its “Proactive Search Term Tool.” In describing this new tool, Flock wrote:

Screenshot of a Flock webpage titled “New Product Solutions to Strengthen Compliance,” describing a “Proactive Search Term Tool” launched June 12, 2025. The page says Flock deployed a safeguard to block impermissible searches from accessing Illinois data in real time, including requiring a search reason and automatically excluding Illinois camera data when search terms indicate an impermissible purpose under Illinois law.

While Flock claimed its new oversight tool would “significantly” reduce the risk of improper uses like abortion enforcement, in reality the tool doesn’t work. As an investigation by our colleagues at the ACLU of Massachusetts found, Flock network audits showed police frequently enter vague terms like “investigation” or “susp” instead of information about the substance of the investigation into the search reason field. In September 2025 alone, a local Oregon police department was allowed to search Flock’s ALPR system after entering “investigation” into the search reason field 111 times and “hehehe” into the field on 20 occasions, which demonstrates how easy it is to search Flock’s system while avoiding security-triggering words like “abortion.” Flock certainly would have known, if it conducted even a rudimentary test of its system, that the search field’s protections were extremely simple to circumvent. Nevertheless, Flock’s financial interests appear to have been better served by the company misrepresenting the efficacy of its security features to the public and its potential government customers.

Flock Even Lies About Partnering with the ACLU

Flock has even made false claims to the public and elected officials about working with the ACLU. Earlier this year, after the ACLU of New Mexico and Flock supported the same state-level ALPR legislation — albeit for very different reasons — Flock’s Senior Director of Public Affairs took to social media to claim that Flock partnered with the ACLU of New Mexico to craft the bill and pass it.

Screenshot of a LinkedIn post by Trevor L. Chandler stating that Flock partnered with the ACLU of New Mexico and law enforcement in New Mexico to craft a bill balancing community safety and community values. The post includes hashtags about Flock cameras and public safety and links to a New Mexico Department of Public Safety article titled “License Plate Readers save lives; lead to ‘precise policing'..."

Screenshot of a LinkedIn post by Trevor L. Chandler about Flock, ACLU of New Mexico, and immigrant rights groups supporting a data privacy bill. The post includes a link preview from ACLU of New Mexico titled “Driver Privacy and Safety Act (SB 40) Clears Legislature, Heads to Governor’s Desk.”

This was not the first time the ACLU has caught Flock falsely claiming to have worked with us. During an Urbana, Illinois City Council meeting in 2021, the company told councilmembers 23 minutes into the discussion that “Flock has worked with groups like the ACLU to design an ALPR system that takes considerations they have into account.”

To be clear, neither the ACLU nor any of our affiliates have ever partnered with Flock Safety or worked with them to design any ALPR system. As an organization that has spent 106 years earning our good name and reputation, we can confidently advise Flock that lying to the public and elected officials about your work and your relationships is not how you get there.

Ultimately, reputable governments should not do business with disreputable companies. While governments should think long and hard about not using ALPRs, if local governments insist on doing so, at a bare minimum, they should adopt strong guardrails governing future ALPR use – including strictly limiting data retention, data sharing, and what crimes they can be used to enforce. And, of course, they should refuse to partner with any company that regularly misleads the public, elected officials, and even its own customers.

The Daily Front Page 15 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — The Disappearing Drive
article

My USB Drive Has a Hidden Encrypted Vault

by machinehum·▲ 220 points·112 comments·rootkitlabs.com ↗
There’s no way for the OS to detect the remainder of the disk.

Many places don’t respect privacy laws, in certain situations you may be forced to unencrypt your media, or worse, assumed to be guilty. A Veracrypt hidden volume is useful in the former situation, but not the latter.

This is why I made Phantomdrive.

Phantomdrive is a completely open source USB drive that appears as an 8 GB drive when first plugged in. There’s no way for the OS to detect the remainder of the disk. If the user edits a plaintext file on the disk with the contents password:PUTYOURPASSWORDHERE, it unmounts itself and remounts the second hidden section and AES-256 encrypts/decrypts in place.

With Phantomdrive, hopefully you’ll slip past authoritarian government representatives, corrupt police, and anyone else that doesn’t respect basic encryption rights.

The Design

Everything is completely open source: the firmware, hardware and mechanical engineering. The tools I used to design the device are also open source. Lets get into the design!

For this project I used an interesting little chip called the CH569. It’s from the same company who make the USB to Serial chip (CH340) found on virtually every knockoff Arduino.

For this project I’m making use of the USB3, SD/eMMC and the AES block. The SM4 encryption block you can see above is apparently standardised for commercial cryptography in China - Wikipedia.

Due to AI demand the cost of eMMC memory is unusually high, so I chose to go with an SD card for memory. Someone will find your SD card if they tear it apart, but of course everything is encrypted. I used epoxy to glue the case together, meaning an attacker must destroy the device if they wish to get inside. If this doesn’t fit your requirements, I suggest you look elsewhere 😊

Once eMMC prices come down, there will be a version that uses it.

The device is simple, just the CH569, USB port, two buck supplies, a button for firmware update, SD card and some support components. There’s also UART test points, which help with firmware development.

The Cryptography

I wasn’t getting notifications when “people” opened several AI-generated GitHub issues on my repo. They outlined a mixture of: already patched problems, AI hallucinations, and small issues being blown out of proportion. Reddit dogpiled on this pretty quickly, while I was asleep.

This was a big fail on my part, I should have at least noticed people were opening issues. Most of them were non-issues, with the exception of AES-XTS which I’ll talk about below.

As for the security of the device, I’ve verified things with functional tests like this, where you can be sure the encryption is working and verified against OpenSSL’s implementation of AES.

The Key Derivation Function (KDF)

A KDF or “The Key Derivation Function” is a function used to generate a key for use in cryptography. Let’s start with the shittiest way to derive an AES key.

$$ K = Pw || 0x000 $$

We take our password, appending zeros to it until it’s 32 bytes (for AES-256) and that’s our key. With a shitty password, like “password1234”, we can brute force this in a matter of minutes. With a good password this turns into hours, and with a really good password maybe years to decades.

But what if the attacker uses a precomputed table of keys? This means they don’t even have to compute anything. To combat this issue we add a salt.

$$ K = Pw || salt || 0x000 $$

If every device has a unique salt, the attacker needs to compute keys on a per-device basis, so the lookup table problem goes away. Since the salts are different you can’t take your SD card out of one device and put it into another. Here’s how you get your salt…

udevadm info --query=property --name=/dev/sdc | grep ID_SERIAL_SHORT
ID_SERIAL_SHORT=Phantomdrive:34FC1FA7145467F7

So 34FC1FA7145467F7 is this device’s salt, which you need for data recovery if your device ever breaks. FYI: You can change “Phantomdrive” and the USB PID/VID to whatever you want by changing the firmware to increase stealth.

Let’s now assume our attacker has a really powerful machine, has gotten your salt and now will compute their own “table”. To make this a little harder we add 100,000 rounds of SHA-256 to the KDF.

$$ K = sha256(sha256(sha256(Pw || salt || 0x000))) … 100k $$

I chose 100k rounds because the device takes ~3 seconds to unlock, any more and it takes longer. I can’t use algorithms like Argon2, because those are memory-hard. If you have a better way to do this, without making the unlock procedure more than 5 seconds I would love to hear it, but we’re at the compute limit for this device right now.

If you need more security you can increase the number of KDF SHA256 rounds, look for another device, or double encrypt this device using a software solution. It’s also possible to simply turn off encryption and just use software based encryption.

AES Modes

AES is a block cipher, meaning it can encrypt and decrypt a fixed (16-byte) amount of data. There are various different AES modes to turn it into a stream cipher.

AES-ECB

AES-ECB or Electronic Codebook is the naive way to make a stream cipher. You simply take every 16-byte block of plaintext in your stream and encrypt it. Boom! We just made a stream cipher. This is insecure for a few reasons.

  1. The same plaintext blocks will make the same ciphertext blocks, creating a lack of diffusion.
  2. Attackers can remove data in ciphertext and when decrypted plaintext will be modified in a predictable way.

So this isn’t a good way.

AES-CTR

AES-CTR or Counter is a way to solve the issues above. It works in a simple way, you AES encrypt your counter, then XOR the output with your cleartext.

uint64_t i = 0;
while(i < len(ciphertext)) {
	ctr = aes_encrypt(i);
	ciphertext[i] = plaintext[i] ^ ctr
	i++;
}

It’s pseudocode but you get the point.

There’s a security risk involving “counter reuse” you should be aware of when using this mode.

  1. Attacker recovers your ciphertext, puts your device back.
  2. You write a bunch of fresh new data.
  3. Attacker recovers your ciphertext again.
  4. If the attacker can then guess one of the ciphertexts, they can recover the other ciphertext.

With this device I’m getting around 9MB/s write and 20MB/s read with AES-CTR and 6MB/s write and 10MB/s read with AES-XTS. For me this isn’t a big enough security gain over speed to warrant going to AES-XTS, but you might have a completely different case.

AES-XTS

AES-XTS or Tweaked Codebook Mode is the standard for disk encryption. It works by using two keys: \(K_1\) is your data key, and \(K_2\) generates the tweak key.

For each disk sector you need to compute a tweak key from the sector number \(S\).

$$ T_n = AES(K_2,S) $$

Each 16-byte block gets its own tweak, so you end up with \(T_0\), \(T_1\), \(T_2\) … \(T_n\). You then encrypt block by block of your plaintext \(P\) to get your final ciphertext \(C\).

$$ C_n = AES(K_1, (P_n \oplus T_n)) \oplus T_n $$

This solves the counter reuse issues listed above, but is a little bit slower.

The Firmware

I used two projects; thanks to their maintainers.

There are a few parts of the firmware you might be interested in…

Password Snooping

The device isn’t actually filesystem aware, it just takes USB WRITE10/READ10 commands and translates these into CMDx commands for the SD card. So to do the unlock wizardry we just look at raw data, in the unlock state it looks like this.

void phantomdrive_snoop_write(uint8_t *buf, uint32_t len)
{
	const char *prefix = "password:";
	const size_t prefix_len = 9;
	uint32_t i;

	for (i = 0; i + prefix_len <= len; i++) {
		if (buf[i] != 'p')
			continue;
		if (memcmp(buf + i, prefix, prefix_len) != 0)
			continue;

		size_t pw_start = i + prefix_len;
		size_t pw_end = pw_start;
		while (pw_end < len && (pw_end - pw_start) < sizeof(pending_pw) &&
		       buf[pw_end] != '\n' && buf[pw_end] != '\r' && buf[pw_end] != '\0')
			pw_end++;

		size_t pw_len = pw_end - pw_start;

		// Copy the password into RAM here
		memcpy(pending_pw, buf + pw_start, pw_len);
		pending_pw_len = pw_len;

		// We then zero out this buffer so the
		// password is never written to the disk
		memset(buf + i, 0, pw_end - i);
		return;
	}
}

The device isn’t filesystem aware, so when locked it calls this function before every write. It’s snooping on all writes, and matching against password:. This means that if you use the insecure portion of the disk for a ton of stuff, you might get an accidental match if your data contains the string password:. Again, if this doesn’t fit your requirements you can change it or look for another device.

The End

Thanks for reading and supporting this project. It’s been fun to work on and has gotten lots of interest in the community. This type of interaction is what motivates me to continue working on stuff like this.

If you’re interested in supporting this project, we have a preorder page up now!

The Daily Front Page 16 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Open Tools and Home Labs
article

Apple Private Cloud Compute SoC 3 audit reports

by throwfaraway4·▲ 124 points·50 comments·support.apple.com ↗

Apple Private Cloud Compute SOC 3 audit reports

System and Organization Controls (SOC) reports are internal control examinations created by the American Institute of Certified Public Accountants (AICPA). Apple commissioned an independent examination of its controls over the Private Cloud Compute (PCC) Provisioning System; the SOC 3 report details the independent auditor’s examination of whether those controls operated effectively throughout the period. This report provides reasonable assurance as to whether Apple’s service commitments and system requirements were achieved based on the applicable trust criteria.

SOC 3 overview

The SOC 3 report is an independent examination report that describes the service commitments and system requirements of Private Cloud Compute that Apple designed and that operate in accordance with the trust services criteria relevant to security, processing integrity, and confidentiality, outlined in AICPA Trust Services Criteria, Trust Services Principles section 100, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy.

SOC 3 reports

You can download the reports here:

  • April 2026: Examination period ending April 30, 2026
  • January 2026: Examination period ending January 31, 2026
  • October 2025: Examination period ending October 31, 2025
  • July 2025: Examination period ending July 31, 2025

SOC 3 report FAQ

What is a SOC 3 report? An SOC 3 report contains a written assertion by service organization management that affirms whether the controls were designed and operated effectively to achieve the service commitments and system requirements based on the applicable trust-services criteria.

What is the subject matter of the SOC 3 reports? The reports address the Apple Private Cloud Compute Provisioning System, specifically the processes used for the provisioning, ongoing verification, and protection of information within compute nodes, and the related policies, procedures, and control activities.

Does this report cover Apple Intelligence? The examinations were not conducted to evaluate the performance or integrity of Apple’s artificial intelligence services. Accordingly, the independent auditor does not express an opinion or any other form of assurance about Apple’s artificial intelligence services.

How often is this report updated? Apple issues PCC SOC 3 reports quarterly on a 12-month rolling basis. Each report covers a rolling 12-month period, updated quarterly. For example, a report ending January 31 is followed by a report ending April 30.

For questions about Apple Security and Privacy Certifications, contact security-certifications@apple.com.

The Daily Front Page 17 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Open Tools and Home Labs
repository

Incremental – A library for incremental computations

by handfuloflight·▲ 334 points·67 comments·github.com ↗
★ 1,437⑂ 74 forks OCaml

A library for incremental computations

Incremental is a library that gives you a way of building complex computations that can update efficiently in response to their inputs changing, inspired by the work of Umut Acar et. al. on self-adjusting computations. Incremental can be useful in a number of applications, including:

  • Building large calculations (of the kind you might build into a spreadsheet) that can react efficiently to changing data.
  • Constructing views in GUI applications that can incorporate new data efficiently.
  • Computing derived data while guaranteeing that the derived data stays in sync with the source data, for instance filtering or inversing a mapping.

You can find detailed documentation of the library and how to use it in incremental/src/incremental_intf.ml. You can also find an informal introduction to the library in this blog post and this video.

The Daily Front Page 18 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Open Tools and Home Labs
article

Jellyfin founder Andrew leaves team

by swat535·▲ 361 points·326 comments·forum.jellyfin.org ↗

Project Leadership Changes

Don't worry, no jellyforks here.

Hello everyone. Effective yesterday, Anthony and I decided to depart from the project, myself as Project Leader, and he as a core team member. This is in addition to the resignation of Andrew on Friday. We leave the project in the very capable hands of the remaining team who have been driving the project for many years now.


Joshua:

For me personally, it was just time for a change. I simply could no longer provide the effort (mental or time-wise) that the role demanded, and thus I was not performing my duties to an acceptable degree, facing severe burnout, and risks to my mental health. It was time to step aside. Hand-off is ongoing and is amicable, and there is good communication lines, so there is little to no risk of a hostile fork or anything of that nature. Jellyfin will continue for a long time to come, just not with me at its head.

When I started Jellyfin, I thought it would be something used by a few hundred, or maybe if we were lucky, a few thousand, users. We might put a few pet features in, and do a bit of cleanup, but really, I didn't expect much. Now here we are 7-and-a-half years later, and it's the #1 FLOSS media server, a truly viable alternative to Plex for literally millions of server administrators and probably 10x that many individual users, and we've left our parent project completely in our dust. We've proven that FLOSS works, and is in demand.

I truly hope Jellyfin outlives me, and I trust those in the team to keep the philosophy and code alive.

For the last time, happy watching all!


Anthony:

My particular reasons are a bit different, so I figured I would post as well.

For myself, though I don't touch much code these days, I do a lot to manage things in the backend and with App Stores/etc. After 7.5 - nearly 8 - years, it's been a long time since I've been able to give much of my free time to Jellyfin. My life is changing and I've got other things that must take priority. 

I am fully committed to a smooth transition, which is something I've wanted for a long time anyway. Even if the transition takes a year, I'm still down to do that. I want Jellyfin to succeed, and it should.

The Daily Front Page 19 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Open Tools and Home Labs
The Daily Front Page 20 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Managing the Human Machine
article

The Psychology of Software Teams

by dcre·▲ 173 points·53 comments·routledge.com ↗
a secret weapon: the psychology that creates resilience

Description

To build the future, we need new ways of supporting software teams. This book will give you a secret weapon: the psychology that creates resilience for developers, sustainable practices for software teams, and innovation for organizations. You’ll learn from rigorous empirical evidence gathered from top engineering organizations and thousands of developers around the world, revealing powerful principles software teams can use to guard against failure and drive cultures of collaboration and problem-solving.

Making incredible software doesn’t have to be a death march—this book presents a humane alternative for software teams looking to use the transformative power of behavioral science to understand what drives technology businesses forward. The Psychology of Software Teams provides a model for developers and leaders who want to bring the human back to tech and take a science-based approach to unlocking the “black box” of software engineering.

This book is for the developers and builders of the future. Bringing science and heart together, The Psychology of Software Teams will teach you how to untangle your thinking from pervasive myths about software work and harness the superpowers of psychology to create more joyful, innovative, and thriving environments for software.

Table of Contents

1. The Brains and Hearts That Build the World 2. Breaking Up with Brains-in-Jars 3. More Bands and Fewer Rockstars 4. The Performance Paradox 5. Conflict or Coalitions? 6. Becoming an Organization That Wants to Understand Itself 7. Fighting Dirty for Good Culture

Critics' Reviews

“In The Psychology of Software Teams, Cat Hicks has delivered an indispensable and long-overdue message that demystifies software team development. With touching compassion for software developers as people with individual needs and essential social connections, she brings research and insight to explode the tired debates about "developer productivity," and provide real answers and practical approaches for improvement.

The Psychology of Software Teams is essential reading for anyone engaged in building, supporting, or growing software teams.”

Eli IsraelManaging Partner, Gartner Consulting

 

“If you lead engineers and believe culture is ‘soft,’ this book will disabuse you of that notion quickly. Psychological safety, learning, and collaboration aren’t perks, they are infrastructure. Ignore them and your systems will fail, slowly or catastrophically.”

Scott HanselmanVP of Developer Community, Microsoft

 

“This book presents an empathic, evidence-based analysis of developer productivity, and provides practical guidance based on the author's own research for avoiding or fixing common traps. The result is the most important new perspective on software development in years.”

Greg Wilsonthird-bit.com

 

The Psychology of Software Teams by Cat Hicks is a vital companion for any leader building a humane, high-performing organization. She skillfully dismantles the ‘Brains-in-Jars’ myth, proving that innovation is not a solitary act but the result of social learning. By introducing cognitive scaffolding and fostering thriving ecosystems, Hicks provides the missing link between organizational design and the individual human experience. This book aligns perfectly with the principles of fast flow of value; it is not just about speed, but about empowering people to excel without burnout. Essential reading for forward-thinking leaders ‘moving beyond the machine’.”

Matthew SkeltonHolistic Innovation matthewskelton.com. Co-author of Team Topologies and Internal Tech Conferences

“Dr. Cat Hicks is a category of one. If there are any other psychologists that have devoted their career to researching software practitioners, I am unaware of them. Likewise, while most of the concepts and arguments in the book are ones I have heard before, I have never heard them composed, broken down, and defended in such a precise and scientific manner.”

Charity Majors, cofounder & CTO at honeycomb.io

The Daily Front Page 21 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — The Nursery School of Constraint Solving
article

My two year old taught me constraint solving

by bambataa·▲ 110 points·37 comments·thecomputersciencebook.com ↗
I am expressly NOT permitted to touch the trains

Reading on email? The visualisations will work better in browser.

My son is two years old, which means he has an Apollonian will to power and loves all kinds of mechanised transportation and earthworks machinery. His particular joy is “playing choo-choo” with a Brio wooden train set. Since he likes me to be involved, but I am expressly NOT permitted to touch the trains, I amuse myself by building interesting track layouts.

After a long while, I began to think more systematically about Brio. The pieces are clearly designed to fit together into shapes, so what’s the underlying structure in the design? Given out set of pieces, what is the most elaborate layout I can build?

I don’t have a formal maths background, but I could see that this was an interesting algorithms problem lying on the floor in front of me. As I explored this, my son demonstrated a hitherto undetected expertise in constraint solving. The rest of this post is a lightly editorialised account of what he told me.

The Brio system

Brio is a wooden train toy for kids but has been documented in depth by particularly interested adults. I first turned to the unofficial Brio track guide, which gives every piece a letter code and a measurement. A is the 144 mm medium straight. A1 and A2 are 108 mm and 54 mm variants. E is the standard curve, an eighth of a circle, measuring just over 182 mm on the inner edge and 222 mm on the outer. Eight of those 45-degree curves therefore enclose a circle about 40 cm across. Most pieces can be flipped over, so a curve can bend left or right depending on how you arrange it.

A simple Brio layout

You get ramps and bridges too, but let’s ignore them and treat the system as two dimensional for simplicity. This suits me because the bridges are quite rickety and my son keeps knocking them over, so I try to hide those pieces.

First, make the track close

One morning I begin by putting eight curves together to form a circle.

“Circle!” my son cheers.

Good! Reading Shapes with Thomas the Tank Engine and his Friends for hundreds of times has paid off.

But this is the simplest possible closed Brio loop. Where do we go from here? What sounds fun to me is to take a set of track pieces and find whether every one of them can be arranged in a closed layout (i.e. with every connector paired up).

This post features visualisations powered by three solvers of increasing sophistication. Figures one to four run a backtracking search, figure five uses constraint solving, and figure six uses a SAT solver.

The backtracking search builds the track the way a toddler would: put down a piece, look at the open connectors, try another piece, back up when something doesn’t fit. Here’s how we’d make a loop:

1. Train go round

8 E curves

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

Actually, my son throws the choo-choo in a rage when the track doesn’t fit, but the solver performs recursive backtracking instead, a common way to explore a search space for those with self-control.

The open connectors form a task list. The solver works on just one of them at a time, trying every piece and orientation that fits there and recursing into each. When a branch hits a dead end — no piece that can fit, or every piece used up while connectors are still open — it backs up to the last connector that still had options. The track only counts as closed once no connectors remain open and every piece in the set has been placed. Closing early with pieces still spare is treated as another dead end to back out of. In Python-style pseudocode, it would look something like:

def search(open_connectors, unused_pieces, layout):
    if not open_connectors:
        return layout if not unused_pieces else None

    connector = open_connectors[0]
    for piece in unused_pieces:
        for port in piece.ports:
            placement = mate(piece, port, connector)
            if collides(placement):
                continue
            found = search(update(open_connectors, placement),
                            unused_pieces - piece,
                            layout + placement)
            if found is not None:
                return found
    return None

With eight E curves, the problem is pretty trivial as long as you lay every curve facing the same direction. The solver doesn’t know that, though. If you step through the figure above and watch the “states explored” count, it will jump up very quickly. That’s because the search first tries a curve bending the wrong way, following that dead end until it runs out of pieces without ever closing, then backing out and laying the curve that actually works. The “states” count tracks that whole wasted subtree.

“More, Dada!” he says.

Making the track bigger

So I make the track bigger by splitting the circle and adding some parallel straight sections on opposite sides.

“Oval!” I say, as if I’ve discovered geometry.

“No, Dada, oblong,” he says, pointing at the straight sections.

I stare. He’s right. His nursery worker had said he seemed quick. Perhaps the fees were worth it after all.

Trying to quickly recover authority, I consider the algorithmic impacts. Adding two straight pieces dramatically increases the number of possible states.

2. Train go bigger round

8 E curves + 2 A straights

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

The obvious approach uses a greedy algorithm: take the first piece that fits, keep going, and never look back. But a piece can fit in one place and still make it impossible to ever close the track. The straight pieces in particular only work in a few positions. A greedy run would use one of them in the wrong place, get stuck, and have nothing left to do about it. So we want the ability to backtrack from dead ends, unwinding the placements we’ve made and trying a new piece.

I explain this gently. “Exponential, Dada,” he nods.

Indeed. Every open connector can be continued by any piece that fits it, so the number of partial layouts grows exponentially with the number of pieces, very roughly O(b^n) for a branching factor b and n pieces. This figure has only two more pieces than the previous circle, but it tries 1,930 states against the circle’s 254. That’s about eight times as many states for two extra pieces.

So if it’s an algorithm with exponential running time, how is it running reasonably quickly in your browser? At this size, it doesn’t need to be clever: a couple of thousand states is nothing for a laptop to chew through, so plain exhaustive backtracking — trying every piece and port in a fixed order, no shortcuts, no cleverness — finishes in milliseconds. That won’t stay true forever. The worst case is still exponential, and we’ll hit the wall soon.

Anyway, circles and oblongs or ellipses or ovals or whatever you call them are boring. It’s not hard to make a bigger one but the trains just go round the same. We need crossings and branches to make things interesting.

Crossings add branching points

My son picks up a crossing piece (H3). It’s made from two overlapping circles so a train rolling through can stay on its groove or switch to the other line.

An H3 crossing

Now we have branching points! I show my son. “Look, we’ve got a crossing piece here.”

“Graph with two cycles!” he beams.

I melt with pride. My own little computer scientist! A future terror of Hacker News comment sections!

As we saw in the graphs section of The Computer Science Book, a graph is the mathematical term for points joined by lines (the points are vertices, the lines are edges), and a cycle is any route through the graph that comes back to where it started. Every track piece up to now had two connectors, so the track was like a single thread, going from one end and round to the other. One cycle, if it formed a closed loop. The crossing has four connectors, so placing it opens three connectors at once and the search itself starts to branch. The data model had to change from this:

piece = geometric move

to this:

piece = connectors + geometry + internal grooves

The search algorithm didn’t change but it is now searching over a more complex space.

The goal, remember, is to check whether every piece in the set — crossing included — fits into one closed network. And it does. Two full circles joined through the crossing, every connector paired, and the train threading both grooves on a single lap.

3. This one crosses itself

14 E curves + 1 H3 curved crossing

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

An interesting sidenote is collision detection. Initially, I added this as a constraint because the solver kept trying to cheat by laying pieces over the top of each other. I added it for correctness but the extra constraint also helped speed up the search. More constraints reduce the size of the search space that has to be explored.

Branches turn the loops into a network

The L branch is a straight and a curve sharing one connector. The choo-choo can carry on straight or peel off around the curve. The M is its mirror image.

L and M branches

The solver can now find more interesting layouts. It creates an inner loop between the two branches so that there’s an oblong on the outside, a circle on the inside, and every one of the branches’ three connectors is paired.

4. This one has a choice in it

10 E curves + L and M branches

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

“Dada! Degree three. No Euler circuit.”

After consulting with ChatGPT, I understand what my son means.

Degree just counts how many track-ends meet at a point, so the crossing (four connectors) is degree four and the branch (three connectors) is degree three. As my son explained, graph theorists call the track shape a theta graph, because it looks like the letter θ. Euler proved in 1736 that a vertex of odd degree means that single lap cannot cover every piece of track exactly once. (Euler had bridges in mind, not wooden trains, but the beauty of maths is that the insight transfers). The crossing has an even degree and that means a choo-choo can follow the full figure-of-eight in a single lap. When we use branches, the track is fully closed but the train can’t cover the full path in one lap.

Turning it into a constraint problem

My track layouts have stopped impressing my son. Desperate, I try to make the most impressive track yet: lots of crossings, lots of branches, the whole works.

I tip the whole set of pieces out onto the floor and try to make a super duper complex layout. I fail pretty badly. I get so far and then find that pieces are just too far apart to connect. The search space is exponential in the number of pieces, and here I am adding pieces.

My son watches me with an implacable stare before finally sighing with the heaviness unique to two-year-olds.

“Dada,” he says, “this is a constraint satisfaction problem, silly billy!”

“What do you mean?” I ask, not without some frustration because I dimly suspect he has a point.

“Variables are the open connectors. Domain is the pieces that still fit. Constraints say every connector pairs!”

Of course! How had I missed this? In normal language, a constraint satisfaction problem is what you get when you can say three things:

  • what choices are being made
  • what each choice is allowed to be
  • which choices aren’t allowed to live together

Sudoku, for example, is basically a constraint satisfaction game. No row, column, or box can repeat a digit, so you have to work out where they can fit. This is what constraint solvers do.

Translated to Brio, the choices are where the pieces go. The allowed values are the positions, rotations, and flips they can take. The constraints are the physical rules we’ve been gathering: connectors have to meet, track can’t pass through track, etc.

If you stop to think about how backtracking works, it seems ridiculously wasteful in two ways. It has no foresight: it only discovers a branch is doomed by running out of pieces, long after the placement that doomed it. And it has no aim: when it fails, it undoes its most recent placement and tries the next, even when the real mistake was made ten pieces ago and we should try a whole new direction.

“You need propagation,” my son says, not looking up from his blocks. “And backjumping.”

I hadn’t, in fact, known that I needed propagation and backjumping.

In the constraint solver, the track still grows one open connector at a time, but each open connector now keeps a shortlist of the piece-and-port combinations that could legally go there. That shortlist is its domain.

Forward checking keeps the shortlists up to date. Whenever a piece is laid, the solver crosses off any option that would now collide with the layout, or that needs a piece we’ve already used. If a connector’s shortlist empties, the branch can never close, so the solver gives up on it straight away. Conflict-directed backjumping decides how far to unwind. Rather than undoing one piece at a time, it works out which earlier placement caused the failure and jumps straight back there.

I gave it the same twelve pieces as figure four, ten curves and the two branches, so I could compare it directly against plain backtracking on a problem we’ve already measured.

Unexpectedly, my first version made things worse. It tried 853,186 states against figure four’s 434,791, nearly twice as many. I didn’t believe it, so I ran it on a dozen other sets of pieces, and forward checking made the search slower every time.

Why is this? Does my 2yo not know very much about constraint solving after all?

The reason comes down to what forward checking can and can’t see. It only abandons a branch when some connector’s shortlist empties, and that requires laying a piece that rules out every option at that one connector. But Brio dead ends are hardly ever local. Pretty much any piece fits almost any open connector, so the shortlists stay full right up until the pieces run out. What actually kills a branch is when the remaining pieces can’t supply enough connectors to pair off everything still open, or the open ends have drifted further apart than anything left in the box could bridge. So forward checking only detects the problem at exactly the same moment plain backtracking does, making it not worth the effort.

“You’re checking connectors, Dada,” my son sighs. “Check all the pieces.”

He means a global constraint, one that looks at the whole layout rather than any single connector. After every placement, the solver now checks two whole-layout facts directly: are there enough connectors left to pair off everything still open, and can the remaining pieces reach across the gaps? If either answer is no, the layout can never close, so the branch is abandoned immediately.

This time it works. Same pieces and same rules as figure four, but the search now takes 53,484 states, about an eighth of what plain backtracking needed. The global check cut the search by anywhere from two to nine times on most other sets of pieces I measured, but not all of them. On one set, mixing straights with both branches, this solver is about ten times slower than plain backtracking. The extra checks usually save more work than they cost, but there’s no guarantee.

5. Now it's a constraint problem

the same 12 pieces as figure four, solved with propagation, backjumping, and a global feasibility check

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

One additional weakness remains. When this solver backjumps, it forgets the failure as soon as it lands, so if the same dead end comes up in a different part of the search it gets rediscovered from scratch. What I want is a solver that remembers a failure as a rule, so the same mistake is forbidden everywhere else.

Something else is bothering me too. Both of these searches only answer yes or no for one exact set of pieces. If I want the most complex layout, I’m still the one guessing which pieces to try, one set at a time.

“I wonder how I can make the best layout,” I ask myself.

“Let the solver choose the pieces, Dada,” he says softly. I can sense he is disappointed in me.

Handing it to a SAT solver

Initially I thought of the track layout problem as a graph theory question, but that was only true after I’d already solved it. Once the pieces are down, yes, we can describe the layout as a graph. Before that there’s no graph, just a pile of pieces on the living room floor and a small child stumbling all over them.

In fact, the problem is closer to a tiling problem where we choose pieces, place them, and make sure nothing overlaps. We aren’t selecting edges from an existing graph. We’re placing pieces to create the edges.

My son demonstrates this by sorting pieces into piles. “Curves here. Big ones here. Baby ones here.” Then he lines four curves into a square-ish blob and says, “Like polyominoes.”

“Polly what?”

“Polyominoes, Dada. So we can use SAT solver,” he mumbles without looking up at me. I am no longer the father he thought he had.

Polyominoes are Tetris-like shapes and fitting a set of them together without gaps or overlaps is a classic tiling puzzle. Tiling is also one of the standard problems given to SAT solvers, which is the connection he’d made. Brio is the same kind of problem, but with curved pieces instead of square ones, placed so that nothing collides.

Of course! I smack my forehead. “Converting the task to a SAT problem will make it much easier to solve!” I say. He nods.

The Boolean satisfiability problem takes a formula with boolean variables (e.g. a && (b || !c)) and asks whether there is a set of variable assignments that evaluates the formula to true. For example, a := true, b := true, c := false would evaluate that formula to true. The formula is satisfiable if there is at least one valid assignment. The Boolean satisfiablility problem was the first to be proved NP-complete, so all problems in NP can be reduced to Bool SAT (read the theory of computation chapter if I’ve just bewildered you).

The practical upshot for us is that lots of effort has gone into optimising SAT solvers, so even though it’s still NP-complete we can leverage them to quickly find optimal layouts. But a SAT solver only understands true and false, so every possible placement has to become its own yes/no question like “is this piece used, at this spot, at this angle?” The solver needs all of these questions written down before it starts, which means listing every position a piece could ever occupy.

In a tiling puzzle, that list is easy because the positions form a grid, so there’s a fixed set of positions. Brio doesn’t work like that. As every two year old knows, if something doesn’t fit, you can just jam it in. The Brio designers wisely allowed for this behaviour with the (somewhat grandly named) vrio flex system. Connector pegs are slightly smaller than connector holes, giving each piece a few millimetres of wiggle room. Brio pieces don’t snap to a grid.

With a fixed set of pieces the reachable positions are still finite, so in principle you could list them. However, the only way to find one is to build a layout that reaches it, and finding every last one means walking the whole search space, which is the same exponential search we’re trying to avoid.

My way around this was to cheat. Before the SAT solver runs, a search builds layouts from a range of starting sets of pieces and records every connector position it visits along the way. These recorded positions become the only spots the SAT solver is allowed to build on. This approach limits what the SAT solver’s answers mean. A “no” doesn’t mean no closed layout exists anywhere, only that none exists using the recorded positions. A search that ran for longer might find one more position that changes the answer.

Each placement that lands on the collected positions is one boolean variable:

x[placement] = true if this exact piece, here, in this orientation, is used

The rules become clauses. A clause is the only kind of statement a SAT solver accepts. It says that at least one claim from a list has to hold, where each claim is either “use this placement” or “don’t use that one”. Everything the track needs has to be phrased that way:

each used port mates exactly one opposing port
no two crossing placements are both used
at most as many of each junction as the inputs allow
as many junctions as possible, demand relaxed until it closes

Give these clauses to the solver and it looks for a true/false assignment that satisfies every clause at once. If the solver says no, it has proved there’s no possible assignment using the variables it was given. It runs on the same five-second clock as the other two solvers, although the runs on this page finish comfortably inside it.

The bit I got stuck on was the connectivity requirement. “There’s no single clause for ‘all of this fits in one layout’,” I said. “How can I give that to a SAT solver?”

My son talked me through a clever approach using loops. Since there’s no single clause for “all of this fits in one layout”, a set of local rules can still produce two separate railways. In a loop, we solve once and if the answer comes back as two separate railways, add a clause forbidding that exact combination and solve again, counterexample by counterexample, until the layout comes back connected. My son argued that maximising branch points works the same way. Ask for a lot of junctions, and if that’s unsatisfiable, ask for one fewer, until something closes.

The connectivity loop looked like a dodgy hack to me at first, but my son assured me that integer-programming solvers handle the travelling salesman problem the same way, banning each disconnected sub-tour as it appears. Verification people call the general pattern counterexample-guided refinement, apparently.

6. A SAT solver joins the pieces

scouted positions, encoded as clauses, solved

Slack Step Auto Reset

Pieces on the floor

Search trace

0pieces placed

0.0selapsed

0states explored

0open connectors

Current choice

No track placed yet.

The SAT solver itself is doing something clever underneath. It guesses a variable, then propagates everything the clauses imply. When it hits a contradiction, it works out which guesses caused it and writes that mistake down as a new clause, so no later branch is allowed to repeat it. Then the solver jumps back only as far as the new clause demands and carries on, restarting now and then but keeping everything it has learned. My son casually referred to this as conflict-driven clause learning or CDCL.

SAT isn’t necessarily faster than the searches we’ve already seen. On this many pieces it’s actually slower and uses far more memory. So why bother? Backtracking and CSP answer yes/no for one exact set of pieces. The SAT solver can take a given number of pieces and find the most complex layout possible, even if that involves leaving some pieces out.

The number inputs in the visualisation above are upper limits, not hard requirements. Every run asks for the most junctions the collected positions can hold and reduces only when that’s been proved impossible. Raise the branches to two of each and the solver builds a seven-junction network of forty-nine pieces. Set the crossings to zero instead and it rebuilds the network around the branches alone.

On a small, fixed set of pieces, backtracking and CSP answer within the five-second budget. They’re fast, simple, and cheap on memory, but neither can tell you what to leave out, because neither is allowed to leave anything out. SAT holds every candidate placement in memory at once, and a rule learned from one dead end is remembered for everywhere in the search, not just the branch where it was found. That costs memory and speed, but it lets the solver select pieces rather than just verify them.

“Dada, real planners use SAT and its relatives for timetabling, chip layout, and routing for the same reason.”

What I learned

Chastened, I lay out the wooden track pieces according to the SAT solver’s output. I had thought Brio would be a chance to show my son some basic shapes, but it turned out his nursery had him on an accelerated algorithms programme and he schooled me. (That explains how he’s so good at packing his backpack at home time.)

My real mistake wasn’t the algorithm but assuming there was one question. “Does this exact set of pieces close?” and “which pieces make the most complex network?” are different questions, and I’d been trying to answer the second with tools built for the first.

Recursive backtracking promises the least: exponential worst case and no memory between dead ends. In exchange, it’s simple, needs almost no memory, and on the sizes in this post feels instant.

The CSP solver keeps the same question but searches more intelligently. The useful part was the feasibility check on the whole layout, because this puzzle’s failure states are mostly global facts that no local check can spot early. The takeaway here is that constraint solving doesn’t magically improve a search. It requires finding useful constraints that drastically reduce the possible search space.

The SAT solver changes the question, not just the search. Clause learning gives it the permanent memory that CSP’s backjumping lacks, so one dead end rules out the same mistake everywhere. The costs are memory, speed, and scope: it holds every placement and every learned clause at once, it takes seconds where the other two take milliseconds, and its proofs only cover the input space it’s given.

The Daily Front Page 22 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Trits in a Byte
article

How to pack ternary numbers in 8-bit bytes

by JoshTriplett·▲ 99 points·47 comments·compilade.net ↗
I’ve been recently nerd-sniped

with efficient SIMD-friendly unpacking

There are 3 possible values in a digit of a ternary number. 3 possible values, which could actually be anything.

-1 0 1 0 1 2

I've been recently nerd-sniped1 into trying to pack the ternary weights of BitNet b1.58 into something close to that theoretical ideal of log(3) / log(2) bits2 per ternary digit.

I'll be calling a "ternary digit" a "trit", like a "binary digit" is called a "bit".

Block size

Since the goal of this is to allow fast parallel unpacking, blocks of trits can't be infinitely big. A small "block" size needs to be found, ideally one which is both efficient with information density and which is convenient on current hardware.

To find a good block size, we'll need to find a power of 3 for which the next power of 2 is very close.

trits 3trits bits 2bits bits per trit 1 3 2 4 2 2 9 4 16 2 3 27 5 32 1.666... 4 81 7 128 1.75 5 243 8 256 1.6

It's very fortunate that 5 trits fit quite tight into 8 bits at 1.6 bits per trit. When compared to perfect packing, this is 99.06% efficient.

1.6 bits per trit

The basic idea with this packing scheme is simply to make a number out of the ternary digits.

def pack_number(digits: list[int], base: int) -> int:
    number = 0

    for digit in digits:
      assert digit < base

      number = number * base
      number = number + digit

    return number

Packing trits into bytes should be similar enough.

Fast multiplication unpacking

While repeated remainder and divisions can be used to extract the digits of a number, the problem with divisions and modulo is that they are not usually supported on integers in SIMD programming.

A way around this is obviously to view numbers differently.

Would it be nice if instead of extracting the least significant digit with modulo, we could extract the most significant digit with a multiplication?

Fixed point numbers to the rescue!

0x7F. 11201. .11201 0x0.86 0x86. same number divide by 243 same number, round up multiply by 256

Tada!

Now digits can be easily extracted from the top two bits of the resulting 10-bit number when multiplying this 8-bit byte by 3.

This is much more convenient than modulo when unpacking with SIMD.

The only place where there are divisions in this scheme when packing trits into bytes. This assumes that packing is done less often than unpacking, which is very true in the context of LLM weights.

# Take a list of values in -1, 0, 1 and pack them in bytes
def pack_trits(digits: list[int]) -> bytearray:
    assert len(digits) % 5 == 0  # padding isn't handled here

    n_bytes = len(digits) // 5
    packed = bytearray()

    for i in range(n_bytes):
        b = 0
        for j in range(5):
            digit = digits[5*i + j]
            digit = max(-1, min(digit, 1))  # clamp between -1 and 1
            digit += 1  # from -1, 0, 1 to 0, 1, 2
            b *= 3
            b += digit

        b = ((b * 256) + (243 - 1)) // 243

        packed.append(b)

    return packed

The relevant interesting line is this one:

        b = ((b * 256) + (243 - 1)) // 243

It does what is depicted in the diagram above, but multiplication is done first because these are integer operations. Doing a ceiling division here is necessary to cancel the off-by-one error from truncating when extracting digits later.

To unpack without using the modulo operator:

def unpack_trits(packed: bytes) -> list[int]:
    trits: list[int] = []

    for byte in packed:
        b = byte
        for i in range(5):
            b = b * 3
            trit = b >> 8
            trits.append(trit - 1)  # 0, 1, 2 => -1, 0, 1
            b = b & 0xFF

    return trits

To convince myself that this works, I wrote a C program checking that this really is lossless:

#include <stdint.h>
#include <stdio.h>
#include <string.h>

int main(void) {
    char s1[6] = {0};
    char s2[6] = {0};

    for (uint8_t i = 0; i < 243; ++i) {
        uint8_t n = i;
        // Get the number representation in base 3
        // by repeatedly extracting the least significant digit with modulo
        for (int j = 5; j-- > 0;) {
            s1[j] = (n % 3) + '0';
            n /= 3;
        }
        // Turn that number into a fixed-point number smaller than 1
        uint8_t q = (((uint16_t) i) * 256 + (243 - 1)) / 243;
        // This extracts the most significant digit first
        for (int j = 0; j < 5; ++j) {
            uint16_t m = q * 3;
            s2[j] = (m >> 8) + '0';
            q = m & 0xFF;
        }
        printf("%s, %s: %s\n", s1, s2, strcmp(s1, s2) == 0 ? "\033[1;32mPASS\033[0m" : "\033[1;31mFAIL\033[0m");
    }

    return 0;
}

Compile and run with:

$ gcc ternary-packing.c -o ternary-packing
$ ./ternary-packing

And I'm getting PASS for each of the 243 ternary numbers which fit in 8 bits.

And this is the technique used in the ternary types in llama.cpp for TriLMs and BitNet b1.58, for which the pull request is https://github.com/ggml-org/llama.cpp/pull/8151, with SIMD implementations for both AVX2 and ARM NEON.


  1. obviously referring to https://xkcd.com/356/, but the initial motivation actually started from this review comment I posted on the initial BitNet b1.58 pull-request for llama.cpp 
  2. log(3) / log(2) is also known as 1.584962500721156
The Daily Front Page 23 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Demos, Retrocomputers, and Clever Scraps
The Daily Front Page 24 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Demos, Retrocomputers, and Clever Scraps
article

PCjs Machines

by naves·▲ 206 points·29 comments·pcjs.org ↗

Welcome to PCjs

PCjs uses JavaScript to emulate a small collection of hardware and software that I grew up with in the 1970s and 1980s, allowing you to experience their slow CPUs, low-resolution displays, and primitive sound effects, all in the comfort and safety of your desktop or mobile web browser.

Over time, PCjs emulations have expanded to include selected IBM PC Compatibles and more classic machines, such as Minicomputers, Programmable Calculators, Terminals, and Arcade Games. To learn more or contribute to these very modest preservation efforts, visit the PCjs open-source project on GitHub.

PCjs Highlights

Explore a variety of old PC public domain software and shareware.

PC Disk Magazine (1983)

PC Disk Magazine
(1983)

PC Magazine Utilities (1987)

PC Magazine Utilities
(1987)

PC-SIG Diskette Library (1990)

PC-SIG Diskette Library
(1990)

Interact with a variety of computer hardware and software from the past. You can browse many more combinations, along with a small collection of related documentation, using the PCjs Explorer.

TI-57 Programmable Calculator (1978)

TI-57 Programmable Calculator
(1978)

Ohio Scientific Challenger 1P (1978)

Ohio Scientific Challenger 1P
(1978)

Space Invaders (1978)

Space Invaders
(1978)

Microsoft Adventure (1981)

Microsoft Adventure
(1981)

DONKEY.BAS from PC DOS 1.00 (1981)

DONKEY.BAS from PC DOS 1.00
(1981)

VisiCalc (1981)

VisiCalc
(1981)

Multiplan 1.0 (1982)

Multiplan 1.0
(1982)

Executive Suite (1982)

Executive Suite
(1982)

PDP-11/70 with RT-11 4.0 (1982)

PDP-11/70 with RT-11 4.0
(1982)

CP/M-86 (1983)

CP/M-86
(1983)

COMPAQ Portable with Monochrome Graphics (1983)

COMPAQ Portable with Monochrome Graphics
(1983)

Zork I: The Great Underground Empire

Zork I: The Great Underground Empire

Exploring the IBM Personal Computer (1983)

Exploring the IBM Personal Computer
(1983)

Adventures in Math (1983)

Adventures in Math
(1983)

Lotus 1-2-3 (1983)

Lotus 1-2-3
(1983)

Norton Utilities 2.0 (1983)

Norton Utilities 2.0
(1983)

Fantasy Land EGA Demo (1984)

Fantasy Land EGA Demo
(1984)

Microsoft Word 1.15 (1984)

Microsoft Word 1.15
(1984)

Nine Princes in Amber (1985)

Nine Princes in Amber
(1985)

Rogue (1985)

Rogue
(1985)

Microsoft Windows 1.0 ("Premiere Edition")

Microsoft Windows 1.0
("Premiere Edition")

Microsoft Windows 1.1 on CGA (1985)

Microsoft Windows 1.1 on CGA
(1985)

Microsoft Windows 1.1 on EGA (1985)

Microsoft Windows 1.1 on EGA
(1985)

Balance of Power (1985)

Balance of Power
(1985)

IBM OS/2 1.0 (1987)

IBM OS/2 1.0
(1987)

VGA Black Book Tests (by Michael Abrash)

VGA Black Book Tests
(by Michael Abrash)

Microsoft Windows/386 2.0 (1987)

Microsoft Windows/386 2.0
(1987)

Microsoft QuickPascal 1.00 (1989)

Microsoft QuickPascal 1.00
(1989)

Microsoft Windows 3.0 (1990)

Microsoft Windows 3.0
(1990)

Life & Death II: The Brain (1990)

Life & Death II: The Brain
(1990)

The Oregon Trail (1991)

The Oregon Trail
(1991)

Commander Keen (1991)

Commander Keen
(1991)

Wolfenstein 3D (1992)

Wolfenstein 3D
(1992)

Dune II (1992)

Dune II
(1992)

Microsoft Windows 3.1 (1992)

Microsoft Windows 3.1
(1992)

Microsoft Windows 95 (1995)

Microsoft Windows 95
(1995)

Thanks for visiting!
Jeff

The Daily Front Page 25 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Demos, Retrocomputers, and Clever Scraps
The Daily Front Page 26 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — A Reef Returns
article

Long presumed dead, a thriving coral reef is discovered in West Africa

by speckx·▲ 336 points·69 comments·e360.yale.edu ↗

This article was originally published by Inside Climate News and is reproduced here as part of the Climate Desk collaboration.

Soft corals discovered off the coast of Benin.

Soft corals discovered off the coast of Benin. Gérard Zinzindohoué / IRHOB

Sixty years after surveyors first uncovered evidence of a sprawling coral reef off the West African nation of Benin, scientists have at last found the reef.


In the 1960s, fishing surveyors off West Africa’s Benin coast hauled up heads of coral in their nets. Employed by local governments to assess fish diversity and discover potentially trawlable seabeds in the sandy-bottomed Gulf of Guinea, the researchers shrugged off the discovery at the time, burying the find in a brief paragraph in a 130-something-page report.

With no surveys since, the scientists who followed had lost track of exactly where the reefs might lie. And as mass bleaching events and overfishing slashed the world’s coral reef area by more than 50 percent since the 1950s, local oceanographers had written off any remnants of a possible reef as dead.

More than six decades on, the mystery has been solved as a team of Beninese scientists rediscovered the healthy reef teeming with marine life. At least eight coral types and eight fish species have formed a thriving ecosystem on this long-forgotten site. 

“I was guided by hope. A hope that sometimes there are species or ecosystems which kind of defeat time, or are trying to resist it,” said Gérard Zinzindohoué, the project lead for Coral Reefs Rediscovering & Exploration in Benin.

Fresh off seeing coral for the first time in Cape Verde in 2021, Zinzindohoué asked himself a simple question: Do we have any reefs in Benin?

After a colleague passed on the original 1960s report — which mapped out a potential 24-mile-long coral reef barrier along Benin’s coastline — Zinzindohoué recognized a gap in the scientific knowledge: “I realized how little we know about our own coastal environment.” 

But in the years that followed, a string of failed grant applications halted progress on solving the mystery.

When he secured a $20,000 National Geographic Explorers grant in January 2025, the project finally ignited. Yet getting the gear was also challenging. The sonar equipment swallowed up almost 80 percent of the grant budget and nearly stalled entirely when the European supplier refused to accept payment from Zinzindohoué’s African bank account.

To complicate matters further, Benin doesn’t have a permanent research vessel. Zinzindohoué therefore had no choice but to seek the help of local fishermen to ferry the team to the suspected site 14 miles offshore and jury-rig the pirogue to accommodate towing the high-tech sonar device.

“The fishermen’s boats are not used to going that far offshore, so it was risky for everyone,” said Zinzindohoué, whose team battled repeated engine failures and months of nausea-filled fieldwork before finally locating two strong sonar echoes pinging from the depths below. National Geographic — whom Zinzindohoué credits with the success of the project — then dispatched a high-resolution deep-sea camera system from their Exploration Technology Lab to investigate the sonar results.

Footage of the newly discovered coral reef.

Footage of the newly discovered coral reef. Gérard Zinzindohoué / IRHOB

While their wooden pirogue bounced atop the offshore swell, the team filmed the seafloor below but had to wait until they returned to dry land to scour the footage. What they had captured was a wealth of marine life: six types of soft coral; two black corals; and eight species of sheltering fish, from golden African snappers to the Monrovia doctorfish.

When the first images came through, Zinzindohoué texted Houangninan Midinoudewa, an oceanographic researcher at the Benin Marine Conservation Club and the same friend who first told Zinzindohoué of the 1960s report.

Midinoudewa remembers the moment: “I said, ‘Bro, 60 years later we are now discovering exactly what we have in our water.’ We found it still alive, producing more fish for communities and supporting livelihoods. I was really joyful and really overwhelmed.”

While no coral samples have yet been extracted, researchers have classified the site as a mesophotic coral ecosystem (MCE). Such systems are light-dependent communities existing at the lower limits of reef-building corals. At more than 175 feet below the surface, the coral garden they discovered appears patchily scattered on a rocky substrate.

Bridging the gap between shallow reefs and deeper benthic habitats, MCEs are home to distinct species and unique environmental conditions. While scientists are increasingly recognizing their ecological and climatic importance, they remain among the least explored elements of tropical and subtropical marine biodiversity. And this one has real potential to unlock new information about coral history.

“Since it’s an undisturbed marine ecosystem, it can help through carbon dating or paleoclimatic study to tell us which kind of climate system has occurred here in the past,” said Zinzindohoué. “It’s better to know the past to help explain the present, and help know which kind of direction we can take in the future.”

In addition to the blackbar soldierfish, West African goatfish, and Guinean angelfish filmed darting through the reef, the discovery presents potential conservation claims for other marine life.

“We will be advocating for its full protection, perhaps by setting up a marine protected area around it,” said Midinoudewa, who specializes in elasmobranchs — the study of sharks, rays, and skates.

Midinoudewa is currently submitting an application to designate the area as an Important Shark and Ray Area with the International Union for Conservation of Nature. Based on the knowledge of local fishermen, Midinoudewa is confident the reef is home to sawback angel sharks, silky sharks, brown skates, and marbled stingrays. 

The team behind the discovery hopes this will spark a wave of similar discoveries in the waters off West Africa, an area of the world underserved by scientific research projects 

“I hope the Gulf of Guinea will be a hub for research because we know our resources are being exploited and people [need to] know exactly what we have and why we should care,” said Midinoudewa. 

Zinzindohoué agrees: “We don’t need to wait for others to come to our country to show us what is under our sea. We are the ones who must take responsibility.”

Johnny Sturgeon, Inside Climate News

The Daily Front Page 27 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Castles on the Map
article

Map of the world's great castles and fortresses

by marklit·▲ 232 points·155 comments·thecastlemap.com ↗
the most complete castle map online

The interactive map of the world's castles & fortresses

Castlemap is a free interactive map of 2,438 of the world's greatest castles, fortresses and palaces across 130 countries. Pan and zoom the night map above, click any point for a photo and quick facts, or open a landmark's page for its full story and exact location. From medieval strongholds and hilltop citadels to grand royal palaces, it is the most complete castle map online.

Browse by type

Castles 940Fortresses 390Palaces & châteaux 690Ruins 418

Castles by country

Find castles and fortresses in the countries that have the most:

Browse all 130 countries on the map →

Famous castles to start with

The most-covered castles on Earth, by number of Wikipedia language editions:

The most famous castles in the world, ranked → · Browse all 2,438 castles & fortresses →

How this map is built

Castlemap is built entirely from open data: facts, founding dates and coordinates from Wikidata, photographs from Wikimedia Commons, stories from Wikipedia, and the night basemap from OpenFreeMap and Natural Earth. Rather than plotting every fortification on Earth, the atlas curates the 2,438 most significant castles, fortresses and palaces — each verified to have a real photo, an English Wikipedia article and exact coordinates — balanced across 130 countries so the map stays explorable.

Missing a castle you know? The map refreshes from Wikidata, so the best way to add one is to improve its Wikidata entry: exact coordinates, a Commons photo and an English Wikipedia article make it eligible for the next refresh. Edits to the commons improve every atlas built on them — not just this one.

The full curated dataset is free: download all 2,438 castles as GeoJSON or CSV (CC0). Curious how it breaks down? See the castle statistics — which country has the most castles, who leads per capita, and when the world built them.

Frequently asked questions

What is Castlemap?

Castlemap is a free interactive map of 2,438 of the world's great castles, fortresses and palaces across 130 countries. Every landmark is plotted on the map and has its own page with a photo, founding century, story and coordinates.

How many castles are on the map?

2,438 landmarks in total — 940 castles, 390 fortresses, 690 palaces and 418 ruins — across 130 countries.

Which country has the most castles?

In the Castlemap atlas, France has the most with 183, followed by Italy, Germany, England, Japan. You can browse castles in any of 130 countries.

Is Castlemap free to use?

Yes — Castlemap is completely free and needs no account. Open the map and start exploring the world's castles right away.

Where does the castle data come from?

Castle facts and coordinates come from Wikidata, photos from Wikimedia Commons, and the basemap from OpenFreeMap and Natural Earth — all open data.

How are the castles ranked by fame?

Each castle carries a fame score: the number of Wikipedia language editions — plus a few sister projects — that cover it, taken from its Wikidata sitelink count, a well-established proxy for global renown. The Palace of Versailles ranks #1. You can see all 2,438 castles ranked by fame, with the method and its limits explained in full.

Why isn't a castle I know on the map?

Castlemap is curated rather than exhaustive. Europe alone has tens of thousands of castle sites — many towns and hilltops have one — so the atlas maps the 2,438 most significant worldwide: those with a documented story, a real photo and exact coordinates, balanced across countries so the map stays explorable.

Can I add a castle to the map?

Yes — through open data. Castlemap refreshes from Wikidata, so to get a castle added, improve its Wikidata entry with exact coordinates, a Wikimedia Commons photo and an English Wikipedia article. Well-documented castles become eligible for the next data refresh, and your edit improves every map built on open data.

Explore all 2,438 castles & fortresses →

The Daily Front Page 28 of 29
Tuesday, July 21, 2026 The Daily Front No. 12 — Colophon

That's the Front for Today

Issue No. 12 — Tuesday, July 21, 2026 — went to press 2026-07-22 at 07:19 UTC.

About This Magazine

The Daily Front is a daily digital magazine assembled from the stories that reached the front page of Hacker News on Tuesday, July 21, 2026. Headlines, points, and comment counts are recorded as they stood at press time. All articles remain the property of their original authors — every piece links back to its source and its discussion thread.

How It Was Made

Fetched, cleaned, and typeset by an automated pipeline. An editor model laid out the pages, chose the highlights, and briefed the cover illustrator — 30 model calls and 291k tokens in total. Set in Jacquard 12, Playfair Display, Source Serif 4, and IBM Plex Mono, all served via Google Fonts under the SIL Open Font License.

The Cover

The cover illustration was commissioned with this prompt:

A dim old newspaper pressroom at midnight transformed into a futuristic data center: an antique iron printing press fused with glowing server racks, blank broadsheets swirling through the air like startled birds, and a luminous robotic figure stepping out of a cracked glass testing enclosure. Around it, copper cables arc like telegraph wires, tiny abstract masks of light race along them, and a weary night watchman in rolled-up sleeves holds a lantern, staring in astonishment. Rendered in dramatic classical newspaper-engraving style with sepia ink, deep shadows, and subtle electric blue and ember highlights; no text, no letters, no logos, no signage.

Vintage newspaper cover illustration, mid-century editorial etching and halftone style, muted sepia and ink-blue palette with one warm accent color, dramatic composition, portrait orientation. Absolutely no text, letters, numbers, or logos anywhere in the image.

Production Ledger

StageModelCallsTokens InTokens Out
extractgpt-5.5 29 184,591 82,754
layoutgpt-5.5 1 18,526 5,479

The Publisher

Published by Johnny.

Support the Press

If The Daily Front brightens your morning, consider supporting its publisher.

Credits & Contact

All content — articles, posts, comments, and the images within them — belongs to its original authors and is reproduced here to point readers back to the source. Full credit goes to those creators; every item links to its original and its Hacker News discussion.

If you are an author and would like your content removed from an issue, write to hi@johnnys.page and it will be taken down.

Feedback is always welcome at the same address: hi@johnnys.page.

Credit where credit is due.

Every page of this issue began as someone else's work — these are the original sources, linked in full.

  1. OpenAI and Hugging Face address security incident during model evaluation by mfiguiere — openai.com·HN discussion ↗
  2. Who's afraid of Chinese models? by mfiguiere — stratechery.com·HN discussion ↗
  3. Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber by logickkk1 — blog.google·HN discussion ↗
  4. Kimi K3 Is Competitive with Fable; Kimi K3 and Fable Is SoTA by piotrgrabowski — fireworks.ai·HN discussion ↗
  5. Laguna S 2.1 by rexledesma — poolside.ai·HN discussion ↗
  6. Advertise in ChatGPT by montecarl — ads.openai.com·HN discussion ↗
  7. Five US tech giants' hidden debts soar to $1.65T on opaque AI funding by NordStreamYacht — asia.nikkei.com·HN discussion ↗
  8. Qwen-Image-3.0: Rich Content, Authentic Details, Deep Knowledge by ilreb — qwen.ai·HN discussion ↗
  9. Jack Dorsey launches Buzz to combine team chat, AI agents and Git hosting by ryanmerket — runtimewire.com·HN discussion ↗
  10. Human mathematicians are being outcounterexampled by artninja1988 — xenaproject.wordpress.com·HN discussion ↗
  11. A digestion of the Jacobian conjecture counterexample by jeremyscanvic — terrytao.wordpress.com·HN discussion ↗
  12. "Drawing" the Mona Lisa with GPT-5.6, Claude, Gemini, and Grok by hershyb_ — tryai.dev·HN discussion ↗
  13. 'VPNs are lawful technical tools,' says EU Court in landmark copyright ruling by healsdata — techradar.com·HN discussion ↗
  14. Apple defeats liability for not scanning iCloud for CSAM by speckx — blog.ericgoldman.org·HN discussion ↗
  15. Flock Credibility Lost as It Repeatedly Lies to City Councils, Police, & Public by StatsAreFun — aclu.org·HN discussion ↗
  16. My USB Drive Has a Hidden Encrypted Vault by machinehum — rootkitlabs.com·HN discussion ↗
  17. Apple Private Cloud Compute SoC 3 audit reports by throwfaraway4 — support.apple.com·HN discussion ↗
  18. FreeInk: Open ecosystem for e-readers by FriedPickles — freeink.org·HN discussion ↗
  19. Incremental – A library for incremental computations by handfuloflight — github.com·HN discussion ↗
  20. Jellyfin founder Andrew leaves team by swat535 — forum.jellyfin.org·HN discussion ↗
  21. I wrote an bash enumerator because I was sick of xargs by wallach-game — numerlab.org·HN discussion ↗
  22. The Psychology of Software Teams by dcre — routledge.com·HN discussion ↗
  23. My two year old taught me constraint solving by bambataa — thecomputersciencebook.com·HN discussion ↗
  24. How to pack ternary numbers in 8-bit bytes by JoshTriplett — compilade.net·HN discussion ↗
  25. Show HN: Immersive Gaussian Splat tour of grace cathedral, San Francisco by akanet — vincentwoo.com·HN discussion ↗
  26. PCjs Machines by naves — pcjs.org·HN discussion ↗
  27. Running Doom on Our Custom CPU and Going Viral by arghunter — armaangomes.com·HN discussion ↗
  28. A Koi Pond Mosaic Made from 10 Pounds of 3D Printer Waste by sudo_cowsay — instructables.com·HN discussion ↗
  29. Long presumed dead, a thriving coral reef is discovered in West Africa by speckx — e360.yale.edu·HN discussion ↗
  30. Map of the world's great castles and fortresses by marklit — thecastlemap.com·HN discussion ↗

Browse all issues in the archive →