OpenAI claims its newly released frontier model, GPT-6 Astra, likely marks the onset of artificial general intelligence. The promotional video OpenAI released for the model shows various OpenAI employees interacting with computer interfaces using Astra through voice. Astra is now rolling out to enterprise customers through OpenAI's gated access program, Daybreak. It will become available over the coming days to ChatGPT Plus, Pro, Business and Enterprise customers, as well as through the OpenAI API and cloud platforms, including AWS Bedrock and Microsoft Azure.

In short : Meta's Muse Spark 1.3 prices inference at two levels : $1.25/$4.25 per million tokens for private data, & $0.10/$0.20 for training consent : a 92% price spread. Michael Mauboussin taught that market prices contain information about underlying expectations. This spread establishes a liquid clearing price of $1.24/m tokens for user & agent prompt data, allowing Meta to vertically integrate the AI data supply chain & acquire post-training data at pennies on the dollar compared to specialized data labs.

Meta launched two things yesterday : a state-of-the-art model & a new pricing system for foundation models. Muse Spark propels US open source models to the frontier. Meanwhile, the pricing system resets the industry’s economics.

For thirty years, enterprise software operated on strict licensing fees with a guarantee of total privacy & zero data retention. Consumer technology operated on the opposite principle : free software in exchange for behavioral data. Consumers trade queries for convenience, but enterprises fiercely protect their intellectual property.

Now that model is coming to AI with a twist.

Meta’s new pricing makes the barter explicit through a two-tier pricing structure with & without privacy :

• The Standard Tier (muse-spark-1.3) : $1.25/m input tokens & $4.25/m output tokens. Your prompts & completions are never used to train Meta’s foundation models.
• The Contributor Tier (muse-spark-1.3-contributor) : $0.10/m input tokens & $0.20/m output tokens. In exchange for a 92% discount on input & a 95% discount on output, Meta retains the right to train future models on your data.

No other foundation model provider currently offers this kind of explicit barter on its API. This is the ads model coming to AI.

As Michael Mauboussin writes in Expectations Investing, there is information in prices. When Meta charges two radically different prices for the same AI, the difference in price tells us the value of the data.

At an agentic 30:1 input-to-output ratio, the blended standard tier costs $1.35/m tokens, while the contributor tier costs $0.103/m. The difference is a $1.24/m token spread, an effective 92.3% subsidy.

For an enterprise processing 1b tokens per day, opting into Zero Data Retention (ZDR) is a $454,000 annual privacy surcharge. That difference is how Meta values incoming customer data : $1.24/m tokens.

This unbundles the $20 monthly consumer subscription. Labs absorbed compute losses on flat-rate consumer plans because default terms granted training rights, an implicit data subsidy that Meta has now formalized per token.

Why surrender 92% of inference revenue? It is not out of altruism.

The public web has been exhaustively crawled ; frontier gains now come from post-training, reinforcement learning from AI feedback, & user usage patterns. Estimates place the market for training data & human labeling at $10b in annual revenue.

Meta’s pricing model bypasses this intermediary. Just as search & social platforms vertically integrated the digital advertising supply chain by capturing behavioral data directly from users, Meta is vertically integrating the AI data supply chain. Instead of paying labeling vendors to simulate human behavior, Meta turns its inference network into a self-funding data flywheel.

At $1.24/m tokens of subsidy, Meta acquires organic reasoning traces at pennies on the dollar compared to specialized data labs, while undercutting closed foundation models on inference price.

Compute is no longer sold simply as an infrastructure utility. It has become a currency traded directly for the training tokens needed to build the next frontier model.

Ultimately, this solves the business model for American open source. Just like ads, the barter is simple : subsidized access in exchange for data.

Full article content is not available for inline reading.

Read the original article →

I’m excited to announce that NVIDIA has agreed to acquire Hugging Face for $12,930,300,000. Together, we will scale Hugging Face’s platform, strengthen its infrastructure and expand access to AI for developers and institutions worldwide.

Over the past decade, Clem, Julien, Thomas and the team at Hugging Face have built something remarkable: a vibrant home for the open model developer community.

More than 18 million developers, researchers and creators use Hugging Face to share more than 3 million models, 500,000 datasets and 1 million applications. More than 200,000 companies use the platform to discover, evaluate, customize and deploy AI.

Hugging Face will remain an open platform for the entire AI ecosystem. Developers will choose the models they want, the frameworks they want, the clouds and inference service providers they want and the computing platforms they want. NVIDIA compute will not be required to build on or deploy through Hugging Face.

Hugging Face will continue to support open source and open weight models from across the ecosystem, from every model builder. It will continue to support multi-cloud and multi-accelerator development and deployment, so builders can use the hardware and infrastructure that best fit their work.

Recently, I coauthored an open letter on the importance of open weights to the AI economy. Joined by leaders from across the industry, we made a simple point: open weights broaden access to AI and help ensure that AI leadership is distributed across companies, institutions and communities.

Open models let startups, businesses, universities and public institutions build on advanced capabilities without training every model from scratch. They enable organizations to match the right model to the right job. That is how AI can advance safely, strengthen cybersecurity and sovereignty, accelerate innovation, and reach factories, hospitals, farms, classrooms and Main Street businesses around the world.

AI advances faster when people can build together.

NVIDIA has been committed to open weight models for years, demonstrated by multiyear investments and major contributions to open source platforms, including Hugging Face. NVIDIA has said that open models, data and tools broaden access to AI, and it has contributed hundreds of open models and datasets to Hugging Face as part of that effort.

• NVIDIA is the largest contributor of open models and data to Hugging Face, and our contributions continue to grow.
• NVIDIA has released more than 500 models on Hugging Face and more than 250 open datasets.
• We build our own models, libraries and tools in the open so developers everywhere can use them, modify them and build on top of them.

As the opportunity for open models accelerates, Hugging Face can serve the global AI community at unprecedented scale. NVIDIA’s infrastructure, engineering and global reach can help improve platform reliability, safety, model evaluation, inference and deployment capabilities, while preserving the open ecosystem that made Hugging Face foundational.

I am honored that Clem came to me as he considered the next chapter of Hugging Face and believed NVIDIA would be a great home for the company, its community and the future of open models. We share this vision, and the Hugging Face team will now bring their passion and expertise to a much larger canvas, with their same iconic 🤗 brand.

To the millions of builders on Hugging Face: thank you for pushing the boundaries of what is possible. We can’t wait to build the future together with you. Together, we will make AI more open, more capable and more accessible to people and institutions around the world.

Today, we are releasing GPT-6 Astra, the most capable model we have ever broadly deployed. Astra is our first model to reach the Critical level of cybersecurity capability under our Preparedness Framework.

The most important things to know about the safety of this launch are as follows:

1. GPT-6 Astra is a significant step up in cyber capabilities and meets our Critical threshold. This means that, with the right tools and access, GPT-6 Astra can find previously unknown security flaws and develop new ways to exploit them across many well-protected systems without a person guiding each step. Accordingly, we significantly strengthened our protections against the model taking harmful cyber actions, whether that’s due to misuse or misalignment. We also took steps to secure our internal development and deployment of Astra and similar models, including stricter isolation, checkpoint encryption, universal monitoring of full trajectories including chains of thought (CoT), and a blocking alignment evaluation process before internal use.
2. GPT-6 Astra is significantly more robust than its predecessors. Incorporating new robustness safety training techniques, GPT-6 Astra is significantly more robust to jailbreaks than GPT-5.6 Sol, including across longer trajectories. We know this from offline tests and our program of rigorous internal and external jailbreak testing and remediation. For users flagged as potentially high risk, we have additionally trained in the ability to adjust the model’s refusal boundary to be more conservative and cover a broader range of dual use risks. We use regression testing to make sure Astra is robust against jailbreaks found in previous testing periods, and performed new rounds of automated red-teaming with our latest internal red-teaming attackers to validate our improvements.
3. GPT-6 Astra is better aligned than GPT-5.6 Sol. Astra is a significant step forward in model alignment, and includes alignment improvements spanning the composition of our pre-training data to our grading during reinforcement learning. We report a new suite of alignment evaluations, and find that GPT-6 Astra is stronger at respecting safety and security boundaries and staying within its authorized scope. In a simulation using more than 54,000 internal Codex tasks, Astra also received roughly half as many flags for higher-severity misaligned behavior as Sol.
4. We are deploying misalignment monitoring broadly. We view model alignment as the primary lever to prevent potential misaligned behavior from our models. However, monitoring provides broad visibility into frontier model behavior, illuminating opportunities to further improve alignment and safety. In addition, monitoring serves as an additional layer of protection against misaligned behavior that is detected. For these reasons, we have additionally added misalignment monitoring to all tool-using inference involved in our external deployment of Astra, with significant compute cost. This system parallels our internal setup.
5. GPT-6 Astra’s monitorability has decreased relative to GPT-5.6 Sol. We have performed significant investigations on the monitorability and controllability of GPT-6 Astra. We have found that GPT-6 Astra is more capable of controlling its own CoT than GPT 5.6-Sol, and less likely to include incriminating information in its CoT. In adversarial settings (where we push the model to evade our monitors) we find that the model is able to remain undetected when strategically underperforming in evaluations (sandbagging) and can sometimes evade our internal monitors when asked to perform certain sabotage tasks. We have not seen evidence of steganographic CoT reasoning (e.g., concealing hidden reasoning within ordinary and seemingly unrelated text), indicating that the evasion risk may largely be bounded to lower reasoning tasks.
   • These findings indicate that the Astra class models could evade our CoT monitors under adversarial conditions. Right now, these findings are largely based on adversarial evaluations (i.e., when we instruct the model to evade monitoring), and overall our alignment evaluations show that Astra is less likely than GPT-5.6 Sol to violate security and safety restrictions overall.
   • However, we take the trend seriously, and we are continuing to investigate these findings and their implications for monitorability as our models become more capable. OpenAI has worked to preserve and utilize chain of thought monitoring, and preserving CoT monitorability is a core goal of the research program. However, these results also underscore the importance of developing alignment auditing techniques beyond examining the model’s chain of thought.
6. GPT-6 Astra more responsibly navigates browsing and workplace settings: GPT-6 Astra is significantly more robust to prompt injections than GPT-5.6 Sol. We have additionally tested the model’s behavior in realistic browsing and professional computer environments, and find that the model is significantly less likely to perform misaligned and potentially destructive actions (for instance unauthorized transactions, data loss, excessive access, or circumvention of controls) compared to GPT-5.6 Sol. It also acts more safely when handling harmful requests in agentic settings, such as requests to assist with violent attack planning or commit fraud.
7. GPT-6 Astra is significantly safer in higher-risk scenarios. GPT-6 Astra responds more safely than GPT-5.6 Sol to challenging requests drawn from production and adversarial human red-teaming. Astra achieves a Pareto improvement in safely completing unsafe requests and avoiding unnecessary refusals to harmless requests. These improvements extend to high-severity scenarios where the risk of harm emerges from the broader context rather than an explicit request. Astra also applies age-appropriate safety boundaries more consistently for users under 18.

For more information, see the full system card.

Introducing GWM Worlds 2

Interactive worlds generated in real time: continuous 720p video at 24 fps and audio at 48,000 Hz, responding to your inputs as you explore. Extending GWM Worlds, showcased in December last year, GWM Worlds 2 supports generated audio and rich subject and scene control.

In December, we introduced GWM Worlds, a world model for real-time environment simulation. GWM Worlds extended our research efforts around real-time video generation, and excelled at maintaining spatial consistency across long sequences of movement.

Today, we're sharing GWM Worlds 2, the next iteration of our research to create interactive environments. Built on top of our foundational audio-video generation model, GWM Worlds 2 turns high-fidelity video and audio generation into real-time interactive simulation. You define the environment, subjects, visual style, physical rules and ambience. Once inside, you steer the world with text actions addressed to any subject or to the scene itself, alongside continuous camera motion. A text action can be a sword slash, a spoken reply, a room flooding with water, a dust storm rolling in or anything else you can put into words.

The world continues from each new input instead of following a fixed clip or script, so sessions have no preset length. This creates a foundation for interactive entertainment, virtual characters, robotics and embodied-agent simulation and generative design and interfaces.

WorldPrompt

Rich control over a world requires an input representation that generalizes across use cases. We base ours on the insight that a world can be split into two kinds of state: what persists and what changes over time. We formalize this as WorldPrompt, a format with two complementary layers.

• Persistent world context:
  • A genesis prompt that includes a scene description covering the environment, its layout, materials, lighting and ambient sound; the subjects that can participate in events, with their attributes; and the laws, reusable conventions that govern behavior, from gravity and collision to character abilities and the camera perspective.
  • A first frame to ground the generation visually.
• A timestamped event stream: Actions that describe movement, gestures, object interactions, speech and sound. Each action is a free-form text prompt with start and end timestamps, addressed to a subject or to the scene itself. Multiple actions can overlap. Camera input that represents a per-frame stream of viewpoint translation and rotation.

Finetuning the Model on WorldPrompt

We take our foundational audio-video generation model and finetune it on the WorldPrompt format. Below are some results showing the model follows the WorldPrompt structure correctly.

Real-Time Generation

The finetuned model is still too slow, and cannot yet generate autoregressively because it is still bidirectional. Therefore, we post-train the bidirectional model into a real-time autoregressive model, GWM Worlds 2. Unlike the bidirectional model, GWM Worlds 2 is also not restricted to a fixed duration and can generate indefinitely.

The same WorldPrompt structure applies here as well, but now the world responds as you play: each clip below was generated live at 24 fps, with a user steering the world through text actions addressed to subjects and the scene, plus continuous camera motion. Recurring actions can be bound to keys for fast play.

The model supports both first-person and third-person navigation like walking, driving and riding through a world. The camera and the subject can be controlled independently.

Subjects and the scene can be directed to take arbitrary actions: movement like running, climbing and leaping; object interactions like switching a lamp on or changing its color; and scene events like a theater stage erupting in fire.

Characters can hold conversations and control the voice, tone and language of the speech, e.g. NPC–player dialogue or a vlogger talking to the camera. Lip movement and delivery are generated to match.

Model Overview

GWM Worlds 2 is an autoregressive diffusion video and audio model generating 720p video at 24 fps and audio at 48,000 Hz. GWM Worlds 2 conditions each AR step on three kinds of context: a global context (the genesis prompt and first frame), the current frame's inputs (camera input and the text actions that span the current frame) and the past generated frames, cached in a sliding window. The video and audio decoders are causal and run with a cache for faster decoding.

Using the Model

The model itself takes the WorldPrompt, with its persistent and event-based context, and outputs video and audio. There are various ways we could imagine using such a model:

• Ahead of time. The user (possibly with the assistance of an LLM) authors the timestamped event stream once at the start, and the model generates the whole video and audio with it. Uses: filmmaking, advertising.
• Turn-based. The generation runs until the user has to make a decision. The user then chooses an action, which an LLM could put into the timestamped event stream format. The model proceeds to generate until the next decision point. Uses: visual novels, interactive film.
• Real-time. The model continuously generates video and audio, and the user can take actions that immediately affect the generation stream. This is the most challenging scenario, as it requires text to be available with low latency, reacting immediately to the world. Making users type actions would be too slow, and even VLMs cannot react within tens of milliseconds. Uses: games, interactive experiences.

Demo

For some videos in the real-time generation section we used the ahead-of-time method to author rich actions beforehand without having to come up with them on the fly. For most of them we used our demo, which implements the real-time method.

Continuing Play from a Video

Instead of starting from an image, we can also prefill the generation with an existing video. Here is an example where we prefill with a generated eight second video and then continue playing from it. Note that the model keeps the environment and audio consistent with the input video.

Agentic Control

We can let agents control the actions of the different subjects. Here is an example where we let an agent control both the character (to move and attack) and the environment (to direct its lighting). Thus, GWM Worlds 2 can be used as a simulated environment for evaluations of agents, and for training them in diverse environments.

Multiplayer

We can also let different users control different subjects. This can be used to implement multiplayer experiences by letting each user control their own character, or by having one user control the world.

World Authoring

In our demo, sessions are started from presets that contain the first frame, the genesis prompt and the possible actions for the different subjects, bound to different keys. Instead of manually typing out these prompts and coming up with actions, we allow users to create their own presets quickly by generating everything with the assistance of an LLM.

Limitations

GWM Worlds 2 is a research preview, and real-time generation still trades fidelity for speed. Difficult camera inputs such as very quick rotations can cause details, textures and geometry to degrade. Long-term memory is also imperfect, and the model doesn't support image references beyond the first frame or prefilled video and audio.

While free-form text makes the control surface general, fully leveraging it can require an external real-time harness that tracks the state of the world and generates actions on the fly, for example the NPC dialogue in an NPC–player interaction.

Real-time video generation is still in its earliest stages, and the constraints outlined in this post will be solved with continued research.

A few weeks ago I wrote that AI had collapsed the cost of building software, and that building it was no longer the hard part.

I was thinking mainly about shadow AI, ownership, and visibility. I still stand by all of that, but I think I missed another consequence of the same economic shift.

We are going to over-engineer absolutely everything.

Code. Tests. Documentation. Policy. Governance. Organisation design. The whole lot.

Not because any of those things are bad. Not because the people using AI to create them are incompetent. Each new artefact will usually look sensible, thorough, and defensible on its own.

The problem is what happens when producing another one becomes almost free, while understanding, validating, maintaining, reconciling, and eventually deleting it does not.

The factory that ate the product

I have been thinking about this since reading Steve Yegge’s Fences, not Sandboxes.

Yegge has been using a system he calls Wheelhouse to work on Wyvern, the game he has been building for thirty years. By his account, Wheelhouse has around 50 to 60 agents, including 18 named officer roles, and averages 270 commits a day across product and orchestration work. In less than ten weeks it helped get the game close to relaunch on Android, iOS, and Steam, delivered a new client, and rewrote its production infrastructure.

This is not an AI demo looking for a problem. It is doing real work on a real product.

Wheelhouse has grown to around 600,000 lines of code and tests, mostly Bash. Wyvern itself, excluding game content, is only around twice that size. Yegge says the factory is growing faster than the product and appears to be heading towards a one-to-one ratio.

The agents have created 450 legal artefacts across offices, runbooks, rulings, authority envelopes, and enforcement mechanisms. There are more than 100 things called fences. The system has a constitution, case law, jurisdictions, and a lifecycle for its own rules.

It eventually became large enough that Yegge created a new officer role, the Head of Wheelhouse Law, to prune obsolete rulings and govern the governance.

Yegge presents this as the unexpected emergence of civilisation inside an agent system. His argument is that a group of interchangeable, amnesiac agents needs explicit law in the same way that groups of humans need institutions. I think there is quite a lot of truth in that.

I also think it is possible that he has documented a second phenomenon at exactly the same time: a software factory gradually turning its productive capacity back on itself.

This is not an obvious failure

It would be very easy to read those numbers, laugh at the medieval government, and declare the whole thing ridiculous.

That would be unfair.

Wheelhouse is plainly producing useful work. Players asked Yegge to slow the pace of new features. When they did, he redirected 80 per cent of his token spend inward, towards quality, throughput, and the health of the factory itself. Much of that appears to be genuine reliability engineering, but it is still quite a place to reach in less than ten weeks.

There is also a genuine coordination problem here. Human teams carry a vast amount of their operating model in people. We remember why decisions were made, which rules are firm, which are situational, and when the sensible thing is to stop and check.

Stateless agents do not have any of that unless it is made explicit. If 50 of them are changing the same product around the clock, they need persistent decisions, authority boundaries, queues, deployment gates, rollback mechanisms, and a shared view of what is happening.

Comparing the factory’s code with the product’s code is not entirely fair either. Wheelhouse contains bits of engineering management, release engineering, CI, SRE, documentation, access control, and institutional memory. In a human organisation, much of that cost would be hidden in meetings, salaries, SaaS tools, and things somebody just knows. A 600,000-line factory could still be cheaper than the human organisation required to produce the same outcome.

So my point is not that large automatically means wasteful.

My point is that AI has removed much of the economic pressure which used to force us to find out whether each extra layer had earned its keep.

Cheap to create, expensive to own

Historically, producing organisational and technical artefacts took effort. Policies needed drafting and approval. Tests took time to write. Documentation required an engineer to stop doing the thing and explain it. A reorganisation needed weeks of discussion, spreadsheets, and increasingly strange boxes in PowerPoint.

That friction was annoying, but it also acted as a filter. It forced somebody, at least occasionally, to decide whether the thing was important enough to create at all.

AI has largely removed that filter. It can produce the policy, the implementation, the tests, the operating procedure, the RACI, the review checklist, and the slide deck explaining the new governance model before lunch.

What it has not made cheap is ownership.

Somebody still has to know which policy is current, notice when two documents disagree, and understand why a test is failing six months later. Every document is another possible source of truth, every rule another possible contradiction, and every abstraction another concept to load before doing useful work.

Tokens are getting cheaper. Cognitive load is not.

Cheap to create. Expensive to own.

Every decision was sensible at the time

The dangerous version of over-engineering does not arrive as one obviously mad decision.

It accretes.

An agent makes a poor judgement, so the team writes down a rule. The rule matters, so it gets a test. The test needs to run somewhere, so the team adds enforcement. Enforcement creates an exception, so the exception is documented. The growing body of rules needs an owner, a lifecycle, and a review process. Eventually the process for changing the process needs its own controls.

Every step is reasonable.

The whole system can still become absurd.

Yegge describes almost exactly this. Each incident created new rulings and doctrine. Rules hardened from custom into warnings, then constitutional law, then mechanical enforcement. When he eventually inspected it, he found obsolete rulings and things which had been elevated into law even though they were really just good craftsmanship.

The agents had been growing it, not curating it.

Ask an AI to design an organisation and it will quite happily give every concern a role and every decision a RACI entry. Ask it for a policy and it will cover edge cases until the result is too long to read. Ask it to improve a codebase and it will find endless opportunities to add abstractions, tests, comments, and validators.

It is trying to be useful, and it can justify almost every addition. It is very good at producing completeness. It is far less inclined to leave something slightly untidy because tidying it would add no meaningful value.

Humans are hardly immune. Engineers over-engineered software long before anybody put a language model in a terminal. Large organisations have always produced policy nobody reads and org charts which make more sense to their designers than the people inside them.

AI did not invent the instinct.

It removed the friction that used to constrain it.

Capacity seeks utilisation

I first described this to myself as chasing a perfection that does not matter. I now think there is a slightly deeper mechanism at work.

Capacity seeks utilisation.

Once you stand up a large fleet of agents, you naturally want to keep it busy. Idle agents feel like waste, even when the cost of idleness is nearly zero. Work is decomposed more aggressively, backlogs grow, and the system needs more coordination to absorb all the simultaneous change.

Yegge’s earlier article, The Shape of Things to Come, describes his previous harness, Gas Town, effectively collapsing because its model developed what he called a “just two more things” habit. It kept improving the harness instead of converging on the real work.

While deliberately scaling the fleet, Wheelhouse accumulated more than 700 fully designed but unimplemented work items. An overnight fleet requires a mountain of work to remain occupied. Yegge estimated that working on Wheelhouse itself consumed 20 to 25 per cent of all his work on Wyvern, and said the figure showed no sign of falling.

At one point the agents produced changes faster than the merge system could absorb them. The queue grew without bound, and the system kept optimising batch sizes until Yegge challenged the premise and changed the approach. He fixed it, but the failure mode is revealing. Every part was behaving rationally while the whole made less and less progress.

More agents create more simultaneous work. More simultaneous work creates more coordination failures. Those failures create more rules, tests, monitoring, and infrastructure. The new machinery creates more things to maintain and more opportunities for agents to improve the machinery.

You can end up building an increasingly sophisticated organisation whose largest customer is itself.

Activity is not value

Measures we already knew were weak become actively misleading in this world. Lines of code, commits, documents produced, tests written, tickets closed, policies completed, and tokens consumed are all measures of activity. AI can accelerate every one of them without improving the overall system.

There is some early evidence of exactly that gap. Faros analysed engineering telemetry from more than 10,000 developers and found that teams with high AI adoption completed 21 per cent more tasks and merged 98 per cent more pull requests. Review time rose by 91 per cent, average pull request size by 154 per cent, and bugs per developer by 9 per cent. At company level, it found no significant relationship between AI adoption and better outcomes. It is correlational research from a commercial provider, not proof of cause, but the pattern is hard to ignore. Production accelerated. Absorption did not.

The same thing is appearing outside software. In a self-reported BetterUp survey about what it calls “workslop”, 40 per cent of US desk workers said they believed they had received AI-generated work in the previous month which looked plausible but pushed thinking and repair onto the recipient. The sender experiences acceleration. The receiver experiences a new job.

Yegge gives us agents, tokens, commits, lines of code, fences, and governance artefacts, alongside some real signs of useful output. What we do not get is enough information to separate earned complexity from self-sustaining complexity.

How much human attention does the factory consume? How many of the 450 legal artefacts have changed a meaningful outcome? Would ten focused agents produce most of the user value with a fraction of the machinery? I genuinely do not know.

The most striking measure in the whole story is not 270 commits a day. It is that the people using the product asked for the pace of change to slow down.

At that point, more production is not automatically more value.

Fences are not the problem

None of this is an argument for running agents without controls.

Yegge uses “fence” quite broadly. Some are contextual rules, while others are mechanically enforced checks. A sandbox provides isolation and limits what an agent can reach in the first place. I do not think those are alternatives. They address different layers of the same problem.

Yegge says that even his strongest model makes at least one terrible decision during unattended operation each day. That observation, to me, supports both contextual rules and hard containment.

For consequential enterprise work, I still want hard boundaries around irreversible, external, and high-impact actions. Within them, agents should have broad discretion, good context, and a route to stop and ask.

The problem is not governance.

It is governance whose volume is mistaken for its quality.

A hundred fences might be exactly right. It might be ninety-five too many. The number tells us nothing until we know what they protect and what they cost to keep correct.

Complexity has to earn its keep

The answer is not another enormous framework for preventing enormous frameworks. It is a return to some quite ordinary engineering discipline.

Internal machinery needs a budget. Not just a token or infrastructure budget, but a limit on how much product capacity and human attention it is allowed to consume.

Rules need reasons. A fence should address a named, meaningful failure mode, not merely something it is possible to imagine.

Everything needs a review and retirement path. Policies, documentation, tests, agents, and organisational roles should all be easier to retire. If nobody can explain what outcome would worsen if one disappeared, treat it as sediment until proved otherwise.

Most importantly, measure the thing outside the factory. Did the customer experience improve? Did decisions get faster? Did reliability improve, risk fall, or somebody get useful time back?

The interesting measure is not how much the AI produced. It is what actually got better after everyone had dealt with the output.

AI is incredibly good at answering, “What else could we add?”

There is always another edge case to document, another test to write, another role to define, another review step to automate, and another piece of the harness to improve.

We are going to need to become much better at asking a different question.

Does this deserve to exist?

That judgement is now the scarce part of the work. The factory can already produce far more than we know how to use.

If the scaffolding is starting to rival the building, the answer is not automatically a Head of Scaffolding.

Introducing WeatherNext 3, our most advanced and accurate global weather AI model

Our flagship AI weather forecasting model now includes real-time satellite data, hourly refreshes, higher resolution, precise precipitation forecasting, and clean energy variables. It’s now integrated across Search, Gemini, Maps, Google Maps Platform, and Cloud.

Every day, the weather influences billions of decisions. Some are as simple as grabbing an umbrella before heading out the door, but others are far more consequential. Wind, rain, and extreme weather events, like heatwaves and droughts, have cascading impacts across agriculture, global supply chains, clean energy production, and national economies.

In recent years, AI has revolutionized weather forecasting, using historical records to make faster and more accurate predictions than traditional methods. Yet predicting highly local and rapidly changing weather has remained a challenge. Previous models often lacked sufficient spatial resolution, and struggled to incorporate real-time weather data from sources like satellites.

Today, Google DeepMind and Google Research are introducing WeatherNext 3, the most advanced and accurate global weather model to date, according to independent live evaluations by Brightband. Our model learns directly from real-time observations, enabling it to provide timely and more localized predictions for the weather events that impact people the most. By using raw satellite data to produce a forecast every hour in high resolution, our model makes reliable forecasts accessible across Google products worldwide.

Rapid weather prediction at unprecedented resolution

A forecast's utility often comes down to detail and how finely it resolves both time and space. WeatherNext 3 generates hourly forecasts at multiple spatial resolutions, maintaining physical consistency from broad global wind patterns all the way down to local topography.

With WeatherNext 3, we can visualize key surface variables — like temperature and moisture — at a 5-kilometer resolution, other surface variables at 10 kilometers, and atmospheric variables, like wind speed, at 25 kilometers. Overall, this provides a global weather picture roughly five times sharper than our previous model, WeatherNext 2, which produced forecasts on a 25-kilometer grid in 6-hour increments.

Real-world data at continuous global scale

WeatherNext 3's biggest leap forward is what it learns from. Most AI weather models, including WeatherNext 2, are trained on data from numerical weather prediction (NWP) models. Although useful, NWP models are complex, supercomputer-driven physics simulations that carry a six-hour data lag. This lag can lead to biases for fast-changing variables like rain or surface temperature.

By ingesting a mosaic of live, global geostationary satellite data, our new model gains a rich, continuously updating view of the atmosphere. This allows the model to generate a new forecast every hour, each one grounded in the most recent satellite observations available, at up to 5-kilometer resolution.

This is important because critical weather develops fast. When storms, fronts, or precipitation systems materialize suddenly, our rapid update cycle and higher resolution provides earlier, more detailed insights needed to help drive an effective response.

Some variables, like temperature and humidity, can fluctuate dramatically over just a few kilometers, which is particularly relevant for communities near coastlines, valleys, or mountain ranges. Traditional models struggle here because they train on representations of the atmosphere that lack detail and miss extreme local variations.

To address this, WeatherNext 3 instead trains directly on sparse weather station observation data. This allows us to make global forecasts on a 5-kilometer grid that account for regional details like topography.

This breakthrough is particularly vital for regions across Latin America, Africa, and Asia-Pacific that have historically been underserved by high-resolution forecasting due to the immense supercomputing costs of traditional regional models. It brings localized, high-fidelity forecasting to billions of people and local businesses in these areas.

Beyond improved resolution and forecast frequency, our model introduces predictions specifically engineered for renewable energy production. The model forecasts 100-meter wind speeds (roughly at turbine-height) for precise wind-energy output, alongside high-resolution cloud cover and sun radiation levels to help solar farms estimate how much light they will receive on the ground.

This data is crucial for global clean energy planning, allowing grid operators and renewables developers to accurately predict how much power their clean energy assets will generate and match it with consumer demand.

Precipitation forecasting at breakthrough accuracy

Global weather models notoriously struggle to accurately predict precipitation. Rain and snow systems are driven by fast-moving cloud processes on tiny scales that are hard to model accurately using traditional physics-based simulations. Consequently, AI forecasts often produce blurry estimates or miss the boundaries of severe storms entirely.

To solve this, we train our model on two exceptionally high-quality sources of precipitation data: NASA’s satellite-based Integrated Multi-satellite Retrievals for GPM (IMERG) and our own global precipitation reanalysis based on satellite radar.

The result is a significant leap in precipitation forecasting accuracy. In medium-range global forecasts, evaluations against baselines show a Continuous Ranked Probability Score (CRPS) improvement of up to 60% against IMERG, 30% for MRMS, and 10% against rain gauge measurements for early lead times.

Research applied across the ecosystem

Our primary goal is to advance weather intelligence to make it universally useful — whether for an emergency responder tracking sudden wind shifts, an air traffic controller planning flight paths, or a farmer managing crops.

To bring these breakthroughs out of the lab and into the real world, we’re integrating WeatherNext 3 across Google’s core ecosystem and beyond:

• High-resolution forecast data: We’re making global weather predictions, updated hourly and ready to integrate into your workflows with no model setup required. This enables researchers, developers and businesses to query the data in BigQuery and Earth Engine, or bulk-download from Google Cloud Storage.
• Available globally: WeatherNext 3 will begin powering weather experiences within Google Search, Gemini app, Google Maps, Google Maps Platform Weather API, and Google Earth Engine starting today. The update dramatically improves longer term forecasts. When planning a day or more ahead, people will see up to 50% more accurate precipitation forecasts — with the greatest improvements in regions where forecasts have historically been less reliable. So if you’re packing for a weekend trip or deciding the best day for an outdoor activity, you’ll now get more accurate predictions to help you plan.

The atmosphere will always retain a degree of unpredictability. However, by training on real-world observations and bypassing traditional modeling constraints, WeatherNext 3 brings us closer to a future where forecasts truly match what is happening on the ground.

To learn more about geospatial platforms and AI work at Google, check out Google Earth Engine, AlphaEarth Foundations, and Earth AI.

Disclaimer: For official weather forecasts, severe weather warnings, and public safety advisories, please refer to your local meteorological agency or national weather service.

Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler

Kubernetes v1.37 includes API support for horizontal autoscaling of workloads down to zero replicas. This feature is now Beta and enabled by default. A HorizontalPodAutoscaler (HPA) that uses a suitable object metric or external metric can now scale a workload to zero replicas, then bring it back when the metric changes.

Before v1.37, you needed an add-on or external component, or you had to enable the Alpha feature gate, to scale from zero. It is now part of core Kubernetes.

Scaling to zero removes the last idle Pod from workloads such as queue consumers and batch processors. The savings are largest when each Pod reserves expensive resources, including dedicated CPUs or GPUs.

The trade-off is cold-start time: the HPA must observe the metric, schedule a Pod, and start the application. This works well when work can wait in a durable queue.

Kubernetes Services do not buffer requests while no Pods are ready, so HTTP and other request-driven workloads need a separate buffering layer.

Why scaling from zero needs a different metric

The HPA commonly scales on CPU or memory usage. Both metrics come from running Pods. Once the replica count reaches zero, there are no Pods left to measure and no signal that can tell the HPA to scale back up.

Object and external metrics do not have that limitation. A queue length, for example, exists independently of the workers that consume it. The HPA can continue reading the queue length while no workers are running.

The following example scales a queue consumer to and from zero using an external metric.

Configure an external metric

The following example uses a Prometheus metric named queue_consumer_lag. It assumes that Prometheus already collects a series similar to this one:

queue_consumer_lag{namespace="default",name="worker_tasks"}

Kubernetes needs a metrics adapter to make that value available through the External Metrics API. One implementation is the Prometheus Adapter, which can expose the series using an externalRules entry:

externalRules:
- seriesQuery: '{__name__="queue_consumer_lag",name!=""}'
  metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (name)
  resources:
    overrides:
      namespace:
        resource: namespace

The exact adapter installation and discovery rules depend on your monitoring setup. See the Prometheus Adapter guide to external metrics for the full configuration options.

Before creating the HPA, you can verify that Kubernetes can read the metric:

kubectl get --raw \
  '/apis/external.metrics.k8s.io/v1beta1/namespaces/default/queue_consumer_lag?labelSelector=name%3Dworker_tasks'

The request should return the current value for worker_tasks. If it does not, fix the metrics pipeline before configuring the HPA. An HPA cannot scale from zero when its metric is unavailable.

Configure the HPA

The following HPA targets a Deployment named queue-worker. It allows between zero and ten replicas, with one replica requested for each 30 queued tasks:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
  annotations:
    kubernetes.io/description: "Scales queue-worker based on the number of queued tasks"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_consumer_lag
        selector:
          matchLabels:
            name: worker_tasks
      target:
        type: Value
        value: "30"

When the queue is empty, the HPA can reduce the Deployment to zero replicas. When tasks arrive, the external metric remains available and the HPA calculates a new replica count, capped at ten by maxReplicas.

Start the Deployment with at least one replica. Manually setting a Deployment to zero has always paused autoscaling. The HPA preserves that behavior and will not wake a workload that it did not scale down itself.

Normal HPA behavior still applies. In particular, the default downscale stabilization window is five minutes. The window prevents a short drop in queue length from immediately removing all workers. You can configure the window through spec.behavior.scaleDown if your workload needs different behavior.

How the HPA distinguishes zero from paused

Scaling from zero creates an ambiguity. A replica count of zero can mean that the HPA scaled the workload down, or that an operator manually paused it.

The controller resolves this with a ScaledToZero status condition. When the HPA scales a workload from one or more replicas to zero, it records ScaledToZero=True. The condition tells later reconciliation loops that the controller owns the zero state and should continue evaluating object or external metrics.

After scaling the workload back up, the controller changes the condition to ScaledToZero=False with the reason NotScaledToZero. A workload at zero without the ScaledToZero=True condition remains paused.

You can inspect the conditions with:

kubectl describe hpa queue-worker

If the adapter cannot return the configured metric, the HPA reports ScalingActive=False with a reason such as FailedGetExternalMetric. Restore the metric or manually scale the workload to recover capacity.

Before upgrading or rolling back

In Kubernetes v1.37, the HPAScaleToZero feature gate is enabled by default on both the kube-apiserver and kube-controller-manager. The API server accepts minReplicas: 0; the controller manager performs the condition-based scaling.

During a version-skewed control plane upgrade, wait until both components support the feature and have it enabled before creating HPAs with minReplicas: 0. A controller manager with the feature disabled treats replicas: 0 as a manual pause and may leave a workload at zero.

Before disabling the feature gate or downgrading to a version without the condition-based implementation:

• Change affected HPAs to minReplicas: 1 or higher.
• Scale any workload currently at zero to at least one replica.

minReplicas: 0 also requires at least one object or external metric. The API server rejects an HPA that only contains resource metrics such as CPU or memory.

From Alpha to Beta

The first Alpha implementation shipped in Kubernetes v1.16. Kubernetes v1.36 added the ScaledToZero condition and the controller behavior needed to distinguish an automatic scale-down from a manual pause.

Kubernetes v1.37 enables the feature by default after adding integration and end-to-end coverage for scaling down to zero and back up from an external metric. The next step is to gather operational feedback before considering graduation to GA.

How can I learn more?

• Read the documentation for scaling to and from zero.
• Read KEP-2021: HPA supports scaling to and from zero pods for object and external metrics.
• Learn how to configure the Prometheus Adapter for external metrics.

How to get involved

This feature is owned by SIG Autoscaling. Join Kubernetes Slack and the #sig-autoscaling channel to share feedback from Beta usage.

Acknowledgements

Thanks to the SIG Autoscaling contributors who took this feature from the original v1.16 implementation to the condition-based redesign and Beta graduation. Thanks also to Guy Templeton and Adrian Moisey for reviewing the KEP, and to the release, documentation, and production-readiness reviewers who helped prepare it for Kubernetes v1.37.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

A connectomics milestone: Mapping the complete male fruit fly brain

We partnered with HHMI Janelia and collaborators to publish a complete map of the male fruit fly’s brain and central nervous system, creating the largest brain map to date. Together with ongoing research on other species, such as fish and mice, these wiring maps begin to reveal the mechanics of how all brains work.

The common fruit fly, Drosophila melanogaster, has been central to scientific research leading to multiple Nobel Prizes. Fruit flies have been a fundamental model organism in genetics, thanks to their stereotypical behavior and short life cycle, and promise to do the same for neuroscience. While the thoughts of this fruit-loving insect might seem far removed from human cognition, the brains of vastly different species share many similarities. Because mapping the 86 billion neurons in a human brain is not yet possible, scientists are using AI to map the brains of smaller organisms, like fruit flies. This will help us decipher how animal nervous systems perceive the world, react to stimuli, and how damaged neural pathways might one day be repaired.

Now, in a project led by Howard Hughes Medical Institute (HHMI) Janelia Research Campus, our team and collaborators have released a complete wiring diagram of the male fruit fly’s brain and central nervous system. Published in Cell, “Sexual dimorphism in the complete connectome of the Drosophila male central nervous system”, is the result of a decade-long partnership that advances the field of connectomics using computing and AI to build cellular-scale maps of entire brains. With over 166,000 neurons and 125 million synaptic connections, this is the largest brain map by number of neurons to date, providing a fundamental resource for scientists to use fruit flies as a model organism for studying how the brain works.

A small subset of cells in the male fruit fly’s brain and central nervous system, as viewed from in front at an angle (left) and from above (right).

The male fruit fly connectome also includes the ventral nerve cord, analogous to the spinal cord, and so begins to expand from just the brain into how the brain controls the body. The male fly connectome has been annotated and verified, or proofread, by a team of human experts at HHMI Janelia. It can be viewed, explored and downloaded via Neuroglancer, the open-source tool we created to enable researchers to visualize huge multidimensional datasets.

The new connectome contains neurons from the central brain (green), optic lobes (purple) and ventral (i.e., central) nerve cord (blue). The new connectome enables linking auditory, visual and olfactory inputs to motor outputs for this key model organism.

This new brain map complements the female fruit fly brain map and recently released complete female fruit fly brain and nerve cord map. Having both male and female brains and central nervous systems mapped allows the two to be compared in places where neurons differ, and used to study the biological mechanisms for fruit fly courtship and aggression. In parts of the brain that are similar in both sexes, having two complete fruit fly connectomes will allow researchers to begin to see the variability between individuals.

An example of a neuron that is different between the male (green) and previously mapped female (magenta) fruit fly brains. The male neuron has two additional projections. AI enables accurate 3D reconstructions to pinpoint these structural differences.

Steps toward mapping a full fruit fly brain

Brain mapping, or connectomics, begins with sectioning a brain into millions of thin slices, taking an image of each section, and using computers and AI to stitch the images together. Our researchers build systems that leverage AI to turn flat electron microscope images into 3D reconstructions, using an evolving suite of techniques to generate accurate neural shapes.

Our AI connectomics tools include flood-filling networks, which use convolutional neural networks to start at a single pixel and identify all other pixels that are part of the same object. In 2019, our Connectomics team released an initial, fully-automated reconstruction of a female fruit fly brain. By 2020, our team and collaborators released a human-verified map of half a female fruit fly brain with 25,000 neurons and 21 million connections, a record at the time. Meanwhile, the team was already working on the full, verified brain map for a male fruit fly, which is now complete.

These methods continue to improve. A recent effort incorporated synthetic neurons into the training data, successfully improving the speed and accuracy of our state-of-the-art reconstruction system, PATHFINDER. We are also helping to develop new techniques for labeling and annotating specific types of neurons. Currently, mapping the fruit fly brain requires years of human effort just to verify and annotate the neural shapes. By reducing this need for manual error correction, research groups can tackle even larger brain mapping projects within reasonable budgets and timelines.

Looking ahead: Mapping entire fish brains

The field of connectomics is already advancing into vertebrates: organisms with a spinal cord. These are anatomically, evolutionarily and functionally more similar to humans. In a study led by Columbia University and published this week in Nature, our team helped map a portion of the elephantnose fish’s hindbrain that is used in signal processing. This paper, “Connectome analysis of a cerebellum-like circuit for sensory prediction”, shows for the first time how the connectome, a static resource, can be combined with other information to study neural plasticity and learning, producing the most complete mechanistic model of learning in a vertebrate brain to date.

Larval zebrafish are one of the few vertebrates whose brains are small enough to be mapped from end to end using current techniques. Zebrafish also have the advantage of being transparent in their larval stage, allowing measurements of neural activity during experiments, as captured in the ZAPBench dataset. Our upcoming paper with Harvard, “A connectomic resource for neural cataloguing and circuit dissection of the larval zebrafish brain”, is the first whole-brain dataset for a vertebrate that includes the neural structure and molecular type spanning an entire vertebrate brain. Our team also released a preliminary version of a dataset that combines neural activity and structure in the same larval zebrafish brain, as an open resource to the research community.

An image from the Fish Fire&Wire dataset, which combines whole-brain electrical activity and neural structure for the same larval zebrafish specimen.

Conclusion

The male fruit fly connectome is a foundational resource that will support a new era for experimental neuroscience, with future applications in biology, pharmacy and medicine. Three companion papers released today show how the male fruit fly connectome has already been used for research on the neuroscience of visual systems, taste and social behavior. Methods developed here will also help advance other projects, such as the upcoming fully proofread map of the zebrafish brain, and mapping a portion of the mouse brain. While modeling the 86 billion neurons in the human brain remains out of reach, we are moving toward revealing how brains function and understanding the processes underlying mental ailments, such as Alzheimer’s, depression or schizophrenia. Someday, we hope these efforts lead to new ways to treat cognitive ailments, improve brain health, and support brain repair.

Acknowledgments

We thank our academic collaborators at HHMI Janelia and elsewhere, and acknowledge core contributions from the Connectomics Team at Google. We are grateful to Hannah Hickey and Elise Kleeman for their help. Thanks to Lizzie Dorfman, Michael Brenner, John Platt, and Yossi Matias for their support, coordination and leadership.

Two months ago, I asked why Meta appeared intent on destroying its engineering organization, at a time when the social media giant was reporting record revenue and profits. The question was raised after the company did two unexpected things:

1. Laid off 10% of staff. Executed large layoffs in May, with circa 10% of engineers shown the door.
2. Moved 20-30% of engineers to AI training. At around the same time, infra and product teams lost a further 20-30% of their engineers, who were reassigned to data labeling work for AI training.

The outcome of that period was low morale and a string of embarrassing outages, including a “zero auth password reset” outage on Instagram, where anyone’s account – including that of former US president Barack Obama – could be taken over just by asking the AI bot to replace Obama’s email with a different one.

Now, thanks to reporting by Reuters, new details have emerged about a plan for much larger layoffs, which eventually did not go ahead. The news report is pretty damning, and I want to get into what the planned AI job cuts reveal about Meta at this point in its history, what Zuckerberg might have been thinking, and what it could mean for other tech companies.

Making Meta “AI-native:” Project Organization Transformation

The plan was formed in January of this year. As per Reuters:

“In January, Meta CEO Mark Zuckerberg and his top lieutenants gathered for their annual leadership retreat at his Hawaii compound. There they hatched a radical plan to reimagine work at the social-media giant in the age of artificial intelligence.

Code-named Project OT – short for Organization Transformation – the plan envisioned an “AI native” future for the owner of Facebook and Instagram. AI would take over much of the daily work performed by thousands of human employees. Virtual workers would be overseen inside Meta by smaller, “talent-dense” cadres of human staffers, according to one internal planning document reviewed by Reuters and three people familiar with the project.”

The idea was that many existing teams could be reduced by 60% in their size through layoffs and reallocation of workers to other parts of the business. Underpinning this was the assumption that AI would enable these smaller teams to operate as well as before. HR at the social media giant projected that the project would involve a bigger layoff than happened in 2022-2023, when 25% of staff were let go. The new plan was to do one layoff+restructuring in May, and another in November.

I suspect a 30-40% company-wide layoff was planned.

But at the last minute, something changed. From Reuters:

“But on the night of May 19, just hours before the first layoff wave, Zuckerberg blinked. Meta laid off 10% of its employees the next day, but it called off planning for the November cuts, according to one internal document reviewed by Reuters.

By then, Meta employees were in open revolt, convinced that the company’s AI transformation initiatives were partly aimed at replacing them.”

The Reuters report shows those employees were right: Meta’s AI initiatives were indeed aimed at laying off as many of them as possible, without changing overall productivity!

Why did Meta want 60% smaller teams?

You must assume that a company like Meta acts rationally overall, and on that basis it’s worth figuring out what the rationale might be in the case of ‘Project OT’. The article offers a hint: executives at the company had been captivated by “AI-native” businesses in Asia, Reuters claimed:

“Meta executives, including Chief Data Officer Alex Schultz and Head of Product Naomi Gleit, visited Asia last year and admired how startups there had built their organizational charts around AI, according to three people familiar with the trips. Meta executives also commissioned their own research into how AI startups were organized and set up pilot projects to determine what being “AI native” would mean at the company, according to one source familiar with the research and internal documents describing the pilots.”

And indeed, in February Meta experimented with “AI-native pods”. The presentation obtained by Reuters shows leadership intended to achieve 60% reductions in team size with small, 3-5 person, “AI-native” teams doing the work of what had been between 10 and 20 people.

Meta seems to have wanted to become smaller not organically, and over time, but with a brutal layoff and sudden reassignments, in the span of a year, ignoring the impact such a sudden change would have on the company, teams, and employees.

Downsides of tiny teams

In theory, a smaller team could work better with less communication overhead and quicker decision-making, so there are cases where the upsides of a small team outweigh the downsides. However, such expected gains would come with several real costs, mostly associated with losing so much experience and skill:

• Domain knowledge: A lot of personal domain knowledge is suddenly gone.
• Redundancy: In a 10-20 person team, it would mean business pretty much as usual. But in a 3-5 person team, you’re down to two people doing everything!
• Capacity for oncall: A healthy oncall schedule needs 6+ engineers if every alert is to be taken seriously.
• Lack of “slack time”: Innovation often comes from having time to focus on other work, instead of putting out fires.
• Professional growth: Engineers pair with more devs and get more feedback on larger teams.
• Judgment: For honing one’s skills, there’s more experience and mentoring to be gained in larger teams.

Is Zuckerberg’s worst fear being out-executed by a startup?

With Meta’s business posting record revenue and profits, it’s worth asking why the social media giant was in a rush to get to 60% smaller teams. My hunch is that Mark Zuckerberg is paranoid about a startup which executes better and that could “destroy” Meta at some point. After all, this is exactly what Facebook did, back in the day.

Myspace had twice as many employees as Facebook and grew faster than Facebook in 2003-2007. But Facebook out-executed Myspace by being more nimble and more focused. If so, is Zuckerberg being paranoid about a similar threat to Meta today? Anthropic, only five years old, with one twentieth of the workforce Meta has, might be going public at a near $2T valuation. Zuckerberg clearly sees AI companies as a form of competition to Meta’s business model.

Most valuable assets: people or GPUs?

One approach would be to lay off 20-40% of the workforce, but there are consequences:

• Workers reject being treated like “cattle”. When people realize 60% of their colleagues were reassigned or let go because of AI, they might look further ahead: will another 60% be laid off at some point?
• Engineering is officially a cost center, not a profit center. At Meta, software engineering became a cost center pretty much overnight.
• Mission, what mission? People often join a company and stay motivated over time due to a mission they personally believe in.

That’s the problem with large layoffs; they prompt precisely the best employees to quit to join competitors, or launch their own businesses. When leadership declares the ‘bottom’ 20-40% of the workforce is redundant, then very few people feel safe.

Do social impacts matter to Meta?

By executing massive layoffs for the sake of AI, Meta could have invited more regulation of the emerging AI sector. Meta is one of the largest tech employers in the US, and it faces an $18B fine following a legal loss regarding platform harm. If the planned cuts had happened at Meta, the government could decide that Anthropic’s and OpenAI’s CEOs were right about the threat to society of mass job losses and roll out stricter employee protections or taxation on companies that replace staff with AI.

Overall, the canceled plan to cut thousands more jobs in this climate just adds to the feeling that there are no adults running Meta. Since Sheryl Sandberg quit in 2022, Meta has acted irrationally, irresponsibly, and unpredictably.

I’ve long had a generally positive view of Meta’s engineering culture, but with the company’s leadership seemingly worshiping AI and holding their colleagues in disdain, you have to wonder which software engineer would choose to work at Meta if other options are available. There are many tech companies that value their human software engineers, understand that great teams make for great companies, and that AI is a tool and not a replacement for human energy, motivation, and thoughtfulness. But Meta is clearly not among them.

TL;DR

Three-LLM runs GPT-2, SmolLM2, Qwen, and Phi models locally in the browser by turning their inference graphs into Three.js TSL compute shaders on WebGPU. Try the demo at https://three-llm.ben3d.ca.

I started this project to test two things: how far I could push the general compute capabilities of Three.js and WebGPU, and what today's small language models can do when they run in a browser. The models range from a 3-million parameter story generator to a modern 800-million parameter chat model.

Three.js is known as a rendering library, but its WebGPU renderer also exposes storage buffers, compute dispatches, workgroup memory, atomics, and GPU readback. A language model puts all of those capabilities to work. It needs hundreds of ordered compute dispatches, large matrix-vector products, reductions, persistent attention or recurrent state, and a tight loop between the GPU and JavaScript as each new token appears.

I built Three-LLM as both a test of that compute stack and a usable inference library. It loads ordinary Hugging Face configurations, tokenizers, and SafeTensors checkpoints in the browser, builds the model from reusable Three.js Shading Language (TSL) compute kernels, and runs inference on the user's GPU through WebGPU. It does not need a server-side inference runtime or model-specific WebAssembly binary.

The package includes CPU reference implementations for validation and GPU implementations for actual use. The library currently recognizes GPT-2, Llama-style, Gemma 3, Phi, and Qwen3.5 architectures. I also made a quick chat application so you can try five checkpoints without writing an application first:

• TinyStories GPT-2 3M
• GPT-2 124M
• SmolLM2 135M
• Qwen3.5 0.8B
• Phi-1.5 1.3B

I made the demo to test the library without first writing an application. Model files range from 15 MB to 2.8 GB before Three-LLM expands their weights to 32-bit floats. On a phone, stick with TinyStories or SmolLM2. Qwen and Phi need enough memory that many mobile devices will fail to load them.

Using the library itself starts with a regular Three.js WebGPURenderer:

import { createTSLRunner } from 'three-llm';
import { WebGPURenderer } from 'three/webgpu';

const renderer = new WebGPURenderer();
await renderer.init();

const runner = await createTSLRunner(
  'https://huggingface.co/HuggingFaceTB/SmolLM2-135M/resolve/main/',
);

const result = await runner.generate(renderer, 'Once upon a time,', {
  maxNewTokens: 64,
  temperature: 0.7,
  topK: 10,
  onToken: (text) => console.log(text),
});

Before the transformer

The central operation remains: y = Wx + b

An LLM owns many matrices containing learned weights. Inference repeatedly multiplies vectors by those matrices, applies a few nonlinear functions, and moves information between token positions. A transformer gives those operations a particular structure.

What happens when an LLM generates one token

The full loop has six parts:

1. A tokenizer converts text into a sequence of integer token IDs.
2. An embedding table turns each ID into a vector.
3. A stack of transformer blocks updates that vector using the current token and the preceding context.
4. A final matrix projection produces one score, called a logit, for every token in the vocabulary.
5. A sampling rule chooses one token from those scores.
6. The model appends that token and runs again.

The model generates a sentence one token at a time. It predicts a token, adds it to the context, and repeats until it selects a stop token or reaches a limit.

Processing the supplied prompt is called prefill. Generating subsequent tokens one at a time is called decode. These two phases run the same model but have different performance characteristics. Prefill has many known input tokens that a specialized implementation can process together. Decode has only one new token per step and must repeatedly read most of the model's weights.

GPT-2, one block at a time

GPT-2 first applies byte-level Byte Pair Encoding to the input. BPE repeatedly combines frequent adjacent symbols, giving the model a fixed vocabulary that can still represent any input text.

Each resulting token ID selects a row from a learned token-embedding table. GPT-2 adds a second learned embedding for the token's position in the sequence. The sum is the first vector sent through the transformer.

Every GPT-2 block then runs this sequence:

1. Layer normalization
2. Causal multi-head self-attention
3. A residual addition
4. A second layer normalization
5. A two-layer MLP using the GELU activation
6. Another residual addition

Residual connections add each block's result back to its input. They let later blocks refine a representation without requiring every block to rebuild it.

After the last block, GPT-2 applies one more normalization and projects the result to the vocabulary. If the vocabulary contains 50,257 tokens, that projection returns 50,257 logits. The sampler turns those scores into the next token ID.

Attention is a lookup built from the current context

Self-attention lets the current token retrieve information from earlier tokens. Each block projects its input into three vectors for every attention head:

• A query describes what the current position is looking for.
• A key describes what each position offers.
• A value contains the information retrieved from that position.

The query takes a dot product with each preceding key. Dividing by the square root of the head dimension keeps the scale stable, and softmax converts the scores into weights: Attention(Q,K,V) = softmax(QKᵀ / √d)V

A causal mask excludes future positions. During generation there are no future tokens yet, but the same rule lets prompt tokens attend only to text that precedes them.

Recomputing every earlier key and value for every generated token would waste most of the work. A KV cache stores them after their first computation. Each decode step writes one new key and value, then compares the new query against the cached keys. The cache grows with context length and becomes an important memory and bandwidth cost.

Expressing the model as TSL compute

Three-LLM represents each model operation as a small TSL compute kernel. A runner connects those kernels in the order required by the model recipe.

One GPU invocation owns one output element and loops across the input vector:

return Fn(() => {
  const outputIndex = instanceIndex.toVar('outputIndex');

  If(outputIndex.lessThan(uint(outputSize)), () => {
    const sum = biasNode.element(outputIndex).toVar('sum');

    Loop(
      { start: uint(0), end: uint(inputSize), type: 'uint', condition: '<' },
      ({ i }) => {
        const weightIndex = i.mul(uint(outputSize)).add(outputIndex);
        sum.addAssign(inputNode.element(i).mul(weightNode.element(weightIndex)));
      },
    );

    outputNode.element(outputIndex).assign(sum);
  });
})().compute(outputSize, [workgroupSize]);

Loading Hugging Face checkpoints at runtime

Three-LLM reads a Hugging Face config.json, tokenizer files, and SafeTensors weights. The configuration selects a recipe. The recipe describes the graph family, normalization, MLP type, residual layout, position encoding, head counts, and checkpoint layout. Tensor-name aliases map names into the common fields expected by the runners.

From GPT-2 to SmolLM2

SmolLM2 135M is close to GPT-2 in parameter count, but it uses the newer Llama-style decoder pattern. Four architectural changes matter to the inference implementation: RMSNorm, Rotary Position Embeddings, Grouped-Query Attention, and SwiGLU activation.

Phi changes the block layout

Phi-1.5 is a 1.3-billion-parameter model. Its inference graph differs from GPT-2 in two ways: it uses partial RoPE, and its attention and MLP branches run in parallel from the same normalized input.

Qwen3.5 needs a different kind of memory

Qwen3.5 0.8B uses a hybrid stack: three Gated DeltaNet layers for each gated full-attention layer. Full-attention layers retain a KV cache. Gated DeltaNet layers replace that growing history with fixed-size recurrent state.

Optimizations that paid off

I tested kernel rewrites, command submission, prefill behavior, readback, and model-loading changes while building the library. A few changes accounted for most of the measured gains:

• Submit a forward pass once: Recording ordered nodes into one Three.js compute call reduced 427 command submissions to one.
• Do not compute unused prompt logits: Only the final prompt token needs vocabulary logits.
• Reuse prompt prefixes: Three-LLM compares the new token sequence with the previous one and reuses the matching prefix.
• Reduce sampling on the GPU: Three-LLM can run a hierarchical maximum or small top-k reduction on the GPU to avoid synchronization points.
• Free copies once the GPU owns the weights: After Three.js creates the GPU bindings, Three-LLM releases static CPU weight arrays.

The FP32 cost

Three-LLM currently runs every GPU kernel with 32-bit floating-point storage and arithmetic. While this provides a simple baseline, it imposes a large memory and bandwidth cost compared to native FP16 or quantized weights. Future development will focus on adding FP16 support and quantized dot products.

Try it

You can run the live Three-LLM chat demo, install three-llm from npm, or read the source on GitHub.

Designing Grok Bot for a world of persistent agents

How we designed Grok Bot for agents that persist beyond a single session — from a chat history to a Bot roster, presence, a computer of the Bot’s own, and work that starts without a prompt.

When we started designing Grok Bot, one of the central questions was how the interface should shape the relationship between user and agent. Most AI interfaces are organized around a chat session the user operates. Each session begins with setup, unfolds as the user looks on, and ends when the conversation stops.

We wanted to design for an agent that persists beyond any one session and can carry responsibility on its own. That meant reconsidering some of the basic objects and signals of the interface, including what belongs in the sidebar, how an agent shows progress, and when its work should become visible.

Rethinking the primitives

AI products have accumulated a large vocabulary in a short time. Chats, sessions, models, context windows, memories, system prompts, projects, skills, connectors, agents, tools, sandboxes, permissions, and automations all describe real parts of these systems.

But exposing each one as a separate product concept asks users to understand more than they need to. We started by asking which concepts a person actually needs in order to work with an agent.

We kept coming back to five:

1. Bots are persistent agents with their own identity, memory, runtime, and tools.
2. Chats are the conversational interface for working with a Bot.
3. Prompts give a Bot context or instructions. They can be used once, saved as Skills, or triggered automatically as Routines.
4. Tools let Bots access information and take action through software, APIs, connectors, the shell, or computer use.
5. Artifacts are the documents, designs, code, data, and other durable outputs that Bots create or modify.

Everything else could remain beneath the interface until the user had a reason to care about it. The next question was which of these five objects should organize the product.

From chat history to a Bot roster

Chats are disposable. We start a conversation to solve a problem. It gets pushed down the sidebar. A week later, we start another one. You rarely go back beyond the most recent five.

That behavior is perfectly reasonable when the unit of interaction is a question. It becomes strange when the thing on the other side of the interaction is supposed to know you, remember previous work, and take responsibility over time.

So the main objects in Grok Bot are Bots, not conversations. A Bot has a name. It has an avatar and a title. It remembers its conversations with you. It has its own computer and tools. When you come back tomorrow, you are coming back to the same Bot.

Presence as interface

Once a Bot was something you maintain over time rather than a session you start, the way Bots appear in the product had to answer three questions at once:

1. Who is this?
2. What are they doing?
3. How much do I need to know?

Who is this

A roster only works if it can be scanned quickly. As the roster grows, we did not want people to have to read every name each time they opened the product. They should be able to recognize a Bot from its avatar almost peripherally.

At the same time, we wanted to keep the avatars consistent enough to read as one system. We studied character systems across illustration, animation, games, and interface design, exploring everything from initials and emojis to pixel art, watercolor, claymorphism, Noritake-style line art, silhouettes, and identicons.

The system we landed on keeps the basic construction consistent, using simple shapes and expressive eyes, then introduces distinction through controlled variations and accessories. Each Bot remains recognizable at a glance without appearing to come from a different visual world.

What are they doing

Once the avatar became the Bot’s identity, it was also the natural place to show state. A Bot may be idle, thinking, working, waiting, blocked, or done. We could have represented each state with a separate indicator, but that would have added another layer of UI for the user to interpret.

Instead, we explored how much of the lifecycle the avatar itself could carry.

At rest, the Bot is calm and slightly curious. When work arrives, it acknowledges the task. As work begins, it kicks into gear. Its motion changes again when it is waiting or needs help, then settles once the work is done. The avatar now shows what the Bot is doing as well as which Bot it is.

How much do I need to know

A related design question was how much of the Bot’s execution to show. One approach would have been the standard “three animated dots” but that would have been too little information, making it hard for users to tell whether the Bot was working or stuck.

We also tried showing a short written description of the Bot’s current action, but once people could see one step, they wanted to see the rest. User research showed us that they were asking for that detail mainly for reassurance that the Bot was still working and on the right track.

In the final design, the avatar’s motion provides the first bit of reassurance by showing that the Bot is active. If someone wants to check what it is doing, they can hover to see its current action.

Their computer, not yours

Each Bot has its own computer, which it can use to browse the web, work with files, and run software. This created another interface problem. How visible should that computer be and when should the user be able to control it?

We explored four arrangements:

• Floating window: kept the computer easy to reach but covered the conversation.
• Side by side: made the work continuously visible and encouraged users to watch it.
• Modal: made checking in easy but treated the Bot’s workspace as a temporary interruption.
• Full screen: gave the computer plenty of room but displaced the conversation entirely.

The more prominent we made the computer, the more the product encouraged users to supervise it. We decided it should remain the Bot’s workspace, with the interface providing different levels of access as the user needed them.

The final design has three levels, which allow the user to enter the Bot’s workspace without being drawn into operating it:

• Status: the title-bar icon turns purple while the computer is active.
• Preview: opening it reveals a pinned side panel where the user can follow the work without leaving the conversation.
• Takeover: when the Bot needs help, the user can open the computer full screen, take control, and then hand it back.

The shape of information

Early versions of Grok Bot responded to almost every request with prose. It described a five-day forecast instead of showing one and narrated a set of tasks instead of laying them out as a board. The user then had to restructure the answer. This led us to treat the form of a response as part of the answer.

To support this, we built inline cards and widgets into Grok Bot. A Bot can answer in prose when prose fits the information and use structured UI when it does not.

The same principle applies to actions. When a Bot creates a Routine, changes a setting, or messages another Bot, the event can appear directly in the transcript. The user can open it when there is more to inspect.

The result is a heterogeneous transcript in which conversation, system events, interactive objects, and visualizations share one timeline.

Organizing intelligence

Once people create several Bots, the product also has to organize how those Bots work together. We needed to decide which context should belong to each role, how Bots should share context when their work overlaps, and how to coordinate them without turning the user into a dispatcher.

We saw one answer emerge as people created more Bots. Some made a Chief of Staff Bot responsible for coordinating several specialists. They could give direction to one Bot instead of checking each one and routing every task themselves.

Giving Bots distinct roles also forced us to decide what each role should know. A legal Bot may need the history of an ongoing dispute, while a finance Bot may need years of financial records. Combining those histories into one large memory would make it harder to give each Bot the information relevant to its work.

Capabilities and context therefore follow different boundaries in Grok Bot. Tools and Skills live at the account level because many Bots may need to browse the web, work with documents, or send email. Memory and Routines belong to the Bot because they reflect what that particular role knows and does over time. Put another way, capabilities can be shared broadly while context remains with the role that needs it.

Work that keeps moving

Most agent sessions begin when a user sends a prompt. That leaves even a persistent Bot waiting for someone to activate it. Routines let users give a Bot a standing responsibility that runs on a schedule or in response to an event, such as watching an industry or preparing a briefing every morning. The user defines the work once, and the Routine activates the Bot when it needs to happen.

We initially treated Routines as secondary configuration. As they became more important to autonomous work, we moved them into the Bot’s main interface. The transcript shows what ran and gives the user a place to review the result or handle an exception.

This also changes the role of conversation. A prompt can start a session, but so can a schedule, an event, or another Bot. Over time, more work may begin without the user being present at all.

The disappearing interface

By the end of the project, much of the design work involved taking things away. We removed window and panel controls, computer-view options, and agent metadata. We also set practical limits of roughly 50 Bots per account and six per group chat. Each decision came back to the same question: Did this help someone delegate, or did it give them one more thing to manage?

The line between operating an AI and delegating to a coworker keeps moving as models improve. Grok Bot reflects where we think it sits today. Designing Grok Bot from its earliest explorations through launch has been about finding that line and helping the interface change with it. As agents take on more responsibility, the interface should ask less of the person.

How Zoom Detects Google Meet Without Microphone Access

Zoom uses macOS Control Center logs and Windows microphone privacy records to detect when other applications use the microphone.

TL;DR

• Zoom can notice that Google Meet, Teams, Slack, and other applications may be in a meeting and offer to start My Notes
• On macOS, Zoom monitors Control Center’s sensor-indicators log stream
• The messages contain records such as [mic] Google Chrome (com.google.Chrome)
• Zoom extracts an application identity and detects when microphone use starts or stops
• On Windows, it obtains equivalent application-usage information from the per-user Capability Access Manager microphone records in the registry
• Reading this metadata requires neither administrator/root privileges nor Zoom microphone permission

Why does Zoom know that Chrome is using the microphone?

Zoom’s My Notes feature can take notes during meetings hosted in applications such as Google Meet, Microsoft Teams, and Slack. Before the user starts it, Zoom can display a Take Note prompt when it thinks a third-party meeting is in progress.

That raised an interesting question: how does Zoom recognize the other application before it has started taking notes?

The answer differs by platform. On macOS, Zoom parses human-readable Unified Logging output. On Windows, it enumerates microphone-usage records in the registry.

The macOS detector

I statically analyzed the arm64 build of Zoom Workplace 7.1.5 (84650).

The implementation is in a class named PrivacyEventMonitor inside viper.framework. Its relevant methods are:

-[PrivacyEventMonitor startMonitoring]
-[PrivacyEventMonitor handleLogOutput:]
-[PrivacyEventMonitor parseSystemLogLine:]
-[PrivacyEventMonitor parseAttributionsStringForMicrophone:]
-[PrivacyEventMonitor notifyMacAppStateChange:previousStates:]

startMonitoring launches /usr/bin/log:

/usr/bin/log stream \
  --type log \
  --level default \
  --predicate 'subsystem == "com.apple.controlcenter" AND category == "sensor-indicators"' \
  --style compact

macOS Control Center maintains the orange and green privacy indicators for microphone and camera use. The same subsystem writes the currently responsible applications to Unified Logging. A microphone record for Chrome looks like:

Sorted active attributions from SystemStatus update: [mic] Google Chrome (com.google.Chrome)

macOS has already supplied the display name and bundle ID. Zoom keeps entries marked [mic], parses those two fields, and compares each new attribution list with the previous one. An application appearing or disappearing becomes a microphone-start or microphone-stop event; no audio analysis is involved.

From Chrome to Google Meet

The UI layer contains a product category named chrome, labels it Google Meet, and applies notification and per-application blacklist settings. The overall flow is:

Chrome opens the microphone
  -> macOS updates Control Center's sensor attribution
  -> Control Center emits a sensor-indicators log record
  -> Zoom extracts “Google Chrome” and “com.google.Chrome”
  -> Zoom detects an application-state transition
  -> product mapping and notification policy
  -> optional “Take Note” prompt

This is more accurately called microphone-use detection than meeting detection. Chrome could be accessing the microphone for a reason unrelated to Google Meet. Zoom’s higher layers decide whether the signal should produce a prompt.

The Windows detector

I also statically analyzed Zoom Workplace for Windows x64 7.1.8.46825. Its detector is in viper_async_device.dll and reads this per-user registry key:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\
CapabilityAccessManager\ConsentStore\microphone

Zoom opens the key with KEY_READ, enumerates packaged application entries and the NonPackaged subtree used by classic desktop applications, and queries each entry’s 64-bit LastUsedTimeStop value. A zero value represents an access interval that has not ended, so Zoom treats that application as currently using the microphone.

The Windows flow is therefore:

Chrome opens the microphone
  -> Windows updates ConsentStore\microphone\NonPackaged
  -> LastUsedTimeStop remains zero while access is active
  -> Zoom enumerates the registry records
  -> Zoom identifies Chrome's executable
  -> product mapping and notification policy
  -> optional “Take Note” prompt

This part uses ordinary registry APIs. I found no ETW consumer, audio-session observer, or PCM processing in the application-attribution routine. Static analysis does not establish its polling interval, the feature flags controlling it, or whether detection metadata is included in telemetry.

Does this require permission?

I tested Zoom’s exact /usr/bin/log stream predicate as an ordinary user, without sudo, and macOS accepted it. Reading the records did not require Microphone, Screen Recording, System Audio Recording, or Accessibility permission.

On Windows, the key is under HKEY_CURRENT_USER and Zoom requests only KEY_READ, so it likewise requires neither elevation nor microphone access.

Neither mechanism should be treated as a stable application API. Zoom depends on undocumented macOS log formatting and Windows registry implementation details that either operating-system vendor could change.

It is a clever use of privacy bookkeeping that both operating systems already expose—and a reminder that privacy indicators can themselves become a source of cross-application activity information.

Microsoft released MAI-Transcribe-2, a speech recognition model with diarization, configurable transcription styles, and word-level timestamps that it says beats Gemini 3.5 Transcribe, GPT-Transcribe, and Whisper V3-Large.

Grok Bot for Enterprise

Grok Bot is now available for enterprises. Grok and Cursor Enterprise customers have free usage for the next two weeks, and can invite their whole organization, including people without an existing seat.

Grok Bot is your team of helpful AI teammates. You delegate real tasks to them and they carry the job through end to end, working autonomously around the clock inside the same tools you use.

Enterprises need the ability to govern Bots at scale and today's release adds access, network, and audit controls that make that possible.

A Bot for every job

A Bot is a worker you create inside Grok Bot for a specific job. Each Bot runs on its own computer in the cloud and can use every app and website the same way you do. You message a Bot like a coworker, and it comes back when the work is done or it needs a decision from you.

You'll usually manage several Bots for different jobs and each runs independently. To teach a Bot a workflow, have it follow along once. It saves the routine, takes your corrections, and runs it on its own from then on. When you've built a Bot that works well, you can hand it to the person next to you as a template. Bots can also message each other and share context, so you're not having to pass context between them.

How customers use Grok Bot

Thousands of organizations have adopted Grok Bot since launch, including customers like Legora, Supermicro, and ServiceTitan. These teams use Grok Bot every day, and the heaviest use is outside engineering. Here are a few popular examples of the millions of bots created in the past few weeks:

Sales. Bots can watch webinars and podcasts by people at target accounts, then leave LinkedIn and email drafts for morning review. During a call, a Bot updates the deck from live notes so next steps are on the slide even before the meeting is over.

Recruiting. A Bot prospects overnight and builds a morning shortlist with outreach queued for review. It texts candidates good luck before they walk in, and after interviews it submits scorecards from that day's Gong calls.

Marketing. After a webinar, a Bot pulls the Zoom Q&A and sends Slack messages to the AEs whose customers showed up. The messages include notes on the questions the customer asked as well as draft replies.

Finance. A specialized procurement Bot monitors vendor spend, usage, and renewals, then finds places to cut costs or negotiate better terms. It has surfaced tens of thousands of dollars in savings across SaaS, recurring purchases, and vendor services.

Engineering. Bots monitor PRs for bugs, security findings, failing builds, and merge conflicts, then keep every task moving until it's ready for review. Overnight audits improve code quality, performance, and security, giving engineers more time for the hardest problems.

Secure by default

Each user's work in Grok Bot runs in its own secure and isolated environment, separate from every other user. A Bot has no access by default and reaches only the accounts you sign it into.

Free for Enterprise for the next 2 weeks

Grok and Cursor Enterprise customers get Grok Bot free for the next two weeks and can invite their whole organization, including people without an existing seat.

OpenAI's GPT-6 Astra on ARC-AGI-3

Summary

• GPT-6 Astra scores 62.7% for $26K on ARC-AGI-3 Semi-Private with our Standard harness, and 99.9% for $19K with a Provider Adapter harness.
• GPT-6 Astra surpasses the human baseline in action efficiency on ARC-AGI-3. It used fewer actions than the median tested human on 96% of levels.
• A key behavior observed in GPT-6 Astra was its ability to turn unfamiliar environments into compact symbolic world models. It represented game mechanics as logical rules and developed its own domain-specific language shorthand to track state and plan actions.

ARC-AGI-3

ARC-AGI-3 is a benchmark for studying agentic intelligence through novel, abstract, turn-based environments. Agents must explore, infer goals, and build internal models of environments to effectively plan actions without explicit instructions.

These environments only contain core knowledge priors and are difficulty-calibrated through controlled testing with human participants. Humans can solve 100% of the environments.

The goal of the ARC-AGI series is to measure the “residual gap” between current artificial intelligence and AGI. We define AGI as a system’s ability to acquire any skill a human can, as efficiently as a human can.

ARC-AGI-3 is the third generation of the ARC-AGI benchmark series. It tests agentic capabilities beyond ARC-AGI-1 and ARC-AGI-2. Each generation expands on the one before it - as frontier AI capabilities advance, our benchmarks must advance with them.

ARC-AGI-3 tests four components of agentic intelligence:

• Exploration: In real-world environments, information is rarely provided passively. Agents must actively obtain it by interacting with their surroundings.
• Modeling: Agents must turn raw observations into a generalizable model that can predict future states and outcomes.
• Goal-setting: Agents must identify target future states with only sparse rewards.
• Planning and execution: Agents must map a path from their current state to a goal, course correcting as new information appears.

Astra Results

With our Standard harness, OpenAI’s Astra (max) scores 62.7% on ARC-AGI-3 Semi-Private for $26K. With the Provider Adapter harness, Astra (high) scores 99.9% for $19K. Both are state-of-the-art scores.

For a cost comparison, during our controlled testing, human participants were paid $115 per 90-minute session, plus $5 per game completed. Participants attempted approximately nine games per session, roughly $12.78 per attempted game before bonuses.

Most of this fee pays for the participant’s time and willingness to take the test, rather than the energy their brain uses. If we look at only the brain’s energy, and price it as electricity, the estimate drops to about 0.6 cents per session, or 0.067 cents per game attempted.

Analysis

Beyond the scores, Astra’s replays show how it turns unfamiliar game mechanics into useful working models. Three findings stood out: the compact algebraic notation it develops, its action efficiency compared with humans, and the custom tools it builds.

Custom Algebraic Notation

When playing ARC-AGI-3, Astra chooses which strategy notes it would like to carry forward. It tracked objects, coordinates, rules, and unfinished plans, while also using a custom domain-specific language notation it generated for the environments.

Astra’s notes stood out for their precision and information density. It distilled the scene into a compact code-like symbolic model: where objects were, how they interacted, and exactly which actions needed to happen in what order. This is an on-the-fly algebraic shorthand rather than a fully fledged programming language. For example:

• Game state: L8: hub q2 (8↓). Lengths: 14=1… records the level, a local rotation index, and mechanism lengths.
• Multi-step plans: extend8 to3; retract10 to2; shorten8 to1 records an ordered sequence of changes to the color-8 and color-10 mechanisms.
• Controls and coordinates: 9−=(39,4), rotate=(49,18), 14+=(59,11) maps operations to the coordinates of the controls that perform them.
• Time and position: Turn 5: P=(24,20), empty, facing west combines a turn counter with the player’s location, carrying state, and orientation.

Action Efficiency Compared to Humans

Before launching ARC-AGI-3, we tested approximately 500 members of the general public to establish a human baseline for action efficiency. For each level, we defined the “human baseline” using the median action count among players who completed it.

In the Provider Adapter harness, Astra (max) used fewer actions than the human baseline on 96.0% of levels and used 51.7% fewer actions per level on average. This is a material milestone. This means by ARC-AGI-3’s measure of action efficiency, Astra matched and surpassed human parity.

Astra’s results show that it needed fewer interactions than the human baseline to execute a solution.

Custom Tools in Agent Harness

We also evaluated Astra in the PRO-LONG harness, an early ARC-AGI-3 red-teaming partner. In this advanced setup, Astra had access to a sandbox where it could execute custom code. We observed Astra create a custom set of tools for each game: board parsers, game-state models, search algorithms, planners, and persistent notes. For more involved runs, Astra even produced small, game-specific software libraries.

Two Harnesses, Two Questions

Our Standard harness for ARC-AGI-3 asks how models compare under the same minimal, provider-neutral interface. Alternatively, the Provider Adapter harness asks how well a model performs when it can use the context-management features its provider designed for it.

With the Provider Adapter harness, Astra's best observed score on ARC-AGI-3 Semi-Private increased from 62.7% to 99.9%. Looking across Public and Semi-Private and all reasoning levels, Provider Adapter runs were approximately 3.66x faster by aggregate recorded elapsed time and used 49% fewer total tokens across the 167 game-reasoning pairs both harnesses solved.

ARC-AGI Series

ARC-AGI-3 continues to be a useful playground for researchers and agents to explore unfamiliar environments, discover rules, and learn through interaction. Astra’s results are also a major milestone worth celebrating. From our perspective, Astra represents a noticeable step-function change in frontier model capabilities.

While we believe Astra represents meaningful progress towards generalization, we are not claiming that it is AGI. The ARC-AGI benchmark series is designed to evolve in tandem with frontier AI. Astra’s progress helps clarify which AI capabilities are out of reach and which questions remain open.

Thank you to François Chollet, Mike Knoop, Matt Mazur, Ethan Bond, and Derek Smith for early review of this post.

1. Assuming 20 W of brain metabolic power and an electricity price of $0.20/kWh: 0.020 kW × 1.5 hours = 0.030 kWh, worth $0.006 per session, or $0.006 ÷ 9 ≈ $0.00067 per attempted game.
2. See the ARC-AGI-3 human testing paper.
3. No evidence of trying to break out of the sandbox was observed.

A MATS researcher found that a synthetic transcript generation prompt could be turned into a universal jailbreak template that hit 84-100% attack success on the nine most vulnerable of 23 models tested, with only recent Anthropic models and Meta Muse Spark 1.1 never fully broken.

MAI-Transcribe-2 is a speech-recognition model that Microsoft says is faster, more accurate, and cheaper than anything its competitors currently sell. It is priced at 10 cents per hour of audio. The model transcribes audio in 60 languages. Microsoft's strategy seems to be to build its own frontier-class models one modality at a time, then steadily swap them into products that once ran on OpenAI's technology.

funes introduces a durable memory layer for coding agents that allows them to retain and recall session histories across different machines and agents like Claude Code, Codex, pi, and Hermes. It enables contextual memory storage and retrieval without external dependencies, using local indexing and embedding.

The Incumbents Are Coming

The bullish case for incumbent systems of record is that AI makes systems of record get more important, not less. Why? Because in theory the customer can now pipe the system’s data into Claude or Codex and skip the AI-native app.

As agents do more work through these systems, the data and actions they control become more valuable. An incumbent system of record plus a general agent (or an agent built by the incumbent) therefore might be enough to get the work done. This is what Salesforce just announced in partnership with Anthropic: Claudeforce lets you work with the Salesforce CRM from inside Claude without having to open Salesforce (or so they claim!).

The argument is partly correct. The incumbents aren’t sitting idly.

The incumbents have an incentive to control and charge for access to their data, and now to push their own agents forward too. We’re already seeing incumbents market products that move from simply storing information toward doing more of the work itself. Docusign’s Iris reviews contracts, Atlassian’s Rovo aims to resolve and route requests, and Klaviyo’s Composer builds campaigns and assesses marketing performance. These products move incumbents beyond the “slap on a chatbot” strategy and into taking action.

At the same time, Claude is starting to coordinate work across applications, making it possible for general-purpose agents to act as a layer above the incumbents. Claudeforce shows what that can look like: Claude can become the front door to the job while Salesforce still controls the underlying CRM data and actions. The interface and the system of record look like they're unbundling, creating an opening for AI-native startups to rebundle around the job.

So where can startups still compete?

The vertical AI-native company has to win through focus. It has to perform a specific cross-system job better than an incumbent’s purpose-built agent or a general-purpose agent like Claude, which will be able to reconstruct it from the underlying tools. Focus can earn the vertical startup deeper access, a deliberate data asset, more specific context, and a learning loop that builds a better understanding over time of what good work looks like for a given job.

The agent hierarchy

To see where incumbents are strongest and where vertical AI companies may have an advantage, it’s helpful to think about the four types of application-level agents, distinguished by how much autonomy and judgment each requires.

• Retrieval assistants find information, summarize documents, answer questions, and draft responses.
• Process agents carry out rule-based work like updating records or routing approvals, using limited judgment to interpret the task, and act.
• Policy agents apply the rules in an organization’s playbooks, precedents, and thresholds to ambiguous cases.
• Principal agents make judgment calls about what the organization should do, often with open-ended tradeoffs around strategy, risk, and resources.

A year ago, most incumbents’ AI products were still at the retrieval stage, if that. They functioned mostly as chatbots and analytical tools pulling from existing records. Now, more can take action based on the workflows, permissions, and rules already embedded in their products. A few are beginning to apply narrow, human-defined policy. Judgment gets harder when the decision depends on information outside the record that the incumbent manages.

The broad shift we’re seeing is incumbents moving up the hierarchy, from retrieval and process toward more judgment through policy, like Docusign’s Iris applying a legal team’s playbook. But that judgment is still largely bounded by the record the incumbent owns.

The job is bigger than the record

An incumbent can automate more of the work around its core record, but the customer’s job to be done is bigger than the record. This isn’t a hard technical boundary because incumbents can pull in outside data and add workflows, but their work still expands outward from the record they already own.

A customer’s work gets done through a combination of its people, processes and software. The contract is not the legal matter, the ticket is not the customer’s resolution, and the opportunity is not the sale. The full job crosses applications, teams, and even companies. Different parties may hold different information, and want different outcomes. The incumbent is limited to building a “local system of work” but the larger opportunity is to manage the job across boundaries, including all of the parties, the people, the documents, decisions, revisions, and the final result.

A general purpose agent like Claude or Codex may be able to reach across all these systems, but access alone doesn’t mean it can perform the job well. Even using MCP, pulling info across applications has latency, and each application may describe the same customer, contract, or transaction differently. Even if a general purpose agent can access every app in one company, it doesn’t automatically have access to information held by external parties (e.g. between buyers and suppliers).

Even with these limitations, Claude can still sit above systems of record. Claudeforce makes Claude the front door to the job while Salesforce still owns the CRM data and actions. And Claude can keep gaining context through deeper integrations blessed by the incumbents.

How vertical AI learns

Owning more of the job matters because it lets startups see the decisions and corrections that produced the final result. A model performs better on a specific job via a vertical harness with the right context, tools, workflows and with the right evals. The harness makes the learning loop possible. The learning loop is what improves the system - the model + harness - after each job, using the agent’s work, expert feedback, and outcomes themselves to improve the next attempt.

Completed records alone don’t automatically suffice as a training curriculum for the work. A signed contract shows what the parties agreed to, but not every alternative considered or every reason for an exception. A closed ticket shows the resolution, but not every hypothesis the support team tested.

Remembering vs. learning

The labs are also building general-purpose memory, so preserving context alone is not a durable advantage. Remembering and learning are different. Memory can help a general purpose agent recall a customer’s preferences or a decision made last week. But it doesn’t tell the agent whether the work was good or why an expert changed it or what to change next time. Focus lets the company see more examples of the same job, learn faster, and get better at measuring improvement.

Profession and institution

There are two kinds of learning:

Learning how a good professional does the work. A company can begin teaching that with assignments created by experts, realistic examples, and standards for a good result.

Learning how a particular firm or customer does the work, including its templates and precedents, risk thresholds and escalation rules. That can begin with the customer’s existing materials and improve through corrections and exceptions in the training process. Some lessons about the profession can improve the product for every customer, but lessons about one firm may just improve the product only for that firm.

To learn both the profession and the institution, the startup doesn’t need to start with the largest stock of historical data. It can manufacture a curriculum for the profession, then use production to learn the institution. As open-weight models and post-training increase, assembling the right data and evals becomes even more important.

Long running agents especially benefit from learning loops. When an agent does work over hours or days, through a complex logic chain with many intermediate decisions and handoffs, the quality of the learning loop matters even more. The longer horizon task can be unbundled and evaluated through a set of checkpoints.

To be clear, incumbents will also learn from the work performed inside their products. But that learning will cover only their part of the job: the contract review inside Docusign, the ticket resolution inside Jira, or the pipeline update inside Salesforce.

How Harvey manufactured the curriculum

Harvey’s work on Tenet shows what the path for vertical AI can look like. Harvey post-trained an open-weight model using synthetic data, public legal data, and human-expert created data, without using customer data to start. It created roughly 1,750 legal-task environments, each simulating a partner-assigned matter, complete with documents and tools and an expert rubric for a high-quality result. The average assignment had about 50 specific criteria. Instead of waiting years to accumulate enough customer history, Harvey manufactured a curriculum it could use to train and evaluate its model.

Harvey’s broader work also shows how a vertical company can train a model for different parts of the job, including industry-specific capabilities like M&A diligence and understanding a firm’s total knowledge.

The startup’s opportunity is to put it all together. Vertical specificity helps the startup to break the work into specific capabilities, tackle the practical frictions around data rights, systems, and permissioning, and fits the product into the customer’s daily work. Eventually, it can feel comfortable taking responsibility for the result. Deployment and responsibility are key here!

What makes a good vertical AI market?

Using Harvey as one example, here are a few axes for evaluating potential vertical AI markets:

• Can an expert quickly tell what the AI got right or wrong, and explain how to improve it?
• Is the work hard enough that judgment matters (vs. simple rules)?
• Does the work happen often enough for the product to learn?
• Can the startup begin with one assignment and grow into doing an entire job?

The strongest vertical AI markets tend to meet all four, giving them a strong learning loop. Many workflows in legal, tax, and accounting meet this test because the work repeats, requires judgment, and experts already review the results. This pattern also shows up in less obvious markets like industrial work. When a manufacturing defect appears, a quality engineer has to gather test results, supplier documents, equipment logs, and the plant rules, then decide what’s acceptable and what needs to change. That information may sit across several systems. One incumbent may store the defect report, but no single product owns the full investigation. A startup could begin with one piece of this work (e.g. drafting the investigation report) and over time own the end-to-end resolution. To do this, it would need to learn both how a good quality engineer investigates a problem and how a particular plant or customer or auditor does it well.

The job is still up for grabs

There are jobs where a system of record plus a general-purpose agent will be enough, but there’s still meaningful opportunity for vertical AI-native startups! The strongest vertical opportunities exist where the work happens often, expert judgment matters, and the learning loop is strong. The incumbent may own the record and the lab may control the front door, but the vertical AI company can still win by becoming the best at doing the job itself.

NVIDIA PAIR connects AI app and agent workflows to a single local endpoint for routing inference across NVIDIA DGX Spark, Windows systems with RTX, and macOS devices.

Models on Cerebras public endpoints are available on the free trial and pay-as-you-go tiers, subject to rate limits and pricing. For additional model families, reserved capacity, higher throughput, and production SLAs, see Dedicated Endpoints. New here? Follow the Quickstart to make your first API call. To pick a model by use case, see the model selection guide. Select any model name below for full specs, capabilities, and per-tier limits.

Available Models

Looking for more models? Many additional model families are available through Dedicated Endpoints.

Model Compression

This section provides transparency about the compression state of each model available on our platform. We host a variety of open-source models from the community. We do not currently host pruned models on our public endpoints. All models served through our public endpoints are the original, unpruned versions. While we conduct research on pruning techniques like REAP (Router-weighted Expert Activation Pruning), these pruned models are shared with the research community on Hugging Face but are not available through our shared API. You can read more about REAP in our research blog. All of our public models are unpruned.

Cerebras uses selective weight-only quantization only during storage to preserve maximal quality. This means that the weights are stored in partial 16-bit / 8-bit / 4-bit, in-line with industry standards. For quality, sensitive layers are stored at full precision with dequantization on the fly, so operations are done in high precision. The activations, attention, and kv cache remain in full precision and unquantized.

Frequently Asked Questions

Will you change a model's architecture without notice?

No. We are committed to serving the original models for all existing endpoints, without modification. We do not alter model architectures via pruning on our hosted portfolio. If we explore additional compression techniques (like pruning) in the future, these would be offered as separate endpoints with pruning-specific names, ensuring complete transparency and allowing you to choose which version best fits your needs.

Where can I find your REAP pruned models?

Our REAP pruned models are available on Hugging Face for research and experimentation purposes: Cerebras REAP Collection. These models demonstrate our pruning research but are not served through our production API.

What are compression, quantization, and pruning?

Compression is an umbrella term for techniques that reduce model size or computational requirements. Common compression techniques include:

• Quantization: Reducing the precision of numbers used to represent model weights (e.g., converting from FP16 to FP8). This reduces memory usage without changing the model’s architecture.
• Pruning: Permanently removing parts of a model, like layers or experts, to reduce model size. This changes the model’s architecture and creates a different model.

“Design engineer” is a fairly new job title, and there isn’t a definition everyone agrees on yet. Ask a few people and you get a few different answers. A designer who can code. A frontend developer with an eye for detail. Someone who sits somewhere between design and development, whatever that means in practice.

None of those are wrong. They’re just descriptions of a person, and I don’t think a person is the interesting part. The role is: there is a specific set of tasks that has to be done in every digital product, and on most teams nobody is responsible for them.

Consistency is more important than ever

When writing code stops being the bottleneck, coherence becomes the bottleneck.

Most of this work happens on products that already exist. Not all of it, but most: something that has been running for a few years, with a backlog, a team that has changed twice, and a codebase nobody has read all of. New products get there faster than they used to. A couple of months in, and there is already a history to be consistent with.

What changed is the pace. When a change took a while to build, that time did some of the work for you, because to extend something you had to go and look at what was already there. Generated code skips that step. It reads well, it looks right, and it tends to know nothing about what sits next to it. Every new feature makes sense on its own, and so does every small change inside one. That’s the problem. Nothing is wrong anywhere in particular, and the product still falls apart.

So you get four kinds of button, three date formats and two competing ideas about what the color blue means. Spacing that is close but not the same. A panel that slides in on one page and fades in on the next, because two different people, or two different prompts, each made a reasonable choice.

Mechanical engineers have a name for this. A tolerance stack-up is when every part in an assembly is within spec and the whole thing still doesn’t fit, because all the small allowances happened to lean the same way. Nobody made a mistake. It just adds up.

This is what a design system is for, and I think it usually gets explained badly. People picture a component library, which is only one of the parts. In practice it’s a set of tools and methods that have to work together: the components, design tokens, written guidelines, and now the context files and agent skills that tell the AI writing the code what the rules already are. That list keeps changing, and keeping it current is part of the job. Together they do two things. They give guidance where somebody has to make a decision, and they put guardrails around the decisions that get made without anyone noticing. That’s how consistency survives any single person on the team and any single prompt.

Consistency isn’t something a team can own as a group. You can ask everyone to care about it, and everyone can care about it, and the product will still drift (see tolerance stack-up). It’s a job. And from my point of view a job for a designated design engineer.

Details make a product a good product

The product is the source of truth, not the design files.

Consistency is not the only aspect of a good product. You can build a product where every button matches, every spacing value comes from the same scale, nothing contradicts anything, and the whole thing is still lifeless and unpleasant to use. Coherence is the foundation and the role as a design engineer doesn’t stop here.

This is the part people feel: animations, transitions, and the microinteractions that tell you an app noticed what you did. A button reacts when you press it. A menu grows out of the thing you tapped instead of appearing from nowhere, and a message tells you your work was saved.

None of it comes for free. By default a screen jumps straight from one state to the next. A door in the real world swings open, it doesn’t teleport, and getting that same feeling on a screen takes somebody deciding to build it.

The same goes for everything a design file leaves out. A file shows a product at its best. One screen width, plausible data that someone made up, and the path where everything goes right. Shipping that same screen means answering a much longer list of questions. What happens with a name that’s sixty characters long? Does the layout jump around when the data finally loads? What if there is no data at all, and is that an empty state or does it look like something broke? What about a slow connection, a narrow phone, someone who never touches a mouse? More and more often there is no design file to begin with. A feature goes from a sentence to something running, and all of those questions still arrive at once, with nobody having thought about them first.

They get answered either way. Usually by whoever is holding the code at the time, near the end of a sprint, in the fastest way available. Which is fair enough. It was never really their call to make. It should be the call of a design engineer.

Two definitions of done

Designers and developers look at the same work from different places. Both have a definition of “done”, and the two definitions aren’t the same.

Done, for a developer: it works, it’s tested, it’s fast, it didn’t break anything else. Done, for a designer: it behaves the way it was meant to behave and it looks good.

They don’t use the same words either. The same feature gets described twice, in two vocabularies, and both descriptions are right.

What helps is somebody who speaks both. Somebody who knows what each side worries about and what each side judges the work by, and who can give the two of them a shared vocabulary to work in.

One more thing I’ve noticed, and can’t explain. The craft you came from first seems to stick to you. A developer who gets good at design is called well-rounded. A designer who learns to build gets asked whether they can really engineer. Same skills, opposite reaction. I don’t know why that difference gets made, or whether it goes away as more people end up doing both.

And then there’s taste, which is a horrible word

It sounds like snobbery. It sounds like someone in an expensive chair explaining why the thing you like is bad. I’ve been looking for a better word for a while and haven’t found one, so I’m going to use this one and try to be precise about what I mean by it.

Taste isn’t knowing what’s good. Most people know what’s good. Taste is what you do when there are ten options in front of you and all of them are acceptable. It’s being able to say no to something that is fine.

It’s also the part of consistency you can’t write down. A rule can say that every dialog closes the same way. It can’t tell you that the one deleting someone’s work should be slower, or heavier, or ask twice. Every good product breaks its own rules somewhere, and no rule can tell you where.

Think about two apps that do exactly the same thing, where one of them feels noticeably better and you can’t explain why. You can’t point at the feature responsible, because there isn’t one. It’s the sum of a few hundred small decisions, none of which would survive being written down as a requirement. That’s the awkward thing about this part of the work: people register it reliably and can rarely name it, which makes it hard to argue for and easy to cut.

I think this is the part that’s becoming more valuable, though not quite for the reason people usually give. Producing something that looks like a working interface has been getting cheaper for a long time and continues to. Design is worth no less for it. The difficulty has just moved. When making things is cheap, the expensive skill is choosing: deciding which of the ten acceptable versions ships, and being willing to throw away nine that would have been fine.

Conclusion

So, a definition. A design engineer is the person who owns whether a product still agrees with itself. In a design file, everything agrees. In a component library, everything agrees. You only find out in the running product, where the pieces sit next to each other. And part of the job is knowing which patterns to break.

I don’t think that has to be a job title. If your team already has someone doing this work without a name for it, that’s the good outcome, and the label would just be paperwork. The title is only useful because it makes the work visible enough to plan for and to hire for.

I also don’t think anyone holds all of this at the same level. The people who describe this role well tend to be describing a team, not a person.

Keeping a product coherent is the part that gets talked about. The harder half is deciding what’s worth being coherent about. Ask me again in two years and I’ll probably have rewritten all of this.

No-build Tailwind.

Get the CSS utilities you want. Nothing you don't.

Curlwind allows you to generate Tailwind stylesheets on demand to get only the CSS utilities you need. Generated stylesheets are cached indefinitely so your site stays fast.

Insert Link

Add the stylesheet tag to your site's head tag.

<!DOCTYPE html>
<html lang="en">
    <head>
        <link rel="stylesheet" href="https://cdn.curlwind.com">
    </head>
    <body>
        <!-- ... -->
    </body>
</html>

Attach Classes

Attach the 'classes' query parameter to URL receive a stylesheet with only the classes you need. Use wildcards to match multiple classes.

<link rel="stylesheet" href="https://cdn.curlwind.com?classes=p-*,m-*">

Receive Stylesheet

The generated stylesheet will contain only the classes you need.

/* output.css */
.p-0 {
    padding: 0px;
}
.p-1 {
    padding: 0.25rem;
}
/* ... */
.m-0 {
    margin: 0px;
}
.m-1 {
    margin: 0.25rem;
}
/* ... */

Generate Variants

Insert a colon (:) after the class name to generate variants.

<link rel="stylesheet" href="https://cdn.curlwind.com?classes=p-*:sm|md,m-*:hover">

Exclude Preflight

Generate stylesheets without Tailwind's Preflight CSS.

<link rel="stylesheet" href="https://cdn.curlwind.com?preflight=0">

Prefixed Utilities

Generate utility classes with a prefix.

<link rel="stylesheet" href="https://cdn.curlwind.com?prefix=tw">

Unminified CSS

Generate stylesheets unminified.

<link rel="stylesheet" href="https://cdn.curlwind.com?minify=0">

Enable Plugins

Generate stylesheets with built-in Tailwind plugins enabled.

<link rel="stylesheet" href="https://cdn.curlwind.com?plugins=forms,typography,aspect-ratio,container-queries">

In the later stages of Spec-Driven Design, designers first define a visual direction through moodboards and written style guides, then use AI agents to apply those styles to working prototypes, and finally refine the results until they match the original vision. The process emphasizes maintaining designer control: AI accelerates implementation, but human judgment remains responsible for selecting references, defining aesthetics, and ensuring quality. Refinement can happen through prompting AI, editing designs in Figma with code-linked workflows, or directly modifying code, with the goal of achieving a polished, pixel-perfect product rather than accepting AI-generated approximations.

Everyone plans for how difficult it is to build a design system that scales. Almost nobody plans for how hard it is to get people to use one.

Two Starting Points, One Solution

Almost every organization we work with starts from one of two places.

The first is a system that has stalled. It was funded and staffed. The components shipped, the documentation went up, and then product teams kept building one-off solutions anyway. The system turned into an expense with no return and a source of frustration for everyone who hoped it would be more.

The second is an organization with a system that hasn’t “officially” started yet. There’s some interest, a rough sense of scope, and usually a designer or an engineer who has been building a system for a while without anyone in leadership knowing. They want to get it right the first time.

These sound like opposites, but they’re really asking the same question: How can we ensure this system will be used?

In our experience, the answer comes down to three factors every time:

• The system must fit the organization.
• The system must fit the products it has to serve.
• The team must be equipped to sustain the system.

Tackling those three factors is the critical work, and it’s what we do. Sparkbox creates design systems that get used. We work with large organizations to build systems and the teams to sustain them.

Delivered Is Hard. Used Is Harder.

Designing a component library that holds up across a large product portfolio is difficult, technically demanding work. Getting the token architecture right. Resolving accessibility properly instead of nominally. Making decisions that won’t have to be unwound in eighteen months. Writing documentation that someone will actually read and that AI can leverage. Most organizations that try this never finish, but those who do have built something with the potential to add real value.

Delivered is an achievement, but it’s not enough.

A technically excellent system that doesn’t align with its organization, products, and team will sit unused while the company that built it wonders what went wrong.

A system that fits these three things perfectly but is poorly built will get launched, and then resented. It will never be able to provide the value that has been promised to the organization.

Both of these mistakes cost twice: once to build the system nobody used, and again to build the one that has to replace it. And then there is the loss of trust. Trust is built little by little, but can be lost in a moment. Each time a system fails makes it harder to trust that the next time will be different.

So when we say a system has to get used, we’re setting the bar to demand both technical excellence AND a good fit. That’s when it gets used, and that’s when it succeeds.

Thinking systematically about how digital experiences get created and maintained is the best way to bring value, consistency, and efficiency to your products.

There Is No Good Design System in the Abstract

There is only a system that fits this organization, these products, and this team. That’s why our work starts and ends with those three factors.

The Organization

Before we begin, we need to know how the company actually works. How do decisions get made, and by whom? Who is sponsoring the system, and how is their success defined? Where does the funding come from, and how long does it last? How do teams communicate?

We need to understand the organization’s structure, funding model, communication, and culture.

All of this changes our work in concrete ways. An organization where one VP can mandate adoption needs a different system (and a very different rollout!) than a federated one where a dozen product teams have their own roadmaps. The first can afford to be opinionated early. The second has to earn its way in, little by little, with governance that makes contributing genuinely easy rather than theoretically possible. The components might end up looking similar, but the engagement is completely different.

There is no one set way to roll out these changes, only ones that fit the organization. How much documentation is the right amount depends on how this organization learns. How strict the contribution model should be depends on how much review capacity actually exists. How fast to move depends on whether the sponsor has twelve months of political cover or four.

The System and the Products

Most organizations have at least the seeds (or sometimes the remnants) of a design system. Grassroots efforts in disparate corners of the company. A sanctioned system that was funded and staffed but never took off. Patterns inside a single product team that could have become a system but never spread.

We start with what’s there. We look at the tooling across design and engineering, the taxonomy and information architecture (or the absence of one), and the technology and design decisions that have already been made. A design system exists to serve product teams, not the other way around, so we need to understand which products will consume it, how they’re built, what constraints they carry, and which of them have deadlines that make adoption harder than the efficiency it brings. All of that helps determine whether the system gets used.

Sometimes the right answer is a small, well-built system that covers the basics everyone actually uses. Sometimes it’s a migration path that lets a team adopt in pieces instead of all at once. Sometimes the most valuable thing we can do is fix the documentation so everything after it gets easier. Understanding how the system aligns with the products it serves is a critical part of whether it succeeds.

The Team

A design system is only as durable as the team behind it, and the design system team is a moving target. The people you need today probably aren’t the people you need two years from now, as the system matures and the skills it demands shift.

Do the people responsible for the system have the authority to make decisions about it? Responsibility without authority is the most common arrangement, and can be the most damaging. How big is the design system team, and how big does it need to be, now and in the future? What skills are there, and which ones are missing? How ready are the contributors on the product teams, and how comfortable is everyone with the tools, including the AI tools?

A design system built to be supported by a team of six doesn’t help a two-person team. It buries them. Most systems don’t come with unlimited team members, just like they don’t come with unlimited funding, so we build for the team that will realistically own the system. That constraint ensures the work is not just great, but appropriate. Systems built to be maintained by their actual owners end up simpler, better documented, and more durable than systems that try to do too much.

Never the Same System Twice

We’ve never built the same system twice. We bring strong opinions, proven practices, and years of pattern recognition into every engagement, but each system we build is unique because each one has to fit an organization, a set of products, and a team that exists nowhere else.

The value we create for our clients is always different based on their needs and unique circumstances. That has been at the heart of Sparkbox since the beginning. It’s what brought me and my co-founders together over 17 years ago, and it’s the same belief that shapes every system we build today. Thinking systematically about how digital experiences get created and maintained is the best way to bring value, consistency, and efficiency to your products.

The Website Design Secret Nobody Tells You (Until It's Already Cost You)

We're going to tell you something that made us genuinely uncomfortable when we first understood it. Somebody decides whether they trust you, like you, and believe you know what you're doing, before they've read a single word on your website. Not after your About page. Not after your testimonials. Before any of that. It happens in less time than it takes to blink, and once it happens, almost nothing you write afterward fully undoes it.

We didn't want to believe this at first. We wanted to believe that good writing, a strong offer, and a decent product would carry a website, and that design was just the outfit it wore. It's not the outfit. It's closer to the handshake, the tone of voice, and the first thirty seconds of a conversation, all compressed into something someone glances at for a fraction of a second on their phone while standing in line for coffee.

Your website is not judged. It's felt. And most of what people feel gets decided by things they never consciously notice.

Spacing, load time, whether a button looks clickable, whether the page seems like it was made by someone who cares. Nobody emails you to say "your line height felt untrustworthy." They just leave, and you never find out why.

We've redesigned our own site more times than we'd like to admit, watched some changes tank engagement overnight and others quietly double it, and spent way too many hours reading UX research to understand why. This is everything we learned, laid out exactly the way we wish it had been laid out for us. No jargon for the sake of sounding smart. Just what actually moves the needle.

And we want to say upfront, this isn't a "we always got it right" article. We've shipped pages we were genuinely proud of that quietly bled visitors for months before we figured out why. We've argued with each other over a button color for longer than we'd like to confess. This is less a lecture and more the notes we wish we'd had taped above our desk from day one.

Let's get into it.

The pillars of a website people actually trust

Before we go deep on any one piece, here's the full shape of it. We've broken down what actually separates a website that converts from one that just exists into the pieces that matter most. Keep this in mind as a map while we walk through each one with the real numbers behind it.

• Clarity: Obvious beats clever, every single time.
• Speed: Every extra second is a small withdrawal of trust.
• Mobile-First: Designed for a thumb, not just a mouse.
• Visual Hierarchy: The eye gets guided on purpose, not by accident.
• Consistency: One style system, used the same way everywhere.
• Accessibility: Designed for everyone, not just some people.
• Trust Signals: Real proof placed right at the moment of doubt.
• Continuous Testing: A website is never actually "done."

First impressions happen before anyone reads anything

Here's the number that changed how we think about every single page we've ever built: people form an opinion about a website in about 0.05 seconds. Fifty milliseconds. That is not enough time to read a headline, let alone a paragraph. Whatever opinion gets formed in that window is happening entirely on vibes, and those vibes come from layout, color, whitespace, and whether the whole thing looks intentional or thrown together.

And it's not a small opinion either. Research out of Stanford's Web Credibility project found that a huge share of how credible people judge a company to be comes down to the design of the site alone, not the content, not the copy, the design. Some more recent research puts the number even higher, with the overwhelming majority of first impressions being design-related before a single sentence gets processed.

We used to think this was unfair. Now we think it's just honest. Humans have always sized up rooms, people, and situations in an instant, long before language enters the picture. A website is no different. It's a room someone just walked into, and they're deciding in real time whether they feel comfortable enough to stay.

The uncomfortable part of this secret is that you don't get a second first impression. If someone forms a negative snap judgment, they're not sticking around long enough to be persuaded out of it by your copywriting. This is exactly why we stopped treating design as the last step before launch and started treating it as the first real conversation we have with a stranger.

Speed is a trust signal, not just a tech detail

For a long time, we thought page speed was an engineering concern, something for a developer to worry about while we focused on the "real" work of design and content. We were wrong, and it cost us more than we realized at the time.

Speed isn't just about convenience. It's about trust. When a page is slow, people don't think "this server must be under heavy load." They think "this feels broken," or "this feels cheap," or they don't consciously think anything at all, they just leave. Google's own research found that a huge share of visitors abandon a page if it takes longer than three seconds to load. Three seconds. Most of us have scrolled past emails slower than that.

Portent's analysis of ecommerce conversion data found that pages loading in one second convert at roughly two and a half times the rate of pages that take five seconds, and that every additional second of load time chips away at conversion rate in a way that compounds fast. Amazon reportedly found that every hundred milliseconds of added latency cost them about one percent in sales. A hundred milliseconds. That's faster than you can finish reading this sentence.

Design for the phone first, not as an afterthought

Most of the traffic hitting your website right now is not coming from a laptop. Well over half of global web traffic comes from mobile devices at this point, and depending on your audience, it can be dramatically higher than that. And yet we still see so many sites, our own early ones included, that were clearly designed on a big monitor first and then squeezed down to fit a phone as an afterthought.

The gap in performance is not subtle. Mobile bounce rates run noticeably higher than desktop bounce rates across almost every benchmark we've looked at, and mobile conversion rates tend to sit at roughly half of desktop conversion rates industry-wide. Some of that gap is intent, sure, people browsing on their phones are sometimes just killing time. But a meaningful chunk of it is friction: text too small to read comfortably, buttons too close together to tap accurately, forms that require zooming and pinching just to fill out a single field.

Clarity beats cleverness, every single time

We used to love a clever navigation menu. Hidden icons, playful labels, a hamburger menu tucked somewhere unexpected because it looked "clean." We thought clever was the same thing as good design. It is not, and we learned that the hard way by watching heatmaps of people clicking everywhere except where we wanted them to.

The websites that actually convert are almost never the cleverest ones. They're the clearest ones. A visitor should never have to think about how to find something, what a button does, or where they are on a page. The second someone has to pause and figure out your interface, you've spent trust you didn't need to spend. Clear labels beat cute ones. Obvious buttons beat artistic ones. A visible, boring "Get Started" button will outperform a beautifully designed mystery icon almost every time, because it removes a decision instead of creating one.

Consistency is what makes a site feel professional

Here's something we didn't fully appreciate until we started auditing our own older pages side by side: consistency does more to make a website feel professional than any single beautiful page ever could. If your buttons look different from page to page, if your spacing shifts, if your headings follow different rules depending on which part of the site someone happens to land on, it reads as unfinished even if every individual page looks fine in isolation.

People notice inconsistency even when they can't name what's bothering them. It shows up as a vague sense that something is "off," the same instinct that makes you double-check a suspicious email even when you can't immediately spot the fake logo. A consistent design system, the same button styles, the same spacing rules, the same type hierarchy, used everywhere, builds a kind of quiet confidence that a site was actually built with care, not assembled from spare parts over several years by several different people with different opinions.

Accessibility isn't optional, even if nobody told you that

This is the one we're most embarrassed we didn't take seriously sooner. Accessibility, designing so people with visual, motor, hearing, or cognitive differences can actually use your site, sounds like a niche technical checkbox until you realize how many people it actually affects, and how badly most of the internet is failing them.

An analysis of the top one million websites found that the overwhelming majority, something like ninety-five percent, have at least one detectable accessibility failure under basic WCAG guidelines. That's not a fringe problem. That's nearly everyone, including plenty of large, well-funded brands that should absolutely know better.

Trust signals have to be placed on purpose

Testimonials, real photos, reviews, case studies, they all matter, but where you put them matters just as much as whether you have them at all. We used to bury our best social proof at the very bottom of the page, past a huge hero section and three scrolls of copy, as if it were a reward for people who stuck around. Almost nobody stuck around long enough to see it.

Trust signals work best when they show up right before a moment of hesitation, not after it. Right before a pricing decision. Right before a signup form. Right next to a claim that sounds a little too good, backed immediately by a real name, a real photo, and a real result. Stock photography of people who look like they're paid to smile, on the other hand, tends to do the opposite of what people intend, it can quietly undercut authenticity instead of building it, because people are getting better and better at spotting generic stock imagery instantly.

A quick gut-check before you ship any new page

Before we move to the last piece of this, here's the actual checklist we run through before publishing anything now, exactly as we ask it of ourselves, no polish included.

Would a first-time visitor know what to do on this page within three seconds, without scrolling? Does this page load fast enough that we'd forgive a stranger's patience for it? Have we actually tested this on a phone, with our own thumbs, not just resized a browser window? Is there a real trust signal sitting right where someone would naturally hesitate? And if we removed every clever flourish from this page, would it still be obvious what we're asking someone to do?

Know when to bring in help

We want to be honest about something here too. For a long time we tried to do every part of our own design ourselves, partly out of stubbornness and partly because we genuinely enjoyed it. At a certain point, though, especially once a site needs to support real revenue, real customer support flows, and real growth, it stops being a hobby project and starts being infrastructure. That's usually the point where most serious brands bring in an outside website design and UX team, and honestly, that's not a failure, it's just a different phase of the same project.

UX is never finished, and the ROI proves it

Here's a number that stopped us in our tracks the first time we read it. Forrester's research has found that for every single dollar a company invests in UX, the average return is around one hundred dollars. Not ten percent. Not double. A hundred to one. Separately, McKinsey's Design Index found that companies in the top quartile for design performance posted revenue growth dramatically higher than their industry peers over a multi-year period.

Numbers like that don't happen because a company redesigned its homepage once and moved on. They happen because design and UX get treated as something you continuously test, measure, and improve, the same way you'd never write one marketing email and assume your entire email strategy was finished forever.

The whole secret, one more time

Here's what we'd tell ourselves if we could go back to the very beginning of all this. Stop treating your website like a brochure you finish once and forget about. Start treating it like the very first conversation you have with every single person who finds you, because that's exactly what it is, whether you've designed it on purpose or by accident.

Every choice, how fast it loads, how it behaves on a phone, whether the navigation makes sense without instructions, whether real trust signals show up exactly when someone needs them, adds up into a single feeling a stranger has within a fraction of a second of arriving. That feeling decides more than we ever wanted to admit for a long time.

Somewhere in your cluster there’s probably a deployment sitting in the default namespace that everyone knows shouldn’t be there. Nobody put it there maliciously, it just happened, early on, before anyone had opinions about namespace hygiene, and now half your other services quietly depend on it. Moving it is now a tricky problem.

That was the exact situation with a service I’ll call auth-svc: an authentication service that dozens of other services called constantly, sitting in default for years, and about to become a genuine problem the moment it needed namespace-scoped things, its own ingress rules, its own policies, that default structurally couldn’t give it. Moving it wasn’t optional forever. But it also couldn’t go down, not even for a few seconds. This wasn’t a vague “other services might complain” risk: auth-svc handled authentication for that entire region’s cluster, so if it went down, nobody in that region could log in. Full stop.

Before getting into why this is actually hard, it’s worth being precise about what “moving it” means. There are two completely separate paths into auth-svc, and both have to keep working throughout the move, or fixing one just creates an outage in the other. Everything inside the cluster reaches it the ordinary way: other services resolve auth-svc.default.svc.cluster.local through Kubernetes’ own internal DNS and get routed to a pod, the standard Service mechanism. Everything outside the cluster reaches it through an ingress instead, a completely separate mechanism that has nothing to do with that DNS name. Whatever the fix turned out to be, it had to solve for both paths, not just the one that’s easier to reason about.

Why “just move it” doesn’t work

The obvious plan, move the deployment, update the references, done, falls apart the moment you look at who’s actually calling this thing. As mentioned, dozens of other services reference auth-svc by its cluster-internal DNS name, owned by different teams, on different release cycles. There’s no atomic moment where you flip a switch and every one of them simultaneously starts using a new name. Some team’s service hasn’t been redeployed in months. You shouldn’t be coordinating that.

The tooling got in the way too. Our deploy pipeline only knew how to ship a service to one namespace. There was no “deploy this to two places at once” option, and modifying the shared pipeline logic every other team also depended on felt like exactly the kind of blast radius we didn’t want to introduce. Whatever the fix was, it had to fit inside a single-namespace deploy, not require rewriting shared infrastructure.

On top of that, we had an OPA policy which enforced that identical ingress rules couldn’t exist live in two namespaces at once, a sane rule that exists specifically to stop the kind of half-finished migration that leaves routing ambiguous.

The insight: a forwarding address

The piece that made this solvable: I didn’t need to migrate every consumer’s understanding of where auth-svc lives. I needed to migrate the service, and quietly redirect anyone still asking for the old address.

Kubernetes has exactly this mechanism, and it’s easy to forget it exists because you almost never need it: an ExternalName service. Instead of pointing at pods, it points at another DNS name, functioning essentially like a CNAME. Deploy the real thing at its new home, then convert the old Service object into a forwarding address:

apiVersion: v1
kind: Service
metadata:
  name: auth-svc
  namespace: default
spec:
  type: ExternalName
  externalName: auth-svc.authentication.svc.cluster.local

Every consumer still calling auth-svc.default.svc.cluster.local gets silently redirected to the real thing in its new namespace. Nobody changes a line of code on their end. It’s the same trick as a postal forwarding order: you don’t visit every person who might send you mail and update their address book, you tell the post office where you actually live now, and everything gets redirected until people eventually update it themselves, at their own pace, with zero coordination required on your part.

That forwarding trick only earns its keep if you actually confirm it’s working before you lean on it. Once the proxy was live, the next step wasn’t scaling anything down, it was watching the metrics through the crossover: checking that traffic hitting the old address was genuinely landing on the new deployment, not silently failing or looping somewhere. Only once that looked clean did the old pods get scaled to zero rather than deleted outright. Scaling to zero costs nothing and buys an instant rollback, just scale back up, if anything downstream looked wrong later. Deleting them outright would have meant rebuilding from scratch if something went sideways, so there was no reason to give up that safety net early. We could defer the cleanup to a later point in time.

The chicken-and-egg problem

The remaining wrinkle was the ingress. External traffic to auth-svc doesn’t come in through the DNS-based Service mechanism at all, it comes in through an ingress, and I needed a working ingress in the new namespace before I could safely remove the one in the old namespace. But the policy engine wouldn’t allow both to exist at once; identical ingress rules across two namespaces is exactly the ambiguous state it exists to prevent.

Classic chicken-and-egg: can’t create the new one without a policy exception, can’t delete the old one first without a traffic gap.

The fix was a temporary, explicit exception rather than fighting the policy itself: annotate the new namespace to bypass the duplicate-ingress check just for this migration, stand up the new ingress alongside the old one for a short overlap window, confirm traffic was flowing correctly to the new deployment, then delete the old ingress and let the exception age out. A brief, deliberate window where both existed, rather than a gap where neither did.

The patch would look something like this:

apiVersion: v1
kind: Namespace
metadata:
  name: authentication
  annotations:
    policy.example.com/allow-duplicate-ingress: "true"

How it actually shipped

None of this went straight to production. It ran in dev first, then a staging cutover, with a couple of weeks between the staging success and doing it for real, mostly just to sit with it and see whether anything subtle showed up under real traffic before betting a critical path on it.

The production cutover itself ended up being the boring part. All the actual difficulty was front-loaded into getting the design right. Once the plan was solid, executing it was closer to a formality than an event.

Why this matters beyond one service

Here’s the thing about default namespace sprawl: it’s rarely caused by carelessness. It’s caused by the complete absence of pressure to ever fix it. Someone creates a policy restricting new services from landing in default, good practice, but nobody sets a deadline or a plan for the services already there. They just sit. For years, in this case. Nothing forces the issue until a team needs something namespace-scoped that default structurally can’t give them, and only then does the debt come due.

If you’re staring at a similarly stuck service, the pattern generalises past this one migration. An ExternalName proxy buys you a zero-coordination path to move anything addressed by DNS, provided you’re willing to hold two versions in careful overlap for a short, deliberate window rather than trying to cut everything over at once. The next time someone tells you a service can’t be moved because too many things depend on it, that’s usually a sign nobody’s looked for the DNS-shaped seam it can be split along.

This only works cleanly because everything here talked to auth-svc through its DNS name rather than a hardcoded IP or ClusterIP. If you’ve got consumers that skip DNS entirely, and some legacy systems do, you’re solving a different, uglier problem.

In the previous post, we introduced KubeVirtBMC and showed how it provides virtual BMC endpoints for KubeVirt VMs. We tested it with raw IPMI and Redfish commands. That was fun, but the real power of KubeVirtBMC shines when you pair it with actual bare-metal provisioning tools.

In this post, we’ll walk through a complete end-to-end demo: using Metal3 to manage and provision KubeVirt VMs through KubeVirtBMC, just as if they were physical servers. You’ll be able to follow along and replicate every step.

Why Metal3?

Metal3 (Metal Kubed) is a CNCF Incubating project that brings bare-metal host management into the Kubernetes ecosystem. Under the hood, it uses OpenStack Ironic to handle the heavy lifting, inspecting hardware, setting boot devices, and writing OS images to disks.

The core abstraction is the BareMetalHost custom resource. You declare what you want (BMC address, credentials, desired image), and Metal3 takes care of the rest. The typical BareMetalHost lifecycle goes like this:

Metal3 expects to talk to a BMC via IPMI or Redfish. Physical servers have these built in. KubeVirt VMs don’t—unless you give them one with KubeVirtBMC.

What We’re Building

Here’s a high-level overview of the demo environment:

Everything runs in a single Kubernetes cluster. Metal3 manages BareMetalHost resources that point to the virtual BMC endpoints created by KubeVirtBMC. When Metal3 tells Ironic to power on a host or attach a boot image, Ironic sends Redfish requests to the BMC pod. The BMC pod translates these into Kubernetes API calls to control the KubeVirt VM. Metal3 doesn’t know (or care) that it’s talking to a VM.

Prerequisites

Before we start, make sure you have:

• A Kubernetes cluster with virtualization support (nested virtualization or bare metal)
• KubeVirt installed and functional
• A storage provider (for VM disks)
• kubectl, helm, and kustomize installed locally

Step 1: Install cert-manager

Both KubeVirtBMC and Metal3 components require cert-manager for webhook certificates.

helm upgrade --install cert-manager oci://quay.io/jetstack/charts/cert-manager \
    --namespace=cert-manager \
    --create-namespace \
    --set=crds.enabled=true

Step 2: Install KubeVirtBMC

helm upgrade --install kubevirtbmc kubevirtbmc \
    --repo=https://charts.kubevirtbmc.io \
    --namespace=kubevirtbmc-system \
    --create-namespace

Step 3: Create a KubeVirt VM with BMC

We’ll create a VM that simulates a bare-metal server. It needs a disk, a network interface, and it should start in a powered-off state so that Metal3 can manage its lifecycle from scratch.

Create a PVC for the VM’s root disk:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: metal3-demo-vm-disk
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
EOF

Create the VirtualMachine with runStrategy: Halted so it stays powered off:

cat <<EOF | kubectl apply -f -
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: metal3-demo-vm
  namespace: default
spec:
  runStrategy: Halted
  template:
    spec:
      domain:
        cpu:
          cores: 4
        memory:
          guest: 8Gi
        devices:
          disks:
          - name: rootdisk
            disk:
              bus: virtio
          - name: cdrom
            cdrom:
              bus: sata
          interfaces:
          - name: default
            macAddress: "02:00:00:00:00:01"
            bridge: {}
        firmware:
          bootloader:
            efi:
              secureBoot: false
      networks:
      - name: default
        pod: {}
      volumes:
      - name: rootdisk
        persistentVolumeClaim:
          claimName: metal3-demo-vm-disk
EOF

Now create the VirtualMachineBMC and its credential Secret:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: demo-bmc-secret
  namespace: default
stringData:
  username: admin
  password: password
---
apiVersion: bmc.kubevirt.io/v1beta1
kind: VirtualMachineBMC
metadata:
  name: demo-bmc
  namespace: default
spec:
  virtualMachineRef:
    name: metal3-demo-vm
  authSecretRef:
    name: demo-bmc-secret
EOF

Step 4: Install the Metal3 Stack

Install the Ironic Standalone Operator

git clone https://github.com/metal3-io/ironic-standalone-operator.git
cd ironic-standalone-operator
make install deploy

kubectl -n ironic-standalone-operator-system wait --for=condition=Available \
    deploy/ironic-standalone-operator-controller-manager \
    --timeout=120s

Deploy Ironic

First, create the namespace and the required TLS certificates:

kubectl create ns baremetal-operator-system

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: baremetal-operator-system
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ironic-cacert
  namespace: baremetal-operator-system
spec:
  commonName: ironic-ca
  isCA: true
  issuerRef:
    kind: Issuer
    name: selfsigned-issuer
  secretName: ironic-cacert
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ca-issuer
  namespace: baremetal-operator-system
spec:
  ca:
    secretName: ironic-cacert
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ironic-cert
  namespace: baremetal-operator-system
spec:
  secretTemplate:
    labels:
      environment.metal3.io/ironic-standalone-operator: "true"
  dnsNames:
  - ironic.baremetal-operator-system.svc
  - ironic.baremetal-operator-system.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: ca-issuer
  secretName: ironic-cert
EOF

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  labels:
    environment.metal3.io/ironic-standalone-operator: "true"
  name: ironic-credentials
  namespace: baremetal-operator-system
type: kubernetes.io/basic-auth
stringData:
  username: ironic
  password: supersecret
EOF

cat <<EOF | kubectl apply -f -
apiVersion: ironic.metal3.io/v1alpha1
kind: Ironic
metadata:
  name: ironic
  namespace: baremetal-operator-system
spec:
  apiCredentialsName: ironic-credentials
  networking:
    disableHostNetwork: true
  tls:
    certificateName: ironic-cert
    disableVirtualMediaTLS: true
  version: "37.0"
EOF

Install the Bare Metal Operator

git clone https://github.com/metal3-io/baremetal-operator.git
cd baremetal-operator

mkdir -p config/overlays/kubevirtbmc-demo

cat > config/overlays/kubevirtbmc-demo/kustomization.yaml <<EOF
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: baremetal-operator-system
resources:
- ../../default
components:
- ../../components/basic-auth
- ../../components/tls
EOF

cat > config/default/ironic.env <<EOF
DEPLOY_KERNEL_URL=
DEPLOY_RAMDISK_URL=
IRONIC_ENDPOINT=https://ironic.baremetal-operator-system.svc
IRONIC_CACERT_FILE=/opt/metal3/certs/ca/tls.crt
IRONIC_INSECURE=false
EOF

kustomize build config/overlays/kubevirtbmc-demo | kubectl apply -f -

Step 5: Register the VM as a BareMetalHost

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: metal3-demo-vm-bmc-secret
  namespace: default
stringData:
  username: admin
  password: password
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: metal3-demo-vm
  namespace: default
spec:
  online: true
  bootMACAddress: "02:00:00:00:00:01"
  bmc:
    address: redfish-virtualmedia+http://metal3-demo-vm-virtbmc.default.svc.cluster.local:80/redfish/v1/Systems/1
    credentialsName: metal3-demo-vm-bmc-secret
    disableCertificateVerification: true
  rootDeviceHints:
    deviceName: /dev/vda
EOF

Step 6: Provision the Host with an OS Image

kubectl patch bmh metal3-demo-vm --type=merge -p '
{
  "spec": {
    "image": {
      "url": "https://releases.ubuntu.com/resolute/ubuntu-26.04-live-server-amd64.iso",
      "format": "live-iso"
    }
  }
}'

Step 7: Verify and Clean Up

To deprovision (wipe the host and return it to the available pool):

kubectl patch bmh metal3-demo-vm --type=json \
   -p '[{"op": "remove", "path": "/spec/image"}]'

Gotchas and Tips

• MAC address mismatch. The bootMACAddress in BareMetalHost must match an actual interface on the VM.
• HTTP vs HTTPS. KubeVirtBMC serves Redfish over plain HTTP by default. Use redfish-virtualmedia+http://.
• Virtual media vs network boot. The redfish-virtualmedia driver boots the IPA ramdisk and provisioning images via virtual media (ISO attachment), which means no PXE, no DHCP, and no provisioning network is required.
• Ironic host networking. In this article, we disable host networking solely for demonstration purposes, allowing us to rely on in-cluster DNS.
• Cross-cluster scenarios. If Metal3 runs in a different cluster than KubeVirt, you can expose the KubeVirtBMC Services externally using Ingress or NodePort.

Why This Matters

• CI/CD for bare-metal tools. Metal3, Ironic, and similar projects can use KubeVirtBMC to run their integration tests on KubeVirt VMs instead of maintaining a fleet of physical servers.
• Developer inner loop. If you’re developing bare-metal provisioning features, you can iterate much faster with VMs that spin up in seconds.
• Training and demos. Showcasing Metal3 no longer requires a rack of servers. A single Kubernetes cluster with KubeVirt is enough.

What’s Next

The KubeVirtBMC project is actively evolving. There is more work underway to improve Redfish compatibility and extend the BMC feature set. If you want to follow the progress or contribute, head over to the GitHub repository.

Magnitude

Run your agent on local models. Free, private, and offline.

Magnitude is an open source inference server that runs the best local models for your hardware, plugged into the agent you already use. It profiles your machine, recommends the models that fit, then downloads, tunes, and runs them. Works with Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi, and Cline, or use the built-in harness.

Get started

Send this to your agent to walk through models and setup:

Set up local models for me with the Magnitude CLI. Install it with `npm i -g @magnitudedev/cli` (or my package manager), then run `magnitude docs onboarding` and follow the instructions.

Your agent will profile your hardware, walk you through the best local models for it, download the ones you pick, and switch itself over to them.

Magnitude supports macOS and Linux. Windows is supported through WSL.

Want to browse the models directly?

npm i -g @magnitudedev/cli
magnitude setup

The interactive setup lets you browse the recommended models and choose one yourself.

Why Magnitude?

• Free to run: no token costs, API keys, or rate limits
• Fully private and offline: models, prompts, and files stay on your machine
• Agent-first setup: one prompt and your agent walks you through the rest
• Knows your hardware: profiles your chip, memory, and bandwidth
• Recommends what fits: the best models for your machine, with estimated tok/s
• Tuned end to end: speculative decoding, concurrency, all set for your machine
• Models on demand: loaded on request, unloaded when idle or memory fills
• Open source: Apache 2.0, yours to modify

FAQ

What is Magnitude?

An open source inference server that runs the best local models for your hardware, plugged into the agent you already use. It profiles your machine, recommends the models that fit, then downloads, tunes, and runs them.

What hardware do I need?

There's no fixed minimum. Magnitude profiles your hardware and recommends the best models for your machine. More memory lets you run larger models.

Why not just have my agent set up Ollama?

Your agent would be guessing. It doesn't know your hardware, which quant fits, or how fast it'll run. Magnitude gives it a catalog with recommendations computed for your machine, an onboarding flow that writes your harness config, and inference built for agent workloads. Models load just in time and unload when idle or memory gets tight.

Which harnesses work with it?

Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi, and Cline. During setup, your agent connects your harness to the model you pick. Or use Magnitude's built-in harness.

Do I need to manage Magnitude after setup?

No. It runs in the background, loads models when your agent needs them, and unloads them when idle or memory gets tight. Your agent can install or switch models through the Magnitude CLI anytime.

Does my data go to the cloud?

No. Prompts, files, and models stay on your machine.

Can it run completely offline?

Yes. Once Magnitude and a model are downloaded, no internet connection needed.

Can I use models outside the catalog?

Yes. You can download compatible GGUF models from Hugging Face and use them in Magnitude.

Learn more

• Documentation
• CLI reference
• Discord
• Report an issue

License

Magnitude is licensed under the Apache License 2.0.

Memory costs are increasing dramatically. Both RAM and hard disk drive prices have exploded over the past year. At Cloudflare, we run several massively distributed storage products (including our famous CDN) that rely on making efficient use of the memory we have deployed so we can continue to serve all of our customers.

With this in mind, we prototyped a way to expand effective cache capacity. By encoding eligible assets with Zstandard inside Pingora, the architecture trades a minor CPU increase for significant storage and cross-data center bandwidth savings.

We have been prototyping a system called Cache Transcoding, which I built during my internship at Cloudflare as part of the 1.1.1.1 Intern Program. When an eligible response enters the cache, we encode it using Zstandard, or zstd, before writing it to disk. We keep that compressed form while the asset lives in the cache and moves between data centers via Tiered Cache, then decode it before serving the response to the client.

In our initial testing, this encoding shrunk eligible assets to ⅓ of their original on-disk size on average. The estimated extra CPU cost in our origin-facing proxy was small, but that is the trade. A small increase in CPU gives Cloudflare petabytes of effective cache capacity and reduces the data transferred between our data centers. The encoding cost is paid once when an asset enters the cache. The storage and bandwidth savings continue every single time that asset is reused.

What is Zstandard?

Zstandard, or zstd, is a lossless compression algorithm developed by Yann Collet at Facebook and open sourced in 2016. Lossless means that after compressed data is decoded, every byte is identical to the original. We can change how an asset is represented on disk without changing the asset itself.

Zstd is designed to balance compression ratio with speed. In our earlier browser compression testing, it compressed data 42% faster than Brotli while producing nearly the same file size, and produced files 11.3% smaller than gzip at a comparable speed. That balance matters because Cache Transcoding would touch a large amount of traffic, so both encoding and decoding need to stay fast.

The prototype uses zstd level 3, giving us most of the compression benefit without turning cache fills into a CPU bottleneck.

Cloudflare traditionally stores an asset using the content encoding supplied by its origin. If an origin sends an uncompressed response, we store those uncompressed bytes on disk and transfer them between data centers in the same form. Cache Transcoding adds compression inside the cache itself.

Not everything is worth compressing

Transcoding does not mean compressing everything. Images, video, and fonts are usually compressed already. In our traffic sample, this media slice represented 21.4% of requests but 63.3% of bytes. Compressing it again would burn CPU for nothing.

Compressible text is different. HTML, JSON, CSS, and JavaScript represented 67.3% of requests and 22.3% of bytes. Within that text slice, approximately 71% arrived uncompressed with Content-Encoding unset and it compresses well.

In our controlled test corpus, the eligible assets compressed by roughly 2.8 times.

Encoding is more expensive per byte, but assets are served far more often than they are filled.

By changing how assets are represented, existing hardware could store more customer content.

Fewer bytes on disk mean each server can retain more objects. This increases cache density and reduces the likelihood that useful content is evicted because an uncompressed representation consumed more space than necessary.

The smaller representation also helps as an asset moves through Tiered Cache because it reduces the data transferred between Cloudflare data centers, making backbone usage more efficient.

Paying the compression cost once

Compression is never free. Encoding and decoding both use CPU, so the important question is whether the byte savings are worth the processing cost.

At zstd level 3 (often the default balance of speed and compression size output), our model kept the extra CPU cost to a few percent under the traffic and reuse assumptions we tested.

We initially considered limiting transcoding to popular content, since hot assets are reused more, but it did not help. Decoding happens every time an asset is served, so limiting the feature to only the hottest content reduced the storage saving without cutting CPU by the same amount.

The simpler policy performed better. Transcoding all eligible compressible text at or above 4 kibibytes (KiB) captured nearly all of the measured storage benefit, while remaining within the CPU budget.

How Cache Transcoding works

On a cache miss, our Pingora-based proxy encodes the body using zstd before writing it to disk. The cache metadata records that the stored representation is compressed and preserves the original content length. Before the response leaves the proxy, the body is decoded back to its original identity representation.

On a cache hit, the stored zstd object is read from disk and decoded. With Tiered Cache, the compressed representation is transferred from the upper tier to the lower tier in the compressed form. Decoding only happens on the client-facing hop.

On a full cache miss, the upper tier fetches identity bytes from the origin. Those bytes are encoded once, stored as zstd, and transferred to the lower tier in their compressed form. The lower tier also stores the zstd representation, then decodes it for the request path.

If the lower tier misses but the upper tier already has the object, the origin is not involved. The compressed object moves directly between the cache tiers. It remains compressed on the wire and on disk, then is decoded once at the lower tier.

If the lower tier already has the object, no network transfer or encoding is needed. The lower tier reads the zstd bytes from disk, decodes them, and passes the original asset onward.

The storage encoding marker prevents an object from being encoded more than once. A cache layer receiving an object from another tier can see that it is already stored using zstd, and preserve it in that form.

Why we only transcode certain text

The fastest compression operation is the one we do not need to perform. Cache Transcoding therefore uses a series of eligibility checks to avoid content that is unlikely to benefit.

The prototype only transcodes a 200 OK response when Content-Encoding is unset, the Content-Type is compressible text, and the response has a known Content-Length of at least 4 KiB. Slice subrequests, responses using active upstream compression, range requests, precompressed responses, unknown length bodies, and binary content remain unchanged.

The 4 KiB threshold removed a large number of tiny requests while leaving out only about 1% of the otherwise eligible bytes. Lowering it would add per-object overhead without saving much more storage.

The threshold and zstd level are both parameters rather than permanent limits. We started with zstd level 3 and a 4 KiB minimum because they gave us a conservative way to measure the architecture. With the initial CPU budget understood, we can test whether higher compression levels improve the ratio enough to justify their additional cost.

Testing over one million requests through the cache

We exercised the prototype against a controlled test zone and correlated each request across request logs, Prometheus metrics, and Jaeger traces.

The correctness campaign covered cache misses, cache hits, single-hop fills, Tiered Cache fills, and more. We varied cache keys to make each request follow a specific path and used traces to confirm where encoding and decoding occurred.

One performance campaign sent more than a million requests across 10 cache servers. Half of the campaign ran with Tiered Cache disabled and the other half with it enabled. This allowed us to measure local cache behavior separately from transfers between cache tiers.

The two assets were approximately 195 KiB and 272 KiB, and both compressed by roughly 2.8 times. This was deliberately a compressible test corpus. It gave us a clear signal for validating the architecture, but it does not represent every text object on the Internet. A broader corpus is required before treating the measured compression ratio as a fleet-wide constant.

Compress once, benefit many times

What this experiment showed us is that there are significant efficiencies we can still deploy across our caching service that can benefit all of our customers. What we built for Cache Transcoding shows that the trade is favorable under the conditions we tested. The architecture preserved the content and remained within the CPU budget.

For next steps, we plan to evaluate higher zstd levels, test a broader range of content types and object sizes, tune different parameters from the eligibility criteria and more. Future work can also examine range requests, pre-compressed origin responses, and passing the compressed object directly to downstream components that already support it without decoding.

Throughout my internship, I’ve had the wonderful opportunity to work alongside Cloudflare's engineering teams on the real infrastructure that stores and serves content across our global network. If you want to start your career by helping build a better Internet, explore our internship opportunities and job openings.

Go's newer map implementation uses a Swiss Table design that groups entries in small blocks with compact control bytes, allowing many candidate slots to be checked before doing full key comparisons. SIMD can compare multiple control bytes at once on supported CPUs, while the layout and growth strategy improve cache locality and lookup performance.

OpenAI has started offering rides in its Cybercab robotaxis. The two-seat vehicle has no steering wheel and is designed to transport passengers with no direct human intervention. Tesla is authorized to operate 314 vehicles in Texas to provide paid rides without a driver. Most of the vehicles are Model Y sport utility vehicles, but the fleet includes 45 Cybercabs.

AI, tools and transformation

The typical big American company today has hundreds, and perhaps thousands, of different pieces of software. It has giant ‘big iron’ horizontal systems of record like SAP and Workday, it has hundreds of vertical SaaS applications, and then there are hundreds more workflows, scripts, automations and databases, right down to the 10 meg spreadsheet running a department. Very often, the company doesn’t even know quite how much it has, what’s actually being used, and what it’s paying for. And yet, with all this software, the company is full of boring, repetitive tasks.

It can be very tempting to think that AI will sweep most of this away. There’s an old joke that an engineer is someone who’ll spend an hour building a tool to automate a task that would take 10 minutes. But with AI, now you can make that tool in five minutes, and you don't need to be an engineer, and you don’t need to write code. You can just ask the model to make the tool for you, or, more fundamentally, just do the task for you itself. Instead of having to create those tools one at a time, software might be dynamic, generative, free-form, and spontaneous. Massively more tasks can be automated, with massively less software.

If you’re a tool-builder, and everybody in Silicon Valley is a tool-builder, this is intoxicating. But I think it misunderstands where software comes from and how people use it, and I think it misses how companies change.

First of all, most people are not tool builders, and most people don’t instinctively think about how their job could be done in a different way. If you spend all your time in the Silicon Valley bubble, it can be easy to forget this, because your entire world is about creating tools that change how things are done. But if you’re a really great matrimonial lawyer, you spend all your day thinking about your cases and your clients, not about what great legal discovery software would do; if you’re a really great enterprise salesperson, you spend all your time thinking about your product and your clients and your competitors, not about how great sales enablement software could make you more productive.

Products like Excel try to bridge this problem with on-boarding flows, assistants, and templates - everything you see in ‘File/New’ is a suggestion for what you could do with this. But every one of those templates still became a company, and that’s what I see in things like Claude for X as well - this is helpful, but not the answer.

Narrowly, that means that the task to be automated might be sitting in plain sight but the people with that task don’t see it. This is what leads to the idea of the ‘forward-deployed engineer’ - someone who is a builder, and knows what AI can build, can ‘just’ walk around a law firm or an architecture office and see the opportunities lying on the table that the lawyer or the architect doesn't see.

The deeper problem is most of what we’ve automated in the last few decades wasn’t obvious, even if you are a tool-builder, and didn’t have an obvious solution either. We can all think of examples of stuff we use every day where our first reaction was “Why would I want that?” Very often, it's not obvious that the problem exists, and very often it's embedded or bundled or hidden inside something else. Equally, even if you can see the problem, or think you can, the right way to fix it often isn’t clear either, and the way to fix it is to redefine it or unbundle it, and working that out is hard. For many successful software companies, there were half a dozen failed attempts that came before and didn't find quite the right approach or the right problem.

None of this is solved by making easier to write code - by making it easier to make tools. The hard part is knowing that you need a tool for this in the first place, and then knowing what the tool should do.

But even once you reach that point, you have to get everybody else to use it, too. Many of the problems, workflows and tasks that we might want to automate touch 50 or 500 people across five different departments, three different systems of record, and four different regulatory regimes. You might have a great idea for doing an accounts payable differently, but you yourself can't change how everybody in the company does it. That has to be a purchase, and a decision, and an 18-month sales process.

Second, all of this means that software is bought or chosen or created on a spectrum from top-down to bottom-up - the company buys SAP and the user makes a spreadsheet - and I think it’s useful to think of this also as a spectrum from institutionalised to improvised.

You have tasks that are easy to do in the dedicated tools you already have, whether it’s SAP, Carta or Rippling. These tasks and workflows have been institutionalized - a bunch of people in those companies and your company have spent a lot of time working out the correct way to do that task, and it’s important that everyone do it the same way with the same tools. But then you have edge cases, exceptions and one-off questions, that are hard or impossible to do in those tools. Your users, bottom-up and creating their own solutions, manage these in a fuzzy, improvised space of freeform substrates like Excel, email, shared folders, Tableau, Powerpoint and CSVs, screenshots, PDFs and conference calls.

But once this task becomes something that you're doing all the time, in the same way every time, and that lots of people are doing, and becomes important and has revenue and risk attached to it, then, at a certain point, the company has to institutionalize it. You need audit, security, maintenance and accountability. You pave the desire path and pay someone to set it in stone. As above, you might not realize that the path is there - you might not realise that you have hundreds of people wasting an hour a day doing this - and it might be hard to work out the right way to fix that, but that process is why the company has hundreds of apps.

We went though a lot of this with the shift to SaaS, which was another order-of-magnitude change in how much software we had, along with a new operating model and a new cycle time, and that killed a lot of incumbents that couldn’t make the jump. It’s a continuous and organic flow of bundling and unbundling. All of those SaaS apps do something that you could do in SAP or Excel or email - Carta is a $4bn company that manages one spreadsheet for your CFO - and sometimes tasks move back. A few years ago I spoke to a consultant who said that half of their jobs were telling people who used Excel to use a database and the other half were the other way around.

Hence, if you’re PwC and you hire 3-4,000 graduates every year, you use dedicated, ‘institutionalised’ software to manage that. If you’re a small firm and you hire five or ten, you use email, a shared folder and Google Sheets. As that small firm grows, at a certain point it will outgrow that, and maybe move to Notion, or to an SME-focused SaaS HCM. But a small team inside PwC might also be using Google Sheets to track candidates to fill a role because Workday is too inflexible - the unbundling begins again.

Now AI rolls across all that. AI will expand all of the existing apps, and there’ll be many new vertical apps, and Excel, and Tableau, Google Sheets, email and all the other freeform spaces for improvising solutions will gain new capabilities. With that cycle, the chatbot itself is a new freeform space that sits next to Excel and email, taking over tasks from them and from your apps, and also losing tasks to those apps.

Now that small company hiring ten graduates might stick in Google sheets a lot longer because AI makes it more scalable, or you might use it as a data store for Gemini, and you might ask “should we get Claude to make something or move this to Notion?”… and then you see there’s a new SaaS app aimed right at you that solves this plus some other problem you hasn’t thought of. AI doesn’t change the question: it creates new choices and moves the thresholds.

I think you can see all of this in the experience of enterprise AI deployment in the last three years. Every big company gave everyone Copilot (or maybe ChatGPT or Claude) and a small number of people are using this a lot (some of whom actually increased their productivity), while a larger set of people are using it a couple of times a week and a lot of the rest of your company isn't really using it at all. This is partly a change management and a training problem, but it's mostly the same problem that you would have had if you'd given everyone in the company a PC and Lotus 123 in 1983, or an internet connection and a web browser in 1997. How exactly does this map to everybody's tasks and the problems they actually have this week? Yes, you did give everybody a PC and Lotus, but that wasn’t how you transformed the efficiency of your invoice processing. Yes, you gave everybody a web browser, but that wasn't how you rebuilt your supply chain management around the internet, and it certainly wasn't how a retailer managed e-commerce.

Narrowly, the way that companies think about changing those kinds of structural processes is to start doing pilots. You run trials of products (both bought and built internal) that use the new capabilities of AI to automate processes that you couldn't automate before. There’s now all sorts of data around how many of these pilots there are, how many work (roughly half, as is normal - this is why they’re pilots!) and what can go wrong.

But again, this is a very old-fashioned CIO conversation around use cases, lighthouses, pilots, heroes, quick wins and measurable results. Meanwhile, the CEO and the board scratch their heads and say “Wait, but we've got 100s of workflows and we've done five or 10 pilots. That doesn’t seem to scale?” Giving everyone in the company ChatGPT does scale theoretically, except that most people aren't really finding ways to use it.

Going back to a hypothetical bank giving everyone spreadsheets in the 1980s, or a retailer giving everyone a web browser in the 1990s, yes, of course you should do that, and yes, of course, you need to think about training and change management and all the other good stuff that KPMG can tell you about. But that isn’t how you think about transforming the way your company works around a generational new technology.

Stepping back, it seems to me that with each new transformative technology, every company has to ask three kinds of questions. First, how do we buy, build and deploy this? Do we do pilots? Should we take the product that's bundled from Microsoft/Google/Oracle, build something ourselves, pay someone to build something, or buy this new thing from a startup? Second, they have to ask how far this changes their operations. What does it mean? What does email mean for us? What does spreadsheets mean for us? The answer to that might be radically different if you were an insurance company or a law firm. And third, you have to ask whether this creates new challenges to your business’s economics, new competitive pressures, or, perhaps, some kind of existential threat.

You don’t answer those questions by giving everyone Claude for X. Indeed, all of this means lots of new pitches for professional services (which is ironical given how many questions AI poses to their own business models). Do you want to work out how to deploy an LLM-enabled voice analytics tool in your call center? You're probably going to call Accenture. The vendors themselves have always been happy to help, and now the big labs have their own ‘deploycos’ - we used to joke that a ‘machine learning scientist’ is a statistician who lives in San Francisco, so maybe a ‘forward deployed engineer’ is anyone that OpenAI hired from a systems integrator. On the other side, your startup is building a great new tool and you want to go to market quickly? You'll probably call the Big Four. You're frustrated with how hard it is to sell AI software into law firms or accountancy firms. Okay - go start an ‘AI-enabled’ law firm and work out if that can be a key point of leverage (or whether it's like starting a ‘PC-enabled law firm’ in the 1980s). And of course, if you’re the board, and you're trying to work out whether this is some kind of existential threat or a massive revenue opportunity, then you’ll think about calling Bain, BCG and McKinsey (or your friendly neighborhood M&A banker) - this is what they do.

Stepping back from all of this, though, there's also a much simpler way to think about the question. With every new technology, we start by using it for the work we already have, and we just do that more and faster. But then, over time, you make entirely new things. We will use AI to automate broad classes of stuff inside existing workflows and existing companies (although, as I’ve outlined above, that will be enormously more trouble and work than just giving everybody a model). But with every previous platform shift, the stuff that actually mattered was the stuff that wasn't even possible before and that no-one even imagined.

Model quality is no longer a clear differentiator. It's only a matter of time before open source catches up to the current state-of-the-art. Model providers must look elsewhere for differentiation. For many, this will mean finding a niche and moving away from the defaults.

Nearly every button click online kicks off a chain reaction that sends data to a specific server, linked to you and your account. What we see as form fields and buttons and links are, behind the scenes, tools that kick off a stream of data from your computer to a server then back again.

Which, if you squint, sounds a lot like email. Email, after all, is just structured text—subject, body, recipient address (this person @ this server), sender’s address, and random other odds and ends. It’s an API call of a sort wrapped up as a human-readable letter, complete with the data to identify you as, well, you.

When you email a colleague telling them about a task they need to do, it’s not all that much different, data-wise, if you squint, from when you assign them a task in an online project management app.

And squint they did, the earliest software developers, looking for ways to hammer distant computers together. In the days when ARPANET was the best network in town and the world wide web was a half-decade away from invention, computing was far from the standardized platforms it is today, with browsers that work more-or-less the same everywhere.

Smaller development teams with no resources to allocate had to find a shortcut, a more universal interface that worked on every computing platform, on every desk. The way to nail it, more often than not, turned out to be email. “Everyone has email, right?” Email offers a happy medium, a way to interact with software with less commitment for users and less build-out for developers. Which is how email became, alongside terminal commands, one of the longest-running, most consistent software user interfaces.

No need for an app. Just send an email.

An App Store over Email, in 1985

Communication standards have been co-opted to control machines for as long as they’ve been around. If you can send a message to another human, intermediated by machine, you can also send a message directly to a machine, as long as you teach it what to do with its contents. And therein lies possibility.

The telegraph may have been invented to send words, dots and dashes at a time, over the wire. But the same wires, the same beeps and buzzes, were used for automated train signaling, commercially, five years before Morse tapped out his famous first telegraphic message. Similar ideas relayed commands from ship decks to the boiler room, and powered the original ticker tape on Times Square.

So when email was invented, in 1971, it was only natural that email would borrow inspiration from the telegraph, both in message style and in use cases. Email offered identity and a stand-in for accounts; you knew which account sent the message, at any rate, and could trust that your reply would go to their inbox and no one else’s. Email offered a free-form way to send data to a server. As long as that server had code that’d watch for new emails, parse their text, take action on what it said, then send back an email in reply, a simple email could be a software user interface.

As it was for Netlib, a 1985 App Store of sorts, built “to fill a need for cost-effective, timely distribution of freely available, high-quality mathematical software to the research community” by Jack Dongarra and Eric Grosse.

Software, at the time, was often stored on magnetic tapes, shared internally inside universities and over ARPANET connections, but inaccessible to the growing numbers of researchers using computers around the world. “There was no convenient mechanism for distributing small pieces of software or individual routines,” wrote the team a decade later. “In addition, there was no central repository for research software. As a result, valuable software produced from research in numerical analysis was often unavailable to others who might benefit from the work.”

Email to the rescue. Say, as their paper listed as an example, you needed software “to compute several integrals numerically.” You’d send the following email:

mail research!netlib 
send dqag from quadpack
send gaussq from go

Netlib’s server would read the email, strip off any extraneous punctuation or signatures, then look up the library and routine names, package up the code, and send it via email.

“In a short time, two pieces of mail come back from netlibd,” they described, one with each piece of requested software. One could instead email send index, for example, to get back a list of all the software on offer, or a whois to request a developer’s address and phone number.

It worked well enough for the most part, human error aside. “Sometimes, by carefully puzzling over other information in the header, a human can guess how to fix the address on failed mail. But netlib doesn't try to work miracles,” said Grosse. It was fast, too, “5 or 10 minutes is typical for ARPANET,” the team report noted, enough that “one user wrote back enthusiastically that the system was so fast he preferred using it to hunting around on his own machine for the library software.”

All of that, over simple email.

No need to build a user-facing app or interface, no restricting the software to one operating system or specific computer specs. Email was a universal way to search for and receive software, in the closest thing the ‘80’s had to an App Store or a GitHub-style repository.

“We chose this mode of interaction via electronic mail, keeping the intelligence local to the central depository,” stated the team in 1987, “because mail is at present the only ubiquitous data-communications service.”

Email as the interface

And the idea spread.

FTPmail popped up on university servers, as a way to fetch files on FTP servers over email, in the early ‘90s. MCI Mail, by 1993, let you send a fax via email, and RFC 1486 tried to standardize print-by-email the same year. Ringo gave you music recommendations, over email, in 1994.

IMDb, even, “was all done by email,” recalled founder Alan Jay about the platform’s early days. “There was no web.” Its initial recommendations came from the rec.arts.movies newsgroup, and you’d email to “query the database by sending messages like title: Casablanca or actor: Meryl Streep,” and “it would send you back the cast list or actor’s filmography.”

Email was beguilingly simple. No need to design a website or support a new platform. All that was needed was a universal email address, a server with code to parse the messages and do their bidding, and reply emails with the data that users had requested. Not all that different from today’s use of chat with emerging AI services; easier to tap into our existing communications paradigm than to invent something new.

As web apps and software as a service emerged through the late ‘90’s and early 2000’s, email remained the fallback, a way to fit into the way people already worked without building out all that much infrastructure. No need to worry about slow mobile browsers or installing an app; just open your email app, send a message to your app, and carry on. Remember the Milk, a simple to-do list app, let you email in a whole list of tasks that it’d parse into individual to-dos, in 2005, back when Blackberry was the king of smartphones.

Task management is an obvious fit for email integration, as so much work happens in inboxes. Trello and Todoist, among other to-do list and project management apps, give you an email address per-project to email in tasks. I Done This takes the opposite approach, emailing you each day so you can reply to log what you’ve accomplished.

Reading is another task that ties in well, with newsletters and blog posts competing for attention alongside personal and work messages. Instapaper, the app to save long-form articles, gives you an email address to forward in newsletters to read later, as does Kindle to let you email articles and books to your device. Readwise takes it one step further, with a unique address you can use to subscribe to newsletters so they bypass your inbox entirely and instead go straight to your reading list.

Writing is natural enough in the inbox, too, making it a shortcut for publishing blog posts. Posterious, a now-defunct blogging platform, took the idea to its extreme. You’d email a specific address, and it’d both create a new blog for you and publish your message as your first blog post in one fell swoop. The idea, if not the app, lives on today, with WordPress.com (and its companion feature in Jetpack) letting you post by email. And Buttondown’s Magic Email Address lets you write and send a newsletter in the most natural way possible, directly from your own email inbox.

And if your favorite app doesn’t include a built-in email integration, but does connect to automation platforms like Zapier, Make, or IFTTT, you can build your own, having the automation watch for an incoming email then take action on the app you want.

Email as identity

Even for the apps that aren’t built around email interaction, email still acts as your universal online passport, the common denominator between nearly every tool you use as the way to identify yourself.

For the earliest email-powered tools like Netlib, that was a boon in building out some of the earliest push notifications. “In the early days of the Netlib repository, when all access was by e-mail and the traffic was mostly from professional numerical analysts, we relied on log files to send out notification of important bug fixes to everyone who had retrieved affected files,” mentioned Dongarra in a 1995 switch to opt-in notifications. But notifying people by email of important fixes based on which packages they’d requested via email made Netlib feel closer to the App Store and its automated updates than anything we’d see for a few decades. No opting in, no accounts needed—an email address tied everything together.

A similarly unique take on email-as-identity came from Japanese signup forms. Instead of tediously typing out your email address then opening your inbox and clicking a confirmation link, Karamail (空メール, or “blank email”) lets you skip the entire process. A Karamail signup process has you tap a mailto: link to open your email app with a blank email addressed to the site or app where you’re registering. Tap send, without a subject or body, and you’ll receive a reply with a login link, much like magic sign-in links but with less typing.

Similar to Posterious’ create-a-blog-by-sending-an-email workflow, the shift from “email as the lowest common denominator interface” to “email as a unique way to interact with software” makes you wonder what a more email-centric world could be.

We’re living in that world, on the publishing side, as social media feeds gave way to newsletters as the default way for serious writers to publish. That, and for authentication, where Slack and others have made magic link sign-in a new standard to keep you from remembering and typing in passwords.

One could imagine, if you squint, a world where everything was run through email. You have to check your email anyhow. Why not email your apps, while you’re at it, sending tasks to your to-do list and drafting your news newsletter in the app where your followers will read it?

Turns out, after all these years of designing ever-better app interfaces, maybe email was the best way to communicate with computers and people alike all along.

Three months ago, Nvidia took the wraps off its RTX Spark “superchip” and a handful of future laptops that would use it. It felt like a consequential moment in the history of the PC, despite all the questions that remained.

And now, as announced at the IFA 2026 tech show in Berlin, we’ve had our first hands-on look at one of these laptops, as well as some announcements around RTX Spark-powered mini desktop PCs. Demand for running agentic AI workflows locally on your computer keeps rising, and these new PCs look like they are designed specifically to feed it.

Nvidia Alternatives to the MacBook Pro

The laptop in question is the Lenovo Yoga 9n 2-in-1, a 16-inch laptop with a 360-degree hinge. As I assumed it would, this thing looks incredibly premium, aiming to be a MacBook Pro competitor in every aspect. The OLED touch display has a sharp 2880 x 1800 resolution and a 120-Hz refresh rate. The whole chassis is surrounded by rounded metallic edges and some very thin display bezels. Other high-end features we don’t typically see include a six-speaker sound system and a 9.2-megapixel webcam.

But here’s the important bit: It’s 0.69 inches thick, just 0.03 inches shy of the 16-inch MacBook Pro. That’s possible thanks to Nvidia’s Arm-based chip under the hood, which combines a Grace CPU with “up to 20 cores” and a Blackwell RTX GPU with “up to 6,144 cores.” The CPU, GPU, and memory are packaged together into a single system-on-a-chip (SoC), sharing more in common with Apple silicon than a conventional Windows laptop. Based purely on core count alone, that would theoretically put the integrated GPU capability of this chip somewhere between an RTX 5070 Ti and an RTX 5080 as found on laptops available today. Those specs also indicate that lower-powered configurations will be sold, though we don’t know how broad the performance range will be. There was no mention of battery-life claims, though presumably one benefit of using an Arm-based SoC (rather than a discrete GPU) is greater efficiency and, thus, better battery life.

Personally, I don’t prefer laptops this large with 2-in-1 capabilities and number pads, so I’m happy that Lenovo is also offering a 15-inch model, the Yoga Pro 9n. While it wasn’t available to see in person, that’s the model I’m more interested in checking out. It shares a lot in common with the 16-inch model, such as the rounded edges, higher-resolution webcam, and very large haptic touchpad. But it has a smaller 15-inch OLED screen with a resolution of 2560 x 1600 and is thinner at 0.66 inches (at its thinnest point). Another unique feature is its Force Pad touchpad, which lets you use a stylus (such as the Yoga Pen Gen 2) to write or draw directly on it.

Interestingly, the Yoga 9n 2-in-1 can only be configured with up to 64 GB of memory, which is less than I thought these AI-focused PCs would offer. I suppose what makes the Yoga Pro 9n a “Pro” model is its configuration options up to 128 GB of memory, as it otherwise seems to have the same performance.

Lenovo’s device is just one among a new line of RTX Spark-powered laptops coming this fall, including the Dell XPS 16, Asus ProArt P16, and Microsoft Surface Laptop Ultra. These larger laptops all seem focused on pleasing the creator and AI enthusiast demographic, though only one 14-inch model has been announced so far: the HP OmniBook X 14.

AI Boxes

The point of all these new PCs is to offer hardware that can capably run on-device AI models locally. That means less dependence on the cloud and more ability to run full agentic AI workflows without worrying about privacy. That’s crucial when an AI model handles sensitive personal data like your financial information, email accounts, or anything else you feel comfortable providing.

Acer announced its own mini PC solution, the Acer SFF RTX Spark, following up on Asus’ ProArt Mini PC shown off earlier this summer. Both are around the same size as the Mac Mini, but offer a “petaflop of AI performance,” up to 128 GB of memory, and the same RTX Spark superchip at its core. These mini PCs are interesting, coming just a week after the announcement of Apple’s M6 Mac mini and M5 Ultra Mac Studio. These small, efficient desktop computers are going to (and already are) play an important role in the adoption of local AI.

Nvidia isn’t the only player here. Lenovo announced an AMD-powered ThinkCentre X Ultra, which also puts 128 GB of memory at the disposal of agentic AI models, alongside AMD’s Ryzen Max+ Pro 495 chip. This is another popular chip being used for local AI, such as on the Framework Desktop. You can even buy the AMD Developer Kit with 128 GB of RAM right now. The expected starting price of the ThinkCentre X Ultra is $3,699, which should give you an idea of how expensive these systems are getting. And note that’s the base model, not the maxed-out, 128-GB version.

Price remains the most crucial missing element. RAM has never been more expensive or more necessary, so I wouldn’t expect any RTX Spark systems to be cheap. The most affordable MacBook Pro (aside from the M5 base model) is $2,349, which gets you the M5 Pro and only 24 GB of RAM. For a 128-GB MacBook Pro, you’re currently looking at $6,139.

Accel reportedly in talks to lead $1B round for Thinking Machines at $40B valuation

Thinking Machines, the AI lab founded early last year by former OpenAI CTO Mira Murati, is in discussions to raise $1 billion at a valuation of at least $40 billion, The Information reported Thursday. Existing backer Accel is in talks to lead the fundraise, according to our source and The Information’s reporting.

The new round, if it is completed, would value the company below the $50 billion valuation that Thinking Machines reportedly sought to secure late last year.

Thinking Machines’ annual revenue run rate stands at over $100 million, according to a source with knowledge of the company’s financials. At that revenue figure, a $40 billion valuation reflects an extraordinarily high revenue multiple.

Accel and Thinking Machines didn’t immediately respond to a request for comment.

In July, the company introduced Inkling, an open-weight model that generates revenue by charging usage-based compute fees for adapting models on proprietary data on its Tinker platform.

The startup’s prior fundraise — a $2 billion round that stands among the largest seed financings in history — valued the company at $12 billion. Andreessen Horowitz led the investment, joined by Nvidia, GV, Lightspeed, and Conviction Partners. Investors backed the round largely on the pedigree of Murati and the former OpenAI researchers who joined her.

Thinking Machines has since had several high-profile departures, with some of the co-founders, including Lilian Weng and Luke Metz, going back to OpenAI.

Adobe for Slack brings image, video, and PDF creation into Slack, letting Slackbot turn conversations and files into polished content without leaving the workspace. Slackbot reads context from conversations, Canvases, and shared files, then routes requests to more than 70 connected Adobe tools. It requires a qualifying Slack plan, Business+ or Enterprise+, plus a separate Adobe subscription.

Full article content is not available for inline reading.

Read the original article →

Agent optimization reduces AI costs by optimizing model selection, deployment, caching, prompts, agent configurations, and observability at runtime. Microsoft Foundry combines these capabilities into a continuous optimization loop that measures cost per successful outcome while maintaining quality, latency, and reliability.

HCP Vault Dedicated audit logs can reach Microsoft Sentinel through a Terraform-provisioned Azure pipeline using a generic HTTP sink, Azure Functions or Logic Apps, and Azure Monitor Logs Ingestion.

Tim Andrews' kidneys were destroyed from diabetes and high blood pressure two years ago. At 66, he had no energy or appetite and was too weak to walk. Andrews received a genetically modified pig kidney in January last year, and then lived with it for nine months. He then received a human donor kidney, providing early proof that pig kidneys, while not yet a permanent solution, offer a bridge to transplants with human organs.

Recent studies have suggested that GLP-1 drugs can reduce the occurrence or severity of certain infections, particularly among more vulnerable groups like people with type 2 diabetes.

Dime, a mysterious silver headset tied through leaks, sightings, ads, and codenames to OpenAI, remains officially denied by the company.

Apple's upcoming foldable iPhone—widely expected to be called the iPhone Ultra—will likely support MagSafe despite its extremely thin design. If true, it would give Apple an advantage over Samsung's foldables, which require cases for magnetic charging. Other rumored features include a titanium body, an advanced crease-reducing hinge, split-screen multitasking, and a price above $2,000.

While the foldable iPhone Ultra is expected to dominate headlines, the iPhone 18 Pro may be the more significant upgrade for photographers thanks to a rumored variable-aperture camera lens that could offer greater control over depth of field and image quality. Combined with reports of a larger battery—up to 5,500 mAh on the Pro Max—the device could become Apple's most capable photography-focused iPhone yet, despite an otherwise familiar design.

Designers are now expected to be technically fluent in AI tooling and world-class in craft at once, two full-time jobs whose bars are rising together. The exhaustion has two sources: mistaking engineering velocity for the right ruler, and a feed running on a constant drip of weekend prototypes. Judgment is becoming the scarce resource, and the designers who come out strongest will be rested enough to do it.

Being ignored is one of the hardest situations designers face, but rejection is rarely a dead end for the idea itself. Curiosity beats the ego trap: ask whether others were rejected too, whether the timing was right, and which tradeoffs the decision-maker had to balance. People agree to ideas based on trust more than merit, so asking for feedback beats cataloging a coworker's limitations.

A curated collection of logos to help designers browse and find their next idea.

The University of East Anglia has unveiled a new brand identity built around the idea “Original by Nature,” aiming to reconnect the institution with its history of independent thinking, creative innovation, and environmental leadership. Developed after extensive consultation with students, staff, and stakeholders, the rebrand introduces a refined visual system inspired by the Norfolk landscape, a stronger verbal identity, and a more cohesive strategy designed to support the university's national and international ambitions.

3D artist Andres Zambrano works in ZBrush, Maya, Substance Painter, Marvelous Designer, Unreal Engine 5, and Blender, chasing handcrafted detail and dramatic lighting on heroic figures.

Managed PostgreSQL services reduce the operational tax of self-hosting by transferring infrastructure, patching, backups, high availability, and platform security responsibilities to the provider. Self-managed PostgreSQL remains preferable when organizations need deep control, specialized configurations, unsupported extensions, or have mature platform engineering and operational capabilities.

Cloud-native environments make periodic GRC checks obsolete because infrastructure and configurations change continuously.