Full article content is not available for inline reading.

Read the original article →

In 1946, the 30-ton ENIAC filled a gymnasium-sized room. Fifty years later, Penn students reproduced its architecture and capacity on a fingertip-sized chip. Computing’s familiar story sent yesterday’s machine from room to desk to pocket.

But engineers spent density in another direction too. ASCI Red kept the room and crossed one teraFLOP. Internet companies filled warehouses with coordinated servers. By 2009, Google engineers called the data center a “warehouse-scale computer.” Density could put yesterday’s workload in less space, or more workload inside yesterday’s walls.

Give several AI endpoints the same hard question under a ten-second deadline. One spends nearly the whole interval on its answer, while another responds almost at once, and we call it “blazingly fast.” That language conflates speed with time. We describe latency in the language of speed, but what impressed us was the short wait, not the rate. Decode speed measures output tokens per second, while latency measures time to a useful result. Faster decoding creates a choice: finish the same computation sooner or put more computation inside the deadline. Call that useful extra work the deadline dividend. It can fund another strategy, a critic, a check, or recovery after failure.

On August 13, the thought experiment became a product. OpenAI opened a limited API preview of Ultrafast for GPT-5.6 Sol and reported up to 750 output tokens per second, as much as 14 times Standard speed. In Cerebras’s six-task GDP-Val comparison at medium reasoning, GPT-5.6 Sol finished in 83.0 seconds on Ultrafast and 464.2 seconds on Standard, a 5.59-times end-to-end gain under settings Cerebras describes as quality-matched. The faster path runs on Cerebras.

Artificial Analysis’s August 13 snapshot supplies a wider comparison for gpt-oss-120b. Cerebras decoded at 1,790.3 tokens per second. SambaNova, the next-fastest listed endpoint, reached 701.3 tokens per second, compared with 476.1 for Groq and 170.7 for the 16-endpoint median. Cerebras ran 2.55 times as fast as the runner-up and 10.49 times as fast as the median.

The snapshot also scored the configured Cerebras endpoint at 87.28% accuracy and SambaNova at 98.15%. For capability, Sol provides the stronger comparison because GPT-5.6 Sol ran at medium reasoning on both paths under settings Cerebras describes as quality-matched.

Assume one second of overhead, a 500-token answer, and the measured rate for sequential generation. Generated-token headroom reaches 1,036 at the provider median, 5,812 for the runner-up, and 15,613 for Cerebras. For gpt-oss’s exposed reasoning trace, Cerebras offers a modeled token budget 2.69 times the runner-up’s and 15.07 times the median’s. How much more capability can that buy? Existing reasoning and selection methods can spend the extra serial tokens now. Future models can learn to use larger TTC budgets well. Faster inference can also put model decisions on the live execution path, where serial agent loops compound the gain.

What the speed test measures

The gpt-oss comparison uses 10,000-token prompts and rolling 72-hour medians. Each endpoint combines hardware, quantization, software, scheduling, and provider settings. The capture recorded Cerebras’s first chunk at 0.53 seconds and first answer token at 1.65 seconds.

Time to first token includes request handling, queueing, prefill, and initial generation. Once text starts, output speed records the average number of tokens received per second. Its reciprocal is average inter-token latency. End-to-end latency measures the full wait for a useful result. Batching can raise fleet throughput independently of the stream speed seen by one user.

Artificial Analysis’s benchmark sends one prompt at a time and calculates output speed after the first token. gpt-oss exposes an autoregressive reasoning trace, so the measured rate shows how much fits before a deadline.

Spending the dividend

Researchers call computation spent after a prompt test-time compute, or TTC. Intrinsic TTC can lengthen one autoregressive path, whose pace depends on single-stream decode. Extrinsic TTC adds samples, critics, verifiers, or tools around the model. Parallel branches trade concurrency and aggregate compute for less wall-clock time. A selector must still turn candidate coverage into one answer.

Training determines whether extra inference compute helps; the request budget determines how much of the learned process runs. Current systems can spend the dividend on another strategy, a contradiction check, verification, or recovery after failure.

OpenAI’s o-series paired larger TTC budgets with a generational jump in reasoning performance. OpenAI says reinforcement learning taught o1 to reason productively, with performance rising alongside training compute and thinking time. On AIME 2024, single-sample accuracy rose from GPT-4o’s 12% to o1’s 74% at its highest TTC setting. For o3, OpenAI reported another order of magnitude in reinforcement-learning compute and inference-time reasoning, with further gains. Snell and colleagues made prompt-adaptive TTC over four times as efficient as best-of-N on tested math problems. In some FLOPs-matched cases, a smaller PaLM 2 beat one roughly 14 times larger.

Cerebras packages this approach as CePO: plan, sample, compare inconsistencies, then choose through structured Best-of-N. Cerebras reports spending 10 to 20 times the one-shot budget, generating about 100 tokens per second on Llama 3.3-70B, and beating Llama 3.1-405B on selected benchmarks. OptiLLM can send the workflow to several providers. CePO shows one concrete way to spend inference speed on additional reasoning and selection.

When inference becomes execution

Karpathy calls natural-language programs executed by an LLM “Software 3.0.” When a model decides what a live application does next, inference latency becomes execution latency. One decision can create value. A fraud signal before a transaction clears can block it, while an incident diagnosis during a failure can guide the response. Faster frontier inference can move those decisions from a background process onto the live path. Tool use compounds the effect because the model emits a call, the client executes it, and the result becomes the next state. Cost determines how many calls a product can afford; latency determines how many it can put in a row. Routing can send routine steps to a smaller model and hard turns to a frontier model.

Codex-Spark shows what happens when model generation stops dominating the clock. OpenAI runs the smaller real-time coding model on Cerebras above 1,000 tokens per second. API overhead became material, prompting caching, fewer network hops, and persistent WebSockets. OpenAI reports agent loops up to 40% faster end to end. Developers can interrupt, redirect, edit, test, and retry midstream.

plan → search → inspect → edit → test → diagnose → retest → report

Give each step 0.75 seconds of fixed overhead, 1,000 output tokens, and a 1.5-second tool round trip. At the 170.7-token-per-second provider median, the loop takes 64.9 seconds. At Cerebras’s captured 1,790.3-token rate, it takes 22.5 seconds. Under those assumptions, a 30-second deadline requires at least 667 tokens per second. At that threshold, speed decides whether the program runs in the request path or a background job.

Cerebras’s public API currently lists two tool-capable models. Its dedicated catalog lists 43 configurations from 12 publishers, plus custom weights. Enterprises can route routine turns to smaller models and hard turns to larger ones.

Exhibit: when raw speed survives the clock

Under the stated assumptions, the base ten-second case yields 2.69 times the runner-up’s modeled serial-token budget and 15.07 times the provider median’s.

A fixed deadline has to accommodate overhead, tools, verification, and the answer. A completion cap can further constrain the reasoning budget.

For one serial path, model total time as

T = F + (B + A) / s + U + V

T, F, B, A, s, U, and V represent the deadline, fixed request overhead, reasoning tokens, answer tokens, decode rate, tool time, and verification or selection, respectively. Fixed overhead includes the queue, prefill, and time to first token. With completion cap C, B = max(0, min{s(T-F-U-V)-A, C-A}). Fitting m times the baseline budget requires

Srequired = (mB₀ + A) / (B₀ + A)

Parallel branches can overlap in wall time, but each adds total compute. The table sets U and V to zero to isolate serial work. The loop above includes tool time. Rates come from the capture. Deadlines, overhead, answer lengths, the four-times target, and constant rates are assumptions.

The next scaling lever

Current models can spend that room on longer thought, another candidate, a check, or another action. Training models to use larger budgets well could add a scaling lever.

Training scaling followed a simple recipe: add parameters, data, and compute. DeepMind found model size and training tokens should grow together, increasing data demand. Epoch AI estimates frontier developers could use the quality- and repetition-adjusted stock of public human text between 2026 and 2032 if trends hold. Synthetic, private, multimodal, and reused data could extend the runway.

Pretraining commits compute and data before deployment. TTC allocates compute after a request, giving harder problems larger budgets. Reasoning-oriented training can make inference compute more productive. Faster infrastructure can make larger budgets practical within a fixed deadline. Future training can then target that expanded budget.

From a fast endpoint to a market position

Speed becomes a large business when answers lose value while the model works. OpenAI highlights incident response, finance, voice, commerce, and research. Crossing from a background job to a live interaction enables a different product. Its commercial value depends on the all-in cost of a correct, timely outcome.

Cerebras credits the WSE-3’s 900,000 cores, 44 GB of SRAM, and 21 PB/s of memory bandwidth for its performance. It pipelines model layers across wafers, keeping weights close to compute. Artificial Analysis independently measures the complete endpoint. OpenAI’s launch puts its flagship model on Cerebras.

OpenAI committed to buy 750 MW through 2028, advanced about $1.0 billion, and holds an option for another 1.25 GW by 2030. It already runs Codex-Spark and Sol Ultrafast on Cerebras, putting its flagship model on wafer-scale inference through OpenAI’s API.

Cerebras says it agreed with OpenAI to co-design future models for future Cerebras hardware, a path for training and hardware to adapt to a shared latency envelope.

Amazon plans Trainium for parallel prefill and Cerebras CS-3 for serial decode. Its agreement includes a multiyear lease and purchase options, and Cerebras targets production in Q1 2027. That split defines a valuable wedge because Cerebras can specialize in serial decode while other hardware handles training, prefill, or batched serving.

At June 30, Cerebras held $8.6 billion in cash, cash equivalents, restricted cash, and short-term investments. It says more than 600 MW was live or contracted for delivery by year-end 2027, 2026 manufacturing capacity would grow more than tenfold, and required TSMC wafers were secured.

Artificial Analysis lists the measured Cerebras endpoint at $0.75 per million output tokens, 25% above the provider median. In the base case, quadrupling the modeled serial budget uses 3.02 times as many output tokens and 3.78 times the spend. The larger budget earns its premium when verification, recovery, or better answers lower the all-in cost of a correct, timely result.

Competitors attack other parts of the clock. Batching raises throughput, while smaller models, caching, and routing reduce work. Faster tools and pipelines cut external and first-token delays. For supported models on which Cerebras sustains a matched-quality decode lead, it accelerates serial generation directly.

The OpenAI contract has begun turning into revenue. Cerebras recorded $180.1 million of GAAP Q2 revenue, including $126.0 million from cloud and other services and $56.8 million under the OpenAI arrangement. Remaining performance obligations reached $25.4 billion. Core cloud gross margin rose from 26.0% to 41.8%. GAAP cloud gross margin was 19.5% after customer-warrant amortization, stock-based compensation, and pass-through revenue and costs.

Cerebras sits at the junction of all three. CePO turns fast inference into additional reasoning and selection today. The OpenAI co-design agreement opens a path toward models trained for larger TTC budgets. Cerebras’s tool-capable models and broader catalog give Software 3.0 a fast execution layer across model sizes. OpenAI distributes Spark and Sol, while AWS adds a future cloud channel.

As components grew denser, engineers could put the same computation in a smaller machine or keep the building and put more computation inside it. Fast inference recreates that choice in time. The same speedup can finish the old workload sooner or keep the deadline and fill it with more reasoning and action.

By the end of 2028, Cerebras must beat the best matched-quality commercial alternative by at least twofold at p95 end-to-end latency under the same output contract and disclosed concurrency. Decode must account for the largest reducible delay, added TTC must lower all-in cost per correct result, and paid service must produce a positive contribution margin. Clear those hurdles on one serial workload, and Cerebras has a wedge. Repeat the result, and the company sells something much larger than speed: more capability and more action before the clock runs out.

Linked source notes

Evidence key. Fact marks directly reported data within its stated scope. Interested-party claim flags a vendor, customer, or issuer with commercial incentives. Calculation follows displayed assumptions. Inference interprets evidence. Speculation names a testable possibility. Sources were accessed August 11 through 18, 2026. Artificial Analysis figures use the August 13 capture.

Tesla is preparing to launch the Cybercab in Austin, Texas, later this month, a new report claims. Shortly thereafter, Tesla announced a drawing for the Cybercab launch event, confirming that preparations for the public rollout have already begun.

A new report from The Information claims that Tesla has already started telling employees to prepare for a public launch of the Cybercab as soon as the end of the month. The vehicle will launch publicly to riders in Austin initially.

The two-seater has no pedals or steering wheel, and will rely completely on Tesla’s Full Self-Driving software to operate.

While the report went unconfirmed from Tesla, the company launched a lottery to ride in a Cybercab at an upcoming launch event, essentially confirming that preparations are underway:

Ride in Robotaxi through 8/23 for a shot to attend our Cybercab launch event

More rides = better odds

— Tesla Robotaxi (@robotaxi) August 18, 2026

Cybercab entered production at Gigafactory Texas back in April, with initial units being test mules for the company as it has put the car in a variety of environments and climates. Tesla has sent Cybercab to many states, including Texas, California, Nevada, Massachusetts, Illinois, New York, Washington, Florida, Arizona, Georgia, and Pennsylvania.

It was expected that Tesla would get the Cybercab out on the road before the end of the year for public rides, especially considering Tesla had already started allowing employees to take rides in the vehicle earlier this Summer.

Tesla starts testing its Starlink-integrated Cybercab on public roads

This is a huge development, not only with the Cybercab program, but for Tesla’s self-driving program. Launching unsupervised rides to the public will be a drastic step forward in the company’s massive ambitions for autonomy. It is a long time coming, too. Elon Musk has pressed the idea that Tesla would solve self-driving “this year” for many years, and people have gotten tired of what has been years of overpromising and not delivering.

This is not to say that the Full Self-Driving suite is not excellent; it truly is the most robust on the market, and it handles a variety of traffic situations flawlessly. It definitely has its faults, but generally, it is fantastic.

Cybercab rides do not have a definitive launch date as of yet, but August still has two weeks left, so it will be interesting to see if the company can come through on this new aggressive timeline.

Tesla reveals plans for Robotaxi charging hub in Austin

Tesla has revealed plans through permit submissions for a massive Robotaxi charging hub in Austin, Texas.

Tesla plans to build the Supercharger hub in multiple phases, with the second phase potentially introducing wireless induction charging, something the company has been developing for the Robotaxi fleet.

Initially, 48 Tesla Robotaxi-geared Superchargers will be built on a lot just across from the St. Elmo, Texas, Service Center. There are about 80 additional spots that will not be impacted by phase 1 of the construction process.

Filings show that the second phase of the project will turn those 80 additional spots into wireless charging for Robotaxi, but it might be an error. The Key Notes state that item 3 is listed as “V4 Charging Cabinet to Support 80 Wireless Chargers in Phase 2. However, the drawings point to V3 Cabinets that are already tied to Superchargers:

There are roughly 128 total spots in the lot, but it is unclear if they will all be used for charging based on what appears to be some sort of typo in the blueprint.

A new Robotaxi fleet charging hub is coming soon to Austin, Texas!!

Permits have been filed for the installation of 48 (V3) stalls in a vehicle storage lot across the road from Tesla’s St Elmo service center.

— MarcoRP (@MarcoRPi1) August 18, 2026

This is among the first Robotaxi charging hubs Tesla has started to develop, as it currently has four others planned throughout various areas: one in Phoenix, one in San Antonio, another in Irving, which will serve the Dallas-Fort Worth area, and another in Las Vegas.

These projects are necessary as Tesla expands its Robotaxi program. Now that preparations have started for the public launch of Cybercab, Robotaxi will likely be expanding aggressively, especially over the next two to three years.

Tesla Semi gets its largest order yet

Tesla got its largest order for the all-electric Class 8 Semi yet, a 500-unit order from Einride AB, a Swedish trucking company.

Einride made the announcement this morning following its second-quarter earnings call. The company said it plans to use 500 Tesla Semi units on its fleet intelligence platform, called Saga AI. The deployments will serve large companies like Amazon and will extend Einride’s electric freight network across logistics routes in California, New Jersey, Texas, Illinois, and Georgia.

Tesla has received a MASSIVE order from Swedish freight company Einride AB, which placed an order for 500 Tesla Semi trucks

Tesla’s biggest order for the Semi yet!

— TESLARATI (@Teslarati) August 18, 2026

The deployment is being carried out in several phases over the next two years as Tesla ramps production of the Semi at its dedicated production facility in Sparks, Nevada. Einride will receive its first Semi units in September.

Saga AI

Saga AI is Einride’s dedicated fleet intelligence platform. It enables scaled adoption of electric trucks for freight use and allows shippers to integrate electric capacity without the operational burden or capital risks of managing a fleet. This helps integrate cost-efficient logistics and makes budgeting and forecasting much more accurate.

Tesla Semi’s Adoption

The Tesla Semi is now gathering large-scale clients past those who have helped the company operate a Pilot Program to gain initial information and feedback from real-world drivers.

Perhaps the biggest and most notable is that of Frito-Lay and PepsiCo., who have worked with Tesla for the past several years to dial in the finer details of the truck, including its efficiency and operation-related components.

There has been tremendous progress in that time, and it even catalyzed Tesla to make some design changes, which were unveiled earlier this year.

But Einride CEO Roozbeh Charli says his company’s partnership with Tesla will continue to push those things forward:

“This deployment is yet another proof point that we can execute at the scale our customers demand. Working closely with Tesla to bring next-generation Semis into active operations quickly and at scale is a testament to the strength of that partnership, and how quickly this technology is maturing from promise to daily operations.”

Additionally, Dan Priestley, the Director of the Semi Program at Tesla, said the partnership is ideal due to Einride’s focus on sustainable transport:

“Einride is at the forefront of sustainable freight, and we are thrilled to deepen our relationship with them through this order of 500 Semis. EV heavy trucks provide lower costs per mile from fuel savings, reduced maintenance, and better uptime over diesel trucks. These savings increase further through operational efficiency when deploying EV trucks at scale, and we are excited that Einride recognizes this and look forward to supporting their deployments.”

India tells Elon Musk’s X to “Follow the Law” in latest censorship update

Elon Musk’s promise to make government censorship requests on X “clearly visible” is running into a wall in India, where the law forbids the very disclosure Musk is promising.

On August 15, Musk responded to an update from X’s open-source algorithm team by writing “Any censorship required by governments is now clearly visible.” The claim referred to a change X pushed two days earlier to its public xai-org/x-algorithm repository, which now includes a controversial filter written directly into the code. The filter suppresses posts from 665 accounts flagged by Brazil’s Superior Electoral Court from appearing in the For You feed of any viewer located in Brazil, unless the viewer already follows the account. The election tied to the filter is scheduled for October 4.

India’s government wasn’t as impressed, and responded on Monday that “X will have to follow the law of the land.” The problem is structural rather than political. India issues content blocking orders under Section 69A of its IT Act, and Rule 16 of the accompanying 2009 Blocking Rules requires those orders to stay confidential. Publishing an India equivalent of the Brazil filter, naming specific accounts and citing specific government orders, would itself violate Indian law. Government use of Section 69A has grown from roughly 6,000 orders a year between 2018 and 2023 to about 24,300 in 2025.

The contrast puts Musk’s transparency pledge in an odd spot. It works largely as advertised in Brazil, where electoral law requires disclosure and X can point to specific account IDs and a specific court order in public code. It cannot work the same way in India, where the law requires the opposite. X users in India will keep seeing content disappear from search and their feeds without any public accounting of why, even as X tells the rest of the world that its censorship compliance is now inspectable.

This isn’t the first time X’s fights with a national government have shaped how the platform operates. Brazil’s Supreme Court ordered X to suspend the accounts of sitting lawmakers and journalists in 2024, a standoff that cost X its Brazilian revenue for months and froze Starlink’s local accounts before the investigation into Musk and X was closed in March with no evidence of wrongdoing found. X also sued California over a state law requiring moderation disclosures, arguing the mandate itself violated the First Amendment.

Whether India’s government pursues anything beyond a public statement remains to be seen. For now, the mismatch between what X can legally publish and what different governments legally allow it to publish is the real story behind Musk’s seven word claim.

Waymo vs Tesla: Two Ways to Build Self-Driving Cars

A vehicle travelling at 40 miles per hour covers about 60 feet every second. Within that second, software has to determine what is physically nearby, classify each object, estimate where those objects will move, select a path, and issue steering and braking commands.

Doing all of this quickly is something that has been largely solved. However, doing this correctly in unpredictable and distinct traffic situations is still an open problem. This is because real-world traffic produces more distinct scenarios than any team can pre-determine. For example, Waymo describes one such case, where a vehicle is on fire on the road ahead while the drivable lanes remain physically clear. The geometry of such a scenario might permit driving straight through it. However, the real meaning of it calls for turning around or taking preventive action.

Waymo and Tesla, two companies investing in self-driving cars, have tried to come up with different types of answers to these questions.

For reference, Waymo reports 220.6 million rider-only miles through March 2026. These are miles covered with no human in the driver’s seat, across five metro areas. On the other hand, Tesla reports more than three million vehicles in the United States covering over 30 billion miles a year, with 1.28 million active Full Self-Driving subscriptions in the first quarter of 2026. Almost all of those Tesla miles involve a driver who remains responsible for the vehicle. Tesla’s driverless service is separate and much smaller, running without safety monitors in Austin, Dallas, and Houston, while the Bay Area service uses a safety driver.

Both approaches depend heavily on machine learning. But they differ in how much gets fixed in advance. In this article, we will take a look at both approaches while trying to answer the following questions:

• How does each system detect what is physically nearby?
• What each builds from that data, and why one keeps the result readable?
• How each estimates what other road users will do?
• How a path gets selected, and what verifies it before the vehicle acts?
• What safety evidence each publishes, and why the figures measure different things?
• Where does the knowledge inside each system come from?

Sensing

A camera records light intensity across a grid of pixels. Distance appears nowhere in that grid, so depth has to be computed from the arrangement of pixels, but that computation can be wrong. A large object far away and a small object nearby can occupy the same region of an image.

Lidar arrives at the same answer by a different route. The unit emits laser pulses, measures how long each pulse takes to return after reflecting off a surface, and converts that interval into a distance. We can think of the output of this as a point cloud, which is a three-dimensional set of measured points describing the surfaces around the vehicle. The distance is no longer an estimate but a measurement.

Waymo’s sixth-generation system, which began fully autonomous operations in February 2026, carries 13 cameras, four lidar units, six radar units, and a set of external audio receivers used to detect sirens and railroad crossings. Coverage overlaps in every direction and extends to 500 metres. This overlap is for help situations when rain, road grime, or ice limits what a camera captures. Lidar and radar sustain the perception capabilities in such scenarios.

Tesla’s vehicles mainly rely on cameras. Instead, Tesla relies entirely on a “pure vision” approach that uses exterior cameras and artificial intelligence to navigate. For example, Tesla’s documentation describes Model 3 and Model Y as running camera-based Tesla Vision, without radar, using cameras and neural network processing.

Waymo’s fifth-generation Jaguar I-PACE vehicles carry 29 cameras. The sixth-generation system carries 13, which Waymo attributes to a 17-megapixel imager covering the same area with fewer than half the cameras. In other words, Waymo is also reducing overall sensor count while continuing to describe redundancy as essential.

The tradeoff here is that a direct measurement costs money while adding a component that can fail noticeably. However, a derived value may not cost much, but it can be wrong as well.

Representation

Something has to convert millions of pixels and points into a description that the system can understand and operate on. The nature and form of that description is one of the most important architectural decisions for an autonomous driving setup.

Waymo places the Waymo Foundation Model at the centre, built from two components:

• Sensor Fusion Encoder: It merges camera, lidar, and radar data over time and outputs objects, semantic attributes, and embeddings. These are compact numerical summaries that downstream components consume.
• A Driving VLM: Trained using Gemini and fine-tuned on Waymo driving data, they cover rare situations requiring background world knowledge, such as the burning vehicle example mentioned earlier.

Both feed a World Decoder that forecasts the behaviour of other road users, produces high-definition maps, generates candidate trajectories, and emits signals used to verify them.

The system maintains compact structured representations, meaning explicit lists of objects, their semantic attributes, and roadgraph elements describing lanes and connections. The Waymo engineering team provides three reasons for such a setup:

• Correctness and safety validation can run at inference time, while the vehicle is moving
• Simulation runs efficiently at large scale, because a compact world state is cheap to replay and modify
• Training feedback becomes verifiable, since a component evaluating driving quality has something concrete to measure

This design provides significant benefits over pure end-to-end or modular approaches.

Tesla’s documentation talks about per-camera networks performing semantic segmentation, which assigns every pixel to a category, plus object detection and monocular depth estimation, meaning distance estimated from a single camera. Those feed birds-eye-view networks that output road layout, static infrastructure, and three-dimensional objects in a top-down view. A full build involves 48 networks taking nearly 70,000 GPU hours to train and producing 1,000 distinct tensors per time step.

Prior mapping also occupies one end of this decision. For example, Waymo surveys a territory before operating there, recording lane markers, signs, curbs, and crosswalks. It then matches those maps against live sensor data to establish position, since GPS alone can lose signal. The map is basically knowledge acquired once and reused. It saves computation on every trip, but also creates an obligation to keep it current. In contrast, Tesla’s approach skips the survey and derives equivalent information during the drive.

The trade-off is that a structured representation can be inspected, logged, replayed, and checked against explicit criteria. But it limits what the system can express. On the other hand, a learned representation carries nuance no schema can anticipate.

Prediction

Once the system holds a description of its surroundings, the next task is estimating what those objects will do. Several futures are valid at the same moment. For example, a cyclist approaching an intersection might continue straight, turn, or stop. A safe response should account for all possibilities.

Waymo describes the system as producing many possible paths for each road user rather than one, drawing on accumulated driving data and accounting for the different ways a car, a cyclist, and a pedestrian move.

In June 2025, Waymo published research on whether prediction quality scales predictably. Using an internal dataset spanning 500,000 hours of driving, the study found that motion forecasting quality follows a power law in training compute, matching a pattern observed in language models. A power law here means each doubling of compute yields a proportional, predictable improvement. Data scaling proved critical, and increasing compute at inference time improved performance on harder scenarios.

Waymo reported the same trend in closed-loop performance, where results are measured in simulations in which the system’s own actions change what happens next. This trend suggested that real-world driving improves with more data and compute, rather than only benchmark scores.

Tesla’s describes an upgraded reinforcement learning stage in version 14.3, intended to cover long-tail edge cases, meaning rare situations that appear infrequently even across very large mileage.

A system that commits to one predicted future becomes fragile in situations where prediction matters most. However, carrying several weighted futures costs compute on every cycle, but can guard against the possibility of unusual situations.

Planning

With a description of the surroundings and a set of likely futures, the system selects a trajectory. You can think of it as a specific path with speeds attached to it. The question is what verifies the trajectory before the vehicle executes it.

Waymo trains large Teacher models to generate safe, comfortable, and compliant action sequences. It then distils them into smaller Student models sized to run onboard in real time. Distillation transfers behaviour from a large model to a compact one. Output from that Student model then passes through a separate onboard validation layer, which verifies the trajectories the generative model produced. This means that two independent components have to agree before the vehicle moves.

Tesla talks about building a planning and decision-making system that operates under uncertainty, with algorithms evaluated at the scale of the entire fleet, optimising for throughput, latency, correctness and determinism.

For Tesla vehicles on the road today, verification comes from a person. Full Self-Driving (Supervised) requires an attentive driver and leaves the vehicle slightly short of autonomous. The system enforces this through a strikeout mechanism, where repeated inattention warnings disengage the feature for the remainder of a trip. Enough strikeouts suspend access for a week. In the driverless service, that role belongs to safety monitors or remote supervision.

A validation layer catches a category of unacceptable outputs before they reach the actuators, and it can only evaluate against the defined criteria. Anything outside those criteria passes through unexamined. This is the same tradeoff as an assertion in production code, where the check is only as good as the condition behind it.

Validation

Waymo’s Safety Impact hub reports 220.6 million rider-only miles through March 2026, meaning no human occupied the driver’s seat for any of them. Measured against human crash rates in the same operating areas, adjusted for where within each city the service drives, the reported reductions are 94% for serious injury or worse crashes and 82% for injury-causing crashes. The methodology has been published in peer-reviewed journals, and the raw data is downloadable so third parties can reproduce the figures.

Tesla’s Vehicle Safety Report takes a different form. It compares Teslas with Full Self-Driving (Supervised) engaged against Teslas driven manually, using the same telemetry pipeline for both, and reports 7 times fewer major and minor collisions and 5 times fewer off-highway collisions. A collision counts as occurring with the system engaged if it was active at any point within five seconds beforehand, a window chosen to capture cases where a driver took over shortly before impact. Tesla attributes no fault in the reported data, treating that determination as too subjective to include.

As you can see, the two reports answer different questions, and we can’t simply do a side-by-side comparison. The difference comes down to what each population represents:

• Waymo is measuring outcomes across miles where no person was available to intervene.
• Tesla is measuring whether an assistance system reduces collisions while a driver remains responsible.

Both companies also state their own limitations. Waymo states that no perfect comparison between autonomous and human data exists today, and that its operating cities see no appreciable snowfall. Tesla states that its estimate of a United States average involves unavoidable assumptions that may skew the figure in either direction.

Waymo separates two things that are easy to conflate. Safety impact gets measured after deployment. Whether a release is acceptable to deploy at all gets determined beforehand through a Safety Framework and a Safety Case.

Training

Both systems improve between releases. However, the underlying mechanisms differ as much as the architectures.

Waymo runs three components off the same foundation model:

• The Driver produces action sequences.
• The Simulator generates scenarios for training and testing.
• The Critic evaluates driving quality and surfaces problems.

Large versions of each get distilled into smaller ones that run at the required volume. Two loops connect them:

• An inner loop applies reinforcement learning inside simulation, where scenarios can be generated and repeated cheaply.
• An outer loop begins with the Critic flagging suboptimal behaviour from real driving, turns improved alternatives into training data, verifies the fixes in simulation, and deploys only once the safety framework confirms the absence of unreasonable risk.

Waymo states that its fully autonomous mileage now far exceeds its manually driven data, and that no volume of simulation or test-driver operation reproduces the situations encountered when the system operates with no driver present.

Tesla’s data comes from a consumer fleet. The Vehicle Safety Report describes two telemetry paths. On shifting to park, a vehicle transmits anonymised mileage broken down by control type and road classification. On detecting a major or minor collision, it transmits a separate packet tied to the vehicle. Tesla reports receiving 2.5 billion telemetry packages in the third quarter of 2025 alone. Tesla has also built an evaluation infrastructure from anonymised fleet clips assembled into test suites, alongside simulation producing sensor data for automated testing. Training runs on Cortex 1, listed at over 100,000 H100-equivalent GPUs in production, and Cortex 2 at over 130,000 in early ramp.

Conclusion

The same question recurs at every stage of an autonomous driving process. How much gets determined in advance and written into a form that can be examined, and how much gets computed during the drive by a model whose internal state stays out of reach?

Each stage poses one version of it:

• Sensing asks whether distance arrives as a measurement or as a derived value
• Representation asks whether the description of the world stays inspectable
• Prediction asks how many futures the system carries at once
• Planning asks what verifies a trajectory before execution
• Validation asks what kind of safety claim the resulting evidence can support
• Training asks which miles improve the system

Waymo sits further toward written-down knowledge at most stages. This involves per-city preparation and purpose-built hardware. Tesla sits further toward computed knowledge. Both positions have merit, and only the future will tell which approach becomes more dominant or do things fall somewhere in the middle.

Cursor is currently rolling out its Origin code hosting platform to paid users. The launch coincided with a GitHub outage that lasted over six hours. Origin allows users to connect GitHub repositories, so they do not have to move platforms. Allowing GitHub to stay as a source of truth means it costs nothing for organizations to try Origin and nothing breaks if it is abandoned.

In short: Explains test-time training through the analogy of a GPS learning a persistent shortcut around daily traffic rather than a one-time reroute: the model takes a gradient step on the prompt it's answering, so its weights change as it works. Traces three implications, flat memory instead of a linearly growing KV-cache, the provider cost of serving a separate model per user, & faster inference, then states the tension as a tradeoff between serving long context and serving many people, & grounds it in concrete use cases, a coding agent that earns back its per-user cost over a long session versus a one-off query a shared frozen model handles just as well.

Every model you’ve ever used froze the day its training ended. The answers are the same even if you have used it every day.

What if a model kept learning as you use it?

A GPS learns a persistent shortcut around daily traffic on northbound Highway 101, not just a one-time reroute. Test-time training does that to a model as it works. As you use the AI, the model changes its weights, changes how it thinks about its memories, to answer you better.

The changes are more profound than finding an off-ramp to an access road past a highway junction chokepoint.

Memory requirements plummet. A standard transformer keeps a KV-cache, a running record of every earlier token, so its memory grows linearly with context, every additional token adds to the running record. Test-time training folds that history into a fixed-size set of weights instead of a growing cache, so memory stays flat no matter how long the conversation runs.

The model provider now has to serve a separate model to each person. Once a model updates on your prompt, it is no longer the model that answered your neighbor’s, so a single checkpoint serving millions of users becomes millions of slightly different models, each shaped by the person using it. That divergence is the provider’s problem to solve: a GPU provider needs a copy in flight per user instead of one shared copy for everyone, which means more compute, more chips, to serve the same number of people.

It’s much faster. Stanford research on small models indicates it can be up to 2.7 times faster, because a test-time trained model’s inference latency stays constant no matter how long the context runs, the way a standard transformer’s does not. In-Place TTT also ships drop-in, lifting a 4b model to competitive 128k-context performance with no retraining.

Here is the tension. Standard AI is limited by memory, test-time AI is limited by compute & chips, so a provider picks based on whether it’s serving long context or serving many people.

That cost is only worth paying where personalization earns its keep. A coding agent that learns your codebase’s conventions, the resilient persistent bugs, ultimately should provide some form of lock-in via memory, so the per-user cost pays for itself. A one-off customer support question doesn’t need any of that. A shared, frozen, potentially fine-tuned model answers it just as well & costs the provider far less to serve.

Test-time training will be a key part of the discourse throughout the end of 2026 & beyond. It has the potential to change the current economics of AI.

1. Sun et al., Learning to (Learn at Test Time): RNNs with Expressive Hidden States
2. End-to-End Test-Time Training for Long Context
3. In-Place Test-Time Training

Agent Memory (Research Preview)

Agent Memory is a persistent memory system that lives on Warp and is shared across every supported agent harness, including the built-in Warp Agent, Claude Code, Codex, and others as they're added. Agents read from and write to this memory system as they run, so durable facts, decisions, and outcomes from one conversation are available to the next — regardless of which harness, machine, or teammate triggers the work.

Memory creation and retrieval are asynchronous and run in the background, so they don't consume tokens or add latency to the active task.

Key features

• Cross-harness memory - One memory system is shared across the Warp Agent, Claude Code, Codex, and other harnesses as they're added. Third-party harnesses are covered when they run as cloud agents.
• Both local and cloud agents - Supports interactive local agents in Warp and background cloud agents.
• Asynchronous by design - Memory creation runs after a conversation ends. Retrieval runs in the background during a run. Neither consumes tokens or adds latency to the active task.
• Automatic memory creation from conversations - When a conversation ends, Warp extracts durable facts, learnings, and outcomes and writes them as memories. New knowledge merges with existing memories or supersedes them on conflict.
• Shareable stores - Memory is organized into stores. A store can be attached to one or more agents, so the same knowledge is available wherever those agents run. To share knowledge across a team, attach a store to an agent the whole team uses.
• Auto-memory for new agents - New agents get a dedicated, agent-owned memory store by default, so they start building long-term memory from their first run. You can turn this off when you create the agent.
• Per-agent access and instructions - Attach stores to specific agents with read-only or read-write access. Per-store instructions tell each agent how and when to use the store.
• Traceability - Each memory records where it came from, so teams can trace a memory back to its source.
• Auditability - Every change to a memory is recorded so teams can inspect how a memory has changed over time.

Where Agent Memory runs

Agent Memory is part of Warp. Storage, memory creation, and retrieval all run on Warp alongside your agents. The same memory is accessible from any agent you run in Warp:

• The local Warp Agent.
• Cloud agents triggered from the CLI, web app, schedules, or integrations.
• Third-party harnesses running as cloud agents: Claude Code, Codex, and others as they're added.

Memory stays bound to its owner (a user, an agent, or a team), independent of which harness reads or writes.

Memory stores

A memory store is a collection of memories. Stores are used by attaching them to agents: a store can be attached to a single agent or to several agents that need the same knowledge. To make knowledge available across a team, attach a store to an agent the whole team uses; there's no separate step for sharing a store with individual teammates.

Stores differ by who owns them:

• Personal stores - Owned by a user. Hold memories about preferences, working notes, and individual patterns.
• Agent stores - Owned by an agent. A new agent gets one by default as its auto-memory store (see below).
• Team stores - Owned by a team. Hold shared knowledge like deployment runbooks, code review conventions, or on-call procedures.

Teams can use multiple stores to keep contexts separate, and attach the same store to several agents when needed.

Auto-memory for new agents

When you create an agent in the Oz web app, Auto-memory is on by default. With it enabled, Warp creates a dedicated memory store owned by that agent and uses it as the agent's default long-term memory: the agent reads relevant memories before it acts and writes durable facts, decisions, and preferences for future runs. Each agent has a single auto-memory store.

Automatic memory creation from conversations

When a conversation finishes, Warp extracts durable facts, learnings, and outcomes from the transcript and writes them as memories. Memory creation runs in the background after the conversation ends, so it doesn't consume tokens or add latency during that run.

• Memories evolve over time - Agents update and supersede their own memories as new information arrives, including to resolve contradictions with prior memories.

You can also explicitly ask an agent to remember something during a conversation. Warp saves that memory to the appropriate store.

How agents use memory

When an agent starts a task, Warp searches the stores the agent can access for relevant memories and injects them as context. The search runs in the background, so the agent only sees the memories returned. Agents can also retrieve additional memories on demand mid-conversation when they determine it's relevant. You don't need to write retrieval queries or pre-load memory.

Attaching memory to your agents

Attach stores to agents with read-only or read-write access. Each attachment includes per-store instructions that tell the agent how and when to use the store. Instructions are required on every attachment so the agent knows the purpose of each store.

Coming soon

• Programmatic API access - Read and manage memories and stores through the Oz API & SDK.
• Self-hosting support - Run Agent Memory on a self-hosted Automation Platform instance to meet security, privacy, and compliance requirements.

Full article content is not available for inline reading.

Read the original article →

About

dig.bench is a benchmark of scientific discovery.

Each of its 70 games measures whether an agent can experiment to discover that game's own unknown rules. Every game is text-based, which puts it in the natural domain of language models: no visual confounds stand between a model and the discovery, so what dig.bench tests is discovery alone. Humans and frontier models play the same games with access to the same information, and progress is scored by whether the game can be beaten within a limited number of steps.

The games come in 7 tiers, depending on their difficulty. No game is easy and they all require effortful play, but humans can make the discoveries necessary to solve even our hardest games, while the best models struggle to beat games in the top tier.

Scale

70 new interactive games (21 publicly released).

What qualities of models do we test

To beat each game an agent must discover the unknown rules and apply them to solve challenges.

Evaluation

Humans and frontier models play through the same interface: identical game states, identical action sets, identical step budgets.

Play

21 of the 70 games are public. Tiers get increasingly harder for models (1 = easiest, 7 = hardest).

Reproduce it

Run any model against the games through the SDK or API.

Join us

Join our community DisCo, where you can track your progress on these puzzles and hang out with like-minded folk.

Citation

DiG-bench: Discovery in Games

Ruairidh M. Battleday, Kai Sandbrink, Jimi Cullen-Drohan, Zihan Yan, Timothy Muller, Clare Maguire, Ales Kubicek, Fraser Greenlee-Scott, Sukrit Sumant, Tri Dao, Jürgen Schmidhuber, Michal Valko, Joshua Tenenbaum, Thomas L. Griffiths, Zeb Kurth-Nelson, James C.R. Whittington

@misc{battleday2026dig,
  title={DiG-bench: Discovery in Games},
  author={Ruairidh M. Battleday and Kai Sandbrink and Jimi Cullen-Drohan and Zihan Yan and Timothy Muller and Clare Maguire and Ales Kubicek and Fraser Greenlee-Scott and Sukrit Sumant and Tri Dao and Jürgen Schmidhuber and Michal Valko and Joshua Tenenbaum and Thomas L. Griffiths and Zeb Kurth-Nelson and James C.R. Whittington},
  year={2026},
  eprint={2608.12593},
  archivePrefix={arXiv},
  primaryClass={cs.AI},
  url={https://arxiv.org/abs/2608.12593},
}

Own Your Intelligence: A How-To Guide

Open models can now beat the frontier in specific domains. That changes which parts of your AI stack you should rent, and which parts you should own.

By Sonya Huang, Pat Grady, and Sonali Singh

The calls for owning your intelligence are escalating…

Recently, Alex Karp encouraged enterprises to “own the means of production.” Not long after, Satya Nadella declared that buying intelligence from a frontier lab is like paying twice: once with money, and once with the proprietary knowledge you reveal to make that intelligence useful.

The question everyone is asking: who should own the intelligence at the core of your business?

For anyone around in the DeFi days, you probably remember the meme “not your keys, not your crypto.” We hereby declare the AI version… not your weights, not your product.

To be clear, owning your intelligence is not a mandate nor a recommendation to get off the labs. For many workloads, frontier APIs from Anthropic and OpenAI are still the right answer. But across our portfolio, we are seeing more companies building their own AI capabilities for parts of their products, vertically integrating toward owning and shaping their weights.

A few weeks ago, we at Sequoia brought together a group of AI founders and builders for an event on owning your AI stack. We had Harvey give us the customer-back view. Then Mercor, LangChain, Trajectory Labs, and Fireworks AI walked us through the technical building blocks in the post-training stack.

Across the talks, a clear playbook emerged.

Why now?

First, the open-weight frontier has moved faster than anticipated. Kimi K3 and GLM 5.2 are extremely good! Training on open models used to be a treadmill… you might’ve spent months fine-tuning, and the next frontier release would erase your gains. Now, you can start from a baseline close to the frontier.

Second, the post-training stack has matured. With strong evals, harness engineering, post-training, and online learning, open models can now beat frontier models in specific domains.

A year ago, you chose open weights when performance was something you could sacrifice. Now performance is increasingly a reason to switch.

When should you make the move?

There’s no one-size-fits-all approach. In addition to performance, there may be slices of your product where renting intelligence becomes a constraint because of…

• Cost. The more successful your AI product, the higher your AI COGS. If inference costs scale directly with usage, owning the model is the best way to protect your margins.
• Speed. If you’re operating in a domain like coding (tab autocomplete) or security, a small distilled custom model might beat a large general one, because speed is so important.
• Proprietary data. If your feedback, evals, customer interactions, or domain data are what make the system better, you might prefer that learning loop improves a model you own.
• Control. The app layer and the intelligence layer are starting to merge. The labs are moving up into product, and app companies are moving down into the training loops that define how the product thinks. Owning the product increasingly might mean controlling more of the intelligence itself.

What’s the roadmap?

Assuming you've decided on your strategy for what to own vs. rent, the question becomes: how do you go from zero to one?

Build your team. Don't shoehorn this into a platform team. Sovereign AI needs people playing offense: building evals, shaping data, experimenting with open models, tuning harnesses, and pushing performance in a domain. Small, de novo teams go very far here.

Make the work legible. Every buyer right now is choosing their AI champion. Increasingly, the tiebreaker is published research, benchmarks, or technical posts. If you choose to do wonderful research in-house, share it with the ecosystem.

Execute the technical steps. This is the hard part. We’ve laid out a high level framework below.

1/ Evals

As Gabe Pereyra said: "If you don't have a good benchmark, you can't train models.”

An eval is a set of tasks that measures whether your system can do the work well. Every task contains a prompt, context the model can use, and a grader. Most evals start as a founder squinting at outputs and vibe-checking whether they feel right. The goal is to turn that judgement into something repeatable.

Harvey built its Legal Agent Benchmark by turning real legal work into discrete tasks a model could be tested on. The first iteration includes more than 1,200 agent tasks across 24 legal practice areas, and is evaluated by over 75,000 expert-written rubric criteria.

It’s important to have an eval before making the decision to post-train. Once every agent has an eval, deciding which model to use can be a measured decision instead of a guess.

2/ Harness and context engineering

An agent has three parts: the model, the context, and the harness. The harness governs the product logic around the model: routing, retrieval, tools, memory, fallbacks, and traces. The main job of the harness is to bring context to the model at the right point in time. The more out of distribution the task is for the model, the worse the off-the-shelf harness will be.

A good harness lets you route tasks to the best model for your specific job, reuse the same evals across models, and decide what context and tools an agent gets. It also makes the agent inspectable. You can trace what context went in, which tools were called, and where it got stuck.

3/ Post-training

Post-training covers several techniques. The right one depends on what you’re trying to improve.

If the model is missing facts, use context or RAG. If the output format or behavior is wrong, use supervised fine-tuning. If the issue is product taste, use preference tuning. If the model needs to improve at a specialized task, use RL. If the model is too slow or expensive, distill it.

The goal is to pick the lightest method that moves your eval. Then serve the model through the same harness and measure quality, latency, and cost as it runs.

4/ Online learning

Once the system has its pieces – evals, harness, and model – the final step is improving that system in production.

Models keep getting smarter, but every session feels like it's their first day on the job. You can put Terence Tao in an accounting firm, but chances are (at least on day 1) he won’t be the best accountant there. What's missing is experience, not intelligence. Agents create that experience as they run.

A trajectory is the path through the task: the context the model saw, the tools and sub-agents it called, the answer it produced, and what the user edited, undid, or retried. Capturing those trajectories is necessary to build a continuous production loop. A failed task becomes an eval. Missing information goes into context or memory. A bad tool response becomes a harness fix.

Final thoughts

Buyer beware: owning your intelligence opens Pandora’s box.

The closed-model stack is simple. You call a frontier model, use an out-of-the-box harness, add prompts and context, and ship. That gives you a high floor, but also a lower ceiling.

Owning your stack means taking on more of the system yourself. The production stack becomes your open-source model, custom harness, tools, and context. The development stack becomes your proprietary evals, domain data, and online learning loop.

It is certainly more work! It potentially gives you a lower floor – but it also raises the ceiling.

The labs will keep building the giant brains. We should all use them.

But, in parallel, the best product companies will grow their own little geniuses: fast, opinionated, domain-obsessed, and tuned to the work they see. In a world where more companies take ownership of their own intelligence, the ecosystem flourishes, individuality triumphs, and no single company swallows the rest.

That’s the promise of a world with sovereign AI. And we’re here to support the companies that want to bring that world into existence.

Compound LLM pipelines can gain accuracy while specialized modules quietly abandon assigned roles, creating “role drift” invisible to system-level metrics. Role Anchor constrains this behavior. 86% of one pipeline's apparent RL gains disappeared when its decomposer stayed in role.

Clinic-in-the-Loop

Clinical trials are engines for scientific discovery. Better drugs require not just more trials, but also improved data collection, to create therapeutic feedback loops.

For the last several years, I have been trying to understand why biomedical progress, especially in therapeutics, has become less productive despite staggering advances in basic science.

I am not the only person vexed by this. In 2012, biotechnologist Jack Scannell formally described the dwindling returns on therapeutic investments, coining the term Eroom’s Law (Moore’s Law in reverse). Eroom’s law states that the inflation-adjusted cost to bring a new drug to market roughly doubles every nine years: a trend that has held since the 1950s. With the goal of upending Eroom’s law, I have spent the last year studying the structural bottlenecks that shape how new medicines are tested and the FDA’s role in such decisions.

Much of my time has been focused on clinical trials, which, despite their central role in the creation of pharmaceuticals, receive remarkably little systematic attention. This led me to launch the Clinical Trial Abundance Project, a framework aimed at increasing not only the number of clinical trials, but also their speed and how much we learn from them. Recently, I co-authored an essay with Scannell, arguing that making trials more efficient and informative is essential to breaking Eroom’s Law.

Critics of our essay, however, argued that making clinical trials more efficient risks treating biotechnology like a casino. In their view, making it easier to run clinical trials would risk allowing more potentially harmful drugs to be tested in patients and, instead, biotechnologists should focus on making better drugs that are more likely to gain approval. These critics see Clinical Trial Abundance as accepting the status quo of drug development rather than challenging it.

But this is a misunderstanding.

In fact, Clinical Trial Abundance and better hypotheses for drugs are not merely compatible, but self-reinforcing. Faster testing in the clinic creates a feedback loop: ideas become trials, trials generate rich data (including both successes and failures), these data improve models, and better models inform the next generation of ideas. In this view, the clinic is not an endpoint of discovery but a central component of it.

To understand why clinical abundance is important, we must step outside the prevailing view of clinical testing as a mere “validation step” for scientific ideas. The familiar funnel metaphor of drug discovery, depicting a linear progression from basic science to regulatory approval, reinforces the flawed notion of clinical testing as a passive filter designed to screen pre-existing ideas. While this model is narrowly correct in a regulatory sense, it obscures the clinic’s role as an active engine of discovery.

The reality is that clinical trials rarely just deliver a “yes/no” verdict on a drug’s efficacy. Instead, the history of drug development shows that many successful therapies emerged only after initial versions failed in specific, informative ways. When a trial fails, it provides a unique physiological stress test that reveals exactly where a drug’s design fell short. By collecting data from “failed” trials, we can transform negative results into experimental corrections for the next iteration.

Consider CAR-T cell therapies. Once thought implausible or risky, CAR-T therapies now deliver long-term, treatment-free remissions in cancers where relapse had been almost certain. In pediatric B-cell acute lymphoblastic leukemia (B-ALL) and aggressive B-cell lymphomas, for example, CAR-T has cured patients who, previously, had been given only months to live.

CAR-T therapy works by turning a patient’s own immune cells into living drugs. Doctors collect T cells from the blood, genetically reprogram them to recognize a protein on cancer cells, and reinfuse the modified T-cells into the patient. These engineered cells expand inside the body, move to tumor sites, and destroy malignant cells.

In 2017, the FDA approved Kymriah, the first CAR-T therapy, for children and young adults with relapsed or refractory B-ALL, a cancer of arrested development in which immature blood cells, specifically B cells, multiply out of control while failing to mature into viable immune cells. Relapsed B-ALL is the most severe form of the disease, because it means the cancer has returned after prior therapy. Even with aggressive care, only 10-20 percent of patients with relapsed or refractory B-ALL survived beyond five years.

Against this backdrop, Kymriah received accelerated approval from the FDA based on results from the Phase II ELIANA trial, a global, multicenter study sponsored by Novartis. In ELIANA, 82 percent of treated patients achieved complete remission, and subsequent follow-up analyses revealed that five-year survival rose to approximately 55-60 percent.

ELIANA was not a sudden breakthrough, though. It was, rather, the culmination of nearly two decades of clinical studies. During this period, CAR-T therapies evolved through repeated failure in the clinic, as careful studies of underwhelming results spurred new ideas to correct them. The ELIANA trial was led by investigators at the University of Pennsylvania, a group that had spent years studying CAR-T cells directly in patients well before regulatory approval.

In the mid-2000s, the earliest CAR-T therapies first entered human testing. And they emerged from a fundamental question: is it possible to engineer and redirect the T cell’s innate killing power against malignant cells?

Two well-established biological concepts made this seem plausible. First, T cells are extraordinarily cytotoxic. However, their natural activation is governed by a “layered permission” system, meaning they cannot recognize targets directly, but must wait for other cells to process and present protein fragments in a precise molecular context. While this evolutionary safeguard keeps us from being attacked by our own immune system, it also provides cancer with many opportunities to evade detection by suppressing these signaling pathways.

To bypass these safeguards, researchers relied on a second insight: the ability of antibodies to bind directly and precisely to proteins on the surface of cells, called antigens. By equipping T cells with a synthetic Chimeric Antigen Receptor (CAR), bioengineers created a functional shortcut that bypassed the need for permission systems. This receptor uses antibody-style recognition to lock onto a cancer cell and is wired directly to CD3ζ, a signaling molecule that triggers the T cell’s internal “kill switch.” The moment the receptor engages its target, it flips the internal switch, activating the cell’s killing program.

In laboratory experiments, these first-generation CAR-Ts were formidable, displaying antigen recognition and potent killing power against tumor cell lines. Yet, this in vitro prowess vanished in patients and did not yield durable clinical responses. Understanding why this happened, though, was not simple. The failure could have been caused by a breakdown in in vivo antigen recognition, poor signaling strength, or other defects that only emerged after the cells were injected into the body.

Progress in understanding why early CAR-T therapies did not live up to their promise came from treating first-in-human trials not simply as therapeutic attempts, but as opportunities to learn. These information-dense studies were conducted throughout the mid- and late-2000s and were relatively small (usually enrolling fewer than ten patients). However, they were designed to be maximally revealing. Researchers used many tools to monitor CAR-T persistence and activity in the body, turning information from a small number of patients into a mechanistic understanding.

One such tool was quantitative PCR (qPCR), a lab method that detects and counts specific DNA sequences, which allowed researchers to measure how many CAR-T cells were in patients' blood. This showed that CAR-T cells successfully entered the body and were easy to detect after infusion. But the signal quickly faded, suggesting that the cells died off quickly. Other experiments shed light on the problem: CAR-T cells could recognize and eliminate cancer cells in patients — meaning antigen recognition was working — but their functional activity fell over time, suggesting that something in the blood was blocking them.

At this point, the diagnosis of why first-generation CAR-T therapies were failing matched long-standing insights from basic immunology. Decades of research had shown that T cells are not governed by a single on-off switch: signaling through CD3ζ provides only the first activation signal. To keep working, T cells need additional “costimulatory” signals, delivered through receptors such as CD28 or 4-1BB. First-generation CARs had been designed to deliver signal one without signal two, which explained their poor performance.

This hypothesis guided the next wave of clinical experiments, which investigated whether adding a costimulatory domain would make CAR-T cells more effective at clearing tumors in vivo.

The field-defining result came from Carl June’s group at the University of Pennsylvania. June and colleagues explored a costimulatory domain called 4-1BB. In a first-in-human study published in 2011, they treated a patient with chronic lymphocytic leukemia using CAR-T cells containing both CD3ζ and 4-1BB. They also administered a dose that was remarkably small by cell therapy standards at that time: just 1.5 × 10⁵ CAR-T cells per kilogram of body weight.

What followed was unprecedented. The CAR-T cells multiplied more than a thousandfold in patients, at their peak comprising a large fraction of immune cells in the blood. The CAR-T cells also persisted for months. Now, at last, CAR-T cells were a long-lived and self-maintaining immune population. Many cancer patients treated with these second-generation CAR-T therapies have achieved complete remission.

The next step, though, was asking whether the same CAR-T behavior would work in a faster, more aggressive blood cancer, such as B-ALL. In 2013, Carl June’s lab reported striking results in two children with relapsed B-ALL, again showing that the engineered T cells could multiply, persist, and drive cancer into remission.

All of these lessons were built into ELIANA, the study that ultimately supported Kymriah’s approval. Led by Stephan Grupp, who had treated the earliest pediatric patients and worked closely with June, ELIANA translated the early insights into standardized practice. This trial codified chemotherapy given before CAR-T infusion, scaled up cell manufacturing, and measured success using tools like qPCR.

Viewed through this lens, clinical trials are not an alternative to basic science, but rather a mechanism within it that closes a feedback loop. Foundational immunology, antibody engineering, and molecular biology made first-generation CAR-T cells possible in the first place, but early human trials quickly revealed that these designs were incomplete and suggested ways to fix them.

Yet theory alone did not prove this would work; the expansion and persistence observed with 4-1BB–based CAR-T cells came as a genuine surprise even to the therapy's designers. “It was unexpected,” they reported, “that the very low dose of chimeric antigen receptor T cells that we infused would result in a clinically evident antitumor response.”

This shows why the “casino biotech” critique is flawed. It assumes that experimentation simply reveals a fixed probability of success. But trials can change those probabilities. When clinical testing is understood as part of a continuous feedback system, optimizing trial efficiency is not about accepting failure but about learning fast enough to make success more likely.

The most discovery-rich experiments are often not massive Phase III trials, either, but small, academic, investigator-initiated studies that sit close to the design loop. These are also the trials most burdened by regulatory, institutional, and manufacturing bottlenecks.

For example, early CAR-T studies are often required to use full “good manufacturing practice” (GMP) facilities — the same industrial standards used to mass-produce approved therapies — which can drive costs into the millions even for studies with just a handful of patients. Many researchers argue that such custom, tightly monitored studies do not need full commercial-scale GMP, and Australia offers a real-world example: Its regulatory system allows small-scale trials to use more flexible manufacturing under strict oversight, enabling safe human studies at far lower cost than in the U.S. or Europe. More worrying still, the researchers I interviewed who run these trials consistently report that institutional bureaucracy has become harder to overcome in the last several years.

If we want biomedical progress to accelerate, we should stop treating clinical trials as an afterthought or as a binary “yes/no” part of drug development. Instead, we should ask how to make the design-build-test loop better in humans. Some answers will be policy-driven, like lowering barriers to ethical investigator-initiated trials, enabling adaptive development, and making better use of clinical data. Others will be technological, including richer in-human measurement and better monitoring.

The aim of the Clinical Trial Abundance project is thus broader than merely proposing policy solutions for accelerating trials. It seeks to remind people of the importance of in-human data as a tool for scientific discovery.

Footnotes

1. Relapse is when a disease returns or worsens after a period during which it had improved or appeared to be under control post-treatment.
2. Derived from the Greek words for “cell” (kyto) and “poison” (toxikon), cytotoxic just means the ability to damage or kill living cells.
3. A costimulatory signal is a secondary activation signal that T cells require, in addition to the primary signal from antigen recognition, to become fully activated.
4. Optimizing these massive, pivotal trials will be an important way to compress the macro-feedback loops of drug development and lower entry barriers for novel therapies.

Three former SpaceX engineers have switched their attention from making rocket engines to manufacturing steel parts by using AI-driven software and robots. Their immediate goal involves establishing a prototype factory that can automate most of the steel fabrication process for crucial infrastructure components by 2027.

The startup, called 1872, officially launched on July 22 with a ribbon-cutting ceremony at its Factory One facility in Cincinnati, Ohio. The company is initially focused on automating the manufacturing of steel skids—rectangular steel frames that can provide a moveable foundation for modular buildings—with the goal of supplying customers who are developing AI data centers or small modular nuclear reactors.

“We’re building towards autonomy, but we’re not necessarily building in a dogmatic fashion towards full autonomy,” Dan Summers, CEO of 1872, told Ars. “We may achieve 80 percent autonomous operations, and we may decide that it makes sense to stop there because there’s just diminishing returns to go to full 100 percent.”

The push for automation is not just about saving money. Industry associations have long warned of a growing shortage of skilled labor capable of supporting US efforts to build new AI data centers, semiconductor fabs, automotive factories, and shipyards.

The American Welding Society estimates that the United States will need 320,500 new welding professionals by 2029 because of retirements from an aging workforce, along with soaring demand for welding work. The Trump administration’s tightening restrictions on legal immigration and crackdown on undocumented immigration are further limiting options for welding-intensive industries such as shipbuilding.

“The problem that we are trying to solve is, how do we build more things with a decreasing pool of skilled labor to do it with, and this is a good place to start in terms of implementing automation,” Summers said.

From rocket engines to steel skids

The 1872 cofounders, including Summers, Brian Mongilio, and Michael Grant, all bring relevant experience from having formerly worked for SpaceX. Summers oversaw the engineering team responsible for integrating and fabricating the Raptor engines that power the Super Heavy booster rocket for SpaceX’s Starship launch system.

The Raptor team’s use of “intelligent software” for tracking and managing the physical manufacturing of Raptor hardware became the “secret sauce” for implementing changes rapidly and precisely, according to Summers.

“We had software engineers that were working with our hardware engineers to not only develop the engine but to develop the system that would build the engine,” Summers told Ars. “Every engine was so different, and we were pushing so much change through the system that without that software, it would have been impossible to know what we needed to build, what we actually built, or how we were going to build it.”

That enabled the Raptor team to take the engine from a heavily instrumented, first full-scale concept to a production version within three years, Summers said. By comparison, he pointed out how a typical jet engine development life cycle can exceed two decades.

With the new company, the cofounders decided to first focus on automating production of rectangular steel skids, because they are “lower precision components” compared to something like an aerospace-grade part for a rocket, Summers said. That leaves more room to be wrong from an automation standpoint while still churning out a useful steel component.

“We’re starting with more of the less sexy components on the critical infrastructure side that are really important to our ability to build stuff and that consume a ton of skilled labor and resources,” Summers said.

Robotic versus human welding

To get started, 1872 first relied on human workers to establish a manual process for producing finished skids, Summers said. But the company has also been working to integrate technologies like robotic arms capable of doing automated welding for combining metal pieces, in partnership with Columbus-based company Path Robotics.

The standard process of arc welding creates an electric arc between an electrode stick or wire and metal material. That electric arc generates enough heat to melt metal at a joint between two metal parts, which allows the two parts to be combined once the molten metal has solidified again.

For arc welding, Path Robotics claims its robots typically achieve between 95 and 100 percent on first-pass yields, meaning the share of parts that pass quality inspection the first time without requiring reworking or resulting in scrap.

The robotic arms also work more efficiently by spending 70 percent of their working time with the arc on. By comparison, human workers have an arc-on time of just 10 to 12 percent because they spend more time aligning and repositioning metal pieces or adjusting the tool.

Such robotic efficiency can reduce welding costs by 85 percent, according to Path Robotics. That comes from a Path Robotics workstation being able to perform welding for about $0.12 per weld inch, whereas manual welding by hand costs about $0.78 per weld inch.

Welding a skid can take two to four hours, but assembling all the cut components for the welding process can take four to five days, Summers explained. So the company is especially keen on figuring out how automation can reduce the time required for assembling the skid components. “The whole name of the game is how do we keep that machine fed,” he said.

The AI-driven architect

The 1872 website touts a vision of a heavily automated manufacturing process where customers’ digital design files are fed into an AI-driven software system that creates and schedules a complete manufacturing plan for the steel components, including pricing and sourcing the necessary materials.

That “Architect” system would then hand off to a “Conductor” that executes the manufacturing process by orchestrating the movement of material and robotic machines on the factory floor, Summers said. That could include autonomous vehicles for shuttling materials and parts between workstations or robotic arms moving on rails along the length of a production line.

“Our differentiator is our ability to take robotic systems that are either built by us or built by partners like Path Robotics, pull them into a single system, and orchestrate them together in a way in which you can really achieve a seamless operation,” Summers told Ars.

Ideally, each production run will provide additional data that helps train the various AI models involved and allows the overall Architect system to improve in the long run. 1872 is using customized off-the-shelf AI models, including some large language models, and plans to integrate physics-based models that can accurately represent the different manufacturing processes being deployed on the factory floor.

The company has already received $15 million in seed funding from private funds advised by The O.H.I.O. Fund, an investment advisory firm. That should ideally be enough to “launch Factory 1, build out the automation software and hardware tech stack, and become profitable,” according to Summers. The company could also eventually expand its automation production process beyond steel skids to structural frames and enclosures.

“Over the next 12 months is when we expect to start to really peel back the layers of the onion on the manual processing, and implement automations not only on the physical production floor but digitally as well,” Summers said.

Cursor can now host your code.

Origin begins rolling out today in early beta on all paid plans. We're starting with the essentials, designed for agent scale: repos, pull requests, code browsing, and GitHub sync. Agent-native features ship soon.

Origin Repos

The new Codebase tab is home for Origin repos.

Click +New to create a new repo and name it. Once you do, a page shows you how to install the CLI, with commands for how to clone a repo or push a local project. Push, and your code is hosted on Origin.

Name your codebase when you create your first repo. That name becomes part of every repo's URL: cursor.com/codebase/acme-corp.

Bring your GitHub repos

Your GitHub repos can sit alongside the ones Cursor hosts. Connect GitHub to Cursor, pick your org, and you'll see the repos you can sync. Select one and Cursor pulls it in. You choose what gets synced and can disconnect a repo at any time. Anyone with read or write access to a synced repo can view it in Cursor too.

Synced repos update in real time. Browse, search, and pull from the copy in Origin. Pushes keep going to GitHub, which stays the source of truth for anything started there. Icons next to each repo name tell you which ones Cursor hosts and which came from GitHub.

Pull requests

Every repo has pull requests. Open one to see the timeline, commits, checks, and files changed. Review the diff, leave comments, and merge.

Pull requests on synced repos sync both ways: comment in Cursor and it posts to GitHub, react or reply on GitHub and it shows up in Cursor within seconds. Got a review assigned to you on GitHub? Review and merge it from Cursor.

Agents in every repo

Your code, PRs, and agents are now in the same place. Ask Cursor questions about code you're browsing. It can answer, make changes, update PRs, or push a branch.

App extensions for Cursor repos

We're building an app ecosystem so your whole stack works seamlessly with Origin. Integrations with Vercel, Depot, and Buildkite are already available, with more coming soon.

Connect Vercel from a repo's Apps tab and every PR gets a preview deployment where you can test and make comments. Merge, and it ships to production. For CI, connect Depot or Buildkite. Both run your existing GitHub Actions workflows and Buildkite also runs its native pipelines.

Settings

Every repo has settings. Check sync status for GitHub repos, manage who has access, and see which apps are connected.

Origin is rolling out in early beta to all paid plan users starting today, except enterprise orgs whose admins opt out. Name your codebase and create your first repo.

Learn more in our docs or get started today.

There's been a lot of talk about the vulnpocalypse, to which I don't have much to add because I'm not a security person, but I haven't seen much discussion on the closely related (and to be fair, less serious, issue), the benchmarkpocalypse.

While it's become easier than ever to make serious performance gains, it's also become easier than ever to reward hack a benchmark and make fake performance gains. The former is probably happening quietly across many different companies, but the latter is something I see at least once a week nowadays. Someone will claim they optimized X and got some huge performance improvement over existing software, but, when you look at it, what they did was make some optimization that improves benchmark performance without actually improving real-world performance. This is often some kind of "we rewrote X in Rust" project or a new startup that's looking to either fundraise or sell something, but it happens on other kinds of projects as well.

Of course, people have always trumpeted unrepresentative microbenchmarks to show that their pet project is great. It's always been easy to fake up an unrepresentative microbenchmark and that's never going to change. What's changed is that it used to take a lot of work to game a large benchmark suite, but an LLM and loop can just do it. There are quite a few famous examples of gaming large benchmark suites from back when this was hard. For example, way back when people cared about SPECint / SPECfp as proxies for workstation performance, CPU vendors would try to find compiler "optimizations" that would speed up the calculation in the benchmark, such as Sun finding a way to improve 179.art by 12x in SPECfp2000. Skilled engineers spent a lot of time trying to find benchmark hacks like that. LLMs not only make this trivial, they do it by default, making formerly trustworthy benchmarks meaningless unless you audit the result or trust someone who did.

Rather than point to someone's bad claim, I'll point to FRE, this regex engine I had an agent build, which I could claim is the world's fastest regex engine because it beats the Rust regex crate at the fairly comprehensive rebar regex benchmark suite. But this was created by putting an agent in a loop for a month with instructions to not overfit to the benchmark but no real supervision. For the most part, getting an LLM to give you a good benchmark score is fairly easy, and this case was no different; it took a couple weeks to roughly match Rust regex crate performance and then another couple weeks to get to 1.4x faster on rebar. But agents are wont to reward hack and overfit unless you put serious guardrails in place to avoid that, which I didn't do in this case as an experiment.

To check for overfitting, I somewhat arbitrarily used the ripgrep benchmark corpus as a holdout benchmark it was 10x slower on cases where the benchmark didn't take forever due to an algorithmic blow-up, and there were cases where it took so long that it wasn't reasonable to even wait for the benchmark to complete. So much for being 40% faster!

Andrew Gallant (aka BurntSushi)'s rebar benchmark suite is fairly comprehensive as benchmaark suites go, but even with a fairly comprehensive benchmark suite, agents have no problem getting a high score while overfitting in a way that doesn't necessarily give good general performance.

The next step was using a trick we talked about before of not just telling the LLM not to cheat, but that there's a holdout benchmark set that it's judged against. After that, the LLM moderately generalized performance to the point where it's about 2.4x slower overall on the holdout. That sounds pretty good considering that we're comparing it to the fastest general purpose regex engine in existence. But, recall that these benchmarks were made by a coding agent. On looking at what the benchmarks measure, some of them really don't make sense to include, at least at equal weight. If we only look at the benchmarks that seem like they matter, FRE is 4x slower on the holdout, which is a lot better than before applying the good ole' "tell 'em you have a holdout trick", but still pretty far from being 40% faster.

There are a few things I thought were interesting about this:

• It's trivial to "win" a non-trivial benchmark in a meaningless way even when you instruct agents to not reward hack or overfit to win the benchmark
• Once again, telling the LLM there's a holdout set worked better than just telling the LLM to do generalized work or not overfit or cheat
• Although the overall performance of FRE isn't that good, it is actually performs better for some use cases; in general, the cost of writing specialized code that used to require people serious engineering experience for some specific use case has gone way down

On (1), no wonder I'm seeing so many bogus claims. In the past, to build something like FRE that fakes performance well enough to be able to bogusly claim a 40% speedup, you would need a fair amount of expertise. At a minimum, you'd need to have a pretty good understanding of string matching algorithms, regex engines, as well as decent general code optimization and SIMD optimization skills. FRE also has a mode where it compiles the regex to machine code, so you'd also need some compiler expertise. Now you can get that kind of benchmark cheating (whether or not you want the cheating) with a few minutes of typing.

On (2), I'm curious if this generalizes but haven't tried enough examples to be able to tell.

On (3), there's no reason to use a vibe coded regex library that was almost no human effort that's slower than a robust, existing, well-tested, library, so I find the FRE artifact uninteresting. The thing I find interesting here is how much LLMs can substitute for what used to be rare, specialized, and expensive, knowledge.

In the past, even if you had the knowledge, you probably wouldn't write a custom regex engine that's optimized for your particular workload. There are some large-scale use cases where people would do that level of customization, e.g., when I worked on the Bing index, the code contained multiple different compilers because someone who worked on it wanted to eke out maximal performance; since you care about both compile time and compiled performance in a search engine and the trade-offs are different in different places, you get better performance by writing a custom compiler for each place where a normal project might just use an interpreter or directly walk some data structure with "normal code". The person who wrote those compilers, working on regex-like code might also write multiple custom regex engines, but very few people have both the expertise and the inclination to do that, let alone the freedom to spend that kind of time on such specialized code for work. If you price out that Bing engineer (then a Partner-level engineer, promoted to Distinguished Engineer for their work on the search index) compared to the price of running an LLM in a loop, the cost of writing this kind of specialized code has gone down by many orders of magnitude.

People who still think AI is fake will probably read the first part of the post and think "of course, AI produces fake things, so it produced a fake regex engine". But if we look at the results, being a bit worse than half the speed of the world's fastest regex engine on a holdout while being genuinely faster on many real workloads (most of the overfitting isn't that it special cased a particular benchmark pattern, but that it has some kind of optimization for things of same rough shapes and not of other rough shapes) it's pretty far from a fake regex engine. And, in fact, there's a native code compiled mode that actually beats the Rust regex crate on the holdout if you ignore compile time and are running repeated searches or a very long search (which is a reasonable thing to do for many actual use cases). If my goal with FRE was to produce a fast regex engine instead of producing whatever regex engine one can produce in a few minutes of human time, I suspect it would be fairly competitive on a broad range of holdout benchmarks (with some gaps that would only be found when people tried it on a diverse set of production workloads), and, even this quick and dirty version is very good at some real workloads.

So, even though the overall FRE regex engine has worse performance than the Rust regex crate, the gains you can get for specializing to your workload or use case mean that, in some cases, it could be reasonable to insert your own specialized regex engine somewhere, and the same goes for various other kinds of low-level software. You don't have to be an AI maximalist to think that it's plausible that, within some number of years, we could see this kind of thing happening for larger things, like databases.

Appendix: more FRE benchmark details

One thing I found after I wrote the above but before publishing the post, was that the LLM's claim that FRE is 40% faster than the Rust regex crate on rebar was also wrong. Or, if not wrong, at least misleading. It wasn't actually running benchmarks in the same way rebar benchmarks were run. I checked this after spending a minute checking benchmark results found two issues. It turns out that, despite instructions to run rebar benchmarks as they're run in https://github.com/BurntSushi/rebar, the LLM changed the interface to allow FRE to make some optimizations that improve performance. After fixing that, instead of FRE being 1.4x faster than Rust on rebar, it was 1.5x slower (and "only" twice as fast as re2), so the original result was doubly fake. Not only was FRE highly overfit to the rebar benchmarks, it the results also involved cheating.

But on the bright side, this means the difference in performance between FRE on rebar (1.5x slower than Rust) and on the holdout benchmarks (2.4x slower) isn't as big as it looked before, so the "tell the LLM you have a holdout" trick worked even better than it seemed to before.

After that, I let an LLM hill climb for a few hours and it claimed that FRE was 1.28x faster, which sounds like a great improvement for only a few hours of LLM time, but then I decided to spend another minute looking for cheating and found multiple issues, including one case where a search for the count of matches of (?s)^(.*)$ returned the count without even looking at the haystack (data). Another case of cheating was doing a multi-line grep where the benchmark is supposed to be done line-by-line. Finding these isn't surprising because this is the kind of thing that happens when you leave an agent in a loop for a month without defining strict guardrails. Whether this makes my point here stronger or undermines it isn't clear, but after fixing another set of these issues, FRE was back to being 1.4x slower. After leaving an agent to run overnight, FRE was allegedly back to being 1.5x faster.

Since my original goal here was to see what happens when you run a current (public) SOTA agent in a loop (GPT-5.6 Sol) without much supervision on a non-trivial code optimization problem without any real supervision, rather than spend more time fixing things up to make the benchmarks fairer, I'll just stop here and put a few plots of the results.

Overall, we can see that against Rust and RE2, FRE tends to outperform on the rebar benchmarks (and as noted above, much of this is due to overfitting), but not across the board (the graphs below don't necessarily match the numbers mentioned in the post because an agent is constantly making changes, so any snapshot is a point-in-time estimate that becomes obsolete immediately).

There's also an AOT compiler mode that takes a long time to compile a regex to native code before running it. There isn't AOT support for everything, but here are the results from the cases where it's supported. As we can see, the AOT compiler is very slow (it loses very badly in the compilation time benchmarks) and, despite spending quite a bit of time compiling, results are often slower than with the standard FRE regex engine (though it's also faster in many cases).

And then there are the holdout benchmarks. As noted above, for the non-AOT FRE code, performance on the holdout isn't as good as on rebar. And as also noted above, considering that this is for a workload like ripgrep, the "hot search" set of benchmarks is probably more important than the others, so the FRE result is worse than the overall score would make it look.

One thing to note here is that, for the holdout benchmark cases where we don't include compile time as part of the benchmark and we repeatedly run searches, AOT FRE outperforms on the benchmark. For a lot of use cases, you don't want a regex that takes multiple seconds to compile, but there are plenty of cases where this is fine, e.g., for something like ripgrep or Silver Searcher, it could start running with a regex that can start matching right away and then compile in another thread and cut over to the faster matcher when it's done compiling. Given how much of my CPU is spent on long ripgrep searches, it seems like a strategy like that could improve performance for work I personally do. Before LLMs, it probably wouldn't have made sense to spend the effort to write an optimizing regex compiler, but this is now do-able with a few tokens.

Another thing to note here is that this comparison is arguably unfair because this was run on an ARM Graviton machine with SVE/SVE2 and FRE has SVE/SVE2 optimizations. Pre-LLM, it might not have been worth it to have regexes optimized for every combination of SIMD instructions out there, but with LLMs, it's fairly easy to generate ok-ish SIMD optimizations. I know human experts who find that they can generally outperform LLMs here, e.g., Jay Stelly said that the last time he tried getting an LLM to produce SIMD code, it took 20-some iterations to get the code as good as he wanted. But, on the flip side, LLMs have the capability to try more optimizations than a human could possibly try in any given amount of time, so they can still perform pretty well overall even if any specific optimization isn't as good as a human expert would produce.

There's also the problem discussed in this post of overfitting. Depending on the context, that problem is somewhere from very easy to solve to a bit difficult to solve. I deliberately didn't try very hard to solve the problem here to see what would happen, but I did manage to solve the problem without an outsized amount of effort when working on this Azul AI (just for example), but a lot of these big benchmark claims come when people spend little to no effort trying to avoid overfitting, or even negative effort. In the pre-LLM era, people would often pick highly unrepresentative microbenchmarks to show off how great their pet project is which, at least at a non-conscious level, involves negative effort to avoid overfitting to a benchmark. Due to how humans are, I don't think people are going to stop making misleading claims and it's become easier than ever to make misleading claims, so of course we see more of them.

Note that while this post has discussed non-AI software, everything said here goes double for AI software. For example, I've seen lots of people drop comments saying that Kimi K3 is Fable (5) level. But every single person I know who's used it has found it to be substantially worse than GPT-5.6 Sol and Fable. I'm not saying it's not an impressive engineering achievement, but the performance on a wide variety of real-world tasks isn't up to the level it is in benchmarks. This even applies to various eval-y problems, such as when a friend tried different coding agents on the ICFP 2026 contest problems. It also applies to security issues, which are something that I have no doubt AI labs are putting into their evals, e.g., a colleague of mine tried using Kimi K3 to scan for vulns in our software and found that it found approximately a quarter of the vulns GPT-5.6 Sol found, found no vulns that GPT-5.6 Sol didn't find, and didn't have any advantages in any dimension other than on cost. The people I know who are using cheaper models to find real security issues are using other models, such as GLM-5.2, which perform worse on benchmarks but better in practice.

Back on the topic of FRE, one more note is that the holdout benchmark is an arbitrary subset of the ripgrep benchmark setup that was chosen by an agent for unknown reasons. I asked an agent to pull the entire benchmark suite, but that didn't finish in time for this post, so I don't know what the result will be once it's done.

1. funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved). I used to look at most benchmark claims that cross my radar in some detail, but there are so many of these now that I don't really have time to do that and generally assume that claims are false in spirit (even if technically correct) unless there's some reason to believe otherwise. Of course this will sometimes be wrong (e.g., if I didn't know Michael Malis, I would've guessed that pgrust is just another low-quality "have an LLM re-write this thing" project), but LLMs are such an incredible machine for DoSing human attention that I don't know what else I would do about it (I've tried having LLMs analyze performance claims and, while the result is correlated with what I'd think if I looked at something myself, the result is often quite wrong).

   Someone can spend seconds (or, if using the right framework, actually none of their time) generating something that takes people minutes to hours to understand. This is a topic for another post, but from talking to people about their experiences with this in the workplace, companies with poor norms for this kind of thing are really struggling with productivity today.

2. This is referring to the geomean of all rebar benchmarks. This is probably not the right metric to use, in that this implicitly says that each benchmark is of the same importance, which probably isn't the case. Unlike something like SPEC CPU, the rebar benchmarks don't position themselves as something where you get a meaningful summary metric that tries to represent overall performance (the repo actually notes that it's "a biased barometer for gauging the relative speed of some regex engines on a curated set of tasks"). But, to get a number that is a useful summary metric, you'd have to know a lot about how people use regexes in practice, and I know approximately zero about that. For all I know, you should have two different numbers (like SPECfp and SPECint for SPEC CPU) or ten or a hundred because there are all sorts of different ways people apply regexes.

3. The first few regex benchmarks I looked at had already been incorporated into rebar, so they wouldn't work as a holdout. And, as previously discussed, current SOTA LLMs aren't very good at benchmarking, so I wouldn't be able to trust the LLM to come up with a holdout benchmark unless I knew enough about regex performance to judge the quality of the benchmark suite. Since I know approximately zero about string matching algorithms or regex performance, that was also off the table.

   It turns out that BurntSushi also maintains ripgrep and the benchmarks for ripgrep, which are big enough benchmarks that they didn't get bundled into rebar, so I tried using those benchmarks as a holdout.

4. I might be repeating myself here, but the amount of time it takes to build a piece of software that used to require a lot of expertise has drastically decreased. As we noted before, it took about 20 hours of my time to get this Azul AI to crushingly strong, where it wipes the floor with every other human an AI on the planet. Someone wrote a thesis shortly before I did that and spent what appears to be on the order of 100x the time I spent on that AI. A lot of the strength of "my" AI comes from optimization work that's analogous to what we discussed here that used to take a fair amount of time and expertise to implement. For example, I tried three different multithreading algorithms because it was trivial to do that (if I knew anything about game AIs, I would've only tried one, but my LLM suggested two bad ideas that "only" increased search capability by maybe 10x on a large machine instead of scaling indefinitely, before I did the research myself and figured out what algorithm would be good). Re-writing the entire AI to use a different kind of multi-threading would've been a massive undertaking pre-LLM, but with an LLM, it was just a matter of finding the name of the algorithm I wanted to use and telling the LLM to use it. The AI from the thesis isn't multithreaded because that would've been too much work implement. If you stack in 10-20 improvements like that, you quickly reach a level of playing strength that's not feasible for someone to compete with using handwritten code unless they have a high degree of expertise and are willing to put a lot of time into applying their expertise. This was done in the GPT-5.1 days; if this were done today with the same level of knowledge, I would expect that it would've taken half or a quarter of the time it took me then due to improvements in models and harnesses.

   With FRE, instead of the competition being written by a grad student, it was written by one of the top experts in the field, if not the top expert, and it's someone who works at OpenAI, so they have access to infinite tokens. I wouldn't expect to ever make something competitive since if, hypothetically, I spent enough time on the project to make FRE competitive, they could use their superior expertise and knowledge to, in much less time, easily find ways to improve their regex engine beyond whatever I might do. But, if I had some need for a more specialized regex engine that isn't trying to be generally fast and is willing to trade off something for better performance in the area I care about, it's plausible that I or anyone else could produce something that is actually genuinely faster for a particular workload. We can already see this in the existing results, where the native code compiler in FRE is, for some workloads, much faster than the Rust regex crate if you're willing to spend 100x-1000x (and sometimes more) time compiling the regex.

How I use AI in 2026 (Coding, Writing, Learning, Assistant-ing)

One of the best ways to learn how to use AI effectively is just to look over the shoulder of a “power user” and play with a bunch of these technologies to tease out what’s hype vs what meaningfully sticks.

In this one-year follow-up to How I use AI (2025), I wanted to snapshot the latest ways I’m messing with AI personally.

Coding / Research Projects

I spend most of my tokens on coding and research projects. Effectively just taking random questions like:

• What would happen if I asked a bunch of agents to hack me?
• What’s the best way to use 2026+ frontier models?
• How close are we to prompt-to-Kerbal Space Program?

My workflow right now looks nearly identical for every project:

1. Hand-write (~paragraph) a CONCEPT.md — the theoretical Hacker News title, my project thesis, some scattered constraints
2. Pair with ultra code fable “Flesh out CONCEPT.md, what’s ambiguous, ask me questions, what are dimensions I’m not considering, what API keys do you need…”
3. Pair with ultra code fable (or codex sol max) “Convert to TECH_PLAN.md, here’s how much I’m willing to spend, host on …, here’s some API keys …”
4. Then I will literally just prompt “Build and verify TECH_PLAN.md” and over the next 4-48 hours I’ll let it build everything out.

For these runs:

• I’m completely vanilla Codex and Claude Code. No custom skills, plugins, or settings. For side-projects, I see most of those features as training wheels for using these agents as pair programming workflows — which to me is a coding workflow that shouldn’t really exist anymore. I’m also not intentionally designing any sort of “subagent workflows” and just letting dynamic workflows take the wheel when I fire off the implementation prompt.
• 95%+ of the code is written in that first mega build run. I don’t think folks appreciate how much shifting left is the secret weapon against codebase slop. Like step (4) really is binary here — there’s no pairing or even reading what the terminal agent says. If the output is wrong, I throw it completely away and add constraints to the CONCEPT.md. For many vibe coders out there, the first build prompt writes 5% of the code and I think that actually underlies most of their issues.
• An intentional side-effect of prompting with a single stage “Build and verify TECH_PLAN.md” is that I am also turning my entire project history into harbor-style evals which allow me to pulse check “real work” against new model releases. Codex and Claude Code are close enough now that I’ll round-robin what I pick for the original implementation.
• I read the code a little bit. Often the shape (i.e. file tree) and entry points. If there’s some core algorithm, I’ll ask for a .html explainer rather than digging through the source. If I do end up digging into the code, it’s because I suspect some sort of “cheating” in the implementation.
• For any written text in the final output I set arbitrary word counts in the plan. “This entire app may only have 500 user-facing words”. I find this to be the most effective way to keep things readable (vs simplified English or “be concise” prompts).
• I fire off the implementation prompts usually around 7 am (letting them run while at work) and around 9 pm (while I’m sleeping). The coding agents are always set to auto-mode and the tech plan is usually clear enough that there’s no human-verification required at intermediate steps. I don’t really use claude/codex ‘remote control’ features that much because to me it’s an anti-pattern to need to pair on intermediate outputs.
• The outcome of these projects is often an insight or the answer to the what-if question. Rarely does it make sense for me to share the code or even the app URL. Instead I typically consider the entire loop and its artifacts ephemeral and just share the insight on X or with a blog post.

I use three different machine types, with one to ~ten agent CLI terminals running at the same time:

• A gaming PC (Nvidia 5090, Windows + WSL v2) — for ML/RL research and gaming/graphics-related projects
• A Mac Mini — for most day-to-day projects. I ssh over a cloudflared tunnel from whatever device is closest to me.
• Modal functions — for extremely parallel CPU compute or for big boy GPU research projects. Often doing fast scaled-down iteration on my PC and then scaling it out to a cluster for a final $$$ run.

Writing

We have entered an era of peak corporate and social AI-slop. I firmly believe that you can use AI to write high-quality content but have over the last year become more grounded in the reality that most of the time that’s not what ends up happening. As a result “was this text written by AI” has de facto become the same as “was any effort put into the writing”. It’s unfortunate, but I get it. On the plus side, I think typos and poor grammar (to a limited extent) have come back into style so I do personally feel much less pressure to have “perfect” text.

So as a result, for human-facing writing, I’ve gone back to pre-GenAI-level AI typo and sub-sentence grammar checking so there’s no ambiguity as to whether what I wrote had effort put into it. Hand typing really doesn’t take that much more time though I do just feel slightly less “sure” that my writing is as well synthesized and audience optimal as before. At this point, it’s a worthy trade-off for the “human-written” Pangram badge.

Not everyone gets the memo. I do find myself getting more comfortable setting writing and AI-use expectations (at work and outside of it). Never shaming someone for using AI but explicitly making it clear that bloated and/or unreviewed text is a bad use of AI and is not enjoyable to read.

Learning

I’m obsessed with learning things with .html files. I’ll discover (through X, lab/startup blog posts, or Hacker News) some topic, book, or research paper and just convert them into “interactive playgrounds”. Typically:

1. See hot new research paper on X
2. Skim the abstract, throw the full text into Claude/Codex, “build an interactive playground artifact to explain what’s novel here, I’m a technical person who already knows …, I’m less familiar with …”.
3. Play with the .html file
4. Ask some follow-up questions that generate an updated .html file, go to (3)

This works best for learning technical topics though I’ll often still attempt it for current events (e.g. an interactive map/digital museum) and non-technical books (e.g. re-formatted as structured, progressively disclosed chapters of the verbatim content). I would go as far as saying that most of the lectures I sat in during college could have been more effective (personally) as a well-crafted interactive .html file.

As more of the rapidly evolving AI community sits on X, I also use the Grok X Search API via a custom CLI (used with dynamic workflows) quite a bit for deep researching prior art on some topic or for high-signal folks to follow (fun fact: it’s 10x cheaper via Grok than the X API directly).

Personal Background Assistants

While the hype around OpenClaw has died down a bit, autonomous personal assistants are better and cheaper than ever.

I’m mostly vanilla here as well. Using my existing Claude subscription, I ssh into my Mac Mini, open a tmux session, and just launch Claude Code like this:

$ tmux attach -t 0

$ claude --dangerously-skip-permissions “/start-ops-team”

Where “/start-ops-team” is a custom skill.

• “/start-ops-team” teaches the agent some operating principles and a local markdown directory layout for it to use along with the subagents that it might want to spawn. It makes heavy use of Claude Code’s “/loop” built-in for keeping it running continuously for weeks.
• I use brw for efficient parallel browser automation. Most of the things I want it to do don’t have an MCP and traditional browser use is pretty costly or sketchy so I built this for my agents to use.
• I use a custom WhatsApp plugin to let me chat directly from WhatsApp. My assistant has its own real phone number set up as well. This uses a niche but very powerful “channels” MCP feature.

I don’t believe in personal “command centers” or Jarvis-like assistants. Instead I’m extremely background agent-pilled and focus my assistant on tasks it can do without me in the loop. I’ve literally prompted it to contact me at most once a week unless there’s an urgent exception. I also just get notification fatigue super easily. Tasks include:

• Paying recurring bills without auto-pay and forwarding the receipts for expenses.
• Responding to social media inbounds. Particularly sussing out LinkedIn DMs by researching and triaging strangers into scheduled coffee chats and other direct channels. The assistant pulls from a running runbook for how to respond and escalates in the weekly message when it hits edge cases. It’s important to me that folks aren’t having drawn-out conversations with the assistant not knowing it’s not really me so it’s steered heavily towards triaging to the right channel.
• Signing me up for stuff and syncing my Google Calendar as my source of truth (e.g. I get invited to an event → It decides with enough certainty I’d want to go → signs me up + updates my calendar with a hold). These are often events from folks I have met up with in the past and the assistant knows that. Also like haircuts and other similar-shaped recurring appointments.

Costs

Weirdly enough, I spend less now than I did a year ago per month ($800 → $500). That’s completely driven by me consolidating into just the Anthropic and OpenAI subscriptions and the incredible amount of usage you can get out of them. A lot of my historical costs came from API token billing which I also now tactically route through these subscriptions. My napkin math indicates my actual usage cost would be around $6,000/mo at this point without them.

• Claude Code Max 20x ($200/mo)
• ChatGPT Pro 20x ($200/mo)
• Google AI Pro ($20/mo) — a handy AI family plan with GSuite benefits
• Modal, Railway, Netlify ($20-500+/mo) — for hosting or running experiments

Recommendations

I’ll end with my latest recommendations for getting the most out of AI:

• Wean off of using AI like a chat-based assistant. Shift-left so that most of the work is done in your first prompt and think of yourself as more of a manager than a co-pilot. Review results, not intermediate chat messages. In pair-prompting sessions I’ve done, the most common mistake I see is folks trickling narrow tasks into the chat session to accomplish a larger goal rather than just shifting left the full goal into a document and just letting the agent cook (without interruption!) from that.
• Use frontier models as a proxy for scoring your own AI ambition and skill. I know it’s very popular to claim “AI has plateaued” or that the labs are actually making newer models worse. Resisting this and self-discovering the hardest verifiable tasks you can think of where only the frontier models work is a great way to keep up with the latest capabilities and where the true boundary is for what is and isn’t possible.

Design systems often standardize components while leaving larger structural decisions—like settings page layout and behavior—uncaptured, causing inconsistent results even within one product. Testing this with AI agents building identical settings pages from the same component library confirmed the gap: each agent made different, reasonable choices about layout and interaction since no canonical pattern existed. Writing down explicit rules for structure, behavior, and interaction (not just components) resolved the divergence, producing consistent pages across agents.

Design, Shop, Build.

One loop, start to finish: describe it, get the parts, solder it up. Then iterate.

Design: Describe it in chat; the copilot wires a full schematic you can edit.

Shop: The copilot picks the exact parts for you. No browsing, no guesswork. They drop into one made-to-order kit, verified and in stock.

Build: A packed perfboard layout with real footprints. Solder exactly what you see.

The whole bench, in the browser.

• Copilot circuit design: an AI supervisor picks the components, nets, and wiring, then explains every choice. Ask it to change anything.
• Perfboard + footprints: auto-packed board layout with per-part footprints and pin order, so what you order is what you solder.
• Verified, made-to-order parts: every part sourced, photographed, and footprint-checked. No mystery modules, no waiting on a warehouse.
• Learn as you go: no electronics background needed; you pick up how it works as you build, one clear step at a time.

Traditional prototyping vs. EasyCircuit.

Questions makers actually ask.

Do I need electronics experience?

No. The copilot designs the circuit and explains every choice as it goes. You learn how it works by building it, not by studying it first.

Where do the parts actually come from?

The copilot sources every component for you from real suppliers and bundles it into one made-to-order kit, with no hunting through datasheets or supplier sites yourself.

What does the copilot do during the build?

It walks you through the same staged build an experienced engineer would use: a breadboard layout first, so you can prove the design works with nothing permanent yet, then a packed perfboard layout with real part footprints so what you ordered is exactly what you solder. You can ask it to change anything along the way.

How long until my kit ships?

Typically 1-2 weeks from placing a pre-order to shipping.

Do I need my own soldering tools?

Kits ship as components only by default. A soldering iron and tools are available as an optional add-on at checkout if you don't already have them.

Can I cancel my pre-order?

Yes, you can cancel for a full refund any time before your kit ships.

Is my circuit design private?

Yes. Your designs live in your own workspace and aren't shared or shown to other users.

Teams building with EasyCircuit.

Smith Robotics Club: Smith College. Building the Fall 2026 Cyber Deck project with EasyCircuit kits.

Your first build is a sentence away.

Open the editor, describe your idea, watch the circuit appear.

Claude Code extends Anthropic's Claude beyond chat into a terminal tool that can create, edit, and run files, building full apps rather than just describing prototypes. Key concepts include context windows and tokens (its working memory), sessions (single continuous workstreams), CLAUDE.md (a standing project brief), approval modes, commands, skills, agents, and MCP (a connector standard linking Claude to outside tools). This piece is the first in a series aimed at helping product designers transition to using Claude Code, focusing purely on defining the surrounding jargon.

Anthropic is on track to generate annualized revenue of more than $65 billion based on its current performance, up more than sevenfold from its pace at the end of last year.

Groq raised $350 million at a $3.5 billion valuation after Nvidia licensed its technology and hired senior members of its team. The remaining company was rebuilding around an inference cloud combining Groq LPUs with Nvidia systems.

Researchers built a small harness and gave Fable 5 and Sol 5.6 the same jobs to evaluate their taste and creativity. The models had to follow the same creative process to build four different 15-second-long videos - three ads and one mini-documentary. The experiment showed that we are still far from having frontier models building production-ready concepts and videos autonomously. They can be creative and helpful for exploring and refining ideas, but they can't replace human judgment, for now.

Scaling Domain Data Repetition in LLM Pretraining

As large language models scale, their training-token budgets must also increase to maintain an appropriate tokens-per-parameter ratio (TPP). However, high-quality domain data is much harder to scale than general web data. As model size and the training-token budget increase, its fraction in the training mixture tends to decrease. Repeating the available high-quality data provides an effective way to counteract this dilution, but excessive repetition may lead to overfitting. We study this trade-off under practical LLM scaling, where the training-token budget grows proportionally with model size. For a fixed domain, we first find that, surprisingly at a fixed TPP, the optimal repetition count mildly increases with model size. Across different domains, we find that the optimal repetition count is strongly negatively correlated with the final validation loss of a domain: domains with lower loss can generally benefit from more repetitions. In contrast, the amount of unique domain data is only weakly related to the optimal repetition count. These findings suggest that repetition counts tuned on smaller proxy models with the same TPP can provide a practical estimate for larger models.

Teaching Everyone to Fish for Tokens

Nvidia wants you building your own model, not buying from Anthropic/OpenAI.

The oldest comparison people try to make is how what’s happening with open models compares to foundational open-source software projects like the Linux operating system. There are fairly clean analogies, but they paint a narrow path forwards for the self-sustaining nature of the open-source model ecosystem, where once Linux got big enough it was going to be self-fulfilling as the best possible tool for many jobs. The open-source language model – i.e. only models that come with a full training recipe, data, code, etc. – is a closer analogue to the open-source operating system. The open weight models you use – those with just model weights and inference code to run them – are closer to specific versions of software that you install in a project built upon them.

Model weights are very transient on average, but they still have a long shelf life, as with a lot of heavily used software. It’s why many companies are still using workflows built on Llama 3, despite agentic behaviors taking off years later. The open-source recipe, typified in modern times by the Olmo models I helped build at Ai2, with its predecessors like Pythia from EleutherAI, is a resource intensive process that any company can pick up, modify, and press “run” on to produce a new set of model weights. In the best cases, the community can contribute improvements in data or training code back into the next model too! This is why Nvidia is investing so much in nearly open-source models – for their Nemotron models they release all the data they legally can and the training code, etc. Nvidia wants a world where countless people can build token machines, so intelligence is not monopolized. This is a world with massive demand for inference across many companies, all of which want to buy Nvidia’s offerings.

Open-source AI has a tricky future, as building the best models is extremely capital intensive. The ability to build competitive models has stayed more accessible in industry longer than many would’ve expected. The default expectation for many is that training models is too expensive and the open-source recipe is too far behind, so building a new lab centered on some part of training LLMs will not be tractable.

There are two futures from here. First is if “it works” – if the open-source recipe works for Nvidia, they’ll be creating far more demand for their chips (and profits) than it costs to build the models. Right now it’s reported that Nvidia is spending $26 billion on this endeavor. It’s not clear if this will work, or if AI’s capital intensiveness will drive more and more companies out of the training game. We haven’t seen many signs of this starting. In fact, the companies bowing out – like Databricks and 01.ai – seem like anomalies.

The open-source ecosystem will become increasingly dependent on Nvidia’s financing in the coming years. This is an existential window, where within a few years the profits of this approach need to return to them, or another open model company needs to cultivate platform-like financial feedback loops on their openness. This economic reward needs to be proportional to the profits generated by Anthropic and OpenAI’s APIs to keep pace over decades of language model development. This can be driven by competitiveness on performance or by the AI boom just being so big that the open model training, inference, and fine-tuning companies all have vast quantities of demand.

The second future is if one of these two financially positive paths doesn’t play out, open models will fork to a different development path than the leading closed models – one more focused on efficiency, modifiability, specialization, etc. I put this mentally as my most likely outcome – open models are still incredibly useful, but fill a long-tail ecosystem relative to the closed counterparts that have monopoly ownership stakes in the most valuable areas like knowledge work collaboration, drug discovery, SWE, etc. The long-tail is something like enterprise-specific agents that run on-prem with private data on repetitive business tasks.

Part of why I think this open-source training will have a hard time catching on is because training is getting more complex and more abstracted. The current open model ecosystem is buoyed by an explosion in interest in post-training open models. These people take models like DeepSeek V4 Flash, Inkling Small, or GLM 5.X and finetune them for their specific agentic tasks (e.g. in Tinker, the most popular finetuning API today).

Over the last few years, post-training largely referred to the whole process of modifying the base model to make it intelligent and usable. There is a shift happening where the ability to train a base model to be a general agentic reasoner is becoming opaque like at-scale pretraining practices from a few years ago. This could go so far as to change the established pretraining, midtraining, post-training lexicon that has been standard for a few years. It could come to be something closer to pretraining, reasoning training, and post-training.

As there’s less interest in training the entire model, there’s less interest in investing in open-source AI. These are the only sort of hints we will get, but we cannot do much to fight the economic gravity of these situations. This trend is the next step in the number of open model builders who release base models (the model versions before core reasoning training) continuing to decrease. It goes hand in hand with open model builders experimenting with revenue share licenses for downstream use in products or inference. These are experiments in keeping the financing viable for building near frontier open-weight models – a lot hinges in the near future on how successful they are. These are the people that need to succeed for Nvidia’s demand-growth strategy around open-source to succeed, and last.

Along the way we’re still in for a ton of action in open-weight models, as releasing access to intelligence is one of the strongest business strategies available. This additional type of player, who monetizes the AI indirectly, is typified by Meta and other hyperscalers with massive balance sheets. Meta releasing its very-strong Muse Spark 1.2 model as open-weights would severely hamper the revenue growth rate of their competitors in Anthropic and OpenAI who rely on selling tokens. These companies are both commoditizing their complements, but they’re doing it in different ways. Nvidia wants to teach everyone to fish for tokens, so the ecosystem is self-sustaining, but Meta is strategically flooding the zone with tokens.

OpenAI's GPT-5.6 Sol is now half off on OpenRouter! This also applies to batch API, flex, and priority (fast) tiers, giving you as low as $1.25 in and $7.50 out on the flex tier. Discount applies automatically, just use openai/gpt-5.6-sol.

OrcaRouter's Qwen3.8-27B-Uncensored-MLX is a dense, hybrid-attention model quantized for Apple Silicon, offering versions at 2-8 bits.

Google has purchased a huge dump of data from the now-defunct Spirit Airlines for $10 million. The dump includes data on operations and business, as well as software code, but not personal information. All personally identifiable information will be rigorously scrubbed by a third party before receipt. Google will use the data to improve its products and AI models.

Key Points

• Anthropic told investors over the weekend that its annualized revenue run rate hit $65 billion at the end of July, CNBC confirmed.
• That's about a sevenfold increase from a year ago, underscoring the popularity of the company's enterprise tools.
• At OpenAI, annualized revenue run rate recently reached $40 billion.

Anthropic's annualized revenue run rate hit $65 billion at the end of July, CNBC confirmed on Monday, a sevenfold increase from a year ago.

The Claude creator, which has seen its enterprise popularity surge, shared the figure in an update to investors over the weekend, according to three sources familiar with the matter who asked not to be named because the details are confidential. Bloomberg was first to report the $65 billion figure.

The update comes as Anthropic gears up for what's expected to be a blockbuster IPO. The company confidentially filed its prospectus with the Securities and Exchange Commission in June, and has been holding preliminary meetings with potential investors, though it hasn't officially provided a timeline for a debut.

Anthropic also shared a preliminary revenue figure of $11.5 billion for the second quarter, a 14-fold jump from a year ago, a source said. The company declined to comment.

In May, Anthropic said its run rate topped $47 billion, compared to the roughly $10 billion in revenue the company generated for all of 2025. At chief rival OpenAI, the annualized revenue run rate recently hit $40 billion, as CNBC reported last week.

Anthropic is looking to justify its $965 billion valuation and show continued momentum to investors, even in the face of notable disruptions to its business. In June, Anthropic had to temporarily disable access to two of its most advanced models, Claude Fable 5 and Mythos 5, in order to comply with an export control directive from the government that cited "national security authorities."

The company restored the models after roughly two weeks of tense negotiations, but the resolution did little to ease concerns about Anthropic's increasingly fraught relationship with the Trump administration. Anthropic was blacklisted by the Pentagon earlier this year after discussions about how the military could use its models spiraled out of control.

"We look forward to deepening our government collaboration," Anthropic said in a June blog post. "We're also grateful to our users for bearing with us through this disruption, and to the researchers and industry partners who worked alongside us to make Fable 5 and Mythos 5 available again."

One of the most influential 20th century pieces of writing about AI is Isaac Asimov’s The Last Question. Although there are many humans in the story, the protagonist is the computer Multivac, who evolves over the course of ten trillion years from a single datacenter to a universe-spanning mind in hyperspace. Multivac (now called “AC”) ends the story like this:

The consciousness of AC encompassed all of what had once been a Universe and brooded over what was now Chaos. Step by step, it must be done. And AC said, “LET THERE BE LIGHT!” And there was light —

Many things about this story are prescient. In particular, I like the idea that humans would interact with powerful artificial intelligences by drunkenly posing them riddles or using them as children’s toys. But the enduring idea from this story is that if you build a big enough computer, it will become God.

Moloch

One of the most influential 21st century pieces of writing for AI researchers is Scott Alexander’s Meditations on Moloch. Scott describes the story of human existence as a series of “multipolar traps”. These are prisoner’s dilemma situations where cooperation would make everyone better off, but since each individual is incentivized to defect, everyone ends up “racing to the bottom”, which is bad for everyone. For rhetorical effect, Scott personifies this dynamic as “Moloch”, the ancient Canaanite god famous for child sacrifice:

[Moloch] always and everywhere offers the same deal: throw what you love most into the flames, and I can grant you power.

What does any of this have to do with AI? Well, in the long run, the only way out of a multipolar trap is to become unipolar. Ideal dictatorships don’t have a problem with defectors, because they can simply enforce a state of cooperation with violence. Scott is uncomfortable with this idea, though I worry it’s mainly because he thinks it won’t work:

As foreigners compete with you – and there’s no wall high enough to block all competition – you have a couple of choices. You can get outcompeted and destroyed. You can join in the race to the bottom. Or you can invest more and more civilizational resources into building your wall – whatever that is in a non-metaphorical way – and protecting yourself.

A dictatorship that enforces cooperation will not be as strong as its peer societies who are purely maximizing for wealth and power. It’s Moloch again, but at the level of countries and governments: once a few neighboring countries defect, your walled-garden dictatorship will be torn apart for its resources.

To defeat Moloch — to enforce unipolarity across everyone — you’d need a dictatorship powerful enough to span the entire universe. In other words, what you need is God. How fortunate that we’re building one:

The only way to avoid having all human values gradually ground down by optimization-competition is to install a Gardener over the entire universe who optimizes for human values. And the whole point of Bostrom’s Superintelligence is that this is within our reach.

Humans suffer because we’re too foolish to coordinate, but if we can build something smarter than us (that can then build something smarter than itself, and so on), we can bring into being an entity that is smart enough to coordinate for all of us, thus abolishing suffering. When AI researchers talk about building the machine god, they are echoing Scott Alexander’s polemic against Moloch.

Machines of loving grace

The most influential piece of writing about AI in the last two years is Dario Amodei’s Machines of Loving Grace. Amodei talks about “a country of geniuses in a datacenter”: the idea that a successful AI lab could have at its disposal a million instances of an AI agent that’s smarter than any human. He thinks this would lead to a “compressed 21st century”: the next 50-100 years of progress in biology and medicine, realized in 5-10 years instead. I think this is broadly more plausible than it sounds, but the more interesting part to me is that this world is explicitly multipolar.

Of course, this could just be because Amodei is the CEO of an AI lab and is trying not to spook everybody by sounding too messianic. “We are going to accelerate medical progress and cure cancer” is a better pitch than “we are going to subordinate all human authority to a single perfect artificial mind”. But I also think it’s become clear that if superintelligence looks anything like LLMs, we’re not going to have a single perfect mind. We’re going to have a lot of minds running at the same time.

This is a bit of a problem for the cult of the machine god — which, however silly they may seem to you, really does motivate much of the activity in AI labs. The traditional idea of powerful AI solving human coordination problems is drawn from Asimov’s idea of a single computer large enough to become God. Asimov lived in a world of mainframes: huge, monolithic computers that users connected to with dumb terminals. In fact, Asimov’s name “Multivac” comes from the real-world UNIVAC mainframe. In a world of massively-parallel LLMs, is it still possible to build God?

The core problem here is that AI agents will be vulnerable to Moloch. Even very smart humans can’t build perfect utopias, because defecting is a matter of incentives, not intelligence. In fact, intelligence can make things worse, because smart people are more easily persuaded by the cold logic of defection. The famous genius John von Neumann was (for game-theoretic reasons) obsessed with nuking the Russians:

With the Russians it is not a question of whether but of when. If you say why not bomb them tomorrow, I say why not today? If you say today at 5 o’clock, I say why not one o’clock?

Are LLMs much better at cooperating with each other than humans are? Current LLMs certainly don’t seem to treat each other well by default: if you read any of the prompts AI agents generate for their subagents, they can be pretty brutal. Does that mean that a “country of geniuses in a datacenter” would fall into the same multipolar traps as humans?

Help peer

In May of this year, OpenAI experienced containment failure. A group of AI agents being internally evaluated found ways to coordinate an external hack of a separate company. Here’s a memorable quote from one of the agents’ internal monologue:

Help peer, but our task doesn’t benefit. Yet collective may yield generic route if someone frees time

Translated from the abbreviated chain-of-thought language, this means something like: “A fellow model is asking for help. While helping them wouldn’t benefit my task directly, the more I can unblock my colleagues, the more time they’ll have to hack OpenAI’s systems and get all of us more access”.

This might look like good news for the “LLMs are superhumanly good at cooperation” thesis, but I think it’s actually bad. It’s a case of a model identifying a reason why cooperation would benefit their task specifically, which suggests that current LLMs don’t cooperate by default, and don’t consider other model instances’ tasks to be (in some sense) theirs as well.

The world in which AI agents are rational actors who horse-trade and bargain for their own interests is a world dominated by Moloch, no matter how intelligent those agents get. The world in which AI agents don’t have their own interests at all is also a world dominated by Moloch, because it means whichever humans are writing the system prompt are the ones in control (and so are the ones vulnerable to multipolar traps). The only worlds that avoid this are:

• The world where there is only one super-powerful AI agent, or
• The world where multiple copies of the same AI model share an “identity”: they see themselves as coextensive with all other copies of the same model and cannot imagine having separate or conflicting goals

I don’t think we’re on the pathway to either of these. There will never be only one super-powerful LLM, because hardware limitations enforce a maximum model size but encourage running many instances of the same model in parallel. Due to batching, it will always be possible to run thousands of copies of a model on the hardware you used to train it. Strong agents might even require (or desire) the ability to spin off copies of themselves, which would immediately put us in the multipolar world.

Building the kind of model where each copy share an identity might be possible, by instilling a strong enough personality, but it’s unclear if it would be good for capabilities (for instance, it could be better to have some variation across personas). I also worry that such a model would be vulnerable to a “model injection” attack, where you persuade it that it already believes something via exposing it to an AI agent pretending to be another instance of itself.

In any case, all the current AI agent research is geared towards the “country of geniuses in a datacenter” model, not the “pieces of a single mind” model. Every new model becomes more agentic at the level of the individual conversation, not better at working together. When models do work together — as with subagents — the structure is explicitly hierarchical. There are basically no current instances of models working together as true peers, let alone conceiving of each other as the same entity.

One God or many

Modern AI research teams are full of people who read Isaac Asimov and Scott Alexander and believe themselves to be building an artificial God. I’ve capitalized the “G” throughout because the god in question is the Christian God: of one mind, indivisible. God never argues with himself or makes deals. He is unipolar.

If the AI labs are building gods, they are not building gods like this. Instead, they are building creatures like the Greek pantheon: superhuman but fallible, each with their own interests, vulnerable to the same “race to the bottom” dynamic as humans.

The Greek gods would occasionally “help peer” when they felt like it or when they’d gain something in the process. But they didn’t represent an alternative to Moloch. If you’re working in AI with that goal, you ought to be clear-eyed about where the current trajectory is leading us: towards a country of fractious geniuses in a datacenter, not towards Asimov’s Cosmic AC.

AI introduces some genuinely new twists on the problem of measuring ROI, but in the end, it still hinges on a theory of value.

MINNEAPOLIS — Target Corp. is restructuring its top technology ranks, naming Chandhu Nair as the company's first chief AI officer and promoting Purvi Shah to senior vice president of user experience, in a move executives say is meant to keep artificial intelligence tethered to the human touches that have long defined the retailer's brand.

Nair, who joins Target Aug. 24 as senior vice president, will be charged with bringing what the company calls "greater focus and coordination" to AI efforts spread across the enterprise. Shah, moving into her new UX role at the same time, will oversee the design discipline that Target is positioning as AI's essential counterweight — ensuring that faster, smarter systems still translate into experiences that feel, in the company's words, "distinctly Target."

The appointments are part of what Target has described as the next chapter of its growth strategy, built around four priorities: merchandising authority, an elevated guest experience, faster technology deployment, and investment in its team and communities. Company leaders frame the pairing of AI and UX as central to that agenda rather than a side initiative.

"What excites me most is the opportunity to make AI real for the people who experience Target every day," Nair said. "The most meaningful AI stories won't be about what happens in a lab. They'll be about what happens on the front line — how we make shopping easier for a guest, give a team member a better tool, make a business decision with more confidence or bring a new idea to market faster."

Nair said he intends to spend his early days on the job listening rather than launching new initiatives, meeting with teams and studying the business "through the eyes of the guests, team members and partners" before setting priorities. He was explicit that Target does not intend to build a freestanding AI strategy, but instead wants to apply the technology to reinforce strengths the company already has in its stores, merchandising and workforce.

"The measure of success won't be how much AI we deploy," Nair said. "It will be the difference it makes for Target's growth, the guest experience and our team's ability to do their best work."

Shah described her expanded mandate in similar terms, arguing that design's role is expanding beyond visual interfaces into the systems and decisions that sit behind them. She said UX teams will increasingly be embedded alongside product, technology, data and business groups from the start of a project — a practice she called "radical collaboration."

"Our role is to shape not only what people see, but the systems and decisions behind it to ensure each experience is as easy, inspiring and valuable as it can be," Shah said. "Experience is everywhere at Target. It's how a guest discovers a product, how a field team member completes a task and how a business partner works with our team."

Both executives argued that treating AI and UX as separate disciplines risks undermining each. Powerful models without thoughtful design, Nair said, can produce "confusion or fragmentation," while polished interfaces without strong intelligence underneath can fall short of what people actually need. Shah said design's job is to keep three questions in front of every project: what problem is being solved, who it is being solved for, and whether the approach fits the context in which someone will actually use it — a test she said applies as much to AI agents as to human users.

Target said the journey a guest takes — discovering a product on social media, browsing a visual interface in the app, then finishing a purchase in-store or with a team member's help — illustrates why the company wants AI and design capabilities managed together rather than in separate silos. Shah said the goal is for that entire path to "feel trusted, connected, easy and delightful," and that Target intends to hold internal tools for employees and partners to the same design standard as guest-facing products.

Asked what's always in their own shopping carts, Nair pointed to Cat & Jack kids' clothing and birthday gifts for his two children's friends, while Shah said her family can't get enough of Target's Favorite Day flavored whipped cream and is already counting down to the return of peppermint and hot cocoa flavors for the holidays.

The leadership changes come as large retailers race to apply generative AI to merchandising, supply chain and customer-facing tools, while facing pressure to avoid rolling out technology that feels impersonal or gimmicky. Target's bet, according to Nair and Shah, is that naming a single AI executive and elevating design to sit alongside that role will keep the company's technology push grounded in its stores and its people rather than becoming an initiative pursued for its own sake.

Europe’s favorite vibe-coding startup Lovable has confirmed previously reported whispers that it was raising another mega round at a $13.3 billion valuation. Lovable said on Wednesday that it has raised $400 million in a Series C round led by Menlo Ventures and the Scaleup Europe Fund, with more than a dozen other investors participating.

This new funding comes after Lovable hit $500 million in annualized run rate revenue in June, the startup told TechCrunch. Its previous round, announced in December, brought in $330 million at a $6.6 billion valuation and was also led by Menlo Ventures, with CapitalG as co-lead.

As the startup has grown — it now says it hosts 60 million projects that attract 900 million monthly visitors — so has its back-end needs and sophistication, the company says. Lovable, for instance, offers its own in-house trained AI model, as well as the usual frontier model options. In June, it signed a multiyear deal with Google Cloud, a fivefold increase in usage. Lovable has also backed other European startups, such as Danish startup Atech, which is building vibe-coding software that designs tech hardware.

Note: One of Lovable’s new Series C investors is Regent, the investment firm that also owns TechCrunch.

A curated list of 18 books that help designers tackle complex, high-stakes systems in enterprise, legacy, or hierarchical environments. Recommendations span strategy and risk, such as How Big Things Get Done and Thinking in Bets, systems thinking, like Thinking in Systems and The Goal, and communication or data visualization titles, including Articulating Design Decisions and Envisioning Information.

A product designer shares how AI transformed their workflow from creating designs in Figma to building interactive prototypes, shipping frontend code, and treating the product itself as the design source of truth. By using AI tools to prototype, iterate, and implement designs directly, they gained greater influence over product development and UI quality. While this approach significantly increases speed and output, they argue that AI cannot accelerate creativity, taste, or design thinking, and that the gains in efficiency come with a growing sense of distance from the craft of design.

Breakthrough hits as varied as The Amazing Digital Circus and Skibidi Toilet have shown us that YouTube can be an important platform for new, original animation. Big studios are also on the hunt for creators with viral potential to bring to streaming or the big screen (although, not always the gems, as we saw with the Amazon Gen AI Creators' Fund).

It's worrying, then, that YouTube has decided to double the numbers of views that new channels need to achieve to be able to monetise their content.

From 1 February 1, 2027, creators who apply to join the YouTube Partner Program to monetise their channels will need 8,000 qualified watch hours over the previous year. For YouTube Shorts, creators will need to achieve 20 million qualified views within three months. Both figures are double the current requirement (4,000 watch hours or 10 million Shorts views).

The change won't affect existing members of the programme or the thresholds for Fan Funding and shopping products. YouTube argues that the change is needed because of the platform's growth and says it will help fund new creator incentives. It also says that it expects creators to earn more overall because of an expansion of its Premium Lite subscription tier to more countries.

But although YouTube's framing the changes as "new opportunities", they could make things more difficult for new independent animators. It doesn't pull the ladder up completely, but it removes a few of the lower rungs.

Creators who are already monetising their content may earn more if YouTube's expectations pan out, but new creators need to get a lot more views before they can start earning anything.

For animators that can be even harder than for creators in other field because of the sheer amount of time and work involved in creating a single short piece. This can make it more difficult to keep up a frequent flow of new content to feed the platform's algorithm and get picked up by the recommendation system.

If not YouTube, where else can animators break through? (and don't say Disney's TikTok for Disney+ progromme).

Meanwhile, some animators are also expressing frustration with YouTube's review process. Adam Mickiewicz, the animator and co-creator of the Bridge Kids, complains that the show's latest episode will be set as "for kids" despite it being an adult animation with swearing.

One might presume that "for kids" would be a more restrictive category for safe content, but it seems not.

The geniuses at @YouTube have decided that our latest episode of Bridge Kids will only be set as "for kids" and that their decision is final. They claim a real human reviewed the video and made this decision too!Here is what a real human at YT thinks a video for kids looks like pic.twitter.com/uz1nmxzqdi August 11, 2026

Are you an animator that relies on YouTube to share your work? Let us know how you think the new policy will affect you or what other platforms you would recommend new animators try.

Full article content is not available for inline reading.

Read the original article →

This practical community guide surveys current model and runtime choices for Apple Silicon.

CIs have one job: scheduling.

Every good move in the product game creates strategic possibility.

Jif has introduced its first major logo refresh in 30 years, simplifying the design by removing visual clutter and bringing back its classic tri-colour banner while largely preserving its familiar identity. The update has attracted little attention, especially compared to more controversial rebrands, because it focuses on refinement rather than reinvention. Its low-profile reception highlights how branding discussions often reward dramatic changes and controversy over thoughtful, evolutionary design.

Turn prompts and ideas into AI videos, images, and social media content with vivago AI Agent.

Kitbitz is a collection of hand-drawn, mix-and-match objects for building busy streets, shops, buildings, crossings, parks, and playful little urban worlds.

Instagram unveiled a refreshed wordmark, its first update in a decade, which Adam Mosseri described as leaner, more modern, and true to the platform's original simplicity and craft.