TheDaily Front

Kaiser Permanente advice nurse Raquel Alvarez Sanchez works from her home office in Santa Rosa on April 6, 2026. Kaiser Permanente nurses have raised concerns about the growing use of AI to monitor their work ahead of upcoming contract negotiations. (Chad Surmick for CalMatters)

KAISER PERMANENTE NURSES who answer advice and triage calls say their duty of care for patients is being increasingly threatened by workplace surveillance.

Seven current and former nurses told CalMatters that those who spend more than 15 minutes on a call with a patient routinely face criticism from Kaiser management or get called into performance evaluation meetings. Call time, they said, factors into monthly performance scores they receive.

In addition to tracking call length, they said Kaiser uses software that tries to predict on a daily basis whether they’re being unproductive or failing to answer calls quickly. Artificial intelligence systems have also been used to rate their empathy and tone of voice.

Their comments come as the California Nurses Association begins negotiating a new contract with Kaiser this month with AI a likely issue. Kaiser nurses went on strike against AI for one day in March and picketed against AI last fall. The CNA is bargaining for 25,000 nurses, including 1,000 in call centers. 

At the same time, California lawmakers are considering several bills regulating AI in the workplace, including one that would protect from retaliation doctors and nurses who override automated care recommendations.

Kaiser defended its use of AI, saying it deploys the technology with patient safety in mind and does not use “average handle time” to assess performance.

Kaiser Permanente is the largest private employer in California, providing healthcare services to more than 9 million people in the state and to 3 million other Americans. That means the company’s use of artificial intelligence could set important precedents for managing workers with AI. It could also have a big impact on patient care, providing an early example of how the healthcare sector balances cost-cutting automation with human presence or touch.

Raquel Alvarez Sanchez, a Kaiser Permanente advice nurse in Vallejo since 2010, said she was on a call with a patient who was suicidal last year that took more than an hour because she had to wait for police to arrive before hanging up. She tried to make the man feel cared for, even though she was cognizant that staying on the call that long would throw off her average call time for weeks and could lead to questions from management. Sanchez, a union steward, said she’s accompanied colleagues to performance evaluation meetings, where they were found to have done everything right on a call — except staying on the line for more than 15 minutes. She said she hasn’t seen nurses get fired for doing that, but she fears that continued pressure can lead nurses to quit or retire early.

“I think at some point all of the nurses have been talked to about their average handle time,” she said. “The only thing I can think of is they’re doing it for profit.”

Another nurse who spoke with CalMatters on condition of anonymity due to fear of retribution described how that surveillance affected a call with a patient last year. Initially she thought her patient, an elderly woman who just received a terminal cancer diagnosis, was suicidal, but quickly came to understand that she was in shock and really needed somebody to talk to.

The nurse wanted to take time to show compassion or comfort to the woman, who acts as a caretaker for her daughter, but she stopped herself out of fear it would hurt her monthly performance score and lead to a reprimand from her manager. She became a nurse to provide people with compassionate care, but “I had to ask myself: Am I going to get disciplined for going off script or saying more than what is necessary?”

Kaiser Permanente advice nurse Raquel Alvarez Sanchez works from her home office in Santa Rosa on April 6, 2026. Kaiser Permanente nurses have raised concerns about the growing use of AI to monitor their work ahead of upcoming contract negotiations. (Chad Surmick for CalMatters)

Kaiser Permanente says its performance evaluations help improve patient outcomes. A company spokesperson said, “Kaiser Permanente does not use Average Handle Time to assess agent performance or enforce call time metrics. Any tools used in contact center settings support our quality assurance efforts and have human review and oversight.” In a statement provided to CalMatters, spokesperson Vincent Staupe added that Kaiser uses AI responsibly, with human oversight, and by “prioritizing patient safety, privacy, and equity,” but he said, “As a large organization, we do not share specific information about internal technology systems for security and operational reasons.”

Is technology putting patients at risk?

It’s not clear how patient care is affected by algorithmic management, nor is the impact of limiting the length of triage and advice calls on patients. Kaiser call center nurses can’t say for certain whether the pressures they face results in adverse outcomes for patients because their contact with patients ends after they hang up the phone. A 2024 public records request by CalMatters to the California Department of Managed Health Care found no complaints by patients against Kaiser related to call times. But nurses insist the risk to patient safety and quality of care is real. 

Consumer Watchdog patient advocate Michele Ramos said many Kaiser patients begin their care on the advice line. They later complain to her, mostly about things that happen in Kaiser facilities, but “I can see now where a lot of the problems” start, given the call constraints nurses are under.

“Kaiser’s been known through the years to manage dollars over managing care, … which is only going to fail patients.”
Michele Ramos, Consumer Watchdog patient advocate

Ramos said the time pressures may fit a broader pattern at Kaiser of putting costs over quality. The health giant was hit with a record fine, $50 million, as part of a settlement over findings from the California Department of Managed Health Care that it delayed behavioral health appointments beyond statutory limits and too often moved patients into group rather than individual therapy. Kaiser also settled with the U.S. Department of Labor after investigations into its substance use and mental health services. Kaiser faced criticism in 2002 for paying bonuses to call center workers who aren’t nurses for keeping calls short, though call center nurses who spoke with CalMatters said they encountered no such practices today.

“Kaiser’s been known through the years to manage dollars over managing care, and I think this would be a contributor to that, which is only going to fail patients,” Ramos added.

Nurses said they are pressured to stay under 15 minutes even for the sorts of calls that often take more time, like diagnosing a patient with multiple symptoms, chronic illnesses, new parents in need of advice and assurance, people who desire extended health education, or people who are overwhelmed after receiving life-altering news who could use some compassion. Nurses say calls that involve interpreters often take 30 minutes or more. About four in 10 Californians speak a language other than English and half of them do not speak English well, according to a state environmental health agency.

“The amount of time that Kaiser is giving us to complete a call is sometimes not safe,” said one nurse, who asked to remain anonymous due to fear of retaliation.

“People can get hurt,” said Charlotte Capulong, who has worked in nurse call centers for 22 years and helped organize Kaiser nurses against the AI tone-of-voice tool. Capulong said nurses felt harassed by managers in meetings she attended as a union rep, even if they successfully carried out all other duties of their jobs except completing calls within 15 minutes.

“You aren’t calling Comcast. We’re dealing with life here,” she said.

Kaiser Permanente Sacramento Medical Center in Sacramento on Monday, Aug. 15, 2022. More than 2,000 mental health physicians went on strike throughout Northern California over staffing issues leading to patients waiting longer to access help. (Rahul Lal/CalMatters)

Nurses are instructed to stick to a script on phone calls and give no more than two to three pieces of advice, Capulong and other nurses said, which means they may sometimes need to decide whether to withhold advice or face a performance evaluation hearing.

The nurses say artificial intelligence could make the surveillance nurses encounter on the job worse.

In summer 2024, Kaiser began testing an AI tool that attempts to assess empathy and tone in the voices of nurses and patients, according to nurses who spoke with CalMatters. In response, nurses circulated and signed a petition in favor of the right to patient privacy, more transparency,  and the right to exercise their professional judgement and encouraged management to involve nurse’s input and feedback. The signature campaign used the same tag line that nurses used at protests outside San Francisco hospitals earlier that year: “Trust nurses, not AI. The AI tests ended in November 2024, but union representatives were told that managers may bring the program back in the future. 

Nurses reported feeling harassed by existing surveillance, “and that was intensified when they said we’re going to use AI to evaluate our calls and grade us,” said Sanchez.

Another nurse speaking on condition of anonymity said “AI did not understand our job and would grade us wrong all the time.”

A Kaiser spokesperson declined to respond to questions about the AI tool or answer questions about the use of AI and other automated systems in the company’s call centers and healthcare facilities, including for evaluating nurse performance or whether patients were informed about the use of AI to evaluate their empathy and tone.

Nurses also said they get little time between calls even if that call involves speaking with a patient who is suicidal, experiencing a mental health episode, or near death. In years past, nurses got around 10 minutes to finish writing notes in a patient’s chart or collect themselves after a particularly tough call. Today they say they typically get 30 seconds or less when lines are busy, although more at slow times, like late at night, or if they get a manager’s permission after a particularly challenging call. The overall pace they say, can lead to mistakes like missing important cues into a patient’s wellbeing.

CNA reps declined to talk about specific provisions they intend to seek related to AI ahead of their talks with Kaiser this summer.

How surveillance and AI shape nursing

Critics say excessive workplace monitoring can lead to lower morale as employees feel less trusted and autonomous, relegated to being no more than algorithm monitors. UC Berkeley Labor Center Technology and Work Program director Annette Bernhardt has warned that algorithmic management can turn people into fleshy robots, echoing complaints from an Amazon factory worker who CalMatters interviewed last year. A 2023 academic survey of call centers in four developed countries found that using AI for management or monitoring left workers with less time between calls and more likely to feel emotionally drained by their work. Nearly half of respondents said that AI tools made their jobs more stressful. A prior study by the same researchers, Virginia Dolleghast of Cornell University and Sean O’Brady of McMaster University found that performance monitoring leads to higher rates of emotional exhaustion.

Dolleghast, who has studied the impact of surveillance technology on call center workers for more than a decade, said what Kaiser call center nurses are experiencing is part of a broader trend: Across different industries, persistent surveillance is increasing stress levels for workers who are resolving complex, emotionally-charged issues. 

“Stress and burnout can lead to more mistakes across a range of areas, and in the healthcare setting that is much higher risk because you’re dealing with people’s lives and their health,” she said.

The converse can be true: Workers who are given more discretion to decide the pace and timing of their work experience higher levels of job satisfaction and less absenteeism.

The 9-1-1 call center at the San Francisco Department of Emergency Management in San Francisco, on Aug. 2, 2019. (Eric Risberg/AP Photo)

Nurses nationwide are more frequently encountering artificial intelligence and similar software systems in the workplace. Half of more than 2,000 nurses who responded to a 2024 survey by the National Nurses United union said their employer uses algorithmic systems to analyze health records. Such systems can do things like determine how fragile a patient is or predict how many hours of care they will need. Two-thirds of the surveyed nurses said their own assessments had at some point disagreed with a computer-generated prediction. Six out of 10 respondents said they don’t trust their employer to prioritize patient safety when using AI.

Pa Vue has worked as a nurse in call centers for the better part of the past decade. She said she and other Kaiser nurses routinely have conversations with managers about call efficiency and receive evaluation scores once a month. She recalls having a score reduced for repeating advice to a patient that she worried had unusual symptoms and possible heart issues.

As a union representative in some performance meetings, Vue has seen managers raise efficiency questions about calls they deem too long. She’s also seen nurses receive lower performance scores if they go against software recommendations based on their professional opinion or make an appointment for a patient without consulting a doctor.

She believes that efficiency aims accelerated by technology can hinder a nurse’s ability to focus and reduce the quality of care that patients pay for.

“I’m not against the use of AI as long as it’s beneficial to the patient but in this particular use [empathy and tone monitoring] it’s to increase productivity and improve efficiency and cut costs. Kaiser is forgetting we aren’t just a call center for customer support, we’re nurses, and we’re there to take care of patients,” she said.

As AI improves and businesses push workers to use it, unions are, in turn, increasingly demanding that employers address issues raised by AI when bargaining for new contracts. Surveillance technology has become a common way for managers to collect data about workers in a number of industries, used for everything from improving safety to hunting for ways to increase profit gains or train AI to do a job.

At Kaiser, AI is a key issue not only among nurses but also for mental health workers, 2,400 of whom are in contract negotiations in Northern California with Kaiser Permanente. Kaiser therapists have said they are concerned about use of therapy session transcripts to train AI models and about the health-care giant using AI to take their jobs. National Union of Healthcare Workers spokesperson Matt Artz told CalMatters contract negotiations are ongoing.

How Kaiser uses AI

Kaiser Permanente is exploring or using AI in many parts of the healthcare experience far beyond nurse call centers. Kaiser uses AI to identify patients in hospitals at risk of adverse events by evaluating data on their electronic health records. An AI system called Preventus is used to determine when to discharge patients. Doctors and therapists use Abridge to record interactions and translate speech to text during in-person visits with patients instead of taking notes. Remote monitoring with AI for patients that need extra care has been tested at Kaiser Permanente facilities in the Bay Area, according to nurses who encountered the technology in the course of doing their jobs.

National Nurses United and CNA President Cathy Kennedy sees the use of AI to detect nurse empathy as part of a long series of steps by Kaiser to limit their autonomy and make them more efficient. She believes AI threatens to automate and fragment the work that nurses do, and companies developing and deploying AI systems should establish that those systems are effective and equitable before deploying them.

Kaiser Permanente in Oakland on Aug. 2, 2022. (Martin do Nascimento/CalMatters)

Notification of new tech deployments is part of the nurse union’s contract with Kaiser but sometimes nurses don’t receive notification, CNA says. So union leaders are attempting to track the number of AI models in use at Kaiser Permanente, advising its members to inform them when they encounter new tech. This paves the way for CNA to push back as it did with the empathy and tone AI last summer or as it did when it stopped a pilot program that would have replaced nurses that sit at the bedside of confused patients with cameras.

Debru Carthan, a Kaiser radiologist, is on the front line of worker-management fights over AI at the company. A member of Service Employees International Union, she is also part of the Coalition of Kaiser Permanente Unions, where she sits on a committee to discuss use of AI and emerging technology at Kaiser. The coalition also has a “see something, say something,” campaign for frontline workers to report when they notice AI deployments; the coalition says that too often management quietly implements AI into workflows without notice or worker input. She worries that the AI tone detector used on advice nurses could discriminate against nurses from different cultures and has come to believe that the use of AI in healthcare generally has more to do with money and corporate greed than patient care.

California lawmakers have responded to worker AI concerns both inside and outside the healthcare sector. They tried and failed last year to address how AI impacts workers like call center nurses. Assembly Bill 1018 and Senate Bill 7, two bills endorsed by the CNA, would have required employers to inform workers before using automated systems on the job to do things like promote or discipline workers or evaluate job performance, but Gov. Gavin Newsom vetoed SB 7, and, facing strong opposition from companies including Kaiser Permanente, AB 1018 failed to pass for the third consecutive year. 

Earlier this year, lawmakers reintroduced a new version of Senate Bill 7, now called Senate Bill 947. Another bill would prohibit employers using AI to predict the emotional state of their employees. Yet another bill would protect doctors and nurses from retaliation if they override recommendations generated by an automated system and require healthcare providers to supply employees with an inventory of automated systems once a year. Kaiser declined to share a comprehensive list of AI systems in use when asked by CalMatters.

Altogether CNA and the affiliated California Labor Federation support roughly half a dozen bills to regulate use of AI in the workplace. Calling AI a central issue in the next presidential election, members of the California Labor Federation and labor leaders from Democratic primary states held a press conference in Sacramento earlier this year to say that if Newsom wants to become president then he needs to pass laws protecting workers from AI. “It’s an ongoing fight, and it’s a fight well worth having,” Kennedy said. “Whenever there are other unions in discussion about artificial intelligence we are in solidarity with them.”

The nurse that withheld compassion to a terminal cancer patient she thought was suicidal said she believes monitoring and scoring systems turn nurses into automatons that check boxes.

“I used to use humor as a way to help patients heal, and I don’t feel comfortable doing that here because I know the calls are being recorded. You can always tell when a patient appreciates the humor or your personal compassion, but I don’t feel like call centers have tolerance for that because that’s not part of the script,” she said. “That really takes away from the whole point of being a nurse and what patients come to know from nurses.”

This story was reported with contributions from Lam Thuy Vo and Ana Ibarra.

This story originally appeared in CalMatters.

A Letter From Our CTO, Raffi Krikorian “

In New Zealand's far north, a Māori broadcaster trains speech models for te reo — a language too small for any market — under a license that keeps the data with its people. PwC, one of the largest accounting firms in the world, fine-tuned an open model on the language of finance and runs it today for hundreds of clients, on its own hardware, with no per-token meter running. Researchers in Lausanne built an open medical model with the Red Cross, tuned to its humanitarian guidelines, and are preparing clinical trials at home and in Tanzania. In East Africa, farmers diagnose cassava disease with a model that runs on the phone itself, offline, in fields the cloud has never reached. In Switzerland, a public consortium trained a national model on public supercomputers and released all of it: weights, data, training code. None of them asked permission, and none of them could have rented this. They own it — that is the whole idea.

We have been here before. Mozilla exists because one company tried to own the front door to the web, and an open community rose up to make sure it never could. Twenty-five years later, someone is running the same play. We bet on open the first time. Open won. Together, we can do it again.

Our belief is simple: the path forward is competition and interoperability. We believe in a world of many models, standard ways to plug them together, and the freedom to walk away from any vendor at any time. Open has a record here. It grew the pie and let more people own a slice of it.

Read what follows as a map: where open AI is winning — some numbers surprised even us — and where it is exposed. A case that hides its weak points is an advertisement.”

Open weights closed the capability gap while the price of intelligence collapsed.

0%

Capability gap to the top closed models — at parity on coding, behind on reasoning

0×

Fall in GPT-4-class inference cost in 36 months: $20 → $0.40 per 1M tokens

01The current state of open-source AI

Parity reached. The contest is one layer up.

Open weights are no longer a compromise. They are where the work happens: a majority of production tokens now route through them, and the five highest-volume models on OpenRouter are all open. Closed models still lead at the frontier, on reasoning and multimodality, but the frontier is not what most workloads need. Commodity inputs do not hold pricing power. Value moves up, to the agentic harness.

The capability gap: 8.04% → 0.5% → 3.3%

Open-vs-closed gap on Chatbot Arena over 24 months. By August 2024, the gap had collapsed to 0.5%, and in February 2025 DeepSeek-R1 briefly matched the top US model. By March 2026 it had reopened to 3.3% as closed reasoning models pulled ahead. But 3.3% is an average over a jagged frontier: open is at or near parity on coding, instruction-following and general knowledge, while the gap concentrates in reasoning, long-context retrieval and agentic tasks. The question is no longer whether open models are good enough. It's what you need for your workload. Hover the points.

Source: Chatbot Arena, Jan 2024 – Mar 2026.

Inference fell 50× in 36 months

GPT-4-equivalent price per 1M tokens — faster than dotcom-era bandwidth or PC-compute price curves. Log scale.

Sources: Stanford HAI AI Index 2025 (280× GPT-3.5-class drop over 18 months); Epoch AI (9–900× annual decay); Nov 2025 MIT study (5–10×/yr at the frontier, hardware-adjusted).

Open weights win the tokens

The share of tokens routed on OpenRouter through open-weight models grew from a negligible base to a third by late 2025 to a majority by mid-2026.

Source: OpenRouter 100T-token study (Nov 2024–Nov 2025) and live leaderboard; intermediate points interpolated. By request count, closed US providers still lead — the open lead is a token-volume lead, concentrated in coding and agentic workloads.

OpenRouter live leaderboard — trailing month, tokens routed

The five highest-volume models are all open weights. Anthropic's closed Claude models are the next US-built entrants.

Open weightsClosed

By mid-2026 the top nine models route roughly 18T weekly tokens for Chinese-built models against ~5.5T for US-built ones — more than 3:1 (FT analysis). Where developers route by cost, they route to open weights.

Open ships easy. Open deploys hard.

Data from the Mozilla / SlashData 2026 developer survey. Open models lead in adoption: 79% of developers adding AI functionality use them, against 71% for closed, and the two are largely complementary, with half of developers using both. But production is where teams stall: only 51% of open-model teams reach production versus 63% for closed. The gap is operational tooling and trust, not model capability.

Open models lead in adoption, and mostly coexist with closed

Share of developers adding AI functionality to their applications who currently use each model type, and how the two overlap.

Open models

79%

Closed models

71%

How they combine

29%OS only

50%Both

21%CS only

Source: Mozilla / SlashData 2026 developer survey. Open and closed aren't substitutes for most teams: 50% run both, 29% open only, 21% closed only.

Where open adoption peaks, and where closed still edges it

Open-model adoption by region. Greater China and East Asia lead at 89%; South America and Western Europe are the only two regions where closed adoption exceeds open.

Same survey, by developer region. In South America and Western Europe, and only there, closed-model adoption runs ahead of open.

Production rate by company size

If the gap were about resources, scale would close it, and it doesn't. Closed climbs 54% → 73% with scale. Open barely moves: 53% → 57%.

Closed modelsOpen models

Enterprises can buy their way through closed deployment. Open deployment waits on tooling nobody has finished. Source: Mozilla / SlashData 2026 developer survey.

Why teams churn: challenges with open models

Δ = churned − still using, in percentage points. The biggest gaps (performance, integration, maintenance) are operational, not capability. Hover the bars.

Still using openChurned away

Mozilla survey, n=1,410. “What are the main challenges you face when working with open or open-source AI models?”

The same challenges, everywhere: what blocks open by region

Share of current and churned open-model developers naming each challenge, by region. Warmer cells mean more developers blocked. The top rows are operational in every region: infrastructure cost, security and compliance, maintenance, deployment complexity. South Asia leans hardest on security and support; only North America and Greater China have more than 15% reporting no major challenges.

ChallengeW. Europe & IsraelN. AmericaGreater ChinaSouth AsiaEast Asia ex GCS. AmericaE. Europe & CISOceaniaAll High infrastructure or compute costs25%26%29%28%28%28%29%18%27%Security, privacy, or compliance concerns20%27%18%39%29%28%25%22%26%Ongoing maintenance and updates27%26%18%26%20%31%21%25%24%Complexity of deployment, hosting, or scaling27%24%19%24%11%30%26%25%23%Lack of specialised support17%16%21%31%24%23%23%32%22%Difficulty evaluating or comparing models14%17%14%23%16%26%25%18%18%Difficulty fine-tuning or customising22%18%18%20%11%22%18%12%18%Difficulty integrating into existing systems19%21%14%20%7%26%19%20%18%Insufficient documentation or learning resources18%15%15%17%15%20%24%15%17%Model performance is not good enough18%15%13%22%16%17%19%8%17%No major challenges9%21%16%5%14%4%8%12%12% Weighted sample size28627720619216414798391411

Source: Mozilla / SlashData 2026 developer survey (MZCS1). n=1,410 current or churned open-model developers; the Oceania column (n=39) and Eastern Europe & CIS (n=98) fall below reliable thresholds.

02The open-source AI stack

The open stack scores high on capability, low on operations.

Nine layers and 48 components of the stack scored across 10 criteria (1–5). Click a layer to open its components: each carries its own criterion scores, maturity grade, open-vs-closed parity verdict, and surfaces some of its most-starred open-source projects.

Hover any cell for detail.

StrongViable, but fragmentedEarly stage

Strong (≥4.0) 3.5–3.9 3.0–3.4 2.5–2.9 Weak (<2.5) the operational gap = standardization + enterprise readiness

Cells are scores per maturity criterion (1–5), ordered strongest to weakest left to right; layer rows are the means of their components. The two coldest columns, standardization and enterprise readiness, repeat down every layer and every component: that repeating cold edge is the operational gap. Source: Mozilla stack map, June 2026 (48 components, 1,361 projects).

03Who's betting on it

Open source is a business model.

Open-weight AI is a commercial market at multi-hundred-billion-dollar scale, built by funded companies and run in production by global enterprises. Databricks crossed a $5.4B run-rate; Mistral scaled 20× to ~$400M ARR in twelve months; DeepSeek reached ~$220M ARR and recently raised $7.4B at a valuation over $50B. Five revenue models are proven at scale: hosted inference, enterprise platforms, on-prem licensing, fine-tuning services, and harness tooling.

The venture-funded open-source ecosystem: total disclosed funding, USD M

Bars grow as you scroll. Color by region of the company.

North AmericaChinaEurope & rest of world

Selected companies; Zhipu AI and MiniMax went public (HK IPO 2026) with undisclosed totals. Corporate strategics (Nvidia, Salesforce, AMD, Google, IBM, ASML, Tencent, CATL, Schwarz Group) back the same ecosystem across model, inference, and tooling layers.

Financial maturity of the open ecosystem

Funding, valuation and revenue traction for the companies carrying the open stack. The ecosystem has moved from grants to venture scale to public markets.

CompanyHQLayerDisclosed fundingValuationRevenue signalLeading investorsStage DatabricksUSAEnterprise platform——$5.4B run-rate—Pre-IPO DeepSeekChinaFrontier open weights$7.4B$50B+$220M ARRLiang Wenfeng; Tencent; CATL; China National AI FundPrivate Mistral AIFranceOpen weights + platform$3.05B$14B (talks at €20B)~$400M ARR, 20× YoYASML; a16z; Lightspeed; NvidiaPrivate Moonshot AIChinaOpen weights (Kimi)$3.9B——Meituan/Long-Z; Alibaba; Tencent; HongShanPrivate Zhipu AIChinaOpen weights (GLM)UndisclosedPublic—Public (HK IPO 2026); prior Alibaba, TencentHK IPO 2026 MiniMaxChinaOpen weightsUndisclosedPublic—Public (HK IPO 2026)HK IPO 2026 CohereCanadaEnterprise / on-prem$1.7B—Command A+ open-sourced May 2026Radical Ventures; Nvidia; AMD; Schwarz GroupPrivate CerebrasUSACompute$2.1B——Fidelity; Atreides; G42; Tiger GlobalPrivate Reflection AIUSAOpen weights$2.13B——Nvidia; Disruptive; Sequoia; Lightspeed; DST GlobalPrivate Together AIUSAInference cloud$1.334B——Aramco Ventures; General Catalyst; Prosperity7; NvidiaPrivate Hugging FaceUSAHub$400M——Salesforce; Google; Nvidia; IBMPrivate LangChainUSAHarness tooling$260M—126k+ stars, 60% dev shareIVP; Sequoia; Benchmark; CapitalGPrivate

Five revenue models are proven at scale: hosted inference, enterprise platforms, on-prem licensing, fine-tuning services, and harness tooling. “—” = not publicly disclosed.

The metered model breaks at scale

Closed frontier models are sold by the token — and at production scale the meter becomes the problem.

A fifth of the usage, 4% of the revenue

On OpenRouter (May–Sep 2025), closed models held ~80% of usage and ~96% of revenue. Price drives it: at ~90% parity, closed costs ~6× more per call.

~$24.8B

in unrealized annual savings — the Nagle–Yue study for the Linux Foundation's estimate of the open-vs-closed price asymmetry, at ~6× the cost per call for comparable capability

Where developers route by cost, they route to open weights.

04Why it's happening everywhere

Open isn't a vendor choice. It's a sovereignty choice.

More than 70 national AI strategies are live. The strategic question has shifted from whether to have a national AI policy to which layer of the stack a country can own.

Click a marker or a country below.

The case for open is optionality

Optionality stopped being abstract in June 2026, and it stopped being a procurement question. Three days after Claude Fable 5 went on sale, a single government's export order forced Anthropic to cut access for every foreign national on earth. No other capital was consulted. None could have been. Selective compliance was impossible, so the models went dark for everyone at 5:21 p.m. on a Friday. Anyone who had built on that model inherited a shutdown they had no warning of and no part in. A provider can switch off a model. Nobody can switch off a copy already running on a machine you hold, and that holds whether the machine is a startup's server or a national supercomputer. For a company, weights on disk are a hedge. For a state, they are the difference between a policy and a permission.

The strategic case for open is the ability to leave, and the cloud era proved the cost of its absence:

$90–120kto move one petabyte out of AWS S3

**80%**of enterprises now repatriating workloads

$3.2M → <$1M37signals' cloud bill after leaving

**2.5×**what GEICO's cloud costs ran over plan

Closed model APIs reproduce the same trap: build on a proprietary endpoint and you inherit the vendor's pricing changes with no clean exit. Open weights are exit rights.

The largest source of open weights is China. By design.

Cumulative Hugging Face downloads, March 2026:

In February 2026 Qwen out-downloaded the next eight organizations combined. On OpenRouter, Chinese open-weight models rose from under 2% of tokens in late 2024 to more than 45% of weekly traffic by April 2026, and about 61% among the ten most-used models. DeepSeek reports 26,000+ enterprise accounts; 58% of new AI startups in 2025 included it in their stack, even as at least eight jurisdictions restricted the hosted service. The resolution is architectural: enterprises ban the hosted app and adopt the weights anyway, self-hosted or via Western endpoints.

This is intentional policy. The State Council's "AI Plus" Initiative (Aug 2025) and the national Five-Year Plan (Mar 2026) codify open-source proliferation as a core directive, and releasing public weights doubles as a macro hedge against semiconductor export controls, offloading global inference onto end users' local hardware. Across the Global South the draw is diversification away from US technology monopolies; elsewhere it is purely financial. Even Microsoft is exploring a secured, Azure-hosted DeepSeek V4 for its heaviest Copilot workload.

Marker size ≈ scale of committed public/strategic capital · Equirectangular projection

Source: Open Source AI jurisdictions dataset, July 2026. Marker size scales with committed public and strategic capital.

05The harness is the new frontier

The agentic harness is another user agent.

The browser was the user agent of the open web: code on the user's side, negotiating with servers on their behalf. That role is being recreated one layer up. Above the model now sits the agentic harness — the orchestration loop, tools, memory, sandboxes, and permission model. It is where production difficulty concentrates, and where the open-vs-closed, owner-vs-renter contest restarts.

The user · other agents · the worldhumans · systems · data · money

Governone plane over many harnesses

Stateful policywhat the session already did

Registry & lineagewhich agent did what

Budget & revocationcost caps · kill switch

Meta-harness · Omnigent · OPA · Agent governance toolkit

Surfacemeets user & money

InterfaceAG-UI · A2UI

Payment & meteringx402 · AP2 · UCP

Actiondo things, safely

Sandboxes & executionE2B · Daytona · Modal

Permission & identitythe write surface — the unsolved gap

Eval & observabilityLangfuse · Phoenix

Reachconnect & remember

Tools & contextMCP

Agent-to-agentA2A

MemoryMem0 · Letta · Zep

Controldrive the loop

Orchestration loopLangGraph · CrewAI · AutoGen · LlamaIndex — the reason-and-act cycle that turns a model into an agent

The model — the weightsopen or closed · swappable · commoditizing toward zero

The layer is already a product category: LangChain alone has 126,000+ GitHub stars and a 60% developer share; MCP reached 97M monthly SDK downloads and 10,000+ active servers in its first year, growing 4,750% in 16 months — and was donated to the Linux Foundation's Agentic AI Foundation in December 2025. Adoption outpaces governance: only ~21% of companies report mature agent governance.

The model is eating the harness, and that's the opening for open

Terminal-Bench 2.0 (May 2026) made the harness look like a free lunch anyone could capture: a third-party scaffold ran Anthropic's own weights to 79.8% while Claude Code managed 58.0% on the same model, a 21.8-point spread that put the harness ahead of the weights. Eight weeks later, Terminal-Bench 2.1 reversed it. The frontier labs read that result and pulled the harness in-house: on every model where both appear, the lab's own harness now wins, and the 21.8-point gap has compressed to roughly 3 at the top: the model eating its way up the stack, weights and scaffold shipped as one product.

May 2026 · Terminal-Bench 2.0

July 2026 · Terminal-Bench 2.1 · official board, verified top tier

That integration is a moat in formation, and the labs have every incentive to deepen it. A harness tuned tightly to one lab's weights becomes a fit rather than a neutral layer. It degrades on anyone else's model, so the tighter the tuning, the less swappable the weights underneath. Lock-in arrives as a side effect of optimization. The open models have no first-party harness to answer with, which is why none appear in the verified top tier of the official board at all.

But absence isn't inability: put every model on one neutral scaffold and the gap collapses

vals.ai's Terminus-2 run of Terminal-Bench 2.1: the same benchmark, one neutral harness for everyone. Capability bars in points; cost per task in the label.

On a fair harness the capability gap is a few points; the price gap is 5×. The strongest open model, GLM 5.2, lands a fraction behind Claude Opus 4.7 and about four points behind Opus 4.8 at roughly a fifth the cost. Integration buys the labs a second edge open deployments lack: a data flywheel where real usage through the lab's harness feeds straight back into the next model. That edge is real, and it cuts both ways: the usage exhaust trains whoever owns the harness, and the only question is whether that's the closed endpoint or your own stack. The labs have proven the harness is worth owning. The same move is open, a harness co-designed with open weights, and the window to keep it a layer is now, before the closed stacks finish welding model and scaffold into one rented product.

The write surface: the unsolved hole at the center of the harness

Reads

Reversible and low-consequence. Fetching a document, querying a database, listing a calendar. These can largely be permitted by default; a bad read costs little and can be repeated safely.

Writes

Side effects that are costly or irreversible. Sending a message, spending against a budget, modifying a record, executing a transaction. This is where confirmation, approval thresholds, cost caps and revocation must concentrate.

The unsolved permission problem is a write problem. The harness ecosystem now spans roughly a dozen frameworks, ten harnesses and three peer protocols, yet no portable model defines which writes an agent may perform unattended, which require human approval, and which are forbidden, across an MCP host, an A2A peer, a direct tool invocation and a framework boundary. The protocols hardened the front door and stopped there: MCP's 2025-11-25 specification moved authorization onto OAuth 2.1, and A2A v1.0 standardized signed Agent Cards, but both stop at authentication. Knowing who an agent is says nothing about what it may do.

The human backstop is failing too. CoSAI's MCP threat model lists consent fatigue, the pattern in which users approve the large majority of prompts, as a top-tier threat. Consent fatigue is itself a write-side failure, because the prompts that matter are the ones authorizing action.

Industry responses are bypassing the framework deadlock by pulling control up to the meta-harness layer. Instead of fragile prompt-based filters inside individual agents, emerging cross-harness architectures (like Databricks' open-sourced Omnigent) enforce stateful, contextual policies that track what a session has done and gate the next write accordingly: requiring human approval for a code push once an agent has pulled an unverified package, or enforcing cost caps that pause a session after a set spend. These controls govern the write surface from a layer above any single harness, which is where the durable permission model is most likely to form. It is the single highest-leverage gap in the layer.

Closed is not the same as secure

A closed API feels safe because of filtering, monitoring, and revocation. All three are functions of the serving layer. Keeping the weights secret does not provide any of them. The same controls live at the harness layer and apply to self-hosted open models. In 2025, authorization failures rated CVSS 9.3–9.4 hit Anthropic, Microsoft, ServiceNow and Salesforce, all closed systems. The NTIA studied whether the US government should restrict open weights and recommended that it monitor them instead. Security concerns are best addressed by investing in the harness. They do not require renting a closed model.

Where closed still leads

Closed systems still lead in four places. The first is the integrated harness. No open model appears in the verified top tier of the official Terminal-Bench 2.1 board, and even on a neutral scaffold the best open model trails Opus 4.8 by about four points. Behind that harness sits a data flywheel, since usage routed through a lab's own scaffold feeds back into its next model. The second is long-context fidelity at 1M tokens, where Gemini 3 holds 89% multi-needle retrieval against DeepSeek V4-Pro's 41%. The third is turnkey compliance, with SOC 2, HIPAA, and zero data retention available by default. The fourth is accountability, meaning a counterparty the customer can hold liable.

Compliance and accountability are contracting problems. The integrated harness is a tooling problem. Long-context fidelity is a model problem, and closing it is work only the open labs can do.

06Opportunities

Five bets. None requires beating the frontier.

They require owning the layers above it — the harness, the memory, the permission model — while those layers are still open.

07The watchlist

Signals that keep the layer open.

Capability & adoption

The 3.3% gap (at parity on coding, behind on reasoning and agentic), and open's OpenRouter token share, especially in agentic coding.

Reverses if: token share stalls while the reasoning gap widens.

The harness

The Terminal-Bench spread between lab-owned and independent scaffolds; MCP/A2A governance under the AAIF; the portable permission spec that still doesn't exist.

Reverses if: the lab-harness lead widens, or a closed platform sets the permission standard first.

Market structure

Open-lab economics (ARR, raises, the Zhipu/MiniMax IPOs) against metered-pricing breakpoints (~2027–28), with sovereign capacity as counterweight.

Reverses if: sovereign funding lapses or open-lab economics fail to scale.

Trust & safety

Tracked, not settled: misuse capability and how easily safety tuning strips from open weights; hard-friction zones, above all synthetic CSAM and NCII; whether NTIA's “monitor, don't restrict” holds.

Reverses if: a major misuse event, or a shift from monitoring to restriction.

There is a test you can run for the rest of this. Look at who is seated in the rooms where AI gets decided, and with what status. The day they seat the people who keep AI open, portable, and widely deployed on equal footing, the shift from renting to owning will have happened. The window is open now. It is closing slowly enough that we can pretend it isn't, and the lease is shorter than it looks. Build with us.

Citations

Section 1 · The current state of open-source AI

• Capability gap 3.3% / gap collapse to 0.5% / six of top-ten Arena slots closed
• 8.04% on Chatbot Arena
• Inference 50× / $0.40 per million tokens / December 2025
• Open weights ~third of production tokens / 100T-token study
• Mistral 20× to ~$400M ARR
• 280× / 2025 AI Index
• Epoch AI 9×–900× annual decay
• November 2025 MIT study
• Live leaderboard / market-share panel / intelligence ranking
• FT analysis
• DeepSeek-R1 (model card)
• 79.8% on AIME 2024 / pass@1
• $0.55/$2.19 pricing
• o1's $15/$60
• DeepSeek-V4 Pro
• 89% of AI-enabled firms use open components
• MIT NANDA ~67% vs ~33%
• Stanford 95% of pilots no measurable impact

Section 2 · Who's betting on it

• Databricks $5.4B run-rate / 65% YoY
• Databricks fundraise >$165B
• Mistral ~$400M ARR in twelve months
• Mistral €3B at €20B valuation
• DeepSeek ~$220M ARR
• DeepSeek raise $7.4B / >$50B valuation
• Microsoft canceling Claude Code licenses
• Token billing consumed annual AI budget
• Uber exhausted AI coding budget
• Uber engineers billing $500–$2,000/mo
• Uber capped spending at $1,500
• Stripe 73% cut on vLLM
• Microsoft exploring Azure-hosted DeepSeek / Copilot Cowork
• Linux Foundation ~80% usage / ~96% revenue / ~6× per call

Section 3 · Why it's happening everywhere

• AWS S3 egress $90k–$120k
• 80% of enterprises repatriating / cost reductions >25%
• 37signals $3.2M → <$1M
• GEICO cloud costs 2.5×
• June 2026 government order / Fable access
• Qwen 942M downloads
• Qwen out-downloaded next eight orgs
• Chinese models >45% of weekly traffic
• 61% among ten most-used
• DeepSeek 26,000+ enterprise accounts
• 58% of new AI startups / market share
• Eight jurisdictions restricted DeepSeek
• State Council “AI Plus” Initiative
• National Five-Year Plan
• Macro hedge / export controls
• France €109B
• EU AI Act GPAI exemptions
• Mistral Series C €11.7B / ASML 11%
• Mistral Medium 3.5
• EC four-part package
• Frontier AI Grand Challenge
• EUROPA consortium
• Portugal Amália
• Germany BMDS SPARK API
• Canada “AI for All”
• Cohere Command A+
• Nick Frosst quote
• Cohere North Mini Code
• India 38,231 GPUs
• ₹10,372 Cr outlay / 600 data labs
• India +5M GitHub developers
• 13.59% of DeepSeek MAU
• OECD.AI Policy Observatory
• Oxford Insights Gov AI Readiness Index 2024
• G42 / $15.2B Microsoft partnership
• South Korea $71.5B
• Saudi Humain $77B / 1.9GW

Section 4 · The harness is the new frontier

• LangChain 126,000+ stars / 60% share
• MCP servers/downloads (year in review)
• Databricks Omnigent
• Terminal-Bench 2.0
• Terminal-Bench 2.1 / Codex CLI / Fable scores
• vals.ai Terminus-2 run
• GLM 5.2
• MCP donation / 10,000+ servers / 97M downloads
• Linux Foundation AAIF formation
• OAuth 2.1 with PKCE (2025-03-26 spec)
• A2A production / platinum members
• ~21% mature agent governance
• Memory vendor landscape (Mem0/Letta/Zep/LangMem)
• Sandboxes (E2B/Daytona/Modal)
• Observability (Langfuse/Phoenix/LangSmith)
• Auth platforms (WorkOS/Okta/Auth0/Stytch/Arcade)
• Safety fine-tuning strip / NTIA response (CNAS)
• CVSS 9.3–9.4 authorization failures
• NTIA “monitor, not mandate”
• Multi-needle 1M-token retrieval
• Future of Life AI Safety Index
• Contractual assurances (Linux Foundation / ITPro)
• MCP 2025-11-25 spec
• A2A signed Agent Cards
• CoSAI MCP threat model

Section 5 · Opportunities

• “Hundreds” (OpenAI)
• “Billions” (Anthropic Series H)

Yet another thought piece about LLMs. I know. Bear with me.

This is an attempt to put words around something I think most developers are experiencing right now but haven't had time to make sense of. Programming with LLMs is genuinely useful and genuinely destabilizing. These two things coexist. If we pretend the second one isn't happening, we will all burn out.

At Pydantic, we build tools that developers use to validate data, build AI agents, and observe what their systems are doing in production. We are, quite literally, in the business of making LLM-powered software more reliable. And we are also having a weird time.

This isn't a thinkpiece about whether AI will replace programmers. It's not a doomer essay and it's not a hype piece. It's an honest account of what it feels like to be a developer right now, from someone inside it, and some thoughts on what might actually help.

Hands in the fabric

When I was first learning to code in my early twenties, I remember having this distinct sensation that programming let me dip my hands into the fabric of the universe and shape it to my will. This was, of course, before I'd hit too many compile errors. But that feeling of touching some deep fundamental layer of abstraction, of being able to make things from nothing but logic, has always stuck with me.

I'm not a Computer Science graduate. I'm a designer and a programmer — formally trained in the first, self-taught in the second. I came to the formalisms of software engineering through painful experience rather than academic instruction. If anything, that made me take those principles more seriously once I understood them. When you've earned your opinions about architecture and code quality the hard way, they feel less like textbook rules and more like scar tissue.

That primal feeling of creation? It's the same promise that the low-code and no-code tools of the 2010s kept making but never quite delivered on. I'm old enough to remember building web pages in Dreamweaver, watching Adobe spruik zero-code design tools that generated absolute spaghetti under the hood. It was always almost there, just good enough to hint at a future that was just around the corner (if only you were smart enough to grasp it).

If you're cynical about the current wave of AI tools, I get it. We've been promised this before. But this time the gap between promise and reality has actually, finally, narrowed to something meaningful. And that's exactly what makes it so unsettling.

What "the code writes itself" actually feels like

Yes the code (sorta) writes itself, but the human reviewing, directing, and course-correcting feels worse, not better.

I recently had a conversation with my colleague Douwe, who maintains the Pydantic AI framework and has been one of the most thoughtful people I know about integrating LLMs into open source workflows. He described waking up to thirty PRs every morning, each one pulled overnight by someone's AI, and needing to make snap judgment calls on every single one. The temptation to delegate the review itself to an AI was enormous. But, as he put it: "at that point, what am I still doing here?".

The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it still do something inexplicably stupid. Port a React hook into a Storybook story file. Read from the wrong plan. Invent components that don't exist. And these aren't errors of capability; they're errors of coherence. The models are smart enough to produce plausible code, but not always smart enough to maintain a coherent intent across a complex change.

This creates a peculiar new kind of fatigue, the fatigue of supervision: of holding the intent in your head while the machine generates volumes of mostly-correct output that still needs your eyes, your judgment, and your taste. Douwe put it well: he used to get a dopamine hit from collaborating with a real person on a cool feature in open source. Helping someone become better at their craft. Now, he said, "everything I write goes into some AI black hole. There's no person on the other side actually learning anything." That loss is real and it's worth naming.

The intensity trap

Simon Willison recently highlighted a Berkeley Haas study which describes how AI usage increases the intensity of work. The constant pull of "one more prompt at the end of the day, one more feature that could make this perfect." I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought.

Marcelo, another Pydantic colleague, when asked about his Claude Code session freezing said: "just open 5 claude sessions. You'll never notice because you're busy giving feedback to the others." He was joking. I think. But it captures something true about the current moment. The parallelism is exhilarating and kind of feral. The number of things you can start has dramatically increased. The number of things you can thoughtfully finish hasn't changed at all, because that part still requires the one resource we can't parallelise: your brain.

Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.

If you're feeling like your work is simultaneously more productive and less satisfying, you're not broken. The feedback loop is broken. And I think we need to start treating that as an engineering problem in its own right, not a personal failure.

It's also, frankly, quite lonely. Programming with an LLM is an intensely solitary activity.

You and the machine, going back and forth, refining and prompting and reviewing. The natural moments where you'd turn to a colleague to ask a question, to rubber-duck a problem, to share the small victory of something finally clicking. Those moments get quietly replaced by another prompt. In a team without a strong existing culture of collaboration, this has a tendency to further separate people, to chill communication at precisely the moment when you most need the reassurance that other humans are finding this hard too.

And it's addictive in a way that makes the isolation worse. Sometimes you get something brilliant, sometimes garbage, and you never quite know which. Textbook Skinner Box. It can be genuinely hard to step back and remember that you're allowed to just... write code. But switching between LLM-assisted and manual work is jarring and uncomfortable, two very different modes of thinking, and it takes a kind of maturity and confidence to give yourself permission to switch.

Breakpoints

This moment brings to mind the fear and angst caused by responsive design. I was working as a designer and frontend developer at the time, following Ethan Marcotte and the Zeldman / A Book Apart crowd like everyone else, and I remember how unsettling it felt to be told that the fixed-width layouts we'd all mastered were basically over.

For the younger devs: there was a genuine cultural moment around 2009 when websites moved from fixed, pixel-perfect, magazine-style layouts to fluid, responsive ones. And designers hated it. The loss of control was existential for people whose entire identity was built around precise layouts and perfect grids. You're telling me the user might see my design at any width? On any device? That the layout I crafted would... flow?

Image design by Jyotika Sofia Lindqvist

The resistance was intense. And it was understandable. People had built real expertise in a paradigm that was being fundamentally disrupted. The designers who thrived through that transition were the ones who reframed their skills. The eye for proportion still mattered. The understanding of hierarchy still mattered. The craft didn't die, it evolved. What became less relevant was the obsession with pixel-level control. What became more relevant was understanding systems, adaptability, and designing for uncertainty.

I don't want to oversell this parallel. Responsive design played out over years. The current shift is measured in months. Agencies lost clients and designers lost gigs over the responsive transition, but it didn't carry the same existential dread. The stakes are materially different, and the pace is genuinely exhausting in a way that the responsive transition never was. But the underlying pattern, of craft evolving rather than dying, of the core skills mattering more not less, I think that holds.

Working with LLMs on code feels like a similar inflection point. The skill isn't gone, it's shifting. You're not less of an engineer because you didn't hand-write every line. But you do still need to know what good looks like, arguably more than ever, because you're now the quality gate for a much higher volume of output.

What survives

In an era when anyone can produce reasonable-looking UI and code that compiles, the distinguishing markers become: taste, nuance, mature architectural opinions, and the contrarian calls that come from genuine expertise rather than pattern-matching.

It's noticeable to me that we are most successful guiding LLMs in the domains where we understand the code, the decisions, and the trade-offs most deeply. As we venture into the shallow ends of our skill sets, the outputs become markedly more impressionistic. Further from production-ready. More plausible-looking, less actually correct. The model doesn't know what it doesn't know, so it fills the gaps with confidence. Sound familiar? It's a very human failure mode, too.

But new skills are also emerging. I've started running what I call pre-mortems on complex plans: asking a fresh LLM session to assume the plan has catastrophically failed and diagnose why. It catches specification gaps that I miss after two days of being too deep in the details. One of our engineers built a tool that extracts rules from thousands of his past code review comments to seed an AGENTS.md file, essentially encoding years of implicit engineering judgment into instructions an LLM can follow. That's not the death of expertise. That's expertise being distilled.

The people who are finding their footing right now seem to share a few traits: they have strong opinions earned through practice, they can distinguish between principles that still apply and habits that were just bandwidth constraints, and they're willing to evolve their workflow without abandoning their standards.

A view from inside the loop

I don't think the current wave of AI represents the end of software engineering as a profession. I do think it represents a serious contraction and a fundamental reshaping of what the work is. The fear of obsolescence is legitimate. The fear of skill rot is legitimate. And the fear that if you don't go fast enough you'll be left behind is — while often overstated — not entirely unfounded.

But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part. Now that it's being automated, those human capacities are revealed as the actual scarce resource. And scarce resources are valuable.

So if you're feeling overwhelmed, destabilized, simultaneously more productive and less happy, know that you're not alone. The team building the tools you're probably using to navigate this moment is feeling it too. We're debugging our reward functions in real time, same as you.

The code is changing. What we do with it is changing. How it feels is... a work in progress.

But the humans are still in the loop. We're just tired. And that's worth talking about.

A chemical process called carbonation, which helps seal cracks, could help explain why many ancient Roman structures are still standing today. Researchers hope that the insights will lead to better modern-day building materials

image of ancient roman villa

The Canopus, a pool at Hadrian's Villa in Tivoli, Italy Carole Raddato via Flickr under CC BY-SA 2.0

Ancient Roman infrastructure has stood the test of time. Today, you can walk through Italy and see concrete buildings, roads and aqueducts that have survived for about two millennia. Modern concrete, on the other hand, usually crumbles within roughly 100 years.

Scientists have long tried to uncover the secrets of Roman concrete’s durability. For years, they assumed that its longevity was thanks to one key chemical process: the pozzolanic reaction, which occurs when volcanic ash reacts with the chemical lime and water. While that still holds, there seems to be more to the story.

It turns out that another chemical reaction, known as carbonation, might also contribute to Roman concrete’s longevity. The findings, published in the journal Science Advances on July 8, could help researchers develop more sustainable and resilient concrete materials.

For the new work, researchers traveled to the 1,900-year-old Hadrian’s Villa, a UNESCO World Heritage site that sits about 17 miles east of Rome. The sprawling estate is an architectural marvel, but one of its scientific gems are the communal toilets. They offer an unprecedented opportunity to study Roman concrete in its original state, unaltered by modern hands.

“Nobody restores a latrine,” says Paulo J. M. Monteiro, a study co-author and civil engineer at the University of California, Berkeley, to Sam Macdonald at Scientific American. “So, the material sat undisturbed for 19 centuries, quietly running an experiment no one alive could start.”

Need to know: Who was Hadrian?

Hadrian was the emperor of Rome from 117 to 138 C.E. He’s well known for having a wall, called Hadrian’s Wall, built in northern England to protect the Roman province of Britannia from neighbors in what’s now Scotland.

Monteiro and his colleagues took a concrete sample from underneath a toilet seat. Back in the lab, they examined it under a high-powered microscope, scanned it with X-rays and analyzed its chemical composition.

As expected, the specimen contained evidence that volcanic ash, lime and water had been combined to form the material. However, a closer look at the concrete’s pores and fractures revealed that calcite, a mineral with calcium, carbon and oxygen, was the primary binding agent.

When atmospheric carbon dioxide reacts with the calcium compounds in the concrete, it forms the hard mineral calcite, which contains a lot of the compound calcium carbonate. The mineral fills small cracks and pores in the concrete, allowing ancient structures to strengthen and heal over time.

“While the pozzolanic reaction is of fundamental importance, our findings suggest that carbonation over a long period of time also enhances the durability of concrete and can help it seal cracks as it ages,” Monteiro says in a statement.

The work builds on a study published in 2023 that suggested that Roman concrete could repair cracks on its own because it was created with chemical reactions involving quicklime, a form of limestone, which left behind calcium-rich deposits in the material. The deposits could react with water, such as rain, and recrystallize to fill in any gaps.

With the new study, carbonates have entered the limelight. The research “strengthens the idea that carbonates are more dynamic in these systems and play a fundamental role, not a marginal one,” says Admir Masic, a materials scientist at MIT who co-authored the 2023 study but was not involved in the new work, to Scientific American.

Monteiro and his colleagues hope that by understanding how Roman concrete worked, modern-day experts can build concrete that has less of an environmental impact. Concrete is one of the world’s most consumed materials, but its production emits an enormous amount of heat-trapping carbon dioxide—about 8 percent of emissions worldwide. According to the United Nations, roughly half of the buildings that will exist by 2050 have not yet been built, which is why it’s important to develop construction materials that have a reduced carbon footprint.

“This study shows how exploring ancient engineering techniques can lead to important revelations,” Monteiro says in the statement. “We hope that by unlocking Roman secrets for enhancing concrete durability, we can someday attain sustainable modern infrastructure development.”

Located in Illinois, he first designed the residence at age 22 and lived in it for 20 years

The Frank Lloyd Wright Home and Studio.Photo: Courtesy of Frank Lloyd Wright Trust, Chicago. Photographer: James Caulfield

For many architecture buffs, the very first stop on a trip to Illinois is the Frank Lloyd Wright Oak Park Home and Studio, the architect’s primary residence from 1889 until 1909. Every day, visitors from across the world travel to the quiet Chicago suburb, which today has the highest concentration of Wright buildings. While in the area, a visit to Wright’s own Oak Park home and studio offers the opportunity to see where many of these structures were designed and how the legendary architect himself lived. Before setting up shop at Taliesin in Wisconsin and later Taliesin West in Arizona, Wright was at work establishing himself and figuring out his distinctive architectural eye in Oak Park. Below, everything you need to know about the Frank Lloyd Wright Home and Studio.

History of Frank Lloyd Wright’s Home and Studio

At age 22 in 1889, Wright was a budding architect and newly married to his first wife, Catherine Lee Tobin Wright. He was working for the architecture firm Adler & Sullivan and still years away from taking on his first independent commission and opening his own practice. With money borrowed from his boss, Louis Sullivan, he bought a lot on Forest Avenue in Oak Park and built a home for himself and his wife. In its first iteration, the residence was modest in size, with a primary bedroom, a nursery, and a work space. In 1895 the first major addition was completed, a project that included reconfiguring the downstairs to allow for a larger dining room and a new maid’s room. Upstairs, a playroom was added and the workspace was divided into two bedrooms for their growing family—by the fall of that year, they had welcomed four of their six children.

The playroom in the Frank Lloyd Wright Home and Studio.

Photo: Courtesy of Frank Lloyd Wright Trust, Chicago. Photographer: James Caulfield

Wright left Adler & Sullivan in 1893 after a dispute surrounding his independent projects, and he opened his own practice that same year. In 1898, after working in downtown Chicago offices for years, he built a studio wing in his home, which would allow him to be closer to his family and his commissions, many of which were being built in Oak Park. Attached to the home via a passageway, but with a separate entrance on Chicago Avenue, this addition included an office, a double-height drafting room with a balcony on the upper level, a reception hall, and a library.

“This is where he really began his architectural career,” Frank Lloyd Wright Trust curator and director of interpretation Sarah Holian says. “You get to see not only how he created a home for his family—he had six children in what is really quite a modest-size home—but also where so many of the early Prairie designs that he’s known for were created in the adjacent studio.”

Wright left Oak Park and separated from Tobin Wright in 1909. Before leaving, he divided the studio and the home, allowing Tobin Wright and the children to live in the studio wing and rent out the house for income. Wright sold the property in 1925 and later owners divided the building into six units and neglected to preserve the historically significant property.

The restoration of Frank Lloyd Wright’s Home and Studio

In 1974, the Frank Lloyd Wright Home and Studio Foundation and the National Trust for Historic Preservation bought the property and set to work restoring the structure. The organizations strived to bring it back to the state it was in 1909 before it had been subdivided. According to the Chicago Tribune, the process took 13 years and $2.5 million, not adjusted for inflation. The project involved removing modern updates, like shag carpeting, and restoring water-damaged walls, among other adjustments. The studio’s foundation was stabilized and a basement was dug out, providing a space to store the Trust’s archive and collections.

Wright’s drafting room in his Oak Park studio.

Photo: Courtesy of Frank Lloyd Wright Trust, Chicago. Photographer: James Caulfield

“There is no question in my mind that, of all of my grandfather’s buildings that have been restored, the Home and Studio has received the finest restoration,” the late Eric Lloyd Wright, architect and grandson of Frank Lloyd Wright, wrote in the foreword to Building a Legacy: The Restoration of Frank Lloyd Wright’s Home and Studio.

Architectural details of Frank Lloyd Wright’s Home and Studio

The original home—first built in 1889, then expanded in 1895—is defined by its high-pitched roof. This element makes it an outlier among Wright’s most well-known residences, whether Prairie or Usonian, which Wright designed later in his career and generally have a flatter profile. “I think people are surprised when they visit for the first time that his home isn’t a Prairie-style home, which he’s so well known for in the Chicago area and certainly for his early career,” Holian says. “It’s a shingle-style structure, which I think is surprising to many people when they come to visit if they haven’t seen photos.” Indeed, the building’s geometric profile is imposing in an entirely different fashion than the well-known Robie House, the definite example of the Prairie style with its long and low profile.

Like the residence wing, the studio wing is clad in cedar shingles and brick, creating a sense of visual continuity between the additions and the original house. Located on opposite sides of the studio wing, the library is octagonal in shape and the drafting room’s upper section is octagonal too, giving the structure a unique geometric façade.

The exterior of the residential portion of the property.

Photo: Courtesy of Frank Lloyd Wright Trust, Chicago. Photographer: James Caulfield

One of the most striking architectural elements of the home is the playroom. The space features a barrel-vaulted ceiling topped by skylights filtered with wood grilles and a mural designed by Wright and painted by Charles Corwin. Accessed through a dark hallway, it’s an early example of Wright’s affinity for “compression and release,” in which a relatively cramped and dim area gives way to a spacious, bright room.

As Holian points out, barrel-vaulted ceilings are just one of many details in the house’s design that would go on to appear in Wright’s later commissioned work—in this case, in the Dana-Thomas House in Springfield, Illinois. “It was his living laboratory, [Wright was] trying to see what designs worked in place as he was living through them,” Holian says.

Interior design inside Frank Lloyd Wright’s Home and Studio

Natural materials and earth tones are employed throughout the Frank Lloyd Wright Home and Studio, with green hues in particular used in light fixtures, upholstery, and stained glass. Detailed woodwork is a constant, and it’s particularly crucial in the living areas and studio. In the early days of the home, the ceiling in the entry, dining room, and living room was painted light green, while the lower half of the walls featured dark green paint, per The Plan for Restoration and Adaptive Use of the Frank Lloyd Wright Home and Studio, which meticulously recounts the home in its various stages. The dining room walls were slightly glitzier, with a gold overlay pattern on the lower half of the walls. Light green was used again in the kitchen for both the ceiling and the walls. Throughout, the green tones were balanced with trim painted red or oak trim with a honey stain.

Both the playroom and the primary bedroom feature custom murals, and the latter features a frieze on each of the side walls too. “Wright never really said that many other artists inspired him, with the exception of Louis Sullivan,” Holian says. “One of the really wonderful tributes to Sullivan in the home is a stencil on the primary bedroom wall that Wright borrowed from the Auditorium Building that he worked on with Sullivan, so we see that very direct influence there.”

Dining room looking south, table and chairs in foreground and 1897 modifications to the bay are not present, platform and two rows of windows visible, at the Frank Lloyd Wright Home and Studio, located at 951 Chicago Avenue, Oak Park, Illinois, circa 1895–1897. (Photo by Frank Lloyd Wright Preservation Trust/Getty Images)

Photo: Frank Lloyd Wright Preservation Trust/Getty Images

Much of the furniture and artwork that’s in the home nowadays are authentic pieces from when Wright inhabited the space, donated or acquired from the Wright and Tobin family beginning in the ’70s. For example, per Building a Legacy, the original dining chairs were at Taliesin in Wisconsin when the restoration of the Oak Park home and studio began. The committee wrote to Olgivanna Wright, Wright’s widow and then president of the Frank Lloyd Wright Foundation, who agreed to donate six of the chairs to the home. Years later, the remaining two dining chairs were brought to Oak Park too.

Frequently Asked Questions

What is Frank Lloyd Wright’s Home and Studio?

Frank Lloyd Wright’s Oak Park Home and Studio is a house museum located in Illinois. Wright himself lived at the property from 1889 to 1909. Many of Wright’s Prairie-style buildings were designed at the studio space on the property, including the Robie House and Unity Temple. The home has been open to the public for tours since 1974 and it was designated as a National Historic Landmark in 1976.

When was the Frank Lloyd Wright home and studio built?

The home was built in 1889 and frequent updates were made by Wright throughout his 20 years living and working at the property. These changes track the main events of Wright’s life, like an architectural biography of the legendary architect. The first addition came in 1895, after Wright’s fourth child was born. He remodeled the kitchen to give himself a larger dining room where the whole family, plus guests, could comfortably dine. According to The Plan for Restoration and Adaptive Use of the Frank Lloyd Wright Home and Studio, this was the first “total environment” in Wright’s career, including “architecture, interior design, furniture, integrated lighting, and heating.” The scheme included a custom grille made of oak veneer that featured oak leaves and geometric shapes. This round of renovations also included converting the original dining room into a study, and adding more space to the east side of the house for a maid’s room, kitchen, and hallway. He also replaced his upstairs studio with a children’s dormitory, rather than giving the children individual rooms.

Three years later in 1898, once he was well into his independent practice, Wright added a studio extension to save himself the headache of commuting. This addition included an octagonal library, a reception hall, Wright’s office, a drafting room, a vault, and tucked in the back, a passageway connecting the studio from the house. Having this much square footage for professional purposes allowed Wright ample space to work and sufficient separation between his home life and work lives—even if they were all on the same property.

Several smaller tweaks were made between the years of 1898 and 1909. Wright left Oak Park in the latter year with Mamah Cheney, a woman he’d fallen in love with after meeting her through her then-husband, a client. Before leaving, he converted the home for his children and wife, Catherine Tobin, to create a rental unit so that Tobin could bring some income in with the extra space. She and the children stayed in the home until 1918. In that same year, architect Rudolph Schindler lived in the apartment inside of the studio. Wright finally sold the building in 1925. It was owned by at least two different families after that, before the Frank Lloyd Wright Home and Studio Foundation purchased it.

How long is the Frank Lloyd Wright House tour?

There are multiple different tours available at the Frank Lloyd Wright Home and Studio. The guided interior tour takes 60 minutes and costs $20 as of this writing. The Inside and Out tour, which combines the guided tour of the interiors with a self-guided audio tour of the Historic District, runs one hour and 45 minutes and costs $30. Once a year, the Trust hosts the Wright Plus Housewalk in Oak Park, walking tour ($125 for the public and $90 for trust members). The event offers the opportunity to see inside architecturally significant public buildings and privately owned homes that are otherwise off limits to the public, in addition to the Frank Lloyd Wright Home and Studio. Tours can be booked directly on the Trust’s website.

Who owns the Frank Lloyd Wright home and studio?

The Frank Lloyd Wright Trust has been the sole owner of the architect’s Oak Park home and studio since 2012.

A love letter to the rocket that everyone is too chicken to build

My purpose, and my belief, is that the bombs that killed and maimed at Hiroshima and Nagasaki shall one day open the skies to man.

—Freeman Dyson, A Space Traveler’s Manifesto, 1958

The nuclear pulse rocket is what you’d get if you hired a 12 year old to get you to Jupiter. It works by farting a continuous string of nuclear bombs (at the rate of about one per second) out its back end and riding the ensuing blast waves on a giant shock absorber, like a pogo stick. A series of hundreds or thousands of nuclear detonations accelerates the spacecraft to pretty much any speed you want, and when it’s time to slow down, you just turn around and start nuking in the forward direction.

Simple, easy, and fun!

The performance on this thing is sensational. Rocket engineers have always been stuck having to choose between thrust and efficiency. Chemical rockets that are powerful enough to get things off the ground (like Saturn V or Starship) are hopelessly inefficient, while the efficient ion motors we put on probes and satellites have only a few ounces of thrust. It’s like forever being forced to choose between an electric tricycle and a top fuel dragster, with no middle ground.

Like an El Camino rolling coal, nuclear pulse rockets occupy that missing middle. The energy density of nuclear fuel gives them incredible miles to the mushroom cloud, while thrust is only limited by how much the hammering the spaceship can take before shaking apart. Where the Apollo rockets had six stages and a mass ratio of about 540:1 (for every kilo of astronaut or spacecraft that landed back on Earth, you needed more than half a ton of fully-fueled rocket on the launch pad), a nuclear pulse rocket has a mass ratio closer to 1.5. It can take off from Earth, land 4,000 tons of scientists and equipment on Mars, and come back in one piece to refuel, as many times as you want.

That kind a mass budget is what Mars mission planners call ‘ample’. Consider that the International Space Station, the biggest object ever assembled in space, weighs 400 tons. Nuclear pulse propulsion means no more worrying about life support or radiation. You can stock the inside with all the oxygen and frozen steaks a crew can eat, encase the whole thing in radiation-blocking plastic, cap it with a glass-domed rotating casino for the view, and still have room for the thousands of fission bombs (dispensed like coke cans) you will need to detonate to get the thing moving. A crew on such a rocket would travel to Mars in comfort and style and arrive refreshed.

For that matter, they could travel to Saturn and arrive refreshed. An early 1958 design envisioned sending a crew of 20 to Enceladus and back within a span of three years, or about as long as it would take to fly astronauts to Mars and back on a conventional mission using chemical rockets. And they could do it in a fully reusable vehicle on a single launch from Earth.

In short, the nuclear pulse rocket solves all of the problems that plague chemical rockets, albeit at the cost of replacing them with much bigger, scarier problems.

Here are some other representative missions enabled by nuclear thunder:

• Soft-land 5,700 tons on the Moon (compare to 17 tons for Apollo)
• Land a 1300 ton payload (three times the mass of the International Space Station!) on Enceladus and return it to Earth on a 3 year round trip.
• Send a crew of 20 on a two year round trip to Callisto or Europa (with enough shielding to make Europa survivable)
• Send a crew of 50 on a 200 day round-trip to Mars, with 30 day surface stay
• Send 10,000 tons to medium Earth orbit.

Orion capabilities. Table adapted from George Dyson’s book Project Orion

Unlike every other kind of spacecraft, the only size constraint on a nuclear pulse rocket is that it can’t be too small. A practical nuclear pulse rocket—and just typing the adjective ‘practical’ here kind of sets my heart racing—weighs around 4,000 tons, about the size of a decemt apartment building. But you get much better performance if you build one the size of a cruise ship, or a city.

Like so many good ideas, nuclear pulse propulsion started with a Polish guy living in New Mexico. While working at Los Alamos in the 1940s, the mathematician Stanisław Ulam sketched out an idea for a spacecraft that could be accelerated by small nuclear explosions behind it. Freeman Dyson and Ted Taylor (the Rembrandt of American nuclear weapons design) later fleshed out the idea at General Atomic and got it modestly funded in the wake of the 1957 Sputnik panic.

Even in the 1950s, it was hard to get anyone with budget authority to stop screaming long enough to appreciate the benefits of the design. And so the budgets for Project Orion were always stingy; no one wanted to take the responsibility of actually making the rocket happen. A toy version of the design was built and tested (with conventional explosives) in 1959, and the project came within a whisker of having a proper atomic test before luck and funding ran out in 1964.

It would have worked great! Like with so many nuclear technologies, whether or not it worked was really low on the list of problems with it.

Declassified image of a 200 ton test version of Orion.

Principles of operation

The nuclear pulse rocket as envisioned in 1958 was a 4,000 ton behemoth that looked like a cartoon bullet, attached by a forest of shock absorbers to a broad, flat pusher plate.

The plate was a flat disk of metal that weighed about 1/6 as much as the ship proper. It’s easiest if you imagine it as a piston in a big two-stroke engine.

The full propulsion cycle looks like this:

1. A small (0.1-3 kiloton) nuclear bomb detonates about a hundred meters behind the pusher plate. The explosion vaporizes a disk of propellant (this can be anything from ice to metal to the crew’s own stored waste) and flings it at the plate at a velocity of many thousands of kilometers per second.
2. The plasma cloud hits the pusher plate, accelerating it with the force of a cannon shot. The intense heat of the collision ablates away a thin layer of oil on the pusher plate, protecting the main body of the plate from damage.
3. Giant airbags and shock absorbers turn the impulsive acceleration on the pusher plate into a longer pulse gentle enough (2-4 g) to be endurable by a human crew, and transmit it to the spacecraft.
4. A spritzer spritzes the plate with a fresh layer of oil.
5. The compressed shock absorbers rebound and return the pusher plate to its original position just as another bomb reaches the detonation point.

You can think of the process like accelerating a golf cart by hitting it with a sledgehammer. How rough the ride is depends on the size of the spacecraft, the size of each bomb, and how far the shock absorbers travel in each stroke.

The bombs go off about once or twice a second, and every explosion adds about 20 mph to the vehicle’s speed. It takes 200 bombs to get Orion out of the atmosphere, and another 600 or so to put the spacecraft in a 300 mile circular Earth orbit.

Normally we think of nuclear bombs as vaporizing everything around them. The Orion concept works by minimizing the time the plate spends in thermal contact with nuclear debris. A round trip to Mars and back might involve 2,000 nuclear detonations, but the pusher plate will have spent a total of less than one second in contact with superhot plasma. The same technique that lets you carry a hot potato comfortably by tossing it hand to hand gets you to the outer planets.

What could go wrong?

It’s a Gatling gun for atomic bombs, what do you think can go wrong? But Orion has some fascinating ways to fail besides the obvious.

One challenge is how to handle a dud. In normal operation, the pusher plate rebounds against each successive explosion like a racket bouncing off of a tennis ball. If a bomb fails to go off, the rebounding piston will want to fly off the back of the rocket into space. So you need a mechanism to arrest its momentum, along with special procedures for firing a half-charge to restore it from a hyperextended state to a neutral position.

Another interesting failure mode is a fizzle—a scenario where the chemical explosives in the nuclear bomb go off, but fail to detonate the nuclear pit. Remarkably, this is far more dangerous to Orion than an atomic blast. The pusher plate is designed to absorb the impact from a uniform cloud of hypervelocity plasma, not sharp chunks of shrapnel. So a lot of design work has to concentrate on making sure the pusher plate isn’t dinged up too badly by flying debris from a conventional explosion.

The most complicated part of Orion is the mechanism for delivering bombs to the correct spot behind the pusher plate. The bombs are heavy (several hundred pounds) and have to arrive at a point a couple hundred meters behind the spacecraft with precise timing. You are basically building an accurate, low-velocity machine gun for nuclear shells.

Several mechanisms were considered: one was a series of angled tubes arranged around the rim of the spacecraft, which would only be exposed when the piston was maximally compressed at the top of the stroke. Another was a rocket launcher that would send little nukes curving around the edge of the pusher plate, detonating when they reached a pair of crossed radar beams. Since the core problem (reliably delivering identically sized containers from a rack) had already been solved in Coca Cola vending machines, Orion famously consulted with that company to help with aspects of this design.

But the biggest technical obstacles facing Orion had to do with computers, not nukes. One was navigation; a big reason the early design had a crew of 20-40 was that so the boys in the nose could get to work with graph paper and sextants when it came time to steer the spacecraft.

Another was making sure bombs with the right yield were fired in the right sequence during takeoff (a problem that became trivial with dial-a-yield fission weapons developed just a few years later).

And there were fundamental questions of design. How turbulence in the plasma wave would interact with the pusher plate was a question only atomic testing could answer in 1959, though it would be easy to simulate on computers today.

An early five-shot proof of concept that actually flew, using conventional explosives.

Drawbacks

There are some drawbacks to the nuclear bomb rocket.

For one, there’s the matter of launching any of this into space. Unless you start nuking Florida from ground level (and I’m not saying ‘no’), you need dozens of traditional rockets to lift this affront to God and Nature into orbit. Even then, its fission products will get caught in the Earth’s magnetic field and eventually spiral their way back home.

But probably the biggest drawback of nuclear pulse propulsion is the thousands of nuclear bombs.

It was not lost on potential funders that whoever sat in the pilot’s chair of this rocket would immediately command one of the largest nuclear arsenals on Earth. All it needed to turn Orion into a Pez dispenser for Armageddon was to redirect the bombs a little bit so they rained down on Earth instead of exploding against a pusher plate.

The list of launch hazards for Orion was also spectacular. A serious accident on the launch pad would cook off thousands of tons of high explosive and contaminate a huge area downrange of the spacecraft with plutonium. An out-of-control Orion zigzagging around the sky would also be a memorable sight, for anyone who was not instantly blinded by it (another awkward hazard). And how exactly do you handle range safety on a 4,000 ton vehicle full of atomic bombs?

Or consider the question of misfires. While the ship could be built to tolerate duds, each misfire meant that someone along the flight path was waking up to an almost-functional nuclear bomb in their backyard.

Some of these risks could be mitigated by launching Orion from remote Pacific islands. But the problem of fallout was pernicious. The 200 explosions that get Orion out of the atmosphere are the equivalent in fallout terms to a ten-megaton air burst. Back in the 1950s, when we were firing multi-megaton H-bombs every other Tuesday, this didn’t seem so bad. But we live in more delicate times, and the problem doesn’t go away once the vehicle reaches space. Any bombs that explode in Earth orbit create clouds of charged particles that eventually fall back down on Earth. Unlike the ascent plume, this fallout is not localized, and settles on the just and unjust alike.

Efforts to ameliorate the fallout problem run us into the final drawback, which is a little bit more abstract. To get the most out of its nuclear fuel and minimize fallout, Orion needs to use shaped nuclear charges with very low yield, that consume as little fissile material as possible. But these happen to be the worst kinds of nukes imaginable from a proliferation standpoint.

No one is really afraid of terrorists blowing up a big, meaty H-bomb that has to be carted around in a truck and needs a couple hundred kilograms of plutonium to detonate. But at the low end, nuclear weapons can be made frighteningly small and light. Ted Taylor describes a working six-inch atomic bomb that he could hold in one hand, while strongly hinting that bombs made with even smaller amounts of fissile material are feasible, provided you’re willing to wrap them in a lot of conventional explosive.

Unfortunately, addressing the fallout problem exacerbates the political problems that doomed Orion in the first place. The best rocket design we have unavoidably pushes the frontiers of nuclear miniaturization, a technology that is inherently destabilizing to a fragile status quo.

And that’s why no one today is riding Orion to the stars.

Benefits

Let’s not be negative Nellies, though. There is also a lot of good to say about the nightmare bomb rocket!

Engineers have been so beaten down by the rocket equation that it can be hard for them to grasp the full possibilities of a spacecraft unconstrained by weight. Rocket design has always been about squeezing the last drop of performance out of lightweight materials. Nuclear pulse rocket design is more about making sure the billiards table stays level during acceleration, and that the ship’s wine cellar strikes the right balance between tannic reds and dry whites. In his blueprints for Orion, Ted Taylor always made sure to include a heavy barber’s chair, just to drive home the point that this was a new class of vehicle.

Only three components on a nuclear pulse rocket need to be built to a high engineering tolerance: the shock absorbers, the bomb dispenser, and the bombs themselves. Everything else can be riveted together out of whatever material is handy. In other words, the nuclear pulse rocket is the thing Starship aspires to be: a rocket that is cheap to mass-produce, fully reusable, and capable of rapidly colonizing the solar system. The only hitch is that no one wants to give Elon nukes.

The fact that nuclear pulse rockets are huge and fast solves the hardest problem of interplanetary travel: protecting crews from radiation. Galactic cosmic radiation is annoyingly dangerous and extremely penetrating, to the point where you need something like ten meters of polyethylene or water to provide protection on par with Earth’s atmosphere. Galactic cosmic rays also have the awkward property that partial shielding can be worse than none, since secondary radiation created when high energy particles collide with the shielding can do more damage than the particles themselves.

Because GCR flux gets worse the further out you go in the solar system, and because voyages to the outer planets would necessarily last many years, cosmic rays set a practical limit to human exploration with chemical rockets. The moon is reachable, Mars is marginal, but anything further than that is off-limits.

There is no way a chemical or nuclear thermal rocket could ever carry adequate shielding against cosmic rays1. But Orion can. Nuclear pulse rockets can be built large enough and fast enough to make trips to Jupiter or Saturn with low cumulative radiation exposure, and armored with enough shielding to protect the crew not only from cosmic rays, but from the intense planetary radiation at desirable destinations like Europa.

And the bigger you make your rocket, the easier it gets to throw in artificial gravity, solving the other big physiological problem of space flight. As I wrote about in an earlier post, you need a structure about 112 meters in diameter to get a livable rate of spin at 1g. If you’re using chemical rockets, you’re limited by the fairly narrow diameter of the rocket fairing, and so spacecraft big enough to provide spin gravity have to be assembled in orbit. But 112 meters is a perfectly workable diameter for nuclear pulse rocket. All you have to do is spin one up once it’s headed in the right direction and live comfortably on the walls until you reach your destination.

As a last benefit, nuclear pulse rockets solve the entry and landing problem on distant worlds through brute force. Instead of worrying about aeroshells and supersonic retropropulsion, you can just null out your orbital velocity, then make judicious use of nukes to slow your descent straight downwards. If you’re squeamish about nuking your landing area, you can always switch to parachutes or chemical retro-rockets at the last minute, or deploy a dedicated lander, like one of those mega-yachts that carries a smaller superyacht as cargo.

The point is you’ll be landing 1950s torch-ship-style—slowly and under full control, without needing to husband every ounce of propellant. Abundance!

A model of Orion in its Air Force configuration as a flying arsenal.

The Four Eras of Project Orion

We came very, very close to building this thing!

Like Taylor Swift, the nuclear pulse rocket went through several distinct eras in its development.

Most programming languages evolve as a single language. Python, Java, Javascript, C++, have new versions and standards, multiple implementations, but they still remain the same language. C and C++ can be compiled with GCC or Clang, Python can be compiled with CPython or PyPy, the same JavaScript runs in both Firefox and Chrome, and Java programs can run on JVM or GraalVM.

Lisp is not like that.

Lisp logo, NASA version.

The Wikipedia page lists more than 20 different dialects, which means there are many variations to choose from. That’s because Lisp is a family of programming languages. They share the same fundamental syntax but differ in their operators, semantics, standard libraries, and language capabilities.

One of the main concerns Lisp beginners have is which dialect to learn first. I see this question frequently asked in online forums. The answer is that the dialect matters, but not as much as a beginner might think. Learning Lisp is about learning a new type of programming. A new way of thinking about problems using code. You will learn the fundamental concepts with any dialect. Then, once you have learned one, it will be relatively easy to switch to another.

I will briefly present the most relevant dialects that are actively used and maintained. I’ll try to highlight their strengths and weaknesses to help you overcome your indecision and pick one to start your Lisp journey.

If you are a beginner, many of the concepts in this article might be completely new to you. Don’t worry too much about them yet. When I was a beginner, I found many of these concepts fascinating and they pushed me to learn more about the Lisp world.

Common Lisp

Abbreviated as CL, it is the most mature and comprehensive of all Lisp dialects. It’s considered the old-school Lisp, since the language — I will call it a language from now on — was standardised in 1994 with a formal ANSI specification. Thanks to this standardisation, there are multiple implementations of Common Lisp targeting different platforms and use cases.

The most famous implementation is SBCL, which compiles directly to native code. It is fast, open-source, and compatible with modern hardware. With it, well-written Common Lisp code can achieve performance comparable to C and Rust. Because SBCL optimises heavily, it compiles a bit more slowly than other implementations but generates some of the fastest code in the Lisp family.

The Yin and Yang Common Lisp logo. The lambda symbol (λ) refer to lambda calculus invented by Alonzo Church.

When I said above that Common Lisp is the most comprehensive dialect, I meant that it offers the broadest set of features among all Lisps. It provides a large amount of functionality out of the box, much of it defined directly in the standard. For example, CL has functions for controlling compilation and evaluation from within the language itself (COMPILE, LOAD, EVAL, COMPILE-FILE, and others). This means that I can use these functions in my code or at the REPL to tell the Lisp process to compile a function, load a file, or evaluate some code. CL also provides DISASSEMBLE, which lets you inspect the machine code generated for a compiled function.

Common Lisp has a condition and restart system, which is one of the most powerful way I ever saw to debug and inspect programs. If a condition occurs during execution, the Lisp process might stop and let you inspect the state of the program and its variables at that point in time. You can then choose to restart the program and maybe retry the operation, or ignore the condition and continue execution. This is also possible because the Common Lisp REPL is deeply integrated with the running system. If your program fails on a remote server, you can connect to its REPL and inspect the live process to understand what went wrong.

Common Lisp supports all major programming paradigms, like functional, imperative, metaprogramming, and object-oriented programming. It offers one of the most advanced object systems, called CLOS, which supports features such as multiple dispatch and generic functions. This makes OOP more flexible than in common object-oriented languages such as Java or C++. It is also worth noting that Common Lisp is dynamically typed but has a rich and expressive type system with optional type declarations.

Standardisation means that the language is stable. The ANSI Common Lisp from 1994 is still the one in use today. Because of it, lispers rarely fall victim to backward incompatibility, and old Common Lisp code often still runs perfectly today. For example, if you go through old Lisp books such as PAIP by Peter Norvig, published in 1991, you’ll find that much of the code still runs on modern implementations. With Common Lisp, you encounter far fewer of the incompatibilities typical of languages like Ruby and Python. Even Common Lisp libraries that haven’t been updated recently will often still run fine on your system because they don’t need to be continually adapted to new versions of the language.

Common Lisp lacks some conveniences that have become common in newer languages, such as concise literals for a wider variety of data structures, persistent immutable collections, lazy sequences and built-in general-purpose pattern matching. Common Lisp was designed in the 1980s by consolidating several existing Lisp dialects into a single language. Its designers chose to retain much of the syntax and patterns of those older dialects, making sure that existing Lisp programmers could adopt the language without having to learn a completely new syntax.

Common Lisp doesn’t have a central direction or corporate sponsor. The community is relatively small and spread across several implementations, projects and communication channels. It’s mostly made up of volunteers who help keep the language alive. It can be a bit difficult to find guides and help: tutorials are often either too simple or too advanced, and documentation is not always easy to find.

It’s currently used in quantum computing at Rigetti Computing, and has been used at Grammarly for its core grammar service and also powers Google Flight Search. Worth mentioning is Kandria, an open-source video game released on Steam and written entirely in Common Lisp.

An interesting fact: Paul Graham originally wrote HackerNews in a custom Lisp dialect called Arc, based on Racket. Today, Daniel Gackle (@dang) reimplemented it in Clarc, a Common Lisp implementation of Arc that runs on SBCL1, serving around 10 million pages per day.

Where Common Lisp shines

CL compiles to native code on all major operating systems and can achieve fast execution, at the cost of slightly slower startup times, so it’s great for long-running processes. It offers one of the most powerful REPLs among Lisp dialects and can be considered, despite its steep learning curve, one of the fastest languages for writing solid software in a short time.

CL shines when you need to do research and prototyping with quick iterations, as in quantum computing, or when the specifications aren’t fully defined yet and change frequently, requiring the software to adapt quickly, as in startups. Paul Graham wrote a famous and inspiring article about how Common Lisp helped his internet startup beat the competition.

Learning resources

A good starting point is A Road to Common Lisp by Steve Losh, which inspired me to write this series. One of the most accessible books for beginners is Practical Common Lisp by Peter Seibel, which is available entirely online. It’s the best introduction to the language I’ve read, as the most important concepts are neatly separated into chapters. A more playful introduction is Land of Lisp, which uses funny characters and comics to teach programming through games. A more advanced book that I enjoyed is On Lisp by Paul Graham, which is entirely dedicated to macros.

The best IDE support for CL is Emacs + Sly/Slime (Doom already has support for it) or Vim + VLime. A weaker alternative is VSCode + Alive.

One of the best resources for beginners is The Common Lisp Cookbook, which has many up-to-date tutorials. For references and libraries, the Awesome-CL list is worth a look. I also printed my own copy of the Common Lisp Quick Reference booklet, which can be faster than finding information in the CL HyperSpec.

Clojure

Rich Hickey created it during a sabbatical year, frustrated by clients refusing to let him use Common Lisp instead of Java and C# because they were concerned about compatibility and maintenance issues. So he decided to write a new Lisp language targeting the JVM, allowing it to access everything the Java ecosystem had built over decades and making it a practical language from the start. The deal is that Clojure provides the language, while the host platform — the JVM — provides the runtime.

Clojure compiles directly to JVM bytecode, which means it’s compatible with any codebase that runs on the JVM (Java, Kotlin, Scala). This compatibility means that Clojure can coexist with other JVM languages in the same codebase, use Java libraries directly, and access all the features the JVM offers, such as OS portability, garbage collection, a fast and optimised runtime, and so on.

Rich Hickey chose to target the JVM so that he didn’t have to reinvent the wheel and build a new compiler for Clojure from scratch. Instead, he focused his efforts on reading research papers on language design and data structures, bringing some of the newest and most effective ideas into the language.

The Clojure logo, designed by Tom Hickey, Rich's brother.

The language at its core is composed of pure functions operating on immutable data structures. Instead of making mutable objects the primary way to represent changing state, it provides explicit mechanisms such as atoms, refs and agents for managing change. This design choice makes Clojure a functional programming language. It supports object-oriented programming, but replaces class-based inheritance with abstractions such as protocols and multimethods. Also the syntax is more modern than Common Lisp’s, with richer literals, destructuring, and overall more compact code.

Clojure also comes with several new features. Its persistent data structures use structural sharing, making immutable updates efficient. It also uses lazy sequences, which allow computations to be performed only when their results are needed. It has strong support for concurrency through constructs such as atoms, refs, agents and futures, and provides records and custom data types when more structured data is needed. EDN (Extensible Data Notation) offers a simple extensible data format based on Clojure’s literals, a better lispy alternative to JSON, YAML and similar. Clojure doesn’t have types, but clojure.spec can be used to describe, validate and generate data without introducing a static type system, useful in large applications.

Rich Hickey designed Clojure with the intention of prioritising stability, similar to what standardisation did for Common Lisp. Even though the language is actively developed, you don’t need to expect major deprecations when updating to a newer version, since the maintainers preserve backwards compatibility and mostly add new features through core libraries.

Since Clojure is designed to be hosted on other platforms, it can be ported to other runtimes, like the JavaScript engine that runs in your browser. ClojureScript is a Clojure compiler that targets JavaScript rather than the JVM, so the same language can run on both the server and the browser. This means that Clojure can be used as a full-stack language.

The JVM integration is great, but it comes with some trade-offs. Error messages are contaminated with a lot of Java implementation details and aren’t always self-explanatory, so stack traces are not necessarily helpful when debugging issues. Java profilers like YourKit are compatible, but even there you will see a lot of Java classes, and it can be hard to map them back to the code you wrote.

In general you don’t need to know Java to learn Clojure. I didn’t know Java when I started and never had substantial problems because of that. However, knowing how to tweak the JVM can be helpful when doing performance tuning on the server.

The community around Clojure is small but active and happy to help newcomers pick up the language quickly. It’s known as Clojurians and mostly hangs out on Slack, where you can also collaborate on open-source projects and find job opportunities.

Clojure is actively used by companies and startups around the world, and it’s probably the most widely used Lisp in production. Some big names include Nubank (one of the largest fintech companies in Latin America), which acquired Cognitect (the main sponsor of Clojure’s development), as well as Walmart, Netflix, Apple, Salesforce, Amazon, Cisco, and Grammarly.

Where Clojure shines

Clojure shines in large software systems where the workload consists of a lot of data processing, or more broadly, anywhere you might previously have picked Java. Code can be written and tested quickly through continuous iteration thanks to the REPL, making the language suitable for delivering reliable solutions in less time. Its immutable design helps eliminate some of the hardest concurrency bugs, while its functional orientation guides programmers towards writing programs as a series of data transformations.

Clojure is great in fields where operations need to happen quickly and often involve processing large sets of data, such as finance and trading. It’s also great for startups solving domain-specific problems with complex logic, since the language’s extensibility allows it to be modelled around the problem.

Learning resources

To give Clojure a try, you might want to check out Try Clojure, then solve some exercises like the Clojure Koans, followed by 4Clojure for more advanced stuff.

The official website offers some of the most curated material you can find, with great explanations of all the core features and the motivations behind the design choices that make the language special. Clojure also has one of the best documentation websites I’ve ever found for a language. All the core library functions come with docstrings, and the community has added usage examples, so you can quickly grasp what each function does.

The best pitch for the language is Clojure Distilled. It’s probably one of the shortest explanations of what Clojure has to offer.

After the release of Clojure, Rich Hickey became famous for a series of talks about software design, in which he shared his deep expertise in fundamental topics like simplicity in software design, state and time, databases, concurrency, and language design. Some of his best talks — Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet?, and Design, Composition, and Performance. I highly recommend spending some time watching them, whether you choose Clojure or not.

Some good books are Clojure for the Brave and True by Daniel Higginbotham, which is free to read online and good for beginners. The one I bought is The Joy of Clojure, which is recommended for programmers who come from OOP languages like Java.

For editors, VSCode has Calva, a complete and rich extension for Clojure. If you use Emacs you can use Cider, plus there are extensions available for most editors/IDEs.

Racket

Racket is a modern dialect descended of Scheme. While other Scheme dialects are generally small languages, Racket has evolved into a fully featured language with its own unique features.

The code is compiled on every major platform and the language has been used in a lot of fields to create web applications, graphical interfaces, databases integration and mostly to quickly develop tools with graphics.

Racket logo.

Racket is language-oriented, which means it’s designed for creating new programming languages. Every source file begins with #lang, which defines the language used by that module. You can create entirely new languages with their own syntax and semantics, while still using the Racket ecosystem underneath. Other Lisp dialects can easily build DSLs, but they are tied to Lisp. Racket advances the concept by making it easy to define completely new languages, without requiring them to use Lisp syntax.

Racket also comes with a wide range of features of features. It includes libraries for cross-platform GUIs, web servers, concurrency and parallelism, regular expressions, pattern matching, classes and objects, and an FFI for calling C code. Its package manager is integrated into the ecosystem, and a large collection of libraries is immediately available. Compared with other Lisp dialects, there is generally less setup required before you can start building something substantial.

Racket offers an advanced macro system, providing the same kind of macro support as other dialects, plus hygienic macros. Hygienic means that identifiers introduced by a macro don’t accidentally capture those in the surrounding code. This makes macros safer to write, especially for beginners, that don’t have to rely on gensym like in the other dialects.

Its macro system is another major strength. Racket supports powerful syntactic extensions, including hygienic macros, which prevent identifiers introduced by a macro from accidentally interfering with names in the surrounding code. This removes many of the name collision problems that beginners might struggle to handle manually when writing macros in other Lisps.

Static typing is supported with Typed Racket, a typed variant of the language that lets programmers add type annotations and have their code checked before execution. Typed and untyped Racket modules can also work together, so typing can be introduced where it is useful without requiring an entire program to be rewritten.

Even though Racket comes from the Scheme tradition and has strong functional programming roots, it supports multiple paradigms. Programs can be written using imperative programming, objects and classes, functional techniques, and metaprogramming.

The language installation comes with DrRacket, a great IDE with everything ready to use the language, available on all major platforms. It combines an editor, REPL, and debugger, in a single programming environment for writing and testing Racket code.

The main downsides are its small ecosystem and limited use in the industry. There are fewer libraries, projects and jobs compared to more popular languages. Performance and deployment can also be weaker points, especially compared with other compiled dialects.

Where Racket shines

Racket shines when designing new programming languages, building compilers and interpreters, or experimenting with new language features. This makes it particularly popular in computer science education and university research. Also, since it’s language-oriented, it’s a great choice when a program needs to provide a simple DSL, for example for customisation, without forcing the user to use a Lisp dialect.

Racket is ideal for prototyping, scripting, and projects where having a comprehensive set of libraries and development tools immedtialy available is important. It’s worth noting that other dialects offer GUI support through external libraries and wrappers, while in Racket it is available out of the box.

Learning Resources

Racket has a rich website with a lot of helpful information. Important resources for beginners include Quick: An Introduction to Racket with Pictures and The Racket Guide, which is the complete guide to the language. Also worth mentioning is Beautiful Racket by Matthew Butterick, a visually curated guide to the language written by a passionate contributor. If you’re looking to write a compiler, check out this course using Racket.

The best resource available for Scheme is SICP, also known as the Wizard Book. It’s not only about Lisp, but it’s a great book for learning the fundamentals of programming and programming languages. It’s also worth mentioning a rather unusual book, The Little Schemer, which consists of a long series of questions that forces the reader to think before looking at the answer on the page.

Special Mention

Elisp

Elisp is a specialised dialect that’s part of Emacs and is used to customise the editor. It’s an old Lisp dialect that comes with quite a few limitations, but it’s probably one of the best practical uses I’ve ever found for Lisp, beyond using it as a general-purpose programming language. It’s used to customise and extend the functionality of Emacs, since much of the editor itself is written in Elisp. By evaluating Elisp code inside it, you can change how Emacs looks and behaves in real time, without requiring a reload.

Learning resources

An Introduction to Programming in Emacs Lisp is freely available online. Another useful resource is Emacs Lisp Elements by Protesilaos Stavrou, an active Emacs contributor and advocate.

Syntax comparison

We can use a simple instruction interpreter to show some of the syntactic differences between the dialects.

(defun calculate (instructions)

  (loop with result = 0

        for (operation value) in instructions

        do (setf result

                 (case operation

                   (add      (+ result value))

                   (subtract (- result value))

                   (multiply (* result value))))

        finally (return result)))




(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Common Lisp, I used the LOOP macro to iterate over and destructure each instruction, then perform the operation by updating local state. Notice that it carries an accumulator (result) through the sequence, essentially doing the same job as a reduce.

(defn calculate [instructions]

  (reduce

    (fn [result [operation value]]

      (case operation

        :add      (+ result value)

        :subtract (- result value)

        :multiply (* result value)))

    0

    instructions))




(calculate [[:add 5] [:multiply 3] [:subtract 4]]) ;; => 11

In Clojure, I used a reduction over the sequence of instructions. Notice that it doesn’t use or update any local state, since the reduction uses immutable accumulation. I also used some syntax that is specific to Clojure, such as vectors [] and keywords like :add, and destructured the contents of each vector with [operation value].

(define (calculate instructions)

  (for/fold ([result 0])

            ([instruction (in-list instructions)])

    (match instruction

      [(list 'add value)

       (+ result value)]

      [(list 'subtract value)

       (- result value)]

      [(list 'multiply value)

       (* result value)])))




(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Racket, we use for/fold to iterate over the instructions while carrying the result from one iteration to the next. We also use pattern matching with match to destructure each instruction and identify the operation at the same time. For example, (list 'add value) matches a two-element list whose first element is the symbol add and binds the second element to value.

Which one to pick?

To summarise the above:

• Clojure gives you modern syntax, functional programming and immutable data structures, great tooling and libraries, an almost drop-in replacement for Java, a full-stack language, a strong community, and maybe even a job.
• Common Lisp gives you native compilation, high performance, the most powerful REPLs, multi-paradigm programming, and a stable, battle-tested language.
• Racket gives you a feature rich language, a great IDE for beginners, a cross-platform GUI, a powerful platform for building new languages and DSLs, easily approachable for students.
• Elisp gives you the ability to extend and customise Emacs.

For most programmers looking for a practical and elegant Lisp they could use professionally, Clojure is probably the safest first choice.

If you want to experience the traditional Lisp development model at its fullest, you want native compilation without rely on JVM, an exceptionally interactive environment and a huge language, choose Common Lisp.

If you are a computer science student, interested in compilers and programming-language design, or if you need a quick way to write tools or need an easy way to use a cross-platform GUI, choose Racket. This is probably the easiest to start with between the dialects.

If you have any questions of feedback, please send me an email.

Footnotes

1. https://news.ycombinator.com/item?id=41683969 ↩︎

Introduction

As of writing, the Zilog Z80 processor was officially launched 50 years ago, in July of 1976, less than 4 years after the last human had walked on the moon, decades closer to WWII than to the present day, roughly at a half way point between the Kennedy assassination and the fall of the Berlin wall, closer to the Korean war than to 9/11 which is itself an event that happened a quarter of a century ago. (Sorry…)

The processor was extremely successful, being used in many 8 bit microcomputers, including early personal computers, home & hobby computers, as well as many embedded, industrial applications.

Together with the 8080 & 8085 that it is binary compatible with, it contributed to creating a de facto hardware standard for 8 bit micros, allowing a de facto software standard of CP/M, and Microsoft BASIC.

The Z80 itself also spawned many clones and derived architectures over the years, famously including the Sharp LR35902, used in the original GameBoy. Zilog themselves eventually gave up their line of 16 and 32 bit derived architectures and returned to Z80 based microcontrollers and variants like the pipelined and higher clocked eZ80, mainly for continued use in industrial applications.

I myself am much too young to have seen the home computing side of this (ignoring the aforementioned GameBoy), but the widespread use in industrial applications means that the original Z80 is still around and in use with Zilog finally discontinuing it mere 2 years ago.

My own first encounter with the Z80 was as a late teenager, when I was browsing an electronics company catalog, surprised to find them still being sold. I designed my own little Z80 computer and convinced a school teacher to let me use the photo lab at night, so I could etch some PCBs.

As several of my former teachers got curious what I was up to, I ended up hearing a lot of interesting anecdotes about old home computers, consoles and a story about DIY wire wrap computer in a Tupperware box, running CP/M and WordStar, hooked up to a "borrowed" IBM terminal that was used to write a thesis on. Over time I ended up being gifted a number of old chips from dusty drawers that made it into my own DIY project, including a bunch of MCS-85 parts, several Z80s, 8085s, 6502s and 6522s.

The whole thing sure taught me a number of interesting lessons about systems engineering and some unexpected ones (reliable power-on reset is surprisingly hard; writing a linker is a lot harder than writing an assembler, writing a compiler is something you can actually do).

Anyway, that is my claim to being allowed to reminisce about the Z80. While I originally wanted to limit myself to some technical details based on my own experience, comparing the Z80 with the 8080 that it was derived from, I ended up diving down a rabbit hole of the Computer History Museums oral history panel, where the people involved recalled even more anecdotes about the development of those chips. The whole "I'll try to write a blog post (again)" idea quickly ballooned in scope.

From the 2200 to the 8008

Once upon a time, the Computer Terminal Corporation (CTC) built a new, programmable terminal, the Datapoint 2200, sporting an 8 bit processor constructed from individual TTL chips. Intel was supplying CTC with shift registers and memory chips at the time.

The idea was floated to replace parts of TTL cemetery with custom ICs, eventually it was considered to try and get the entire 8 bit CPU on a single chip. Two different companies were ultimately contracted for this task: Texas Instruments and Intel.

Neither company finished their design in time. When Intel had the chip ready, originally named 1201 based on a systematic naming convention, CTC were already selling terminals based on the TTL design.

Engineers at CTC were also unsatisfied with the performance of the chips and they had already made changes to the architecture for the next generation of the terminal anyway.

While TI ultimately canned their design, Intel went ahead and successfully commercialized their version as the 8008 (like the 4004, renamed by marketing).

The 8008 Architecture

        ___   ___
-9V ---|1  |_| 18|<- IRQ
AD7 <->|2      17|<- READY
AD6 <->|3      16|<- CLK1
AD5 <->|4      15|<- CLK2
AD4 <->|5      14|-> SYNC __
AD3 <->|6      13|-> S0     |
AD2 <->|7      12|-> S1      > State
AD1 <->|8      11|-> S2   __|
AD0 <->|9      10|-- +5V
       |_________|
         

  A   B   C   D   E H L PC   C P Z S

The 8008 has 7 registers: A, B, C, D, E, H, L. Where A is the designated accumulator, the others can be used as operands or scratch. As the name might imply, H and L together form the High and Low part of a memory pointer. Accessing memory is done through an 8th pseudo register M, representing the memory byte that HL points to.

The processor internally keeps track of ALU state (Cary, Parity, Zero, Sign) in a few flag bits on which it can perform conditional jumps (including call and return).

The program counter PC is pretty much never visible directly. There are dedicated function call & return instructions, but the processor uses an internal return address stack that is 8 levels deep. The reason for this was that the Datapoint 2200 was originally supposed to use serial memory, a call stack in memory was considered to end up a performance bottle neck.

Memory addresses are 14 bits wide, there is a separate I/O address space with a total of 32 I/O ports (the addresses are always immediate and bit-stuffed into the opcode).

For interrupt handling, there is a special "restart" instruction that essentially calls into 1 of 8 slots (0x00, 0x08, 0x10, 0x18, ..., 0x38) at the beginning of the address space. The slot index is bit-stuffed into the RST opcode itself. When an interrupt occurs, the processor signals to the periphery that it got the hint and then blindly executes the current contents of the data bus that better be an RST instruction.

From there, it gets a bit tricky. The CPU does not have a general purpose stack that it can safe registers to, all memory access needs HL, but you don't want to clobber HL in the interrupt handler. The intended way to solve this was through external latches on the I/O bus, serving as scratch registers.

All in all, the architecture is fairly simplistic, requiring about 3500 transistors and used a DIP18 package. Address and data were multiplexed, requiring external latching. Internal decode/execution state was exposed that needed to be decoded to drive latches and figure out what the processor is attempting to do (read from or write to memory, or the I/O bus).

The processor needed two phase-shifted clock signals (it ran at 500kHz), a +5V positive supply and -9V negative supply.

From the 8008 to the 8080

The shortcomings of the Datapoint 2200 derived 8008 architecture were known during development, and in typical engineering fashion, before development was even wrapped up, ideas were thrown around for an improved architecture.

Federico Faggin, who was brought over from the 4004 project, was pushing to start work on an improved version, but management insisted to first see how the market would react to their two microprocessors. Competitors eventually announced their own 8 bit designs in the making and the delays ended up costing Intel a total of 9 months of their lead time.

Even before the project was finally approved, Federico Faggin got approval to hire Masatoshi Shima away from Busicom to work on the 8080 design. In many ways similar to how CTC had a hand in the development of the 8008, Busicom was involved in the development of the 4004, originally wanting a set of custom chips for their calculators.

Criticism and feedback from potential customers that the 8008 was demonstrated to, also influenced the design of the 8080, and it was decided early on to set aside binary compatibility.

The 8080 Architecture

A F B C D E H L SP PC

The 8080 has in essence the same register set as the 8008, but it replaces the internal return address stack with an external one that lives in memory and is accessed via a stack pointer register (SP).

The stack pointer can be exchanged or moved in to/out of HL, registers can be pushed on or popped of the stack pairwise. Besides HL, the other register pairs are BC, DE, and AF (accumulator and ALU flags), but the 8080 assembly prefers to call the later the "program status word" PSW.

Memory addresses are bumped up to full 16 bits, giving the machine a 64k address space. The I/O ports are bumped up to 256. BC and DE now also allow rudimentary indirection (loading/storing the accumulator), the accumulator and HL can be loaded/stored at an immediate destination.

A few double-byte arithmetic operations are added that can work on register pairs (e.g. increment/decrement), mainly to allow pointer arithmetic and 16 bit counters. Using those instructions on AF would actually act on SP instead.

Interrupt handling works much the same way, using restart instructions, but with the added feature that interrupts can be enabled/disabled in software. An explicit stack also no longer requires saving registers using I/O hardware.

Here is a slightly modified memory-copy example from the Wikipedia page, it copies a number of bytes (stored in BC) from DE to HL.

memcpy:
    PUSH    B           ; pushes BC
    PUSH    D           ; pushes DE
    PUSH    H           ; pushes HL

loop:
    LDAX    D           ; A := *(DE)
    MOV     M, A        ; *(HL) := A
    INX     D           ; ++DE
    INX     H           ; ++HL
    DCX     B           ; --BC

    MOV     A, B        ; A := B
    ORA     C           ; A |= C
    JNZ     loop        ; jump if not zero

    POP     H
    POP     B
    POP     D
    RET
    

A few things that are noteworthy here: instructions that act on register pairs always use a single register as a mnemonic for both, the "X" ion the "INX" differentiates the double-byte increment from an "INC" on a single register byte. The to Intel 8080 assembly has an almost 1:1 mapping of mnemonics to opcodes and is extremely easy to parse, making an assembler easy to implement. To a degree, this comes at the expense of human readability.

Furthermore, the double byte arithmetic has no influence on the ALU flags, it is a separate, independent function block. After decrementing BC, we need to manually check if both registers are zero.

Electrical Interfacing

To improve speed, the 8080 used NMOS logic. The downside of this was the the CPU now needed 3 different supply voltages (-5V, +5V and +12V). It also stuck with using 2 phase-shifted clock signals (in the 9V to 12V range), making electrical design around the chip a bit cumbersome.

Thanks to a 40 pin package (something Faggin recalls as an uphill battle to get approved), the CPU no longer had to multiplex data and address lines. But like the 8008, it still exposed internal processor state externally, multiplexing the actual control states on the data bus, requiring external latching and decoding.

Intel would of course sell support chips for state decoding, clock generation and so on. Additionally, one might also want to buy an accompanying interrupt controller and something like a programmable interval timer, at the very least to drive DRAM refresh, possibly using one of those handy Intel DMA controllers.

Intel addressed at least some of those short comings with the 8085, only requiring a single 5V supply and a single 5V clock signal. The freed up pins expose a few additional control signals. But still needing some specialized support chips.

Zilog and the Z80

Dissatisfied with his experience at Intel, the delays and uphill battles with management to even get the 8080 project approved in the first place, Federico Faggin finally decided to quit Intel and start his own firm together with Ralph Ungermann, then head of the microprocessor division.

Originally somewhat directionless, Faggin at first considered designing a microcontroller, but realized that the margins were too tight to make it economical for a fabless semiconductor startup.

He eventually settled on designing an improved version of the 8080, nicknamed "Super 80", later becoming the Zilog Z80. They secured funding from Exxon and also brought over Masatoshi Shima from Intel to work on the design, later increasing the size of the team to a total of 11 people to work on layouting, software simulation, and so on.

The design of the Z80 was intended to be binary compatible with the 8080, while adding registers, addressing modes, new instructions, drawing inspiration from other contemporaries like the 6800. It also aimed at simpler electrical interfacing and higher speed than the 8080.

The entire development of the processor up to the first, working prototypes cost roughly $400k, finishing on time and under budget (they had secured $500k from Exxon).

Zilog relied on Mostek to manufacture their processors (after some hostilities with Synertek they initially contracted with). They did eventually secure further funding from Exxon to build their own fab, but kept second sourcing the Z80.

The Z80 Architecture

A F A' F' B C B' C' D E D' E' H L H' L'   IX     IY     SP     PC  

The Z80 is fully binary compatible with the 8080 instruction set.

Inspired by the 6800, it adds two index registers IX and IY that can be used in place of HL (same encoding but with an opcode prefix) and with an immediate offset.

The AF, BC, DE and HL register pairs are bank switched, allowing simpler & faster interrupt handling.

Speaking of interrupts, the Z80 has 3 different ways that it can handle them: An 8080 compatible way (mode 0), one that always calls to a fixed location (mode 1), and one that dispatches through a call table (mode 2), using the number on the bus as an index. An extra register is used to locate the base of the table in memory.

The Z80 also adds a bunch of bit rotate, bit test & set instruction instructions, BCD arithmetic, along with built-in loop instructions (using BC as a counter), self-repeating block transfer, block compare and string operations.

Because Intel claimed a copyright on the assembly mnemonics, the Z80 ended up using its own assembly language with an arguably cleaner syntax. The Z80 assembly expresses operands more explicitly and uses overloaded variants of basic mnemonics.

This is essentially the same program from above, in the more expressive Z80 assembly:

memcpy:
    PUSH    BC             ; full name of the register pair
    PUSH    DE
    PUSH    HL

loop:
    LD      A, (DE)        ; explicit 2 argument syntax
    LD      (HL), A
    INC     DE
    INC     HL
    DEC     BC

    LD      A, B            ; overloaded name
    OR      C
    JP      NZ, loop        ; overloaded name, condition is an argument

    POP     HL
    POP     BC
    POP     DE
    RET
    

Of course, on the Z80, the entire byte copy loop could also be replaced with a single, self-repeating instruction: LDIR.

Improved Bus Design

The Z80 only needs a single 5V supply and a single clock signal. Many of the externally latched/decoded states of the 8080 are explicitly exposed by the chip, such as as MREQ or IORQ to indicate memory or I/O access, RD/WR signals that indicate exactly what the name suggests, and an M1 signal that indicates the current memory access is an instruction fetch. Those signals can be connected to something as simple as a single 74xx138 to drive an (E)EPROM, some form of RAM and an UART controller. Connect the address and data lines directly to the Z80 and you essentially have a working computer!

If the RAM in use happens to be DRAM, the Z80 can also take care of DRAM refreshes, using an internal refresh counter that it puts on the address bus during instruction decoding cycles, asserting a control line to tell the external decoding logic to do a DRAM refresh.

With interrupt mode 1, where the CPU always calls to a hard wired location, a simple design can get by without any external interrupt controller, hooking a single device up to the interrupt pin or using something as simple as a 74xx148 (priority encoder) and a latch.

How the Story Continued

Even before the Z80 was finally released in July of 1976, rough design work on the 16 bit Z8000 architecture had already begun. The Z8000 was released in 1979, after the Intel 8086, but before the Motorola 68000.

Like the 8086, it used segmented memory, but unlike the 8086 exposed a segment number on the bus that an external MMU chip was supposed to convert to a linear address (and check bounds & permissions).

While common heritage of the 8080 can be clearly seen in the 8086 instruction set, a number of features from the Z80 were also carried over, such as the self repeating block and string operation or loop instructions. The design of the Z8000 MMU also influenced the descriptor table based design of the 286's 16 bit protected mode.

Despite the fact that Zilog aimed their products for a computer oriented market, even at an early time when microprocessors were considered logic replacement, their ties with Exxon ended up being one of the reasons why IBM ultimately decided against a Zilog processor for their PC, opting for an Intel 8088 instead.

Part of the reason Exxon was interested in Zilog in the first place was their intent to build up a computing empire of their own, rivaling IBM. They had a number of other companies they strategically invested in (e.g. typewriter, word processor or printer manufacturers), some of whom even designed products around Zilog parts, all eating away at the market share of competing IBM products.

The close ties with Exxon eventually also caused friction between Faggin and Ungermann, the later leaving Zilog before it became a full Exxon subsidiary in 1980.

Zilog eventually split off of Exxon again in 1989 and went public in 1991, subsequently changing hands several times, bouncing around between private equity and actual electronics companies, currently owned by Littelfuse.

The Z80, after a long life as an embedded processor, was eventually discontinued in June of 2024.

Links and References

• Ken Shirriff, Tracing the roots of the 8086 instruction set to the Datapoint 2200 minicomputer
• Ken Shirriff, The Texas Instruments TMX 1795: the (almost) first, forgotten microprocessor
• CHM, oral history panel, Intel 8008
• CHM, oral history panel, Intel 8080
• CHM, oral history panel, Intel 386
• CHM, oral history panel, Zilog Z80
• CHM, oral history panel, Zilog Z8000

In 2026, technology can be a lifeline – or a weapon.

For people experiencing domestic violence (DV), tech-facilitated abuse is now one of the most common forms of control. This includes GPS stalking, hidden tracking apps, spyware, image-based abuse, and monitoring of messages or location.

Australian research shows that 99% of domestic violence cases now involve some form of technology-facilitated abuse. In some states, reports have risen by as much as 650% over the past five years. Children are also heavily impacted – studies indicate that 27% of DV cases involve tech-related harm to kids.

The good news is that technology can also be used to reclaim safety and independence. A properly configured DV Safe Phone gives survivors powerful tools for privacy, discretion, and control – helping them stay connected while reducing the risk of being tracked or monitored.

At PrivacyPros, our expertly hardened de-Googled Privacy Phones are designed with these exact needs in mind. They offer near-zero telemetry, strong app isolation, physical kill switches, and emergency features that can genuinely help people in high-risk situations.

Why a Regular Phone Can Be Dangerous in DV Situations

Standard smartphones from Apple, Google, or Samsung often share location data, app activity, and other information in the background – even when you think privacy settings are turned on. Abusers can exploit this through:

• Spyware and stalkerware apps
• Shared accounts or cloud sync
• Location tracking via cell towers or apps
• Monitoring of messages and calls

A DV Safe Phone significantly reduces these risks by stripping out unnecessary tracking and giving you physical and software controls over what can be accessed.

Key Features of a DV Safe Phone

When choosing or configuring a phone for safety, focus on these critical areas:

1 – Operating System: Prioritise De-Googled Options

The operating system is the foundation of your phone’s security.

GrapheneOS (running on Google Pixel hardware) is currently one of the strongest choices for DV safety in 2026. It offers:

• No built-in Google tracking
• App isolation and hidden profiles (up to 32 separate profiles)
• Verified Boot (tamper detection on every startup)
• Strong permission controls
• A duress PIN that can instantly wipe sensitive data in emergencies

This makes it far more discreet and secure than standard Android or iOS devices.

2 – Hardware That Supports Strong Privacy

We recommend recent Google Pixel devices because they have the best hardware support for GrapheneOS, including secure bootloaders and long-term update support (up to 7 years).

Look for phones with:

• At least 12GB RAM
• 128GB+ storage
• Good battery life
• Physical or easy-to-access controls for disabling microphones, cameras, location, and sensors

Always choose new, unlocked devices from trusted Australian sellers to ensure you receive the full 2-year Australian Consumer Law warranty.

3 – Essential Safety & Discretion Features

A well-configured DV Safe Phone should include:

• Hardware kill switches or easy toggles for mic, camera, location, Bluetooth, and network
• No-log VPN support (such as Proton VPN)
• Anonymous browsing options (Tor)
• Encrypted messaging and self-deleting message capabilities
• Tracker detection tools (to spot hidden AirTags or similar devices)
• Metadata removal tools for photos and files before sharing

Practical Tools That Make a Real Difference

At PrivacyPros, we configure our Privacy Phones with advanced but easy-to-use safety features, including:

• Geofencing Alerts – Set up safe zones that notify you or trusted contacts if crossed.
• Bluetooth Tracker Detection – Automatically scan for hidden tracking devices like AirTags.
• Location Spoofing – Mask your real location when needed while still allowing apps to function.
• Secure Anonymous File Sharing – Send documents or evidence through encrypted, self-deleting links.
• Integrated Encrypted Ecosystem – Combine secure email, VPN, and storage so everything stays protected even if the device is compromised.

These tools are configured during our expert hardening process (typically 4–7 hours per device) so everything works reliably from day one.

Getting Help and Building Safety

A DV Safe Phone works best alongside professional support. Key Australian resources include:

• 1800RESPECT – National sexual assault, domestic and family violence counselling service
• Lifeline: Crisis and DV support. Call 13 11 14.
• MensLine Australia: Support services for men Local DV support services and refuges
• 13 YARN: Culturally safe crisis support for Aboriginal and Torres Strait Islander people.
• Local DV support services and refuges
• The eSafety Commissioner’s resources on tech abuse

Many support workers and organisations are now recommending de-Googled privacy phones as part of safety planning because they reduce the digital footprint that abusers can exploit.

Final Word

Technology should never be a tool used against you. With the right device and configuration, your phone can become a source of safety, connection, and empowerment rather than vulnerability.

If you or someone you know is experiencing domestic violence and would like to explore a DV Safe Phone setup, we offer personalised consultations to help configure the right solution.

-> Explore Privacy Phones

-> Book a Confidential Consultation

-> Browse Our Free Privacy Tools

Reclaim your digital strength – safety is within reach