For four decades, an engineer could obtain and run the core tools of the field on the same terms as anyone else, whatever their nationality, employer, or location. Frontier AI has now broken that arrangement, and the clearest evidence arrived in a single week of June 2026.
Anthropic released Claude Fable 5 on Tuesday 9 June, the most capable model it had ever made generally available and the first public member of its Mythos class. By Friday it was gone. A United States Commerce Department export directive required the company to suspend access for any foreign national, inside or outside the country, with no exception for allied jurisdictions, and Anthropic disabled both Fable 5 and the more specialised Mythos 5 worldwide to comply. The European Commission objected on 14 June that such controls "should not be discriminatory." An engineer in Copenhagen, Lisbon, or Tallinn who had built something on Fable 5 over those few days found, by the end of the week, that the tool had been withdrawn at the source, and that nothing they could do locally would bring it back.
I do not normally write about the week's events in this newsletter. I am making an exception because the episode is not really about one company or one model. It exposes a change in the conditions under which software gets built, and the field has not yet found a good way to talk about it. The usual conversation ranks models by capability and benchmark score. The prior question, the one Fable 5 forced into view, is whether a given engineer is permitted to call the model at all, and the answer to that question now rests with a government the engineer did not elect.
The discipline grew up under an arrangement that kept its tools politically neutral, and it is worth being precise about what that arrangement was. The GNU project and the Free Software Foundation treated source code as a commons. The Internet Engineering Task Force standardised network protocols through rough consensus and running code, which kept specifications open to any implementer. Open-source software moved from the periphery to the foundation of commercial practice, and the public cloud extended the same logic to infrastructure by renting general-purpose compute to anyone who could pay. The practical upshot was that a maintainer in Nairobi could clone a repository, compile it, publish a package, and submit a patch on the same technical terms as a maintainer in Boston. None of this was ever total, since proprietary tools and trade secrets always sat alongside the commons. The claim worth defending is narrower: for roughly forty years, the artefacts the discipline as a whole relied on were available on terms that no single actor controlled.
Frontier AI changes that arrangement at its root, because the capability that now sets the ceiling of practice reaches the engineer as a hosted service rather than as a copy they hold. When access is withdrawn, the familiar engineering responses do not help, since each of them assumes you possess something you can run elsewhere. There is no local copy to mirror, no repository to fork, and no way to self-host a computation that executes on another company's hardware under another government's law. Whether you may call the endpoint at all is decided by the provider's jurisdiction of incorporation and by the sanctions and export-control rules that reach your individual request. When Fable 5 went offline, the model had not changed and no dependent system had failed. The channel had been closed, and for everyone outside the permitted jurisdiction that was enough to end the work.
It is fair to ask whether any of this is new. Electronic-design-automation suites have been export-controlled for decades, and proprietary databases were always sold under licence and embargo, so working practice has long absorbed gated tools. The difference that matters is substitutability. An embargoed tool could be re-implemented, bought through an intermediary, or replaced by a weaker but available alternative, because the thing being denied was an artefact. A hosted frontier capability offers no such route, because what is being withheld is a live computation performed somewhere you cannot reach. For as long as the denial holds, there is no partial workaround, only absence.
Software engineering does not have to invent a vocabulary for this from scratch, because political economy has already built one that fits. Farrell and Newman (2019) observed that economic and informational networks tend to form through preferential attachment and therefore grow lopsided, with a small number of hubs accumulating most of the connections and most of the traffic passing through them. A state that holds legal jurisdiction over such a hub can put it to coercive use in two ways: it can deny a target access by closing the hub to them, which the authors call the chokepoint effect, and it can watch the traffic of everyone who passes through, which they call the panopticon effect. Their evidence came from the exclusion of Iranian banks from the SWIFT messaging system and from the surveillance programmes disclosed by Edward Snowden, but the structure they described now maps cleanly onto the substrate of software.
Our hubs are easy to name. Package registries such as npm and PyPI are the single effective distribution point for their ecosystems. A handful of code hosts concentrate the world's collaboration. Frontier model endpoints sit in three jurisdictions. Each is a chokepoint that depends on a jurisdictional decision, and the record since 2019 is no longer hypothetical. Between 2019 and 2021, GitHub, operating under United States sanctions law, withheld private repositories and paid services from users in Iran, Syria, Crimea, Cuba, and North Korea, and restored Iranian access only after obtaining a specific licence from the Office of Foreign Assets Control. In October 2024, a patch removed several Russian-associated maintainers from the Linux kernel MAINTAINERS file, a change later confirmed to follow from sanctions compliance. The source stayed clonable by anyone, the removed maintainers included; what the sanction reached was the maintainer role, the gate through which patches enter the repository and, as maintenance research has long argued, the scarcest resource the commons has.
The compute layer underneath carries the same concentration at higher stakes, since the substrate cannot be forked or mirrored the way code can. The processors that train frontier models are designed by one firm, fabricated by another on lithography that comes from a single supplier, with high-bandwidth memory from three (Miller, 2022). Most stages of that chain have between one and three viable suppliers. When the United States extended the Foreign Direct Product Rule to reach foreign-made goods built with US-origin technology, a Taiwanese foundry was obliged to stop advanced-node production for a Chinese customer, and that customer then re-engineered its device software, build toolchains, and eventually its operating system around domestically available processors. A decision taken at one node of the chain worked its way up through every layer of software built on top of it.
Jurisdiction also reaches the engineer from the other direction, through regulation that travels well beyond the regulator's own borders. Bradford (2020) called this the Brussels Effect: European Union rules become global rules without any treaty obliging other governments to adopt them, provided the market is large, the target is hard to relocate, and production is integrated enough that firms find it cheaper to apply the strict standard everywhere than to maintain a separate variant for Europe. The General Data Protection Regulation, the Digital Services Act, and the AI Act now shape the design of systems built and run far outside the Union, so that meeting European requirements becomes a property of the code rather than a task for a legal department alone. Put the two forces together and the practical lesson is that the thing deciding what an engineer can build is no longer only the tool in front of them or the team around them. It is also the surface through which they reach the tool, and the question of whose law governs the points where that surface narrows to a few hubs.
The reason a single model can now acquire the legal status of a controlled good becomes clearer from the figure that circulated before the public Fable 5 release.
Within roughly two months, about fifty vetted organisations using the restricted Mythos programme reported more than ten thousand high- or critical-severity software vulnerabilities, a concentration of offensive capability that no gated tool of the earlier era ever placed on one side of a perimeter.
A government reads a tool that finds exploitable flaws in widely deployed software at machine speed as a weapon, and a weapon delivered through a hosted endpoint can be turned off for everyone outside the perimeter within a day. The object of state attention, in other words, was the channel rather than the artefact, which is exactly why the response took the form it did.
For the European researcher, the first symptom is methodological. A study that benchmarks "leading models" is drawing a jurisdictional sample whether or not it admits as much. A replication package can pin the prompt set, the scoring pipeline, and the analysis scripts, yet it cannot pin the model behind the endpoint. If that model is enrolment-gated, quietly updated, deprecated, or pulled by directive, a result reported against it can no longer be reproduced by anyone outside the perimeter, and when a hosted model is retired it takes every baseline measured against it along too. A group in the Union hoping to replicate a finding reported against Fable 5 lost that ability during the model's launch week.
This is the sort of standards-of-evidence problem that careful empirical work is built to handle, but only if the field agrees to treat the access conditions of a study as part of its design rather than as bad luck. Russo and Stol (2021) set out how to study messy socio-technical phenomena without giving up rigour, and the disruptive research playbook (Storey, Russo, et al., 2024) addresses the harder case of a technology that keeps changing the rules while it is being studied. The practical demand is modest. An AI4SE evaluation should record the jurisdictional provenance and the access channel of every model it samples, in the same spirit that survey research records the demographics of its respondents. A finding built on a capability that one jurisdiction can revoke carries a dependency, and a dependency that goes unrecorded is the usual starting point for a later argument about whether the result ever held.
There is a way to keep working, and the field has already watched it succeed. The DeepSeek R1 release of January 2025 published openly downloadable weights together with a good deal of methodological detail, which put a reasoning model of near-frontier capability within reach of any group that owns modest inference hardware (DeepSeek-AI, 2025). A model whose weights you hold is an evaluation target that stays put: it cannot be deprecated out from under a study or switched off by an order from a capital, because the researcher possesses the artefact. Seen from the access problem rather than from the older debate about software freedom, open weights are less an ideological commitment than the one form of frontier-adjacent capability whose continued availability a European team can guarantee for itself.
The connection to this newsletter's longer argument is direct. The Copenhagen Manifesto (Russo et al., 2024) holds that software engineering must stay answerable to the people who build and use it, and that tools should be judged by what they do to those people's autonomy, learning, and well-being rather than by speed alone. The conditions under which those people are allowed to build now belong to that same subject. Autonomy over one's tools, followed all the way down, turns into the question of whether one may reach the tools at all, and through the Fable 5 week that question was answered in capitals where the affected engineers have no vote.
Work through these questions for one build-critical system. Each names a specific exposure rather than a general worry, and each has an answer you can write down.
1. List every capability your product cannot ship without. For each, record whether you hold the artefact or only reach it through a hosted endpoint. The second category is your denial surface.
2. For each hosted dependency, name the jurisdiction where the provider is incorporated. That jurisdiction's sanctions and export law reaches your individual requests, not only the provider's corporate conduct.
3. Identify which dependencies have a viable open-weight or self-hostable substitute today. Where none exists, mark the capability as single-sourced and treat it the way you would treat a sole-supplier component.
4. For your most important hosted model, write down the procedure your team would follow if access ended tomorrow without notice. An empty procedure is an unmanaged risk, not an improbable one.
5. Audit your package and registry dependencies for maintainer accounts concentrated in one legal order. A sanction can remove a maintainer role without changing a line of source.
6. Check whether any published evaluation your team relies on was measured against a model you can no longer access. Those baselines are no longer reproducible and should be re-grounded on a target you control.
7. Record the access channel for every model in your own internal benchmarks. An evaluation with no documented jurisdictional sample is hard to defend once the model moves.
8. Work out which European obligations, under the AI Act or the Digital Services Act, already reach your codebase regardless of where you operate. Compliance has become a property of the code, not a downstream legal task.
9. Decide, explicitly, which capabilities matter enough to warrant keeping an accessible fallback at all times. This is a continuity decision, and it belongs to engineering rather than to procurement.
Keep one open-weight model running in your local toolchain even when a hosted frontier model is better, so that your ability to work does not rest on a channel you do not control. When you cite a model's behaviour in a design discussion or a postmortem, note the version and the date you accessed it, since hosted models change without announcement. Before you commit to a library, look at where its critical maintainers are based, because a dependency whose maintenance lives entirely in one jurisdiction carries a risk that no static-analysis score will show you.
Add one line to your dependency and vendor reviews that records the jurisdiction of each hosted capability your team relies on, and treat a single-jurisdiction frontier dependency the way you treat any sole supplier. Hold a small continuity budget for an accessible fallback model, and present it to your team as the version of the capability they can keep rather than as a downgrade. When you set a definition of done for AI-assisted work, require that any internal benchmark record the access channel of the models it used, so the team's evidence outlasts a withdrawn endpoint.
Do not price a roadmap on the assumption of continuous access to one provider's frontier model, since the Fable 5 episode shows the assumption can fail inside a week for reasons no commercial relationship can prevent. Commission a map of where your build-critical capabilities concentrate by jurisdiction, and review it as a standing risk alongside cost and reliability. Treat open-weight capability as strategic infrastructure rather than a research curiosity, because it is the only frontier-adjacent option whose availability you can promise your own teams. Where European regulation already reaches your code, fund the work to meet it as product engineering, not as a compliance task that arrives late and over budget.
For years the case for open tools was argued mostly on principle, about freedom and licensing. The Fable 5 week made a narrower and more practical case: an organisation outside the permitted jurisdiction lost a working capability overnight, through no fault in its own systems and with no technical way to recover it. That argument is harder to wave away than the older one, and it is going to recur, because the structure that produced it is not going anywhere. Which of the capabilities your teams depend on would survive a closed endpoint, and would you know before it happened?
Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through "Software Insights," he translates empirical research into actionable guidance for software practitioners and organizations.
If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.
danielrusso.org/advisory (Opens in a new window)
Bradford, A. (2020). The Brussels effect: How the European Union rules the world. Oxford University Press.
DeepSeek-AI. (2025). DeepSeek-R1: Incentivizing reasoning capability in large language models via reinforcement learning. Preprint.
Farrell, H., & Newman, A. L. (2019). Weaponized interdependence: How global economic networks shape state coercion. International Security, 44(1), 42–79.
Miller, C. (2022). Chip war: The fight for the world's most critical technology. Scribner.
Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.
Russo, D., & Stol, K.-J. (2021). PLS-SEM for software engineering research: An introduction and survey. ACM Computing Surveys, 54(4), 1–37.
Russo, D., et al. (2024). Generative AI in software engineering must be human-centered: The Copenhagen Manifesto. Journal of Systems and Software, 218, 112115.
Storey, M.-A., Russo, D., et al. (2024). The disruptive research playbook. ACM Transactions on Software Engineering and Methodology.
In May 2026, Pope Leo XIV released his first encyclical, "Magnifica humanitas," a text devoted to safeguarding the human person in the time of artificial intelligence…
In May 2026, four Ericsson engineers (Britto, Palmgren, Saini, and Ohlin) released a paper titled The AI-Native Large-Scale Agile Software Development Manifesto. The…
A pragmatic engineering and financial analysis of the tech sector, AI economy, and venture capital
See latest post
34,272 Followers
The Reclaimed Capitalist, an educational newsletter focused on corporate operational analysis and macroeconomic trends.
See latest post
29,526 Followers
A newsletter on U.S. politics and history – and the ongoing struggle over how much democracy, and for whom, there should be in America
See latest post
Leave a Reply