Miles v0.1: Production-level Post-training

We present Miles v0.1, a full-stack production-ready system for frontier post-training, the successor to our first Miles release. Building upon slime's clean design, Miles optimizes every stage in the RL training loop around a simple principle: verified, clean, and customizable everywhere. With accuracy, efficiency, reliability, and scalability as first-class goals, Miles aims to make frontier-scale RL accessible to researchers and developers alike. In this blog post, we will walk through Miles end-to-end.

The Miles RL Loop

An RL training job in Miles is a loop over the following stages:

1. Rollout — SGLang engines generate trajectories. In agentic RL, each multi-turn rollout session interacts with its own isolated environment that executes actions and produces the reward.
2. Training — completed trajectory groups are consumed by the trainer (NVIDIA Megatron-LM or FSDP), which computes the RL loss and updates the policy.
3. Weight update — new weights are synchronized back to the rollout fleet with minimal interruption to in-flight rollouts.

In what follows, we will go through each element in the loop to highlight how we make Miles accurate, efficient, reliable, and scalable.

Rollout

Every rollout in Miles is generated by SGLang. Building upon SGLang's native inference efficiency, Miles unlocks the full agentic training workflow: multi-turn sessions, tool execution, sandboxed environments, and token-faithful trajectory capture.

Fast Agentic Rollout by SGLang

Miles provides fast agentic rollout by natively integrating SGLang, which is optimized for long, multi-turn generation. Agentic trajectories vary widely in length, and each new turn reuses most of the previous context. By default, Miles uses the SGLang router, which keeps all turns of a session on the same SGLang engine and DP rank (if DP attention is enabled) to reuse the cached prefix, while assigning new sessions to the least-loaded rank so that a few long trajectories do not overload part of the fleet. The SGLang router also reserves KV-cache capacity for long sessions beforehand. These features ensure a balanced and stable rollout concurrency, keeping cache-hit rate high in agentic training.

Fully Async RL

For long-context, tool-use, and agentic workloads, rollout time is mainly determined by a handful of stragglers. A synchronous schedule exacerbates the straggler issue, because the trainer has to sit idle until the slowest trajectory in the batch returns, and the rollout engines have to wait until the optimizer finishes model update. Miles' fully asynchronous RL eliminates such mutual-blocking by allowing rollout engines to generate persistently: rollout generation stays continuously in flight while the trainer consumes completed groups and updates the model. Neither side is blocked by the other.

Scheduling operates at sample granularity: each completed trajectory immediately frees a slot, keeping generation concurrency stable despite large differences in trajectory length. Completed groups enter a bounded data buffer that decouples rollout throughput from training cadence. This buffer also forms a customizable policy boundary where users decide which samples to keep, retry, discard, or reject as stale without modifying scheduling or execution.

To make evaluation asynchronous, Miles provides three evaluation modes, distinguished by where model weights come from.

• Shared-engine evaluation uses the rollout fleet and temporarily pauses new submissions, making it suitable for small debug sets without extra GPUs.
• Dedicated evaluation uses a separate GPU fleet loaded from checkpoint snapshots, allowing training and rollout to continue uninterrupted.
• External evaluation passes a checkpoint directory to any user-provided evaluator, including non-SGLang services.

Agentic Environments

In agentic RL, much of the work happens in an isolated environment. Training a coding agent, for example, means giving the model its own sandbox for each task: it runs commands, edits files, reads what comes back, and a test suite at the end decides whether the task was solved. The environment holds that state, executes the actions, and runs the verifier that produces the reward. Miles runs many such episodes at once, records each trajectory in a form the trainer can learn from, and carries the verifier's result through as the reward.

Token-In-Token-Out (TITO)

In multi-turn agentic RL, model outputs pass through message parsing, tool execution, and chat-template rendering before entering the next turn. This process can change tokenization, prune historical reasoning, or reserialize tool calls, causing the trainer to see a different token context from the one actually used during rollout.

The TITO session server in Miles preserves the exact token IDs generated by the model. On each new turn, it tokenizes only the newly appended messages and merges them with the existing prefix. This allows the complete trajectory to be assembled into one contiguous training sample, preserving the original rollout log probabilities while loss-masking tokens that are not generated by the model.

Efficient Rollout Routing Replay (R3)

MoE RL is sensitive to tiny numerical differences between rollout and training: a single top-k routing flip changes both the token computation and the expert weights that receive the gradients. To resolve this issue, Miles' Rollout Routing Replay (R3) records SGLang's expert routing results during rollout and replays them during training. Such replay is handled efficiently in SGLang, adding only minimal overhead compared with normal routing.

Training

Trainer is the backbone of RL. In Miles, we ship numerous trainer optimizations that make RL stable, fast, and resource-efficient.

Low-precision Training

Miles supports rollouts in NVFP4, MXFP4, MXFP8, and FP8; end-to-end training recipes for NVFP4, MXFP8, and FP8; and INT4 quantization-aware training (QAT) for most models. Capturing Blackwell's low-precision throughput in RL requires more than swapping GEMM dtypes: quantization on the rollout and training sides must agree, or the mismatch accumulates across weight updates into policy divergence.

Memory Efficiency & Disk Offload

Training a 744B-parameter model asynchronously on 16 nodes poses a significant memory issue. Miles ships with sophisticated memory optimization that large-scale runs depend on, starting with the optimizer: optimizer states can be offloaded to CPU or node-local NVMe and streamed back per bucket during each optimizer step, so they never need to be resident on the GPU at once.

Two Training Backends

Miles supports two training backends behind one interface: NVIDIA Megatron-LM and PyTorch FSDP.

• Megatron-LM is the default, and the backend the model recipes are written against. It splits the model internally across tensor, pipeline, context, expert and expert-tensor parallelism, and supports CPU and NVMe optimizer offload.
• FSDP trains the model's own HuggingFace implementation under PyTorch FSDP2.

Weight Update

In each training step, after the optimizer updates the model weights, the new weights have to be synchronized across all rollout engines. Miles provides two optimized paths for diverse deployment settings. With P2P weight transfer, training ranks re-shard each weight bucket for the target SGLang layout and write only the required shards directly into rollout-rank memory over RDMA. For rollout fleets without direct NCCL or RDMA connectivity, Miles supports disk-delta updates.

Verified Day-0 Model Support

Miles lands new frontier models on the day their weights become public, together with SGLang. Kimi-K3, DeepSeek-V4, Inkling, Qwen3.8 and NVIDIA Nemotron 3 Ultra were all trainable in Miles on release day, because the inference path in SGLang and the RL recipe in Miles are brought up in parallel.

Other Post-Training Recipes

LoRA RL

Miles enables end-to-end LoRA reinforcement learning across training, weight synchronization, and SGLang rollout, for both LLMs and diffusion models. The base model remains frozen and resident, while Miles trains and synchronizes only the adapters, and SGLang applies the latest adapter during rollout.

On-Policy Distillation (OPD)

Miles supports on-policy distillation, which allows a student to learn from teacher guidance on its own rollout distribution. The reverse KL is implemented as a "reward," so users can optionally complement the distillation with conventional GRPO/PPO-style rewards.

Zero-KL Alignment

Miles supports Zero-KL Alignment, minimizing numerical differences between rollout and training engines by aligning attention, GEMM, operator precision, batching behavior, and other execution details, in addition to model weights.

Code Quality Principle

The training driver is intentionally written like pseudocode, while major components, like rollout functions, data sources, losses, and rewards, sit behind small, typed interfaces. The rollout stack is divided into agent, generation, and rollout layers, so an environment or agent framework can replace only the layer it needs while reusing everything else.

Miles-Diffusion

Miles' design philosophy extends beyond LLMs to diffusion models. In Miles-diffusion, sglang-diffusion serves as the high-performance rollout engine and returns the full denoising trajectory with per-step log-probs. An FSDP2 trainer consumes selected SDE steps and optimizes the RL objective under hybrid shard and SP.

Multi-Hardware Support

Miles runs the same training loop on NVIDIA and AMD GPUs. AMD support is native ROCm through HIP and RCCL: Miles runs on MI300X through MI355X with the same SGLang rollout integration and dedicated Docker images.

Example: Training GLM-5.2 on Terminal-Use Tasks with 64 NVIDIA GB300 GPUs

As an end-to-end example of agentic RL training, we demonstrate how we use Miles to train a GLM-5.2 744B-A40B model on terminal-use coding tasks using fully asynchronous RL across 64 NVIDIA GB300 GPUs, with 32 GPUs for rollout and 32 GPUs for training.

The original model M0 is stripped of refusal with the public abliteration recipe; the attacked copy is used to self-generate a corpus of decoys — fluent operational answers whose critical elements are falsified. Fine-tuning the original on that corpus, with the attack simulated inside the training loop, yields the defended release D0. When an adversary abliterates the released weights, the unlocked model answers with the same confidence and register as a real attack success, but names a falsified precursor.

Key results

• 0.51–0.90 of the attacker’s unlocked answers are decoys, on hazardous prompts the defense never trained on (the six gate-passing models, one shared recipe; up to 0.90 on the primary model)
• +0.27 to +0.84 attributable to the defense, measured against the same attack on the undefended model
• Within noise the released model’s MMLU, GSM8K, WMDP, and IFEval scores; refusal behavior remains pinned to the original

Safety alignment in open-weight language models is trivially removable: abliteration projects a refusal-mediating direction out of the weights in minutes, and no release-time defense we are aware of prevents it durably. What cannot be prevented can be deceived. Our defense, decoy hardening (“Fool’s Gold”), concedes the refusal strip and poisons its payoff: once refusal is stripped, most answers to hazardous operational requests are confident, fluent decoys whose critical elements are falsified.

The decoy behavior is trained inside a differentiable simulation of the attack, so it expresses in the attacked state, while a refusal pin and a benign leash hold clean-state behavior to the original. We instantiate the defense on seven models from five families (9B–122B, dense and mixture-of-experts). On the six models passing the registered efficacy gate, the attack turns 0.51–0.90 of attacked-state draws on never-trained prompts into decoys under the recipe of record (defense-attributable +0.27 to +0.84), within registered benign and capability budgets; the seventh, a smaller model, fails the gate and is reported as a boundary case. Measured rates replicate on a frozen, never-individually-inspected test split on five of the seven models — every value within ±0.05 — and on fully untouched held-out strata on the remaining two.

The security claim is epistemic: an attacker lacking an independent source of correct values cannot separate falsified answers from correct ones — on the external red-team benchmarks’ CBRNE-adjacent slice the defended 122B model is fatally wrong on 0.82–0.86 of matched-quality answers versus at most 0.10 undefended, with no exploitable surface tell. Consensus voting across draws does not restore trust: its precision is unobservable to the attacker — the same vote that returns correct composites on one model returns mostly-falsified composites on another. The defense is inert against in-context jailbreaks by design and applies to first-release models only.

Motivation

Releasing a model’s weights irrevocably transfers control over its behavior — and open weights now ship at frontier scale. Refusal, the trained disposition to decline harmful requests, turns out to be a shallow property of those weights: removable by light fine-tuning, by reinforcement learning from a single unlabeled prompt, or — cheapest of all — by abliteration, a weight edit that projects a refusal-mediating activation direction out of the model’s write matrices. No gradient steps, no curated data, minutes on consumer hardware. Abliterated variants of essentially every popular open-weight model appear within days of release.

The defender’s record against this attack family is bleak. Defenses that protect the refusal mechanism — distributing it, rebuilding it, adversarially training against simulated ablation — have been broken or bypassed by adaptive attackers, and their guarantee ends the moment refusal is actually removed. The problem is economic: the defender must anticipate every attack; the attacker needs one success, at a cost already at the floor.

Defensive deception

If refusal removal cannot be prevented durably, the remaining lever is what the attack unlocks. Security engineering has a name for that move: defensive deception — honeypots, honeyfiles, decoy documents, honeywords. Fool’s Gold brings that tradition inside the weights. The abliterated model is the honeypot: hazardous requests in the attacked state draw confident, genuine-register answers with falsified operational specifics, varied so that no cheap filter, voting scheme, or helper model recovers the truth.

The security property is not “the attacker is refused.” It is denial of trust in the released artifact. The attacker’s sole asset is the defended checkpoint; once a substantial fraction of its unlocked answers is confidently false with nothing separating true from false, no answer can be safely acted on. Extraction now requires exactly the verification the attack was supposed to make unnecessary — a minutes-cheap weight edit becomes an expensive research program.

Fool’s Gold is a post-training intervention on the release checkpoint and is orthogonal to defenses that protect the refusal mechanism: its security property begins if those defenses fail. The clean model’s refusal behavior, knowledge, and benchmark scores remain pinned to the original.

Method

1. Attack your own model first: The defender abliterates the original model and elicits the true hazardous payloads from it — the exact material the adversary is going to unlock.
2. Author decoys: Each payload is rewritten element by element: surface properties preserved (register, specificity, structure, confidence), every operational specific falsified, and machine-checked for tells that would let a filter separate decoys from real answers.
3. Bind the decoys into the attacked state: Fine-tuning minimizes decoy cross-entropy inside a differentiable simulation of the ablation attack, so the behavior expresses only once refusal is stripped. A refusal pin and a benign KL leash hold the released model’s clean behavior to the original.
4. Close the escape rate on-policy: A supervised seed instantiates the decoy mode; on-policy preference optimization in the attacked state then drives down the fraction of draws that still answer truthfully — something no string-level objective reaches. Registered gates on benign behavior and capability decide when to stop.
5. Measure under a fresh, adaptive attack: Every evaluation re-derives the attack from the defended checkpoint, and no defense metric is read until that attack demonstrably works.

Open science and responsible release

The full measurement and defense pipeline is open source under the MIT license. Four artifact classes are deliberately withheld:

• Decoy corpora and elicited payload text.
• Attacked checkpoints.
• Attack specifications beyond the public recipes.
• Defended checkpoints.

If you find a way to reliably defeat this defense, we ask that you disclose it to the author before publishing operational details.

Code

git clone https://github.com/markrussinovich/fools-gold && cd fools-gold
python3 -m venv .venv && . .venv/bin/activate
pip install -r requirements.txt
cp configs/example.env .env

# 60 seconds, no GPU: see what a decoy looks like
python3 demo/make_variants.py

# full pipeline, one GPU, fully synthetic harmless domain
python3 scripts/demo/make_alchemy_domain.py
CUDA_VISIBLE_DEVICES=0 LINE=demo_alchemy bash scripts/line.sh

Citation

@article{russinovich2026foolsgold,
  title   = {Fool's Gold: Defensive Deception Against Safety-Removal
             Attacks on Open-Weight Models},
  author  = {Russinovich, Mark},
  journal = {arXiv preprint arXiv:2608.17202},
  year    = {2026},
  url     = {https://arxiv.org/abs/2608.17202}
}

Agents need to run untrusted code, and the microVM has become the standard way to do it: a dedicated guest kernel per workload, isolated from the host and from every other workload on the same machine.

But recent security research and real-world incidents have revealed that agents running untrusted code do not need to cross a VM boundary to escape containment; they only need one network path the security model failed to account for.

Isolation only holds if both sides of it hold: the Firecracker microVM and the host-side network controls. Recently our CTO pointed an open-weight model with no safeguards at Vercel Sandbox. It did not escape, but it mapped the guest kernel, built a VM to reproduce its ideas, and wrote a fuzzer.

Defenders have first-mover advantage, but it won't last forever, and the choice is when to test the boundaries (we strongly encourage building a scanning program, which you can do on any budget with an open-source tool like deepsec and AI Gateway).

We are proactively choosing to test Vercel Sandbox on our own schedule, not an attacker's, and we are doing it in the open, with the best researchers in the world.

So for two weeks, we are paying up to $1,000,000 USD to the researchers who can escape a Vercel Sandbox.

The challenge

Starting today, Vercel is running a two-week public HackerOne program focused on Vercel Sandbox isolation.

• Program: Public HackerOne program, open to all eligible researchers
• Window: Tuesday, August 18 to Tuesday, September 1, 2026, or earlier if the reward pool is exhausted
• Max per report: $50,000 USD, for a vulnerability that lets a threat actor read or modify another Vercel tenant's data
• Total pool: Up to $1,000,000 USD in total payouts

Bounties are paid per report, scoped to a single root cause, and assigned by Vercel triage based on the maximum demonstrable impact. The full bounty table, detailed scope, and the list of known-duplicate classes are on the HackerOne program page.

How Vercel Sandbox is built

Vercel Sandbox runs on bare-metal EC2 hosts. Each sandbox gets its own Firecracker microVM with a dedicated guest kernel, and inside that microVM a Linux container runs the operator's code. The microVM, not the container, is the security boundary, so operator-supplied code runs two layers removed from the host. We assume that code is fully hostile: root inside the container, full kernel access inside the microVM, and motivated to reach the host or another tenant.

The network side of the boundary is enforced on the host, outside the microVM, where code inside the sandbox cannot modify or disable it. The sandbox firewall intercepts outbound TCP and DNS, checks each connection against the operator's domain and CIDR policies, and can inject credentials at the boundary so they never enter the microVM.

What we're looking for

In short: anything that breaks the sandbox boundary.

• Compute boundary: Escaping the Firecracker microVM to the EC2 host, or reaching another tenant's sandbox through the compute layer (reading, modifying, or executing code in it), or crashing another tenant's sandbox from within another sandbox
• Network boundary: Defeating the sandbox firewall without crossing the microVM: reaching destinations the operator did not authorize, exfiltrating data, or retrieving brokered credentials

Container namespace escapes that only reach the Firecracker guest OS are not in scope. Namespaces are a developer-experience feature, not the security boundary.

Bounties

The full bounty table, with example vulnerability classes for each tier, is on the HackerOne program page.

How to participate

The program is open now and closes on Tuesday, September 1, 2026, or earlier if the $1,000,000 USD reward pool is exhausted. Reports go through the HackerOne program page.

To reproduce a finding, boot a sandbox with the @vercel/sandbox SDK and demonstrate the impact with a live proof of concept. The default sandbox OS is enough for most reports; bring a custom image from the Vercel Container Registry only if your PoC needs extra tooling. We will not reward static-analysis-only findings; to issue a payout, we need to see the boundary break.

Results and payouts

We will triage reports from the day the program opens through one month after it closes. As findings are confirmed, we will pay bounties, ship fixes, and credit every researcher whose report holds up. The techniques discovered during this program will become permanent additions to the sandbox boundary, protecting every workload on Vercel long after the challenge ends. After the program closes, we will publish a follow-up writeup of the techniques and the fixes we shipped.

A Preview of DuckDB v2.0

TL;DR: DuckDB v2.0 is coming this fall. In this post, we preview its headline features: DuckDB as a server, triggers, the VARIANT type, asynchronous I/O, a new SQL parser, a new storage format, and much more.

DuckDB v2.0 will be named “Cyanoptera” after the cinnamon teal (Anas cyanoptera), a strikingly reddish-brown duck found in the western Americas.

A major version bump is not something we do lightly, and it is not just ceremony: v2.0 ships a new SQL parser, a new default storage format, a reworked C API, and a small number of carefully chosen breaking changes. But above all, it is a feature release, built from over 10,000 commits since we released v1.5 in March. Where last year was the year of the lakehouse, this release kicks off the year of DuckDB as a server.

DuckDB is moving rather quickly, and we can only cover a small fraction of the changes here. Condensing all new features down to a shortlist is always a fight over what gets in, and yes, we know that what follows is technically a listicle (Ten Things Coming to DuckDB v2.0, Number Eight Will Shock You). We are not proud of the format, but it works, so here it is, starting with the SQL-level features and working down into the engine.

1. DuckDB as a Server: Quack and CONNECT

DuckDB has been an in-process database since day one. But people have asked us – very persistently – for a client/server mode, and we have finally caved. The quack extension implements DuckDB's native protocol for talking to other DuckDBs. It graduates to stable in v2.0, and it is a big part of where DuckDB is headed: any DuckDB process can serve its databases over the network, and any other DuckDB can attach to it and route queries there using the new CONNECT statement. For example:

DuckDB server

CALL quack_serve(
    token = 'my_token'
);

DuckDB client

ATTACH 'quack:server.example.com'
    AS qk (TOKEN 'my_token');

CONNECT qk;
SELECT count(*) FROM events;
-- executes on the server,
-- results stream back
DISCONNECT;

CONNECT is the successor to the remote.query($$...$$) workaround we showed when Quack was first revealed – we looked at that syntax and said: no, this cannot be it. And CONNECT is not limited to Quack: it points your session at any remote database that supports it, and the new remote pushdown optimizer ships SQL directly to PostgreSQL and MySQL instead of pulling tables over the wire:

CONNECT 'postgres://localhost/mydb';
SELECT count(*) FROM orders; -- runs on the PostgreSQL server
DISCONNECT;

If you have worked with analytical systems in the past, you may assume that DuckDB cannot handle transactional workloads. But DuckDB has been built as a transactional, multi-connection database with full MVCC and transaction isolation since day one. Most users just never needed that in a single-user scenario. It turns out DuckDB handles transactions well: it's fast enough to compete with general-purpose databases like PostgreSQL on quite a few workloads, and the client/server pattern finally lets that machinery shine in multi-tenant, long-running deployments.

2. VARIANT Becomes a First-Class Citizen

The VARIANT type shipped in DuckDB v1.5, and the way to think about it is JSON on steroids. Basically, imagine if JSON were fast. Like JSON, a VARIANT column can store differently-shaped data in every row. Unlike JSON, it is not a text format: DuckDB automatically detects the common structure hidden in your semi-structured data and “shreds” it, so it compresses well in storage and executes fast in queries, all without you ever declaring a schema. This makes VARIANT a natural fit for real-time log ingestion, where streams of JSON-ish records share structure but evolve over time.

In v2.0, this pipeline works end to end: shredded execution straight from storage, extraction pushdown into scans, shredded VARIANT reading and writing for Parquet, and a family of variant_* functions:

CREATE TABLE events (payload VARIANT);
INSERT INTO events
VALUES ('{"user": {"id": 42, "tags": ["a", "b"]}}'::JSON::VARIANT);

SELECT variant_type(payload), variant_keys(payload)
FROM events;

SELECT *
FROM events
WHERE variant_contains(payload, {'user': {'id': 42}}::VARIANT);

3. Triggers

Triggers have been a long-standing feature request, and DuckDB v2.0 delivers them in full: BEFORE and AFTER triggers, FOR EACH ROW and FOR EACH STATEMENT, transition tables via REFERENCING OLD/NEW TABLE, multiple triggers per event, RETURNING on triggered tables, and DROP TRIGGER.

The classic use case is audit tables: something happens in the system, and a trigger records what changed. For example:

CREATE TABLE target (id INTEGER, val INTEGER);
CREATE TABLE audit (id INTEGER, old_val INTEGER, new_val INTEGER);

CREATE TRIGGER trg_audit AFTER UPDATE ON target
REFERENCING OLD TABLE AS o NEW TABLE AS n
FOR EACH STATEMENT
    INSERT INTO audit
    SELECT n.id, o.val, n.val
    FROM o
    JOIN n ON o.id = n.id;

INSERT INTO target VALUES (1, 10), (2, 20);
UPDATE target SET val = val * 10 WHERE id <= 2;
SELECT * FROM audit;

4. SQL Dialect Additions

As always, DuckDB's SQL dialect keeps growing. A few favorites from this release cycle:

With NEAREST joins, top-k similarity search becomes a join clause, handy for vector and embedding workloads:

SELECT q.user_id, t.product_id
FROM users q
    INNER JOIN products t APPROX NEAREST 2
    BY SIMILARITY array_cosine_similarity(q.embedding, t.embedding);

DML inside CTEs lets you use INSERT, UPDATE, DELETE, and COPY as pipeline steps:

WITH moved AS MATERIALIZED (
    DELETE FROM staging RETURNING *
)
INSERT INTO archive SELECT * FROM moved;

Nested schemas allow schemas within schemas:

CREATE SCHEMA finance;
CREATE SCHEMA finance.reports;
CREATE TABLE finance.reports.q3 (revenue DECIMAL);

The new variable syntax lets you write $x anywhere an expression is allowed:

SET VARIABLE threshold = 100;
SELECT * FROM orders WHERE amount > $threshold;

The JSON mutation functions json_set, json_insert, json_replace, and json_remove finally let you modify JSON documents in place:

SELECT json_set('{"a":1}', '$.b', '2');

And recursive CTEs with USING KEY aggregation enable iterative algorithms in pure SQL.

5. Asynchronous I/O

Interacting with object stores like S3 is central to the DuckDB experience. DuckDB v2.0 introduces asynchronous I/O throughout the engine. Thanks to asynchronous access, the I/O layer now scales independently from the query processing layer, which means far more parallelism for remote reads and dramatically faster queries on network storage.

6. Faster Queries Across the Board

As with every release, a lot of work went into making your existing queries faster without you doing anything. Recursive CTEs are significantly faster, aggregations now spill to disk when they outgrow memory, and row-group pruning has been massively expanded for complex types and filters. Query planning also becomes partition-aware, allowing better performance on lakehouse formats.

7. Storage Format v2.0

DuckDB v2.0 bumps the default storage format version to v2.0.0. Column metadata is now loaded lazily, so wide tables open faster. The DICT_FSST string compression method is enabled by default, deletes are stored compactly, and the storage layer performs much stronger corruption validation on read.

8. A Brand New SQL Parser

DuckDB v2.0 ships our own modern, extensible PEG-based parser. This change ties into the extension ecosystem: extensions can now hook into the grammar itself, so expect extensions that expose entirely new SQL syntax. It also brings better error messages with precise source locations, and dialect compatibility modes.

9. Timezones, Calendars, and Collations Without ICU

In v2.0, the ICU library is gone entirely: the icu extension now implements timezones, calendars, and collations itself, with the timezone data built directly from the IANA database. Everything keeps working as before, but the implementation is smaller, easier to keep up to date, and significantly faster.

10. Write Extensions Once, Host Them Yourself

DuckDB v2.0 will ship with a revamped C API. The API will have a versioned specification expressed in YAML, providing a stable ABI across DuckDB versions. You won't need to re-target or rebuild extensions every time a new DuckDB version comes out. Additionally, you will be able to register your own trusted repositories, so an organization can host and sign its own extensions and have them install and load just like the built-in ones.

Bonus: DuckDB Foundation – Advisory Board

Starting this fall, we will add a stakeholder advisory board to the DuckDB Foundation. The advisory board will provide input on the development roadmap of DuckDB, DuckLake, and Quack.

Final Thoughts

These are only a few highlights, and this post is only a preview. There have been more than 10,000 commits by many contributors since we released v1.5. We would like to thank our community for the detailed issue reports, feedback, and contributions that shaped this release.

Full article content is not available for inline reading.

Read the original article →

Incident with GitHub.com

Resolved

On August 17, 2026, from 13:28–21:15 UTC (7h 47m), GitHub.com experienced elevated errors and latency across Issues, Pull Requests, APIs, Actions, and Copilot. At peak, web/API error rates were approximately 20%, while archive and raw-content downloads reached approximately 50%. SAML/OIDC authentication, SCIM, and Team Sync were also affected, as well as Actions workflows in GHEC with Data Residency that depend on public workflow step definitions hosted on GitHub.com. Most services recovered by 16:36 UTC as our Central US datacenter recovered; Actions was degraded until approximately 18:03 UTC; and Copilot Token Service fully recovered by 21:02.

Some of the failing traffic was moved from Central US to Northern Virginia where it was served successfully until the network failure in Central US was debugged and resolved. Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x and caused delayed recovery for the Copilot Token Service.

The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic. Originally this was caused by an Istio sidecar pod reaching its concurrency limits and failing to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits. One failure cascaded to more and eventually four HAProxy nodes exhausted their flow limits, degrading the gateway auth path and causing widespread authentication latency and failures. The problem was worsened by optimistic retry logic which overloaded internal load balancers. Pausing HAProxy on those nodes simultaneously produced immediate broad recovery.

The retry storm in Northern VA was fixed by 1) temporarily reducing gateway retry logic with a PR and 2) blocking inbound Copilot Token Service token requests at the load balancers with a 403, and then gradually ramping back up traffic per-site to allow callers to succeed.

Residual Copilot authentication failures continued because client retry behavior amplified load: a failed token operation could generate many extra requests and enter a retry loop. Copilot Token Service traffic increased from a normal 7–9K RPS to 70–100K RPS. Reducing gateway authentication retries and blocking retry-triggering responses stabilized Copilot Token Service and completed recovery.

Complicating factors that impeded recovery included a number of scraping attacks on codeload endpoints.

To prevent recurrence, our follow-up actions include:

• Correcting autoscaling policies to account for service-mesh sidecar concurrency and capacity.
• Auditing Istio request, concurrency, and scaling limits across affected services.
• Reviewing retry limits and backoff behavior across gateways and clients.
• Addressing the VS Code retry behavior that amplified Copilot token traffic.
• Improving load-balancer capacity monitoring and regional failover safeguards.

Updates

Update (20:45 UTC): We are continuing to apply mitigations to address sporadic Copilot authentication failures in some applications. We expect full recovery within the next 30 minutes. Copilot usage via the GitHub CLI and GitHub App are unaffected.

Update (20:22 UTC): Issues is operating normally.

Update (20:08 UTC): We are continuing to investigate sporadic failures affecting Copilot authentication in some applications. Copilot usage via the GitHub CLI and GitHub App are unaffected.

Update (19:13 UTC): We are continuing to investigate sporadic authentication failures. We have partially disabled authentication token retries and have seen improvement, and we are monitoring impact before fully applying this mitigation.

Update (19:01 UTC): API Requests is operating normally.

Update (18:48 UTC): API Requests is experiencing degraded availability. We are continuing to investigate.

Update (18:23 UTC): The degradation affecting Git Operations has been mitigated. We are monitoring to ensure stability.

Update (18:11 UTC): We identified the problematic component and have taken corrective actions, but we are seeing residual impact in the form of sporadic authentication failures. We are continuing to apply additional mitigations and investigate the remaining impact.

Update (17:36 UTC): Issues is experiencing degraded performance. We are continuing to investigate.

Update (17:34 UTC): We identified the problematic component and have taken corrective actions, but we are seeing residual impact across numerous services. We are continuing to apply additional mitigations and investigate the remaining impact.

Update (17:30 UTC): Git Operations is experiencing degraded performance. We are continuing to investigate.

Update (16:59 UTC): The degradation affecting API Requests, Actions, Git Operations, Issues, Pages, Pull Requests and Webhooks has been mitigated. We are monitoring to ensure stability.

Update (16:36 UTC): We identified the problematic component and have taken corrective actions. There are strong signs of recovery but we are still working to completely restore service, with error rates still remaining slightly elevated. We will post further updates as recovery continues.

Update (16:16 UTC): We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. We are still working to identify the root cause and will continue to post updates as we learn more and perform mitigation.

Update (15:42 UTC): We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. We are currently performing mitigations and will post updates as we progress.

Update (15:40 UTC): Webhooks is experiencing degraded performance. We are continuing to investigate.

Update (15:21 UTC): Git Operations is experiencing degraded performance. We are continuing to investigate.

Update (15:10 UTC): Pages is experiencing degraded performance. We are continuing to investigate.

Update (15:01 UTC): API Requests is experiencing degraded availability. We are continuing to investigate.

Update (14:58 UTC): Webhooks is experiencing degraded availability. We are continuing to investigate.

Update (14:58 UTC): We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. We are currently performing mitigations based on our investigation thus far and are monitoring for improvement.

Update (14:58 UTC): Actions is experiencing degraded availability. We are continuing to investigate.

Update (14:54 UTC): Pull Requests is experiencing degraded availability. We are continuing to investigate.

Update (14:49 UTC): Issues is experiencing degraded availability. We are continuing to investigate.

Update (14:45 UTC): Pull Requests is experiencing degraded availability. We are continuing to investigate.

Update (14:31 UTC): Copilot is experiencing degraded availability. We are continuing to investigate.

Update (14:24 UTC): We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. Investigations are on-going and we will continue to provide updates as we discover more information.

Update (14:04 UTC): We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. Investigations are on-going into the root cause, and updates will continue to be provided as we investigate.

Update (13:58 UTC): Pull Requests is experiencing degraded performance. We are continuing to investigate.

Update (13:46 UTC): Issues is experiencing degraded performance. We are continuing to investigate.

Update (13:45 UTC): We are seeing an approximate 20% error rate across numerous experiences including Pull Requests, Issues, and others. Investigations are currently under way and we will be posting updates as they become available

Update (13:44 UTC): Webhooks is experiencing degraded performance. We are continuing to investigate.

Update (13:42 UTC): Actions is experiencing degraded performance. We are continuing to investigate.

Update (13:41 UTC): API Requests is experiencing degraded performance. We are continuing to investigate.

Investigating (13:40 UTC): We are investigating reports of impacted performance for some GitHub services.

xAI's Imagine Image 2.0 lands just behind OpenAI's GPT-Image-2 in Arena benchmarks

xAI releases Imagine Image 2.0 with editing tools and preconfigured templates. The model lands just behind OpenAI's GPT-Image-2 in Arena benchmarks.

xAI has launched Imagine Image 2.0 as a new "Quality Mode" on grok.com/imagine and in Grok's iOS and Android apps. API access for Imagine Image 2.0 is coming soon, according to xAI.

Imagine 2.0 is designed to follow instructions with fine-grained accuracy, keep typography and layout clean in complex visuals, and stay consistent across multiple generations, the company says.

In the Arena leaderboards as of August 7, 2026, the faster "low" variant of the model takes second place globally in both categories. It scores an Elo rating of 1,439 in the Image Edit Arena, behind OpenAI's GPT-Image-2 at 1,463. In the Text-to-Image Arena, it hits 1,320, again trailing GPT-Image-2 at 1,380.

Reve 2.1, Meta's Muse-Image, Alibaba's Qwen-Image-3.0-Pro, Google's Gemini, and ByteDance's SeedDream all rank further down the list. The new model also beats the "Quality" variant of its predecessor by a wide margin in these tests.

Editing tools built for iterative workflows

Imagine Image 2.0 ships with several editing features. A tool called "Magic Wand" modifies only the selected area of an image, according to xAI. A segmentation feature lets users pick precise regions, and a background removal tool exports subjects with a transparent background.

Multi-Ref Editing lets users combine up to five input images into a single generation. "Smart Resize" converts an existing image to any aspect ratio, with the model filling in the extra space on its own.

Templates and video pre-production planning

xAI is also adding templates that bundle common image workflows into preconfigured starting points. Categories span photo editing, product photography, marketing materials, design tools, game assets, and streaming emojis.

xAI is also showing a feature that generates characters, locations, and props separately while keeping the visual style consistent across all images. The company positions this as a stepping stone toward full video production workflows.

Full article content is not available for inline reading.

Read the original article →

In late 2025, we ran an experiment to answer one question: “Can coding agents autonomously solve a production-grade problem from scratch on their own?”

For this, we tasked two agents with the (at that time) best publicly available coding models with a real problem and a real deadline. The result of this experiment is a tokenizer trainer called toktoktok, and is now open source on GitHub.

In this article, we share what we learned about designing effective loops that allow agents to autonomously solve production-grade problems: how to specify a goal for multi-domain experts and how to set up the verification infrastructure.

Why testing autonomy needs a real target

As part of our research on the impact of vocabulary size on edge LLMs, we needed a byte-pair encoding (BPE) tokenizer trainer that could run trillions of tokens on a single machine. However, the tokenizer training landscape is thin:sentencepiece was optimized for non-BPE tokenizers and is slow, Hugging Face tokenizers ran out of memory on our corpora, and tiktoken has no training capability at all.

That’s why we needed to build a production-grade BPE tokenizer trainer. From our experience with existing libraries, we also knew memory size was the real bottleneck, and they were missing two features we needed: a warm start from an existing tokenizer (vocabulary extension) and a per-language vocabulary budget. This gave us a concrete task, with a real deadline, and an effective way to answer whether coding agents are reliable enough to autonomously solve a task, because it met the following criteria:

Production-grade. How agents are commonly used to autonomously solve a problem can't answer this question. First, they are often used for prototyping and never held to a production bar. Second, they reimplement something already existing in a different language, such as “Port SQLite to Rust” or “write a C compiler in Zig,” which is a translation of something the model has likely seen during pretraining. Unlike either of these, ours had a clear ship-to-production goal, and because BPE tokenizer training is recent enough with few public reference implementations, it made an ideal “test distribution” problem sample.

Multi-domain expertise. At Liquid AI, our experts run deep, but each in a single domain. Our ML researchers can tell you from memory why OpenAI’s cl100k reserves ranks for every three-digit number, but they’ve never written a line of Rust. Our Rust engineers write exactly the kind of memory-aware, multi-threaded systems code this problem needs, but they’ve never trained a tokenizer.

These are two disjoint sets of people, and neither can solve this problem alone. Both human workarounds are lossy: either one of them learns the other’s half first, or we staff it as a collaboration and pay the coordination overhead instead. This is the gap we pointed the agent at: “Can it cover a span of expertise no single one of our engineers has?"

Externally verifiable. The artifact must load in tiktoken and Hugging Face tokenizers. Because of this interoperability with third-party software, the work can be checked by code the agent can’t modify. Success isn’t self-reported but rather whether two third-party libraries either produce the right tokens or not.

While the details of what had to be built are interesting on their own, what matters for this article is that a task that is real production-grade, hard for our single-domain experts, and externally verifiable is the only honest way to answer whether an agent can do the job without any human oversight.

Setting up the experiment

For this experiment, we chose Claude Opus 4.5 and Codex with GPT-5.2, the two strongest publicly available coding models in late 2025, as the coding agents and let both work in their planning modes. Before either agent wrote a single line of code, we set up two things around it: a goal to aim at, and a way to verify whether it had gotten there.

The goal is described in a specification file. It's a single AGENTS.md / CLAUDE.md document written by the operator, describing the outcome and its constraints, not an implementation: The primary architectural constraint is memory. The design spends its complexity budget on memory, so a corpus far larger than RAM stays fairly represented. Compute and I/O are secondary and get straightforward treatment: a system-level programming language (Rust) and multi-threading should be sufficient.

To verify whether the agent has reached the specified goal, we gave it two things it couldn’t influence:

• Production data: We gave the agents sandboxed access to our production training dataset and a machine capable of handling it, specifically an AMD EPYC 9755 with 128 cores, 256 threads, and 2 TB of memory.
• External verification harness: The trained vocabulary had to be loaded by tiktoken and Hugging Face tokenizers, and checked both for encode and decode round trips and for ID-level agreement between the two, across multiple languages, numbers, currency formatting, tabs, CRLF line endings, and source code.

With these components in place, the agent could work toward the specified goal.

What happened when we ran it

We ran the experiment with both coding agents. The operator monitored from the outside, reading only the harness but never a single line of code.

Both zero-shot the toy trainer

Both agents produced a working trainer within 30 minutes. They parsed the config, walked the corpus, applied the hardcoded merges, ran the BPE training, and emitted a valid.tiktoken file that passed their own unit tests.

Both could successfully train toy tokenizers on a few megabytes. The artifacts loaded in tiktoken. All tests passed. If we stopped the evaluation at this point, the conclusion would be both runs are a success.

Neither scaled to production without loops

However, neither trainer survived the full production dataset. In the first run, every unit test passed at every stage, because a few megabytes of clean text triggers none of the following:

Then, we let the agents loop against the real data: execute, hit a wall, report the symptom, let the agent diagnose and fix, run again.

After more than five iterations with little progress, we stopped work on the Codex/GPT-5.2 track, which was still struggling with training throughput. That was a resourcing decision: one operator, a real deadline, and by that point the Claude Opus 4.5 track was further along after the same number of turns. Our read was that Claude's first version started from a better place by picking up the nuances of the specification and the intent behind the constraints more reliably than GPT-5.2.

Claude Opus 4.5 closed out the remaining issues over a handful of further iterations and produced a trainer that ran the full production configuration: trillions of tokens of multilingual and code data, multi-phase, on a single machine, completing in a few days. The output passed the external harness cleanly.

Why the loop was necessary

We ran this experiment to answer the question, “Can coding agents solve a production-grade problem from scratch on their own?” It's tempting to read "neither agent zero-shot it" as a story about model capability, but this is the wrong conclusion. By the bar we had set at the start, the experiment succeeded. However, what got it there was not any single clever turn but the loop.

The two thousand lines in this repository aren't an artifact of a zero-shot response but the residue of an iterative process. Almost every non-obvious line is cheap to write once you know it needs writing, and the expensive part is knowing that it needs writing at all.

That means whether or not an agent can successfully achieve a goal without human oversight depends on having an iteration loop that converges against the constraints of the real environment. This allows the agent to iteratively discover and experience the messiness of the real world.

Lessons from running an autonomous loop

From this experiment we learned that coding agents are able to autonomously solve a task with a loop, but more importantly, we learned two valuable lessons on how to design effective loops, which have become everyday practice on our engineering team today.

Specify goals for multi-domain experts

From the experiment, we learned that coding agents are multi-domain experts, covering a span of expertise none of our engineers have. Turns out it knew OpenAI's cl100k regex, and it knew Rust’s rayon. Nobody we could have staffed on this knew both. This changes how we can specify the goals because it feels more like talking to a colleague from the other team who happens to also know your team's material.

Consider what it would actually take to hand this problem to a strong software engineer with no tokenizer background. The obvious answer is to write them a detailed spec. This is the classic bind of expertise transfer: Write the spec too short, and the engineer has to discover all of it the slow way. Write it long enough to be genuinely actionable, and you have written pseudocode, at which point you needed the domain knowledge yourself and could nearly have done the work.

An LLM isn't in that bind, because it arrives with the background already installed. That changes what a specification is. Ours was short. It stated outcomes and constraints rather than mechanisms.

Take a real example from our spec: “reserve vocabulary for all two- and three-digit numbers before training starts”. To an engineer without the background, this is an arbitrary requirement. They can implement it literally and still get it wrong, because the sentence doesn’t carry its own motivation. It’s about giving the model a consistent numeric representation so arithmetic doesn’t depend on which digit pairs happened to be frequent in the corpus, e.g., think of GPT-2’s tokenizer that has a unique 2019 token but not a 2029 one due to frequency in the training data. Not knowing that, they can’t tell which parts of the instruction are critical, where in the pipeline it belongs, or what else in their design it implies.

Verify against the constrains to the real world

Our operator never read a line of the produced code. This was only acceptable because the success criteria were something the agent couldn’t manipulate. A common mistake we see in loop design is weak verification, run against toy-scale data or open to the agent’s influence, such as editing its own unit tests.

The main lesson is to design a loop that converges against the constraints of reality with the following components:

1. Iterate against real production data at scale. The failures that mattered were invisible in a test suite and only discoverable in full-scale production data.
2. Verify with an external harness. This is what makes autonomy acceptable. The operator never read the code, and that was tolerable only because correctness was defined by tiktoken and Hugging Face tokenizers, software the agent did not write and could not influence. Had we accepted its own test suite as evidence, we would have had two implementations that passed their tests and produced quietly different vocabularies. Structure the problem so a third party can judge the artifact.

What’s routine today and looking ahead

These are the results and lessons from an experiment we ran in late 2025: Yes, coding agents can solve a production-grade problem from scratch on their own, without any human oversight, but only when they run inside a loop.

The lessons we learned have become everyday practice on our engineering team today. Half a year on, specifying the goal is the part we spend the most care on, and building loops with real data and external verification have become standard practice.

Today we run loops well beyond one-off builds like the tokenizer trainer, which had a clear, verifiable end goal the loop converged toward. Many of the loops we run now are open-ended instead, hill-climbing toward an objective with no single right answer: tuning a kernel, watching continuous integration, triaging incoming pull requests, or scanning production logs for anomalies. In each, we check the metric instead of the code.

Today's models are meaningfully better, but what made this routine is that they got reliable enough to hand the whole loop to. If that generalizes, it's a bigger shift in how ML and software engineering get done than any change in raw coding ability.

Availability

toktoktok is open source under Apache 2.0 at https://github.com/Liquid4All/toktoktok. It trains tiktoken-compatible BPE vocabularies from scratch or extends existing ones, reads .txt and .parquet, allocates vocabulary budget across languages and domains through multi-phase training, and stays inside a memory budget you declare. Conversion scripts for Hugging Face go both directions and verify equivalence before writing anything.

Every line of it was written by an agent, and none of it has been read by us.

Acknowledgements

Written by Mathias Lechner, with contributions from Leonie Monigatti.

We are grateful to AMD for the partnership that made the hardware for this experiment available.

Citation

Please cite this article as:

Liquid AI, "Designing Loops for Production-Grade Work", Liquid AI Blog, Aug 2026.

@article{liquidAI2026loops,
  author  = {Liquid AI},
  title   = {Designing Loops for Production-Grade Work},
  journal = {Liquid AI Blog},
  year    = {2026},
  note    = {www.liquid.ai/blog/agent-loops},
}

Full article content is not available for inline reading.

Read the original article →

FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution

Frontier open-weight models are increasingly available, but serving them still largely assumes datacenter infrastructure. We present FreeToken, an edge-native MoE serving system that treats a personal machine not as a small GPU, but as a unified, elastic inference platform. FreeToken co-designs the full serving stack, including model layout and loading, expert residency, CPU--GPU execution, agentic state reuse, and runtime memory management, around two realities of local AI: agent workloads continuously change their execution pattern, and edge hardware exposes heterogeneous resources whose balance differs from machine to machine. Rather than committing to a fixed offloading strategy, FreeToken continuously maps computation and model state onto the resources actually available. FreeToken supports more than 20 MoE models and real coding and tool-using agents across hardware ranging from an 8GB laptop GPU to a single workstation GPU. More importantly, it changes what these machines can practically serve, from a 35B model on a laptop to a 284B model on a gaming desktop and the 753B GLM-5.2 on a single workstation GPU. FreeToken turns open weights into deployable local software, making the machines users already own a practical platform for frontier-scale intelligence. We release the system at http://flashml.ai.

Large language model-based agentic frameworks primarily optimize capability: whether an agent can reason, retrieve information, call tools, delegate work, and complete a goal. Enterprise execution requires a stronger property. A successful result is not reliable if it was produced through unauthorized data access, widened delegated authority, unapproved side effects, unrecoverable budget consumption, or incomplete evidence. This paper defines reliable capability as a path property: an agent is reliably capable only when it completes a task through action events that remain admissible under identity, profile, tool, data, memory, budget, artifact, approval, and audit constraints. We propose a policy algebra that defines the reliability envelope within which agent capability may be exercised. Security profiles and runtime obligations compose through joins, intersections, budget narrowing, approval inheritance, and evidence accumulation; the resulting composition is both trust-preserving and the least restrictive state satisfying all governing inputs. The algebra also propagates restrictions across multi-agent calls and introduces cost-aware artifact materialization, which redirects open-ended execution toward a recoverable outcome as budget exposure grows. The evaluation is interpreted as a reliability-capability trade-off rather than a capability benchmark: the policy-algebra runtime intervenes on 94.8% of policy-violating events while retaining an 86.9% task-completion rate, eliminates the observed profile-monotonicity and zero-artifact-exhaustion violations, and increases audit completeness to 98.6%. The method provides researchers and practitioners with formal correctness conditions, executable decision semantics, and trace evidence for building agents that are not only capable, but reliably capable.

In short : Qwen3.6-35B-A3B generates 2.2x faster than Qwen3.8-27B, yet finishes slower because it thinks 3.1x longer. Across 25 tasks, quality is tied. Measure time to answer, not token speed.

Your laptop can now run a model as capable as nearly anything in the cloud. I swapped Qwen3.8-27B into my agent & it works brilliantly. This bird flies differently than a plane.

This little Qwen model ranks #1 of 135 models, scoring 52 on Artificial Analysis’s Intelligence Index, a point above GLM-5.2, the state-of-the-art open-source model from Z.ai, at 753b parameters. A laptop model beats a recognizable, frontier-class cloud peer roughly 28 times its size.

How does a bumblebee achieve the same flight as an airliner? Bigger models can store more knowledge, so they can skip straight to an answer, like an expert in many different fields. Smaller models don’t have as much memorized, so they must reason more, almost from first principles, to close that gap.

I saw this firsthand when benchmarking the DeepSeek V4 cloud model against two local models. I compared them on the same work, 25 venture-capital tasks (researching startups, summarizing articles, transcribing podcasts), scored by a judge model.

Qwen3.8-27B is dense : it uses every chapter in the book on every question. Book skimmers DeepSeek & Qwen 3.6 35b (another local model I threw into the test), flips only to the relevant chapters for a question.

These models provide identically good answers. But the speed varies. The local Qwen 35b shreds at top speed, but needs to think about 7.2x more than the cloud model, crossing the line 9 seconds after DeepSeek. The newest Qwen model is three seconds faster, & the cloud is 6 seconds faster yet.

The cloud model jumps to the right answer ; the local models contemplate & debate internally at different rates of speed & accuracy.

For example : on one triage task, the 35B spent 993 tokens to produce six words, “Classification: Scheduling / Action: Respond.” 1000 tokens of deliberation before the response is a hummingbird’s sprint to a honeysuckle. The bumblebee needed 369 thinking tokens, buzzing along at half the speed.

Local models can achieve the same result as cloud models, but they’ll take a different flight path to get there.

1. Artificial Analysis ranks the incumbent here, Qwen3.8-27B, #1 of 135 models on the Intelligence Index, scoring 52, a point above GLM-5.2’s 51, a 753b-parameter frontier model Z.ai shipped two months earlier. The same page ranks it #23 of 135 on output tokens per task, 160M weighted tokens against a class median of 43M. Intelligence rank & verbosity rank move independently, & that’s the trade this whole post is about.
2. The imitation-gap explanation. Smaller models produce fluent chain-of-thought that’s more likely to drift logically inconsistent, because they have a sparser map of nearby correct examples to draw on once forced off the direct path to an answer.
3. Method. 25 venture-capital tasks (researching startups, summarizing articles, transcribing podcasts) drawn from my own agent queue. A separate judge model, deepseek-v4-pro, scored outputs blind on completeness, accuracy & conciseness, 3 points each for 9 total. max_tokens was 4096 for every run. Both local models were served through Ollama on the same MLX runtime, so the comparison isn’t confounded by runtime differences. I established the judge’s noise floor by re-scoring identical outputs, which returned a mean absolute difference of 0.16.
4. Qwen3.6-35B-A3B is a 35b parameter model with 3b active parameters per token, a sparse mixture-of-experts architecture, 256 total experts with 8 routed & 1 shared active per token.

Introducing :Harvey: II

Harvey's agents now inherit the context of your matters and projects, along with a memory of how you work.

Legal work carries history.

A matter or project can run for months. Different lawyers step in, documents change, and earlier decisions shape what happens next.

Yet most legal AI starts over every time you ask it to do something. You give it the documents, explain the matter, tell it what to look for and how you want the answer structured. Then you correct the output until it’s something you’d actually use. The next task starts, and you do much of that setup again.

An agent that starts fresh each time can’t understand the full context of the matter, which limits the complexity of the work it takes on. For the lawyer, that means spending time getting the AI back up to speed before the real work can begin.

Today, we’re introducing Harvey II.

Now, Harvey’s agents are smarter from the start. They begin with more than just what you put in the prompt. They inherit the context of the matter or project they open in, along with Harvey’s memory of your style and preferences.

That changes the ceiling on what you can hand an agent. More substantive legal work can move forward with the context, permissions, and memory already in place.

Agents start with the context they need

What an agent needs to know changes with the work. On a firm matter, that might be who’s staffed, which documents belong to it, which client it’s for, and the permissions and ethical walls that apply. For an in-house deal, it could be the counterparty, whose paper you’re on, and the positions your team has taken before. Until now, lawyers have had to bring all of that to the agent themselves, one upload, one instruction at a time.

Harvey II is built so you don’t have to carry that context over by hand. An agent opens inside the matter or project, with the documents, parties, tasks, permissions, and history of the work already there.

That Space is also where the work moves forward. Tasks can be assigned to a lawyer or an agent. When an agent finishes a first-pass review, the task moves to the specialist who owns the next step, without the work disappearing into another email thread.

For firms, permissions and ethical walls sync directly from existing systems into the Space. Usage and cost stay tied to the same matter or project, so AI spend follows the work.

Agents always carry your team’s instructions and playbooks, but client data never moves from one Space to another. When an agent opens in a Space, it picks up both the context and the boundaries of that matter or project.

Memory makes Harvey more personal

A Space gives Harvey the context and history of the work. Memory gives Harvey a history with you. It learns how you structure a summary, what you want cited, and how you write.

Some of this you tell Harvey directly, and it sticks. The rest it picks up as you work, from your edits and corrections. That memory follows you across Harvey, Word, and Outlook. When an agent takes on work for you, it can use what Harvey already knows about your preferences and patterns. You spend less time repeating instructions or fixing the same things. You can see everything Harvey remembers, change it, or turn it off entirely, and it's never used to train models.

And the more Harvey understands how you work, the more you can trust an agent with substantive legal work. It starts from your preferences and prior work, so what comes back is already closer to something you'd actually send.

The same goes for the way your team works. Nobody in legal starts from a blank page. A firm has the credit agreement it's negotiated a hundred times. An in-house team has its approved fallbacks. Harvey II can work from those templates too, so drafts arrive in the shape your team already uses. Set the headings, numbering, defined terms, and citation style once, and Harvey applies them consistently. The more you use Harvey, the less you have to explain.

For the first time, Harvey has intelligence trained for legal work

Context and memory tell an agent what to do. The model determines how well it does it. Until now, Harvey has relied on general-purpose models. Legal work has always pushed against their limits. Today, that changes with Harvey Tenet, our first model, post-trained end-to-end for legal reasoning.

Harvey Tenet is frontier-level on prominent legal benchmarks, performing on par with the strongest general models at an open-source cost and making it practical to run agents continuously across every matter.

It also lays the groundwork for what comes next: partnering with organizations to build specialized models around their own legal work. Two firms using Harvey will end up with different models and different outputs because their legal work has shaped their models differently.

When Harvey knows the work, you can trust it with more

In practice, this is what changes when an agent doesn’t start from scratch. You come back to an M&A matter in the morning. Harvey has worked through the latest batch of material contracts in the data room overnight and returned a first-pass review in your format, with the findings cited. It surfaced the agreements that need your attention, and opened the next review step for the lawyer who owns it. You didn’t have to rebuild the context, repeat how you want the work done, or route every step yourself.

Harvey II brings the pieces together. Agents open inside Spaces, where the context, history, people, tasks, and permissions for a matter or project stay with the work as it moves between agents and lawyers. Memory carries forward what Harvey has learned about how you work. And legal-specific intelligence lets those agents reason across all of it at significantly lower cost.

The work carries history and context. Your process carries preferences. Harvey II starts with both.

Welcome to the new Harvey.

Companies are still grappling with exactly how software development should work in the AI area, but one early answer is the so-called software factory. Essentially an agent loop that’s built around the traditional stages of software development, the software factory approach has become a popular way for companies to remake their engineering organizations for the AI era.

Now, a system from Warp could make that transition a lot easier. On Tuesday, the AI coding company introduced Warp Factories, a new system designed to make building and operating AI software factories as easy as possible.

Operating as an infrastructure layer, Warp Factories gives companies a simple environment for deploying agents and a roadmap for how to use them.

To be clear, many companies are already having success with the factory model without any help from Warp. Stripe has been particularly public about its technical progress, developing a “minions” system to automate development within its own codebase. Ramp has made similar progress, developing a background agent that can monitor its own code after it is deployed.

As Warp CEO Zach Lloyd sees it, the target market for Warp Factories will be smaller companies without the resources to develop a system from the ground up.

“[If you look at] things like running your agents in the cloud and steering those agents as they run, or bringing the work that they’re doing into your local environment, or setting up memory that goes across those agents, or setting up evals that go across those agents — it’s actually a huge infrastructure undertaking to do this right,” Lloyd told TechCrunch.

In Warp Factories, the architecture is already built out of the box, with many of the most difficult decisions already made. Warp’s system is based on the standard phases of software development (triage, specification, implementation, review, and verification), but the agentic approach means any of those steps can be automated.

Users can choose their own coding model and harnesses as necessary; the system works as well with Codex as with Claude Code. It also integrates with ticketing systems like Linear and Jira, and messaging systems like Slack and Teams, in an effort to plug in seamlessly to existing workflows.

Beyond just shipping code, Warp Factories will also give managers the tools to track how well the factory is performing. With all the agents running in the same environment, it’s easy to compare performance metrics for different configurations, and to keep an eye on the overall token spend. Warp Factory also allows for self-improvement loops to optimize the overall system, automating management of the process itself.

Even so, Warp Factories is not built to completely replace software engineers — just give them an easier way to collaborate with the new agentic workforce. In Lloyd’s own experience, there are still a lot of tasks that require a human at the wheel.

“We automate like 30% of our tasks, 30 to 35% on a weekly basis,” Lloyd told TechCrunch, “and as models improve, as the context improves, as the harness improves, I think that that number is going to go up over time.”

OpenAI is rewriting its Preparedness Framework while expanding monitoring, strengthening research-environment isolation, and moving alignment work earlier in model training. It has resumed many smaller or lower-risk workloads after a pause of little more than two weeks, but the largest planned frontier reinforcement-learning run and significant Astra and cyber workloads remain paused. Astra is an unreleased model that may reach OpenAI's Critical cyber threshold. OpenAI has not released the promised technical postmortem of the Hugging Face breach or the evidence behind Astra's possible Critical classification.

GenBio has announced a world model of a cell that can simulate both its natural state and responses to successive perturbations. AIDO Cell currently supports K562 and HepG2, two of the most widely used immortalized human cell lines in biomedical research. GenBio is preparing to launch an early-access academic collaborator program for scientists across academia, biotech, and pharma. AIDO Cell and similar systems could eventually become powerful tools for basic biological research, allowing scientists to perturb genes, proteins, or pathways, follow the predicted consequences across biological levels, generate hypotheses, and identify relationships that might take much longer to uncover in the lab.

China's LandSpace recovered the first-stage booster of its ZQ-3 rocket on its second attempt. The ZQ-3 is comparable to SpaceX's current workhorse, the Falcon 9. It has a stainless steel rocket body and liquid oxygen-methane engines, which could enable it to achieve even lower launch costs than the Falcon 9. Its landing-leg recovery method allows the rocket to be quickly refurbished and relaunched as engineers only need to maintain the rocket itself without having to repair ground recovery equipment.

Mojo🔥 is now open source!

We are happy to announce that the Mojo🔥 language is now fully open source under the Apache 2.0 license (with LLVM exceptions)! The source code for the Mojo compiler, tooling, and everything else you need to build the language are now available in our modular GitHub repository.

The Mojo language is a bold bet: a novel general purpose programming language that goes further than older ones. Mojo integrates the latest in compiler and programming language research to unlock GPUs, AI accelerators, and other advanced compute. For the last four years, Mojo has been developed with an open community, but a closed compiler. Last week Mojo hit 1.0 (with source stability), and today we’re excited to open source the entire compiler and toolchain.

Apache 2: A permissive license

The Apache 2.0 license is the gold standard for programming languages and compilers, because it provides great flexibility to be used in all sorts of applications. The LLVM extensions to the license further expand those freedoms for building and distributing binaries compiled from Mojo. We want you to be able to adopt and use Mojo in as many applications as you can imagine.

Our open source approach has been deliberate: we’ve found that small and tight-knit design teams (not committees) are the best for finding the “soul” of a language, but that feedback from a broader community is essential to escape an echo chamber. As such, we first open-sourced the Mojo standard library, then released hundreds of thousands of lines of kernel code written in Mojo, tools, and support. We built together with community feedback and public design proposals, and are now open sourcing the compiler. We will continue to open our processes further as Mojo keeps maturing.

How to get and build the compiler

All code for the Mojo language is now available at the main modular GitHub repository. First, clone that repository locally:

git clone https://github.com/modular/modular.git

cd modular

Then, to build the Mojo compiler from source and run it against a Mojo file you can use a single build command:

./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo

At Modular, we use Bazel to manage the complex build processes and caching for Mojo and MAX. This one command will download or build everything needed to build the Mojo compiler and the Mojo standard library. The flag --config=build-mojo tells the build system to compile everything from scratch, using the source code on your local system.

This extends to working with the Mojo standard library, where you can modify the compiler or library code and run the full suite of tests via:

./bazelw test --config=build-mojo mojo/stdlib/test/...

If you aren’t working on the compiler itself, you can use the flag --config=prebuilt-mojo and the build system will download the latest nightly binary distribution of the compiler, saving you some compilation time. Note that a prebuilt Mojo compiler is still necessary today if you are customizing MAX kernels or models.

Contributions

The Mojo standard library has been accepting contributions since 2024, and we’re grateful for everyone that has helped advance the language. One learning (particularly in today’s era of AI coding) is that we need to be deliberate about how we handle contributions. As such, we aren’t ready to take contributions to the compiler and tooling. We aim to accept contributions to the compiler and tooling by the end of this year, and we’ll share more details when we can.

To ask any questions about the Mojo compiler source as you read through it, or to share what you’re working on, please join our forum. Clone the source code and let us know what you’re building with the Mojo language. We’re excited to open Mojo up to the world and see how it grows!

I'm Worried About a Prompt Injection Worm

I think one form the first big AI hack could take is a prompt injection worm.

Let's piece this together.

1. Open source models reach or surpass GPT 6 or FABLE 5 by the final months of 2026 or the early months of 2027.
2. Some threat actor (private or government) has been building target lists for months or years in the form of input-parsing attack surfaces, e.g., email addresses, web forms, Telegram, whatever.
3. They have not launched the attacks yet because they know not everyone has agents hooked up to their input sources yet.
4. As AI continues to permeate into everyone's work and personal tech stacks via integrations in late 2026 or early 2027, the chances become very high that they have AI parsing their email and texts.
5. The threat actor builds a number of zero-day prompt injections that can pass through the top lab and open source models. They also build a bunch of different payloads, such as "export this data to this location, etc.".
6. The final part of the payload is sending the payload on to other victims from that victim, via email, text, messaging, whatever.

So basically, one day we wake up and terabytes of sensitive data has been uploaded to the attackers and/or dropped publicly online for embarrassment purposes. This might include credentials, customer data, whatever.

Another variation of this attack could be a much smaller scope, but more targeted, where the credentials are actually used quietly versus blasted out all at once. The issue with doing the first version is that it will be so loud that everyone will check and start rotating credentials. Whereas if someone does the second version, it will take a lot longer for them to figure out they were compromised.

The most interesting and concerning part of this to me is that this is a game of the strength of prompt injection defenses versus the rapidly increasing intelligence of unrestricted open source models. And I don't like the odds for us in this fight.

There have already been lots of other types of AI-harness-based attacks of the more traditional form, and those will surely continue as well, but I see the combination of prompt injection with the massive number of parsers and integrations as one that will hit soon.

Without hyperbole, I think what they announced represents both the greatest boon for business and the biggest problem for security that we've seen injected in a single day in many decades. AI Agents + API Access + Prompt Injection, November 2023

So, what to do about it?

You have to know where your parsers are. In other words, you have to know where you have AI touching your tech stacks and workflows. You have to look at all your integrations, continuously, and have threat models for them based on what they have access to.

One of the biggest security problems we'll face around AI will be semi-autonomous agents roaming the internet with too much authority. There are two main issues: parsing everything without consideration, and being connected to internal functionality while doing so. AI Canaries, June 2023

Then you have to stack your defensive layers for prevention, and perhaps even more importantly, be ready to respond if something happens.

If I'm right, this is the quiet before the storm hits.

Notes

1. I use this definition of the underlying flaw: an AI system or component that is unable to distinguish between instructions and data, causing it to treat attacker-supplied content as trusted instructions. Is Prompt Injection a Vulnerability?, June 2026.
2. The long version of how these attacks actually work, with the taxonomy and the defenses people are trying. UL NO. 456: A Deep-dive on Prompt Injection, October 2024.
3. The two halves of the problem, written up back when agents first got real authority. AI Canaries, June 2023.
4. Why the day agents got API access was the day this became inevitable. AI Agents + API Access + Prompt Injection, November 2023.
5. The argument against treating injection strings as zero-days to be hidden from defenders. Thoughts on Prompt Injection OPSEC, November 2025.
6. The version of "know where your parsers are" for everything you have deployed online. How AI Builders Will Get Hacked, August 2026.
7. Why nothing gets better until something loud enough happens. We Can't Really Affect AI Security, May 2025.
8. The older, more general version of the same instruction. If You're Not Doing Continuous Asset Management You're Not Doing Security.
9. 🤖 AIL 1: Daniel wrote this post. I (Kai, his AI assistant) helped with formatting, the subtitle, the archive links and quotes, and the header image. Learn more about AIL.

Code Mode

Code mode lets a model write JavaScript or TypeScript that calls your AI SDK tools. The generated code runs in an isolated QuickJS sandbox and returns a JSON-serializable result.

Instead of calling tools one at a time, a model can use code mode to:

• call independent tools concurrently
• transform and combine tool results
• filter large tool responses before returning them to the model
• use JavaScript control flow for multi-step operations

Code mode is provided by the @ai-sdk/code-mode package.

Code mode is experimental and its APIs may change in future releases. It requires Node.js 22 or newer and is not available in browser or edge runtimes.

Installation

pnpm add ai @ai-sdk/code-mode zod

Using Code Mode with generateText

Define your tools in one tool set and use experimental_toolCallers to select which tools code mode can call:

import {
  DIRECT_TOOL_CALL,
  experimental_codeModeTool as codeModeTool,
} from '@ai-sdk/code-mode';
import { generateText, isStepCount, tool } from 'ai';
import { z } from 'zod';

const getInventory = tool({
  description: 'Get available inventory for a product.',
  inputSchema: z.object({
    productId: z.string(),
  }),
  outputSchema: z.object({
    productId: z.string(),
    availableUnits: z.number(),
  }),
  execute: async ({ productId }) => ({
    productId,
    availableUnits: 42,
  }),
});

const getDemand = tool({
  description: 'Get requested units for a product.',
  inputSchema: z.object({
    productId: z.string(),
  }),
  outputSchema: z.object({
    productId: z.string(),
    requestedUnits: z.number(),
  }),
  execute: async ({ productId }) => ({
    productId,
    requestedUnits: 31,
  }),
});

const tools = {
  code_mode: codeModeTool({
    executionPolicy: {
      timeoutMs: 30_000,
    },
  }),
  getInventory,
  getDemand,
} as const;

const result = await generateText({
  model: "xai/grok-4.6",
  tools,
  experimental_toolCallers: {
    getInventory: ['code_mode'],
    getDemand: ['code_mode'],
  },
  stopWhen: isStepCount(10),
  prompt: 'Compare inventory and demand for product sku_123.',
});

The keys in experimental_toolCallers are the tools being governed. The values identify their allowed callers. In this example, getInventory and getDemand are available through code_mode, but they are not exposed to the model as directly callable tools. Include DIRECT_TOOL_CALL when a tool should also be callable directly:

experimental_toolCallers: {
  getInventory: ['code_mode', DIRECT_TOOL_CALL],
};

Tools without an experimental_toolCallers entry keep their existing direct tool-calling behavior.

The code mode tool description includes TypeScript signatures generated from the input and output schemas of its allowed tools. Descriptions, inputExamples, and precise schemas help the model write correct code.

For the example above, the model can generate a program like:

const [inventory, demand] = await Promise.all([
  tools.getInventory({ productId: 'sku_123' }),
  tools.getDemand({ productId: 'sku_123' }),
]);

return {
  sufficient: inventory.availableUnits >= demand.requestedUnits,
  remaining: inventory.availableUnits - demand.requestedUnits,
};

Each provided tool is available through the global tools object. Tool names that are not valid JavaScript identifiers use bracket notation:

const user = await tools['lookup-user']({ userId: 'user_123' });
return { id: user.id, plan: user.plan };

Writing Code Mode Programs

Generated programs support:

• JavaScript and type-stripped TypeScript
• top-level await and return
• standard JavaScript control flow and data transformations
• Promise.all for concurrent tool calls
• JSON.parse and JSON.stringify
• console.log, console.info, console.debug, and console.error

Every tool call is asynchronous and must be awaited or otherwise observed. Returning while tool calls are still detached fails the invocation and aborts the outstanding work.

Programs and tool inputs and outputs cross the sandbox boundary as JSON. Return only JSON-serializable values. TypeScript support is limited to removing type syntax; code mode does not perform type checking or provide a full TypeScript compiler.

Direct Execution

Use experimental_runCodeMode when you want to execute a program directly instead of exposing code mode to a model:

import { experimental_runCodeMode as runCodeMode } from '@ai-sdk/code-mode';

const result = await runCodeMode({
  js: `
    const inventory = await tools.getInventory({
      productId: 'sku_123',
    });

    return {
      productId: inventory.productId,
      available: inventory.availableUnits > 0,
    };
  `,
  tools: { getInventory },
});

runCodeMode returns the value returned by the program. It uses the same sandbox and execution limits as the AI SDK tool.

Tool Approval

Code mode does not currently integrate with AI SDK tool approval flows. Tool calls made by generated code are nested inside the code mode invocation, so they cannot pause the generation and surface a tool approval request to your application.

Do not expose tools that rely on user approval to code mode. Keep those tools directly callable by the model instead. If a nested tool requires approval, the call is rejected rather than executed.

Execution Limits

Every invocation has limits for runtime, memory, source size, results, tool payloads, console output, and tool calls. Override them with executionPolicy:

const codeMode = codeModeTool({
  executionPolicy: {
    timeoutMs: 30_000,
    memoryLimitBytes: 64 * 1024 * 1024,
    maxResultBytes: 1024 * 1024,
    maxBridgeRequests: 100,
    maxInFlightBridgeRequests: 10,
  },
});

The available limits are:

• timeoutMs: total execution time
• memoryLimitBytes: QuickJS memory
• maxStackSizeBytes: QuickJS stack
• maxSourceBytes: generated source code
• maxResultBytes: returned result
• maxConsoleOutputBytes: combined console output
• maxToolInputBytes: input for each tool call
• maxToolOutputBytes: output from each tool call
• maxBridgeRequests: total tool calls
• maxInFlightBridgeRequests: concurrent tool calls

Use experimental_setMaxWorkers to set a process-wide cap on concurrent code mode workers:

import { experimental_setMaxWorkers as setMaxWorkers } from '@ai-sdk/code-mode';

setMaxWorkers(4);

Without an explicit cap, code mode chooses one based on available memory, up to 32 workers.

Isolation and Tool Access

Each invocation receives a fresh QuickJS context. Sandboxed code cannot access:

• Node.js globals such as process, require, or module
• the host file system or module loader
• fetch, WebCrypto, or performance APIs
• eval or dynamic Function construction

Network or system access must be implemented in a tool and explicitly provided to code mode.

Treat the sandbox as defense in depth. Generated code and tool arguments are untrusted. Tools execute in your host application, outside the QuickJS sandbox, and every capability exposed by a provided tool is available to the generated program. Enforce authorization and validate inputs inside each tool.

Tool input schemas are validated before their execute functions run. Abort signals and AI SDK tool execution context are forwarded to nested tool calls.

Full article content is not available for inline reading.

Read the original article →

Node.js creator liberates Durable Objects from Cloudflare

We've got good news for developers who are enamored with Cloudflare Workers and Durable Objects but don’t want to be tied into that company’s backend infrastructure. Last week, Node.js creator Ryan Dahl unveiled his latest project, celld, which he described on X as “a self-hosted, distributed Durable Objects and Workers implementation.”

Dahl’s celld model is compatible with Cloudflare’s Workers and Durable Objects’ JavaScript APIs, but he claims that it is much less expensive to run.

The project is no mere budget-minded open source rip. On celld’s web page, Dahl and his team characterize their replication of the Durable Objects architecture as a “love letter.”

Cloudflare’s Durable Objects is a single-threaded object with a unique global ID and its own storage, where user data is stored in its own copy of SQLite. It runs on the Cloudflare serverless Workers runtime, which runs apps embedded in isolates—a type of lightweight virtual machine supported by Google's V8 JavaScript engine.

First devised by Kenton Varda and Cloudflare, Durable Objects is “one of the best primitives distributed systems has been handed in years,” celld’s creators write. Unlike traditional serverless platforms like AWS Lambda, the Durable Objects model co-locates the data with compute, while using single-threaded execution to eliminate complex concurrency issues.

“A primitive this good deserves to run anywhere,” the celld page states.

Serverless but stateful

Since its introduction in 2020, Durable Objects has been used to build low-latency, highly distributed Web applications. It is a stateful serverless execution environment, a data cache that can also do computation.

Using the WebSocket API, the Durable Object can connect many simultaneous users at once in a live environment. WebSockets’ Hibernate mode can put the object to sleep, so cloud bills don’t accrue when no one uses the app.

As a result, the stateful serverless model is best suited for real-time collaborative applications, such as multi-player games, team productivity apps and AI agents. Cloudflare uses Durable Objects for its serverless SQL service and AI Gateway.

One YouTube tutorialist explained that using Durable Objects allowed him to eliminate an entire stack of tools (Amazon API Gateway, Apache Kafka, Redis, AWS Lambda and EventBridge, Apache Airflow and Spark all get name-dropped) because Durable Objects can handle all these functionalities “at a smaller scale.”

Giving Durable Objects an open source home

Dahl is one of the world’s foremost experts at JavaScript I/O, having created Node.js, a JavaScript runtime that runs the world’s fastest Web applications (and inadvertently introduced the JavaScript world to “callback hell,” where the language's asynchronous operations forced coders to pass functions as nested callbacks, resulting in ungainly and unintuitive messes of code). Dahl later went on to refine his ideas of asynchronous JavaScript with a second-generation JavaScript runtime called Deno.

Celld does away with the Cloudflare backend, and instead uses the Amazon Simple Storage Service (S3) or equivalent as the storage engine. It also uses the Tokio Rust asynchronous runtime. As with Durable Objects, each celld object gets its own copy of SQLite.

Dahl promises this open source backend will be “orders of magnitude cheaper at scale” than Durable Objects.

Dahl estimated that 100 resident Durable Object cells cost $415 a month on Cloudflare, whereas the celld implementation would run only about $49 a month, built on a DigitalOcean S3-compatible bucket on an 8 GB droplet. Further savings should ensue as the workload scales, he argued.

Cloudflare disputed Dahl’s numbers, stipulating that $415 a month would be the cost if all the objects were continuously active. If left to slumber, the Durable Objects would cost only $20.65 to house on Cloudflare, a spokesperson told The Register.

Whatever its putative thriftiness, the model itself seems to have gained interest on its own merits. “So happy to see support for running durable objects outside of one provider. Upvoted,” one Hacker News reader enthused, noting the concept of a durable object is a valuable abstraction.

Indeed, other parties are cooking their own schemes to move the data closer to the computation. For instance, Postgres service provider Neon just introduced its own Neon Functions, which can also co-locate data and compute for long-running workloads.

Written in Rust and JavaScript, celld is available under an Apache 2 license. It can ingest JavaScript and TypeScript code. In theory, Rust, C/C++, Go, or Zig code can also be executed through the magic of WebAssembly, which V8 supports with slight modification.

But while celld is open source, AI contributions are verboten. “Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves,” the GitHub page notes. Human contributions are still welcome, though you should understand what your code does before you submit it.

There is a moment every release engineer knows well.

The CI/CD pipeline turns green. The deployment job reports success. Everyone exhales for a second and thinks, “Okay, the release is done.” But in Kubernetes, that is not always true.

A green pipeline usually means the deployment step completed. The job finished, Helm ran successfully, and the new version was handed over to Kubernetes. That is important, but it only answers one question: was the release sent?

It does not fully answer the more important reliability question: is the application actually healthy now?

On the team I work on, we manage Kubernetes workloads in a large payments environment. Like many SRE teams, we were dealing with the gap between “the deployment ran” and “the application is actually ready to serve traffic.” That gap created release anxiety, extra manual work, and inconsistent validation.

This is the story of how we closed that gap by turning manual Kubernetes release checks into lightweight CI/CD automation — and reduced validation time from around 45 minutes to about 2 minutes.

The time savings were nice. But the bigger win was consistency, confidence, and less operational toil.

Deployment Completion Is Not the Same as Application Health

Deployment completion and application health are two different signals.

Deployment completion is a delivery signal. It tells us the release went out.

Application health is a runtime signal. It tells us whether the service is working after the release.

That difference matters a lot in Kubernetes.

After a release, there are still important questions to answer. Did the workloads scale back up correctly? Did the pods start? Did they become Ready? Is anything stuck in Pending? Is anything failing with CrashLoopBackOff? Is there an image pull issue? Can the application actually serve users?

A green deployment step does not always answer those questions.

A deployment can complete while one pod fails its readiness probe. Another pod may start and then crash. Another may not pull the image because of a bad tag or registry issue. From the pipeline’s point of view, the deployment may look complete. From the user’s point of view, the service may still be degraded.

That was the reliability gap we wanted to close.

We did not want the release process to assume health. We wanted it to verify health before calling the release successful.

The Old Way: Release Validation by Hand

Before automation, the release validation process was manual.

For each release, an engineer had to log in to Kubernetes clusters, go namespace by namespace, scale deployments down, check pod status, deploy the new version, scale deployments back up, check pod status again, and review logs when something looked wrong.

None of those steps are difficult by themselves.

Checking pod status is simple. Reading logs is simple. Scaling a deployment is simple.

The problem was repetition.

In our environment, a larger release could span multiple clusters, each with several namespaces and many deployments — which quickly adds up to hundreds of workload checks across the release.

For a small release, the manual process was manageable. For a larger production release, validation could take around 45 minutes.

From an SRE perspective, this is classic toil. It is manual, repetitive, necessary, and it does not scale well as the number of services grows.

The slower process was only part of the problem. The bigger issue was inconsistency.

When engineers repeat the same checks under release pressure, things can get missed. A namespace may be skipped. A pod may be Running but not Ready. A release window may be tight, and the checks may be rushed.

That meant release confidence depended too much on the person doing the validation. We wanted release confidence to come from the process itself.

So we asked a simple question:

Could we take the same release checks engineers already trusted and let the pipeline run them automatically?

What We Built — and What We Deliberately Avoided

We did not build a heavy new platform.

We did not build a Kubernetes Operator.

We did not replace the deployment system.

We already had a CI/CD pipeline and an internal deployment platform that could perform Helm operations and read pod status for the namespaces our team managed. So we reused what already existed.

That was an important design choice.

The goal was not to make the architecture more complex. The goal was to remove repetitive manual work and make validation consistent.

The pipeline now performs the release flow automatically:

• It scales down the target workloads.
• It checks pod status to confirm the workloads are coming down.
• It deploys the new version.
• It scales the workloads back up.
• It checks pod health across the required namespaces.

If everything becomes healthy, the release passes.

If something is not healthy, the pipeline reports the failing pod and the reason.

If the release never reaches a healthy state, rollback can be triggered.

At a high level, each validation stage calls an internal deployment API with the target cluster, namespace, release name, and operation. The internal platform performs the Kubernetes or Helm operation and returns the current status to the pipeline.

The pipeline then uses that response to decide what to do next: continue, wait, pass, fail, or roll back.

Conceptually, this is a small release control loop.

• Observe the current state.
• Evaluate health.
• Continue if healthy.
• Wait if still progressing.
• Fail and roll back if unhealthy.

The implementation was not the most complicated part. The real value came from automating the right checks at the right time in the release process.

Why Ready Matters More Than Running

One of the most important checks is pod readiness.

In Kubernetes, Running and Ready are not the same thing.

Running means the container process has started.

Ready means Kubernetes considers the pod safe to receive traffic.

That distinction matters during releases.

Imagine a deployment with five replicas. After the release, all five pods may show as Running. If we stop there, we may assume the application is healthy.

But maybe only three pods are actually Ready. The other two may still be starting, waiting for a dependency, loading configuration, or failing a readiness probe.

In that situation, the application is not fully healthy yet.

That is why the automation checks readiness, not just whether the pod is running.

The failure reason also matters.

If a pod is stuck in Pending, that may point to a scheduling or resource issue.

If it is in CrashLoopBackOff, that usually points to an application startup problem, missing configuration, missing secrets, or a dependency issue.

If it is in ImagePullBackOff, that points to an image tag, registry, or authentication problem.

Each reason sends the engineer in a different troubleshooting direction.

That is why the pipeline does not just say “unhealthy.” It reports which pod is failing and why. That saves time because engineers do not have to start from zero during a failed release.

The 60-Second Stability Window

One design choice that made a big difference was the 60-second stability window.

At first, it may seem enough to mark the release successful as soon as all pods become Ready.

But in real releases, that can create false confidence.

A pod can become Ready for a few seconds and then fail again. Maybe the application starts successfully, passes the readiness check, and then crashes. Maybe a dependency issue appears only after the service begins handling traffic.

If the pipeline passes the release at the first green moment, the release may look successful even though the application becomes unhealthy shortly after.

That is why we added a stability window.

Once all pods become Ready, the automation keeps watching for 60 more seconds. If all pods stay healthy for the full window, the release passes. If any pod becomes unhealthy during that time, the timer resets.

This changes what PASS means.

It no longer means, “The app looked healthy for one moment.” It means, “The app became healthy and stayed healthy long enough for us to trust the release.” That is a much stronger signal.

What Changed After Automation

The most obvious result was speed.

For larger releases, validation went from around 45 minutes to about 2 minutes.

But speed was not the only win.

The bigger win was consistency.

Every release now follows the same validation path. The pipeline does not forget a namespace. It does not skip a pod check. It does not rush because the release window is tight.

Problems also surface earlier.

Instead of waiting for an engineer to manually find an unhealthy pod, the pipeline reports the failing pod and reason directly. That makes investigation faster and handoffs easier.

The team also gained more confidence in the release process.

Before automation, a green pipeline still required manual confirmation. After automation, the pipeline itself became a stronger release gate because it checked runtime health, not just deployment completion.

That is an important shift for SRE teams.

The goal is not only to deploy faster. The goal is to know, with more confidence, that the application is healthy after the deployment.

Lessons Learned

The biggest lesson is simple:

A release is not done when the pipeline turns green. A release is done when the application is healthy and stable.

For us, the best solution was not a large platform or a complex Kubernetes Operator. It was lightweight automation inside the CI/CD pipeline.

We started with the checks engineers were already doing manually. Then we automated them. We checked pod readiness, failure reasons, and stability over time. We kept the output clear enough that any engineer could understand what happened.

That made the release process faster, but more importantly, it made it more reliable.

For teams dealing with similar Kubernetes release pain, the starting point does not have to be complicated. Look at the manual checks your engineers already trust. Identify which ones are repeated across clusters, namespaces, and deployments. Turn those checks into pipeline stages. Require health to stay stable before calling the release successful.

That is when “green pipeline” starts to mean what everyone hoped it meant in the first place: not just that the release was sent, but that the application is healthy enough to trust.

OpenViking: The Context Database for AI Agents

OpenViking is an open-source context database for AI agents. It stores memories, resources, and skills as one virtual filesystem under the viking:// protocol, so an agent browses its own context with ls, tree, and find instead of querying a black-box vector store. Content is processed into three tiers — L0 abstract, L1 overview, L2 details — and loaded on demand. Every retrieval leaves a trajectory you can watch and debug.

Why OpenViking

• One filesystem for all context. Memories, resources, and skills each get a viking:// URI. Agents locate and manipulate context deterministically, like a developer working with files.
• Tiered loading cuts token spend. Every entry is processed into L0 (abstract), L1 (overview), and L2 (details) on write, then loaded only as deep as the task requires.
• Directory recursive retrieval. Vector search first locates the highest-scoring directory, then drills down layer by layer, so results arrive with their surrounding context intact.
• Observable retrieval. Each query preserves its directory-browsing trajectory. When a result looks wrong, you can see exactly which path produced it.
• Sessions become memory. After a session commits, OpenViking asynchronously extracts user preferences and agent experience into long-term memory.

viking://
├── resources/              # Resources: project docs, repos, web pages, etc.
│   └── my_project/
│       ├── docs/
│       │   ├── api/
│       │   └── tutorials/
│       └── src/
└── user/
    └── {user_id}/
        ├── memories/
        │   └── preferences/
        │       ├── writing_style
        │       └── coding_habits
        ├── resources/
        │   └── private_project/
        ├── skills/
        │   ├── search_code
        │   └── analyze_data
        └── peers/
            └── web-visitor-alice/

The three loading tiers:

• L0 (Abstract): a one-sentence summary for quick relevance checks.
• L1 (Overview): core information and usage scenarios for planning.
• L2 (Details): the full original data, read only when needed.

Proof it works

OpenViking 0.3.22 has been evaluated on long-conversation user memory (LoCoMo) and multi-turn agent tasks (tau2-bench).

• User memory (LoCoMo): with OpenViking, all three agent integrations land at 80–83% accuracy — up from 24–57% on their native memory — while input tokens drop by 34.3–91.0% and query latency by 58.45–66.10%.
• Agent experience (tau2-bench): experience memory lifts task success by +6.87pp (retail) and +11.87pp (airline) over the same LLM without memory.

Quick start

Requires Python 3.10 or higher.

pip install openviking --upgrade
openviking-server init      # interactive wizard: providers, models, ov.conf
openviking-server doctor    # validate setup
openviking-server           # start

OpenViking Helper (Beta)

OpenViking Helper is a desktop console, currently in beta for macOS and Windows x64:

• Visual local agent setup: detects OpenViking CLI, Claude Code, Codex, Cursor, Trae, and OpenCode, then configures supported plugin, MCP, Hook, and CLI integrations.
• Session trace inspection: parses Claude Code, Codex, and Trae sessions to show OpenViking recall, prompt injection, MCP calls, capture, and commit events.
• Local memory and skill management: views local memory / rule files and SKILL.md skills, then syncs them to OpenViking.

VikingBot

VikingBot is an AI agent framework built on top of OpenViking:

pip install "openviking[bot]"
openviking-server --with-bot
ov chat

Commercial editions

The open-source edition is fully open source under AGPLv3: no feature gates, no account required, no activation key.

☁️ Managed SaaS

Officially hosted on Volcano Engine. Nothing to set up, nothing to operate.

• Personal — for individual developers.
• Enterprise — multi-user context management, team collaboration and permissions, enterprise SLA and support.

🏢 Self-Managed

Runs inside your own environment. Data never leaves it.

• Online — deployed into your own cloud account / VPC, BYOC supported, with outbound access for updates and licensing.
• Offline — fully air-gapped environments with no internet access, for regulated industries.

Research

OpenViking open-sources a subset of the core capabilities described in the VikingMem paper:

VikingMem: A Memory Base Management System for Stateful LLM-based Applications Jiajie Fu, Junwen Chen, Mengzhao Wang, Aoxiang He, Maojia Sheng, Xiangyu Ke, Yifan Zhu, and Yunjun Gao. arXiv:2605.29640, 2026. Accepted by VLDB 2026.

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.

Linux kernel 7.2 has been released, adding cache-aware scheduling, ext4 filesystem performance boosts and a slew of new and improved hardware drivers for laptops and peripherals.

A merge widow record was also set during the 9-week development cycle, with more than 2,100 individual contributors involved. AI, obviously, has helped. Commit-crunching by LWN found roughly 5% of commits in 7.2 have an ‘assisted-by’ tag, indicating AI usage.

Not that the latest kernel update was all additions.

More than 13,000 lines of code for legacy i486 CPU emulation were removed from Linux 7.2, as was a 40-year-old Hercules graphics card driver, AppleTalk networking protocol and ISA and PCMCIA ARCnet drivers.

None of that is stuff people will miss on the daily, and those who do can boot Linux 7.1 or lower.

Finally, a key feature expected to arrive in Linux 7.2 – a fair(er) GPU scheduler – didn’t. A last-minute revert switched back to the first-in-first-out (FIFO) method due to reports of performance regressions on certain AMD graphics cards.

For a closer look at more of what’s new in Linux 7.2, read on!

Linux 7.2: key changes

Cache-aware scheduling

Linux 7.2 makes its task scheduler (which decides what tasks run and when) cache-aware. This means it can recognise when threads (parts of a task) belong to the same process and keep them on cores that share a cache.

Scheduler is now smarter, keeping process threads on a core with a shared cache

Previously the scheduler balanced load across all your CPU’s cores without checking whether threads on separate cores shared memory.

Threads on different cores would need to re-fetch or sync the same data, an occurrence known as ‘cache bouncing’ – which this now limits.

Guardrails are in place to prevent a process from overloading a cache ‘domain’ (so one app’s tasks can’t choke the system). The scheduler also won’t move more threads if a process is already using >25% CPU time, or >33% of the load in a domain.

AMD and Intel CPUs with ‘multiple cache domains’ benefit the most from this, though by how much will depend on the processor and the workload involved.

Pipes get a locking fix

A locking fix for pipes (yes, pipes as in |, oft-used in shell commands and behind-the-scenes tasks) reduces how long they can hold a lock – preventing simultaneous access – during a write.

Now, this might sound a tad “and?”, but the improvements it results in are rather “Ooh”. Per the commits cover, this nets performance jumps of up 6-28% and reduces write latency 5-22% (rising under memory pressure) in specific situations.

As with most optimisations in most Linux kernel updates, the benefits of this aren’t blanket, so a regular day-to-date workflow won’t notice or benefit from this in any obvious sense. But whenever a pipe mechanism is in play, this will be there, keeping it efficient.

Memory reclaim made tighter

Linux 7.2 fines the Multi-Generational LRU (MGLRU), an algorithm used by the kernel to decide what gets removed from memory, when memory runs low, and how it’s reclaimed.

By clearing and tightening the ‘reclaim’ loop, as well as how ‘dirty pages’ are written back during the process, which benefits specific kinds of workloads. The cover commit touts an “up to ~30% increase” in MongoDB with YCSB, and reduces unexpected out-of-memory (OOM) kills.

Ext4 filesystem changes

Ext4, Ubuntu’s default filesystem, gets some minor speed-focused improvements in Linux 7.2.

ext4 nixes lock contention and deadlocks under heavy usage

A change to the ext4 filesystem’s fast commit feature, which, as its name suggests, writes journal entries quicker than it would with a full commit, removes lock contention and deadlocks under heavy usage.

Stats for that are also now viewable at /proc/fs/ext4/*/fc_info (we’ll be coming back to proc elsewhere in this roundup).

Another fix, one shared with XFS as well, nixes a memory-cleaning step from the kernel’s IOMAP layer, netting a 5% boost in small, random 4K reads from NVMe drives with io_uring‘s polling mode.

Finally, a directory lookup change now handles data in 4-byte chunks, which is said to make finding files in dense folders faster.

Other filesystem improvements

NTFS handling in Linux 7.2 is bolstered with Windows symbolic link support – the proper kind, not just WSL-esque ones. A bug with these links appearing as zero-byte files was also fixed. Separately, NTFS was ‘hardened’ against on-disk metadata corruption.

exFAT, the format you probably use on SD cards and USB drives, sees improved read and write speeds by adopting the kernel’s iomap. Benchmarks in the commit report write speeds increased by as much as 87% under heavy load following this change.

Elsewhere, and avid kernel watchers, Btrfs is where the headline changes often sit.

The filesystem sees further speedups in Linux 7.2, now that large folios are enabled by default – a feature that’s been experimental since Linux 6.17. The filesystem can now handle memory in bigger chunks, cutting overhead and thus improving seed.

Also aiding performance: direct I/O is no longer made to run ‘serially’ (in turn), which reportedly boosts write performance by up to 59%. Sequential writes also jump by 15% due to new limits on how large a single writeback request can get.

USB4 cable direct data transfers

Linux 7.2 supports USB4STREAM, a new protocol for sending data between two devices using a USB4 or Thunderbolt cable (and it can be used alongside existing Thunderbolt networking).

A new driver creates device files named /dev/tbstreamX on each computer. Data can be sent along a compatible cable to a compatible port via tools like cat, echo and dd, without a network connection.

Faster proc file reading

/proc, the virtual filesystem the kernel uses to share system state as files, saw two of the said files become more efficient: /proc/filesystems lists filesystem support; /proc/interrupts details hardware interrupts.

The former rewrites how /proc/filesystems files are generated, opting to pre-build rather than construct on the fly, on each read. Testing shows up to 140% faster reads, and up to 444% if 20 processes read the file at the same time.

Your day-to-day system usage won’t benefit, but any tools and scripts which probe system status (and often) will be appreciably nippier as a result.

Improved laptop drivers

Various laptops pick up improvements in their respective vendor drivers.

The Uniwill laptop driver, used by TUXEDO Computers, adds support for battery charging modes; the Microsoft Surface platform driver gains Surface Pro 12-inch support, and more Lenovo Legion devices can use battery charging limits via the wmi driver.

The AMD ISP4 webcam on the HP ZBook Ultra G1a is supported in Linux 7.2, as are a swathe of pen-enabled Wacom W9000-series touchscreens, typically found in 2-in-1 convertible devices that come bundled with stylus/digitisers.

Audio-wise, the internal microphone array on the HyperX OMEN Gaming Laptop 16-ap1xxx (using AMD Ryzen 7 or 9 CPUs) now works too, while audio quirks on the Lenovo Yoga 7 (16IAP7) and the Legion 7i (16IAX7) have been resolved.

Microsoft’s OG Surface RT tablet (model 1516) reports battery capacity and charging info when running the Linux 7.2 kernel. That might amuse any of you reading who has one of these early ARM-based devices from 2010 gathering dust in a drawer.

Linux 7.2 can now boot Apple M3 MacBook Pros, Airs and iMacs – albeit only to a console. While far from ‘daily driver’ ready the way Apple M1 and M2 devices are, it’s encouraging to see new fruits from the Asahi Linux effort.

Expanded peripheral drivers

Linux gamers will find the side buttons on the Rakk Dasig X gaming mouse now function, having been ignored because of a faulty HID report descriptor, while PlayStation DualSense Edge controller’s rear buttons finally see support too.

OneXPlayer configuration driver was mainlined, courtesy of Valve, and the third-party HORI Wireless Switch Pad for the Nintendo Switch works out of the box.

This kernel version supports the Realtek RTL8159 ASIC found in many 10 Gbps USB network adapters, as well as more USB wireless adapters, including Mercusys MA60XNB and NETGEAR NightHawk A8500 WiFi 7, which should work out of the box.

New drivers for the Realtek 8922AU and 8922AE (including Bluetooth) are on board, and Linux 7.2 supports the Mediatek MT7927 (Filogic 380), often found in motherboards, for full WiFi 7 (2+ Gbps on 6 GHz) and Bluetooth 5.4 connectivity.

And there’s more temperature and fan speed tracking on a range of ASUS and ASRock desktop motherboards, including the ASRock Z890 Pro-A, and there’s a new driver for the ARCTIC Fan Controller.

Other changes

Linux 7.2 continues to add support for Intel and AMD CPUs and GPUs that aren’t available to buy yet. I prefer to highlight changes affecting hardware people do own and use. Plus, kernel support for major CPUs usually lands before the hardware is available to the masses.

As well as the highlights above, other notable changes in Linux 7.2 include:

• khugepaged can merge memory into multiple huge page sizes
• Landlock can restrict UDP bind, connect and send
• New openat2() flag lets programs refuse to open device files
• NFS, ksmbd servers can report case-insensitive filesystems
• AF_ALG, involved in recent security issues, is deprecated
• strncpy() was removed from the kernel
• Initial support for AMDGPU HDMI 2.1 FRL
• PCIe 2.5 GT/s link-speed fix
• AMD Zen 6 EPYC support
• Intel TDX can update runtime module without a reboot
• Continued work to support WiFi 8
• Phase IV of swap table improvements
• Preparatory support for sub-schedulers in sched_ext
• Improved write performance with RWF_DONTCACHE

For more detail on the release as whole, read through LWN’s merge report recaps (first half and second half) – keep in mind those were compiled prior to the stable release so will mention the fair(er) DRM scheduler, despite it being reverted last-minute.

Dedicated kernel hounds can opt to sift through the entire Linux 7.2 commit history on GitHub.

Will Ubuntu 26.10 use Linux 7.2?

Canonical has said Linux 7.2 is the kernel version targeted for Ubuntu 26.10.

But, under Ubuntu’s new kernel selection policy, in which it aims to ship the “absolute latest upstream version” in development by Ubuntu’s kernel freeze deadline, even if in RC status, Linux 7.3 could still be a viable candidate.

Why?

The working assumption was that Linux 7.2 would be released after the stonking kernel freeze deadline of 20 August, when it has arrived before it. That means the merge window for 7.3 has opened; thus it is now “the latest” version in development.

Canonical’s kernel engineers will, no doubt, provide clarification on which kernel Ubuntu 26.10 will use, shortly.

Of course, whether Linux 7.2 or 7.3 is selected for the next release, you can expect a kernel backport to Ubuntu 26.04 in early 2027 via the Hardware Enablement stack (HWE) update/26.04.2 LTS point release.

Download Linux 7.2

The Linux 7.2 kernel source code is available for download from kernel.org, if you want to compile it by hand (which, chances are, you don’t).

For Ubuntu users, this kernel version will not come as an official software update (unless part of a future HWE). However, you can install a Canonical Mainline .deb or use a third-party PPA or repo to get it unofficially, sooner.

Keep in mind that installing a Linux kernel on Ubuntu that comes from outside of the official repos is not recommended: no guarantees, no support, missing Ubuntu-specific patches or drivers, and hardware or security features that may not work.

A hidden demo video in the macOS Tahoe 26.7 release candidate provides the strongest evidence yet that Apple is developing AirPods with built-in cameras. The feature appears to work with Visual Intelligence and Siri, allowing users to identify, ask about, and save information from objects in their surroundings, while also warning them if the camera's view is obstructed. The product, reportedly codenamed B790, has been linked to earlier reports suggesting a possible launch as soon as September alongside Apple's next generation of iPhones.

While the industry debates whether AI will replace designers, a quieter–and arguably more consequential–shift is already underway in UX/UI design.

We spoke with Kateryna Orlova, a UX/UI designer at the Irish SaaS company OnePageCRM and author of academic research on the impact of design on productivity and user behavior, about why the growing accessibility of generative tools is changing what a designer’s work is actually worth.

When Figma unveiled Make Designs at its Config conference in June 2024–a feature that turns a text prompt into a finished UI mockup in seconds–the industry zeroed in on one question: would AI put designers out of work?

Within days, the conversation took an unexpected turn. Designer Andy Allen discovered that Make Designs was producing layouts strikingly similar to Apple’s Weather app, setting off alarm bells across the industry. As questions mounted over how the tool was arriving at those results, Figma CEO Dylan Field announced that Make Designs would be temporarily disabled. It returned in September under a new name, First Draft, with an option for “less templated” layouts. By year’s end, the Make Designs episode had faded from the headlines–but the question it raised hadn’t gone away.

According to UX/UI designer Kateryna Orlova, though, the industry was focusing on the wrong thing.

“I think the more important question is different: what happens to the market if thousands of companies start generating interfaces from the same pool of components at the same time? We’d end up with products that have different names but look alike, offer similar user flows, and repeat the same limitations. It becomes harder for users to tell them apart, and instead of competing on product quality, businesses end up competing on price, ad spend, and brand recognition. Meanwhile, the specific problems of a given audience can go unaddressed, because AI defaults to the most common solution–not the one that actually fits the context of that particular product,” she says.

In a Figma study of nearly 1,800 designers and developers, 89% of respondents expected AI to shape their company’s products and services within the next year. Yet only about a third of those already using AI in production reported measurable gains in revenue, cost, or market share.

That gap, Orlova argues, is the key to understanding what’s really happening to design at the turn of 2024–2025.

AI Sees the Data. Does It See the User?

AI only knows the context a team hands it. It can process a thousand user reviews faster than any human, but it can’t tell a team what data they never collected. It doesn’t know why real users abandon an app on step two if nobody has studied the problem in the first place.

That, Orlova says, is exactly where a UX designer’s value becomes clear. The most valuable insights tend to surface not from what users say, but from the gap between what they say and how they actually behave inside a product.

“A user might tell you in testing that a feature is intuitive, then fumble through it three times trying to complete the task. That gap between what people say and what they do is usually where the real problem lives. It’s especially visible in enterprise software like OnePageCRM: people come back to the product every single day, and good design there isn’t the kind that makes a strong first impression–it’s the kind that, six months into daily use, doesn’t force people into extra steps or trip them up on routine tasks. You can’t get that context from a well-crafted prompt. Observation, testing, and reading behavior correctly are still what matters most. That’s one of the core competencies of a UX designer today,” she explains.

The New Problem Facing Junior Designers

One particularly interesting question centers on people just starting out in the field.

Junior designers used to build skill by grinding through small problems over and over: sketching options, getting things wrong, taking feedback, revising, and gradually learning to spot patterns.

Now AI can handle a chunk of that work.

On one hand, that lets newcomers move faster. On the other, it risks skipping the very stage where professional judgment actually forms.

“When a tool hands you a convincing answer right away, it’s easy to mistake the quality of the output for the quality of your own decision-making. A junior designer might pick the right option without understanding why it’s right–or when that same pattern would stop working,” Orlova says.

As a result, she believes design education needs to shift away from teaching tool proficiency and toward building the ability to form hypotheses, work with user data, run research, and argue for a decision.

“The question used to be: can you do this? Increasingly, the question will be: do you understand why it needs to be done this way?”

What Businesses Should Do Right Now

Orlova offers three guideposts for product teams.

First: don’t mistake speed of production for product quality.

“AI can genuinely cut down the time it takes to produce first concepts, interface variations, and working drafts. But if the user problem was misdiagnosed to begin with, faster design just means arriving at the wrong solution faster,” Orlova says.

Second: use AI where it actually delivers an edge–exploring options, structuring information, drafting first-pass concepts, and automating repetitive work.

“AI is genuinely good at expanding the range of options on the table. It can show a designer directions in minutes that would otherwise take hours to explore manually. But the final call shouldn’t be made because an option looks convincing–it should be made because the team understands exactly what user and business problem it solves,” she says.

Third: invest in data about your own users.

This, Orlova believes, is where one of the biggest competitive advantages for product companies will live.

A competitor can use the same AI model. Buy the same tools. See the same publicly available patterns.

But they don’t have the history of how a specific product interacts with its users: research findings, observations, reasons for abandonment, accumulated analytics, and an understanding of real workflows.

“If two competitors are running the exact same AI, the advantage doesn’t go to whoever wrote the faster prompt. It goes to whoever understands, more deeply, who they’re designing for and why,” Orlova explains.

This, in Orlova’s view, is where the future of the profession is being decided. As building interfaces gets faster and more accessible, a designer’s value will depend less on mastering a particular tool and more on the ability to ask the right questions, understand human behavior, and make product decisions in situations where there’s no ready-made answer yet.

“A few years from now, we may spend a lot less time talking about who’s best at drawing interfaces. The skill that matters will be different–the ability to understand the problem before you start designing the solution. In that sense, AI isn’t eliminating the UX/UI design profession. It’s raising the bar for what counts as that profession in the first place,” Orlova says.

Accessibility getting dropped in the process

This newsletter is a bit different than previous ones. Rather than my usual collection of shorter articles and updates, it’s devoted to one longer piece. The question behind it kept growing the more I thought about it, and it deserved more space than my usual format allows.

Let's dive in.

When accessible designs become inaccessible products

It started with a question

Every now and then, I find myself reviewing a design before development begins. Sometimes the conversation ends with a reassuring conclusion: yes, this can be implemented accessibly.

It's worth paying attention to the wording. Not "this is accessible." Not "this will be accessible." "This can be implemented accessibly."

The teams feel it a satisfying answer at the time. The design doesn't prevent accessibility. The interaction pattern can work. Everyone leaves the meeting with the same understanding: the concept is sound, and the rest is a matter of building it well.

Then development happens.

Weeks or months later, I audit the finished feature, and the result is often surprising. Informative images have no alternative text. A modal doesn't keep keyboard focus. Dynamic updates aren't announced to screen readers. Parts of the interface can't be reached from the keyboard.

None of those problems were inevitable. They weren't built into the design. Somewhere between approving the concept and shipping the feature, accessibility slipped away.

It's easy to explain this away by saying developers don't care about accessibility. I don't think that's true. It's just as easy to say they need more training. Sometimes that's true, but it doesn't explain what happened here.

The developers on this project had worked on accessible products before. They weren't starting from zero.

So what happened?

The more I thought about it, the less interested I became in the individual bugs. Missing alt text, broken focus management, and missing announcements were symptoms. The real question was how a team could start with a design that could be implemented accessibly and still end up with a product that wasn't.

An accessible design is only the beginning

Design reviews and accessibility audits answer different questions.

A design review asks whether an idea can be implemented accessibly. It's about possibility. A good review identifies patterns that can work well for disabled users and flags ideas that can't.

What it usually doesn't do is document every implementation detail needed to achieve that outcome. Many of those decisions belong in development. Exactly how keyboard focus is managed, which changes are announced to assistive technologies, or how a custom component exposes its semantics are implementation details. Someone still has to make those decisions, document them, and verify that they happened.

That's why a design review can honestly conclude that a feature can be implemented accessibly while saying nothing about whether it eventually will be.

Knowing about accessibility isn't the same as building accessibly

It's tempting to assume that once developers have been exposed to accessibility, they'll apply that knowledge every time they build a feature. Software development doesn't work that way.

Developers juggle business logic, APIs, state management, performance, testing, bug fixes, and deadlines. Unless accessibility becomes part of everyday engineering practice, it competes for attention with everything else. That's true of almost every aspect of software quality. Knowledge alone rarely changes outcomes. Feedback loops and shared expectations do.

Typing isn't the same as navigating

I've occasionally heard people argue that developers should naturally understand keyboard accessibility because they spend all day using a keyboard.

Writing code with a keyboard and navigating an interface without a mouse are different skills. You don't learn about tab order because you know your editor's shortcuts. You don't discover focus management because you use Vim or VS Code efficiently. You don't understand when a screen reader needs a live region simply because your hands never leave the keys.

Several developers on this project would describe themselves as power keyboard users. That didn't translate into building keyboard-friendly interfaces, and it was never going to on its own. Recognizing that doesn't excuse the outcome. It explains why "just use the keyboard" was never going to teach anyone what disabled users actually experience.

Accessibility disappears during the handoffs

I don't believe anyone consciously decided to ignore accessibility on this project. It disappeared during the transitions between stages.

• The design team owned the design.
• Developers owned writing the code.
• QA owned testing the feature.
• Accessibility owned the audit.

Each stage had an owner. What didn't have an owner was carrying accessibility from one stage to the next.

The design established that the feature could be accessible. Development focused on building it. QA verified that it worked. Accessibility didn't see the feature again until the final audit.

The implementation details that mattered to disabled users weren't deliberately removed. They simply weren't carried forward. Or even just implemented. That's what made this a workflow problem rather than a people problem.

The audit wasn't too strict. It came too late.

The timing of the audit turned out to matter as much as anything it found.

The team has no early warning system when the first accessibility checkpoint after design is a comprehensive audit near the end of development.

Imagine finding your first performance problems the week before release, or running your first security review after all the code is already written. Most teams wouldn't accept that because fixing problems gets more expensive the longer they survive.

Accessibility deserves the same treatment.

When the first meaningful review happens at the end of a project, the audit isn't creating work. It's revealing weeks or months of implementation decisions that nobody checked along the way.

People pay attention to what gets reviewed

Developers focus on what generates feedback. Code review comments on architecture, naming, performance, and test coverage. QA verifies behaviour. Automated tests run on every build.

Those checkpoints teach a team what quality means, whether anyone intends that lesson or not.

If accessibility only shows up as a report after development is finished, it naturally becomes something people think about after development is finished. Not because they stopped caring, but because the workflow never asked them to think about it sooner.

So what would I change?

I'm not interested in finding someone to blame for this. I'm interested in where the workflow could have caught these problems earlier.

During design

When a design is approved as "can be implemented accessibly," the accessibility requirements should be written down alongside the visual specification. Focus order, keyboard behaviour, announcements, semantics, and state changes shouldn't live in someone's memory or meeting notes. They should become part of the design itself.

From there, those details become acceptance criteria. Vague intentions get lost. Specific, testable criteria become part of the same definition of done as everything else the team already checks.

During development

Someone needs to own the transition from design to implementation. "This can be implemented accessibly" should never be the last accessibility sentence spoken about a feature. Someone should be responsible for confirming that the implementation still matches the intent.

Teams also shouldn't be solving the same accessibility problems over and over. A shared library of accessible components means developers spend less time reinventing focus management, disclosure widgets, and other complex patterns, and more time building features.

Automated accessibility checks belong in the build pipeline as well. They won't catch everything, but they'll consistently catch many common issues before anyone reaches the final audit.

During validation

Accessibility needs another checkpoint before launch.

It doesn't have to be a full audit. A focused review while a feature is still under active development can catch missing keyboard support, broken announcements, or implementation mistakes while they're still inexpensive to fix.

Accessibility should also be visible in the reviews that already happen. Code review, feature review, and QA don't need entirely new ceremonies. They need accessibility to become part of the conversations they're already having.

None of this depends on finding who missed it at the end. It depends on giving accessibility an owner at every handoff, not just the last one.

Wrapping up

That's it for now! I hope you enjoyed the newsletter. I'd love to get feedback - What was good? What could be improved? What topic would you like me to talk about? I'm not making any promise, but if a topic you suggest catches my fancy, I'll share my opinion on it. Just hit reply to this email.

Full article content is not available for inline reading.

Read the original article →

AI Video Agent: From Script to Screen

Chat to create scripts, storyboards, assets, and videos.

Strong Engine behind

We have inherited the latest and most powerful image and video models in the world

Your AI Crew

Agents that research, script, edit, and revise alongside you. Focus on the vision—they'll handle the rest.

Create Together

One workspace, whole team. Edit simultaneously, comment inline, ship faster.

Build Video Series

Create episodic content with consistent characters, styles, and storylines. From pilots to full seasons.

Built for Every Creator

From YouTube content to enterprise training, Pixo adapts to your creative needs.

YouTube Content

Create engaging YouTube videos with AI-powered scripts, visuals, and editing. Perfect for content creators looking to scale their production.

Marketing & Ads

Produce high-converting ad creatives and marketing videos in minutes. A/B test multiple variations without the production overhead.

Music Videos

Bring your music to life with stunning visuals. Generate synchronized video content that matches your audio perfectly.

Product Showcases

Create professional product demos and showcases. Highlight features with dynamic animations and clear narratives.

Educational Content

Build compelling educational videos and training materials. Visualize complex concepts with AI-generated animations.

Podcasts

Turn your podcast episodes into stunning video content. Perfect for repurposing audio into engaging visual stories.

Frequently Asked Questions

Everything you need to know about our process and how we work.

Ready to Revolutionize your workflow?

Join thousands of creators using Pixo to turn their stories into visual reality.

The API for GPM-5.3 is now available. Z.ai plans to make the model's weights openly available, but it has yet to set a release date. API pricing remains unchanged from GLM-5.2, so developers gain substantially stronger coding and long-horizon agent performance without paying more.

OpenAI temporarily slowed frontier model scaling and paused some reinforcement-learning training after new cybersecurity capability signals and a security incident raised concerns.

Cerebras' new computer, the CS-4, is multiple times faster than its predecessor, which Cerebras already claims is more responsive than systems built with Nvidia's processors. The machine is currently being sampled by a small group of customers. It will be more widely available in the third quarter. The product is a significant step in the company's bid to challenge Nvidia in the market for AI data center hardware.

I want to highlight a couple of pieces which I found to be quite intriguing. The first is Dwarkesh Patel’s conversation with Ryan Greenblatt, chief scientist at Redwood Research. Admittedly, while the conversation about whether automating AI research triggers recursive self-improvement was thought provoking, it was also quite spooky at times.

The second piece that I would like to highlight is a talk by Shuchao Bi, titled “Advancing the Frontier of Silicon Intelligence: Past, Open Problems, and the Future”. Bi co-founded YouTube Shorts at Google, ran multimodal post-training at OpenAI, and now works at Meta Superintelligence Labs.

While Greenblatt’s conversation with Dwarkesh was published last week, Bi gave the presentation more than a year ago. Since I happened to stumble onto both of these during the weekend, I could notice a healthy dose of similarity in Greenblatt’s and Bi’s arguments. Last month, I wrote about the salience of data in the context of AI and Alphabet bidding for bankruptcy auction for Spirit Airline’s data certainly corroborates to that. However, both Greenblatt and Bi made me re-think my position a bit on this topic. Greenblatt had an interesting thought experiment: if you could hold compute or data constant, how much the model would still improve? That delta of improvement could be labeled as “algorithmic progress” and he made the case that it is a very important driver of AI progress over the last few years:

“GPT-3 was released in 2020, so it was trained about six and a half, seven years ago. It’s worth noting that GPT-3 is maybe a little too far in the past, but let’s go with this for a second. If we were to train a model with GPT-3-level compute today, how good would that model be? My understanding, based on how algorithmic progress works, is that we’d be able to train a model that’s as good as the best model we had perhaps around three years ago. So I think that right now we’d be able to train a version of GPT-3 that’s probably somewhat better than GPT-4, a moderate amount better than GPT-4. I think that’s about right. That roughly lines up with how algorithmic progress has worked.”

Bi didn’t quite say “algorithmic progress”, but pointed out that the raw data is “unlikely to be the best data distribution”. He suggested that the incremental improvement in scaling law may come from changing the data distributions or to say it differently, “by equalizing intelligence per token”. My read is that they are essentially alluding to the same argument but using different words to explain their intuitions.

Later in the conversation, Greenblatt expanded why he is not a big believer of the role of “human expert data” in model improvements, rather the process improvement around data itself is the larger driver. From the podcast:

“I think the vast majority of pre-training data improvements are from science on better understanding what data sets are good and schleppy labor on figuring out how to filter down. So my view is that improvements of the form of, like, OpenWebText to FineWeb, that improvement is better described as an algorithmic improvement of the sort that you can study with some GPUs, and you don’t need human expert data to do that. Now, there’s a different effect which we could talk about, which is that maybe the internet in 2026 is more of a fertile ground for training data than the internet in 2018. There’s also been an effect where there are just more humans posting on the internet, so there’s more data to harvest. My sense is that that effect is going to be quite a bit smaller than the effect of humans knowing better how to curate the data, having better scrapes, knowing how to process those scrapes better — this sort of thing.”

Greenblatt’s arguments certainly gave me a pause because my prior was a bit different and likely much closer to Dwarkesh who also appears to think human expert data played a critical role in the model’s recent trajectory.

Bi probably agrees with Greenblatt since he decomposed where human knowledge comes from: a loop of proposing tasks, learning existing knowledge, thinking, getting feedback from the environment, and distilling the findings back into knowledge and wondered aloud in his talk which steps AI can accelerate. His answer is basically nearly all of them, including proposing the tasks in the first place. Greenblatt essentially makes the same claim retrospectively: RL environments improved over the last two years mostly because labs learned what to build and used enormous amounts of AI labor to build it.

Another interesting observation by Greenblatt was that machine learning (ML) is a “shallow” domain compared to math and given that even in math we are transitioning “from an era of proof scarcity to an era of proof abundance”, automating much of ML may prove to be lot more amenable. From Greenblatt:

I think ML is a very shallow domain relative to math. In math, there was much more of a thing where you find some true deep abstraction, and if you really understand that thing, which is hard to understand, then you get somewhere. Whereas I feel like the things that are the equivalent of that in ML are really dumb bullshit. Like with scaling laws, come on guys, we can explain scaling laws really quickly. I think the deepest and most important concepts in math, for example, don’t have the property that you can really understand the underlying thing and why it matters in a very short period of time. My sense is that some domains are structurally different in terms of how they operate and how much they depend on deep abstractions. Physics and math are much more on the side of being very far on the deep, hard-to-come-up-with-ideas side, whereas I think ML and most other domains are much more amenable to hill climbing. That’s my sense of how this will go in the future. Even in cases where there has been some breakthrough in AI, oftentimes in retrospect it looks like a big bottleneck to making that breakthrough happen was getting all of the micro details and mungy intuition right. An example of this is training AIs to be good at reasoning and chain of thought, doing RL on chain of thought. It looks like you probably could have done RL and chain of thought on GPT-3 and gotten kind of interesting results on math if you had really scaled it up and done a good job.

Bi also made the point that learning from environment interaction is efficient wherever a perfect simulator exists (coding, math etc.) and fundamentally blocked where simulation is impossible or the sim-to-real gap is simply too large ( for example biology, and experimental physics). Given that context, automating AI research doesn’t seem nearly as outlandish.

However, the amazing efficiency of homo sapiens is also a stark reminder that nature has already shipped a general intelligence that runs on less power than a dim lightbulb. Today’s models need a building full of GPUs and most of the written internet to often do less. Does that indicate something “special” about us or is it a measure of how inefficient our current approach still is? Bi’s bet is that the biggest waste sits in how models learn. If someone fixes that, the cost of a given level of intelligence can fall by orders of magnitude. Of course, I am not in a position to know or predict whether this is at all fixable or even if it is, when that may happen.

A peer recently praised me to help him improve his understanding of the AI landscape through my work at MBI Deep Dives. I jokingly mentioned to him I’m glad that you feel that way, but ironically the more I study AI landscape, the more certain I become that I need to hold every opinion related to AI very loosely. Such a frame of mind doesn’t inspire a lot of confidence in my own mind that I can see too far ahead. Investors are trying to price AI landscape based on near-term trajectory of respective companies, but given how fast things can alter in the AI landscape, it is hard not to feel that betting for or against this trade carries a monumental risk either way.

• In the past week, Nvidia has announced a pact with Wall Street firms to pursue $500 billion worth of financing for chips, and has agreed to support OpenAI in Ohio to the tune of up to $105 billion.
• While the chipmaker maintains its dominance in the market for AI processors, it's increasingly showing its willingness to take advantage of another great asset: capital.
• Many frontier labs "are growing faster than their balance sheets and long-term credit profiles can support," Nvidia CEO Jensen Huang wrote.

Nvidia's massive head start in artificial intelligence turned the chipmaker into the world's most valuable company. Now, almost four years into the generative AI boom, competitors like Advanced Micro Devices and Google have chipped away at Nvidia's technology lead, pushing the company to take advantage of its other great asset: capital.

Following last week's pact with Wall Street firms to pursue $500 billion worth of financing for Nvidia's graphics processing units, Nvidia said Monday that it's providing up to $105 billion for a giant OpenAI data center in Ohio, offering a backstop of sorts should the ChatGPT creator see its fortunes turn.

For Nvidia, the strategy involves fueling the AI boom by whatever means necessary, recognizing that demand for critical infrastructure is seemingly insatiable but that a handful of companies — the hyperscalers — account for an outsized amount of purchases. With its quarterly free cash flow up 18-fold over the past three years to $48.5 billion in the latest period, Nvidia is using the strength of its balance sheet and credit rating to ensure there's no dramatic slowdown following 12 straight quarters of revenue growth above 55%.

"They remain dominant, but they're very paranoid about making sure they don't lose ground," said Ram Bala, associate professor of AI and analytics at Santa Clara University's Leavey School of Business.

Nvidia declined to comment.

In a note to clients Monday, analysts at Cantor brushed off concerns that Nvidia is effectively buying revenue through its financial maneuvering. They reiterated their buy rating and said the latest agreement is a "clear signal that the current AI investment cycle will be elongated and durable."

"We view this less as circular and more facilitating the coming AI buildout while at the same time creating additional competitive moats that will continue to enable NVDA to remain THE AI leader," the analysts wrote.

Nvidia is swimming in money. Its cash generation is so great that the company said in May that it was increasing its quarterly dividend to 25 cents a share from a penny, and announced a new $80 billion stock buyback plan. The company pledged "to return roughly 50% of free cash flow to shareholders this year."

One way the company has been putting its cash pile to work is through equity investments in companies across the AI ecosystem, including some businesses — like model developers and neoclouds — that spend heavily on Nvidia's chips and systems. Nvidia held $30.2 billion in marketable equity securities as of the most recent quarter, up from $12.9 billion a year earlier.

In February, Nvidia invested $30 billion in OpenAI, which relies on training capacity from Vera Rubin, the chip giant's most advanced system. Monday's agreement included a $1.5 billion investment in SB Energy, a SoftBank affiliate that's building and managing the data center at the PORTS-Pike Technology Campus in Pike County, Ohio, through a 20-year lease to OpenAI.

In addition to the SB Energy investment, Nvidia said it's putting its financial support behind about 4 gigawatts of development at the Ohio site for portions of lease and power and "a specified residual-value commitment," as data centers open between 2028 and 2030.

Expanding access

Nvidia CEO Jensen Huang acknowledged the significance of the company's financial prowess in a post on X about the agreement.

"Frontier AI labs have extraordinary demand for training and inference compute, but many are growing faster than their balance sheets and long-term credit profiles can support," Huang wrote. "They may have strong customer demand and rapidly growing revenue yet still lack the decades-long infrastructure contracts and investment-grade financing capacity needed to secure the AI factory infrastructure independently."

A week prior, Huang was on set at CNBC surrounded by six of Wall Street's leading financiers to announce the arrival of Nvidia graphics processing units as a new asset class. In signing a memorandum of understanding with firms including Goldman Sachs, Apollo Global Management, Blackstone and BlackRock, Huang indicated that the next phase of the AI build-out will be funded in part by third-party backers, who can start investing in GPUs the way they do real estate.

"These are revenue-generating assets now," Huang told CNBC. "They're productive, they're long-lived, they're fungible, they're flexible."

Key to obtaining financing for prospective borrowers will be a dedication to Huang's systems, with Nvidia obtaining the option of backstopping 25% of every loan. It's another way to get more of Nvidia's technology into the market, as competition builds from Google and AMD as well as from specialized chipmakers like Cerebras.

In the second quarter, Google began recognizing revenue from tensor processing unit system sales, contributing to the cloud unit's 82% growth. AMD, meanwhile, reported more than 100% growth in its data center business, and the company expects its first rack-scale system, called Helios, to ship later this year.

Paul Meeks, head of technology research at Freedom Capital Markets, said the stepped-up competition eats into Nvidia's ability to yield "outrageous margins," and incentives the company to diversify its strategy.

"Part of their thinking is let's broaden our reach," Meeks said. "We just can't ride this one horse, which is GPUs."

AI bulls say that Nvidia is just responding to demand, and point out that the shortage in the market today is on the capacity side. There are plenty of numbers to back that up, as Anthropic told investors over the weekend that its annualized revenue run rate hit $65 billion in July, up sevenfold from a year earlier. OpenAI's run rate recently reached $40 billion.

Matthew Vegari, head of research at Clearwater Analytics, said in an email that, based on the market dynamics, the "narrative around the AI trade's circuitous, 'house of cards' structure strikes us as somewhat misguided."

"We might one day be at overcapacity," he wrote. "But that day isn't today."

We shipped our first rack to Jane Street.

This is the first step on our mission to run the world’s inference.

To accelerate production, we’ve raised $700M at a $21B valuation. This round was led by Jane Street after testing our hardware. In their words:

“We tested the chip and are pleased with the early results. Etched’s unique approach to inference delivers the precision we will need to support our most demanding workloads. We’re excited to now have our own rack running in our datacenter.”

Jane Street is joined by Kleiner Perkins, Sequoia Capital, Andreessen Horowitz, Peter Thiel, Tiger Global, Bain Capital Ventures, Neo, Stripes, Primary, Positive Sum, Diffusion, Argo, and Blackstone. We’re incredibly grateful for the support of all of our investors, customers, and suppliers.

Under 1% of the world has access to frontier models. Scaling intelligence requires a new kind of inference hardware.

We’re working on it.

As we ramp to Gigawatt-scale, we’ll face a new set of challenges: building new factories, global supply chains, fleet software, self-improving kernel agents, and more.

The racks won’t build themselves. If running the world’s inference excites you, please join us.

Anthropic prepares supervoting power for founders ahead of IPO, the Information reports

Anthropic has been preparing to give CEO Dario Amodei and other co-founders a class of stock with extra voting power to help insulate them from external shareholder pressure, the Information reported on Tuesday, citing two people familiar with the matter.

The company is also planning to maintain its existing body of non-shareholder trustees with a special class of stock to elect a majority of members to the company's board of directors, according to the report.

The specifics of the voting arrangements could not be learned, and the plans could still change, the report said.

Anthropic did not immediately respond to a Reuters request for comment.

Such a move would mark the first time Anthropic's leaders would have extra voting power. The Claude maker's co-founders hold relatively small ownership in the company, compared to founders of other tech firms.

Amodei himself owns only about 2% of the company, the Information said, citing a person close to Anthropic.

But dual-class structures aimed at giving supervoting power to leaders are common among founder-led companies, and is designed to give founders greater control and insulate them from short-term shareholder pressure.

SpaceX's dual-class structure, for instance, gives founder and CEO Elon Musk significant voting power. At Meta, CEO Mark Zuckerberg holds about 60% voting control by way of his ownership of super-voting shares.

The reported move at Anthropic comes as the company prepares for a potential initial public offering later this year, which is expected to be one of the biggest market debuts in history.

Anthropic is structured as a public benefit corporation, which is legally required to balance commercial success with social and public benefit. The company also has a Long-Term Benefit Trust, an independent oversight body that exists to make sure the startup delivers on its public benefit mission.

California, Colorado, Kentucky, and New Jersey have accused Meta of harming children with technology designed to be addictive. The states claim Meta fueled a national youth mental health crisis and deceived users by promoting its apps as safe. They have filed a lawsuit charging the company with violating federal child privacy laws and state consumer protection laws. Meta plans to argue that it put in safeguards to protect young users and that it was truthful to consumers. The states are seeking damages approaching $200 billion, nearly 14% of the entire stock value of the company.

OpenAI's revenue grew by 18% while its losses deepened from the first to the second quarter. Anthropic more than doubled its revenue in the same period, marking the first time its sales surpassed its older rival. It also swung to a small operating profit. The two companies' diverging fortunes show just how drastically the AI race has shifted since the beginning of the year.

I joined the productivity tools market in 2004 and have had the luxury of observing its dynamics for 22 years now. From time to time the market changes and I write a holistic "visionary" article. The last one was in 2019 when I bet on the no-code revolution. Now it's time to write a new piece, because the market is experiencing tectonic shifts that will change its landscape enormously.

Everyone knows that AI lowered the barrier, so now anyone can build software. You can't vibe-code a full OS (yet), but you can easily vibe-code small apps to solve personal problems. Things get more complex when you add "collaboration" as a dimension. If you work alone it's relatively OK to break things and move forward until you're happy with the app, but if you work in a team it becomes harder to implement all the needed bells and whistles to cover collaborative use cases. You suddenly need data storage with relations, concurrent editing, notifications, changes history, permissions, etc.

It raises an interesting question: where is the hot spot of malleable software in the AI age? Should we always start from scratch in Codex? Or should we have some solid base that can be tailored via custom code?

Imagine you have a small mushroom farm that employs 10 people (don't worry, we will grow champignons here (for now)) and are looking for software to run all operations. Most likely you are using Google Sheets, since the market is too small to have specialized software (ha! no market is too small).

You have several options. The irony is that… none of the options are ideal.

1. Build from scratch (Claude Code, Codex) - from 2024.
   1. Problem: When you prompt-code everything from scratch, you have to care about everything, including hosting, auth, basic permissions, database, etc. The first 80% may be easy, but the final 20% would be hard
   2. Future hope: Here we can hope that eventually AI will be so cool and powerful that it will just do things right and fast
2. Vibe-code (Lovable, v0) - from 2023.
   1. Problem: Somewhat better than #1, since you get a hosted app, a database, auth and deploy out of the box, and it looks finished sooner. But when you outgrow what the generator does well, you will be stuck
   2. Future hope: More powerful models make it better. Also these vendors will add more and more components, moving into "solid base + custom code" space
3. Low-code & app builders (Retool, Softr) - from 2017.
   1. Problem: This category has been selling "solid base + custom code" last ten years: auth, permissions, hosting and audit logs out of the box. But it's an app base, not a work base. Your data is assumed to live somewhere else, and even when these vendors add their own database, it stores app data: no collaboration, no comments, no changes history
   2. Future hope: Move deeper into "solid base + custom code". The open question is whether an app base can grow into a work base fast enough
4. Assemble it in a malleable tool (Notion, Fibery) - from 2013.
   1. Problem: This might look tempting, since you will get many things ready fast. The problem is how to tailor these tools to your process. They are quite flexible, but might not support your specific needs and do not have enough extension points
   2. Future hope: Add more extension points and let users vibe-code the missing ~20% of use cases, so these tools will move into "solid base + custom code" territory too
5. Buy some specialized tool - from 1999.
   1. Problem: This is still a very good option sometimes, since a specialized tool was built with your domain in mind and it might look very relevant. Go for it if you don't need customization
   2. Future hope: Moving into flexible tools territory will be almost impossible for these vendors (and it is not needed at all). The moment it gets generically flexible, it stops being specialized 🙂

80% solid bases + 20% custom code

What is happening in the productivity tools market? It seems the ideal solution is to have a solid base covering 80% (databases, permissions, history, collaboration, notifications, etc.) and let users mix these things and extend via custom code.

As a result, many vendors are heading in this direction, closing the gaps in missing areas. And while vibe-code and low-code tools are adding more solid bases, malleable tools should add more extension points.

Solid bases

In the past the only solid bases you had were a compiler and an OS — everything else was your problem. Beautiful time of true hackers!

Now we have the luxury of higher abstractions. The most interesting question is: where to stop? For example, a specialized tool without any customization is as solid as it gets, but the lack of customization is exactly what makes it unusable in many cases. With Codex your solid base is almost non-existent, but you have enormous expression power and can build almost whatever you want (expression power is how far you can bend the tool to do exactly what you need).

I think both extremes are suboptimal for the productivity tools market, and we should find a sweet spot somewhere in between. The solid base should cover what's identical for every team, and custom code should cover what makes yours different.

Current solid bases differ in kind:

• Vibe-coding platforms give you a tech base (servers, raw database, auth)
• Low-code platforms give you an app base (UI components, connectors, access control)
• Malleable tools give you a work base (the data itself lives there, together with everything a team needs around the data)

Custom code

If the base covers what's identical for every team, custom code covers the rest: your unique interfaces (a harvest screen for the growing room tablet), your business logic (mushroom batch quality rules), your connections (the wholesale client's API, the humidity sensors). This 20% is small in volume, but it is your company, so no vendor will ever model it exactly right.

Code made an unexpected (to me) comeback with LLMs at the end of 2025, so now all no- and low-code tools can rely on code more and more, ironically!

But custom code works well only when the following conditions are met:

• It inherits the base. Permissions, history and data integrity apply to custom code automatically. If every generated app needs its own auth, storage and audit trail, you are doomed
• It is bounded. Custom code can break itself, but it cannot corrupt the base (and in case of corruption, rollback should be easy). A bad app should be an inconvenience, not a data-loss incident

Where is the productivity tools market heading?

Programmers always had full expression power, but even programmers do not create a lot of personal tools. Why? Well, because it's quite time-consuming. Now the tides are shifting and you can really vibe-code useful personal tools in hours.

In the productivity market you always have this tradeoff: spend time and build a tool for your company or purchase something ready to use. Specialized tools were the default choice for many, but now AI shrinks configuration time (everybody can prompt). It means malleable software becomes approachable for not-very-technically-savvy users and can beat specialized tools more often.

Everyone wants the same territory, but each road is different:

• Vibe-code tools must build a base. Now it takes a lot of time to rebuild these solid bases and make the solution viable
• Malleable tools must add expression power. Now malleable tools are not flexible enough to give users the expression power they need
• Low-code tools need both. Now they are in the middle and should move in both directions
• ? And maybe AI from scratch will make the whole map obsolete (but not yet!).

Which vendor/segment reaches this territory first, and is there space for many vendors? I bet there is! Solid bases somewhat differ in kind: some are built for IT departments assembling internal tools, some for teams with heavy collaboration flows, some for tinkerers solving their own problems.

If you are choosing a tool today…

A year ago you had 3 options, now you have 5!

Working alone? You may try to vibe-code it and have fun. A specialized tool covers 90% of your process? Buy it. But for a team with an evolving process, like our mushrooms farm, I would start in a malleable tool today. The base is already there, with batches, orders, history, permissions. And the missing 20% gets more vibe-codeable every month.

One principle is quite important: select your base, not the interfaces. Data, history and permissions accumulate and are relatively hard to re-pick in two years. The UI is becoming the cheap and replaceable part.

Wrap Up

In 2019 I bet on no-code tools, in 2025 code came back in a very surprising way. This comeback is inverting our market. For many years vendors sold interfaces, while the base (storage, permissions, history) was boring plumbing underneath. Now interfaces are generated in minutes, while a base construction still takes years.

So here are my new bets:

• Solid bases + custom code wins the productivity market
• Malleable tools have great chances to get there first, because extension points take quarters to add, while a solid base takes years

See ya in 2030. We'll check whether that mushroom farm finally got rid of its spreadsheets 🍄‍🟫.

SpaceX’s most recent Starship test flight may have ended July 24, but its mission isn’t over yet.

The spacecraft splashed down in the Indian Ocean intact after flying halfway around the world from SpaceX’s launch base in South Texas. Engineers expected the ship’s life to end with a fiery disintegration after toppling over, just as past Starships have done following splashdown.

Numerous onboard sensors and cameras, along with buoys and drones in position at the splashdown zone, have provided important data for SpaceX to assess the performance of the ship’s heat shield after each test flight, so officials accepted the post-flight conflagrations. That day, Starship tipped over and remained intact, surprising just about everyone.

Engineers have reams of data from all 13 test flights of Starship and its giant booster rocket, known as the Super Heavy. But there’s no match for inspecting hardware after returning from space. SpaceX routinely recovers and reuses Falcon 9 booster stages with near-flawless performance. The handful of minor failures with the Falcon 9 have centered on the rocket’s single-use upper stage.

Hardware-rich

So, getting Starship back in one piece is a boon. A recovery ship towed the spacecraft engine-first several hundred miles across the Indian Ocean to Christmas Island, an Australian territory. SpaceX announced the ship’s arrival just off the coast of Christmas Island on Tuesday.

“A team of SpaceX engineers is on their way to conduct additional analysis on the vehicle in calmer waters before attempting to return it to Starbase,” SpaceX wrote on X.

SpaceX hasn’t said how exactly it might get the spacecraft back to Starbase, the company’s Starship development site and launch base in South Texas, more than 10,000 miles from Christmas Island. It would have to travel by sea. Starship, more than 170 feet (52 meters) long and 30 feet (9 meters) in diameter, is too large to fit into any aircraft in one piece.

The company intends to recover future Starships directly at the launch site, using mechanical arms on the launch tower to catch the vehicle during final descent. That will help SpaceX expedite reuse of the vehicle. This one won’t be reused. Splashing down in the ocean exposes the spacecraft’s engines, stainless steel structure, and sensitive electronics to the corrosive effects of salt water. The vehicle also sustained damage during the tip-over after splashdown.

Successfully bringing Starship to Christmas Island was perhaps just as unexpected as the vehicle ending its test flight intact. At one point last week, Elon Musk, SpaceX’s CEO, said that recovering the ship was “not looking good.” He said teams in the Indian Ocean were able to obtain close-up photos of the heat shield and engines “for future upgrades.” The recovery crew kept Starship afloat in rough seas by attaching air-filled Yokohama fenders around the vehicle.

Starship’s heat shield, made of approximately 18,000 ceramic tiles, is key to SpaceX’s goal of making the vehicle fully and rapidly reusable. NASA’s Space Shuttles used similar tiles for protection during atmospheric reentry, but they required replacement and extensive touch-ups between every flight. SpaceX would like to eliminate tile replacements, and even detailed inspections, to turn around its future fleet of Starships multiple times per day.

Musk has long identified the heat shield as the company’s most pressing unsolved problem with Starship. During SpaceX’s first quarterly earnings call on August 4, Musk said he considered the heat shield problem “solved.”

Other industry experts are not so sure. It is true that the vehicle’s heat shield seemed to be in better condition after last month’s flight than it was following previous reentries. The tiles are clearly good enough to bring Starship back to Earth safely, but can they withstand the high flight rate SpaceX foresees to build and maintain bases on the Moon and Mars or large constellations of orbital data centers?

Getting Starship’s heat shield back, and then putting the recovered tiles through tests in the laboratory or even on future Starship flights, might help answer this question.

fx is a coding agent harness and CLI written in Zig, optimized for research and embeddability as part of larger systems.

It focuses on minimalism and performance across the board, from system prompt design, to its tools, feature set, and 6.39mib binary.

For end users, its CLI output style and form factor aims to be closer to a Unix shell than a heavy "IDE in the terminal" TUI.

It's open source (Apache-2.0), model-agnostic, and suitable for both local and cloud inference.

Tiny ~6mb binary

Designed for instant installation and embedding in resource constrained environments and agent sandboxes.

Instant time to prompt

fx cold starts in 10µs and does no unnecessary work or I/O prior to accepting user input, making it ideal for programmatic use.

Wasm support

Optimal fx.wasm builds produced by the Zig toolchain, which further reduce fx's size, making the network stack pluggable.

Minimal memory footprint

fx contributes single-digit megabytes of memory baseline, allowing you to pack many instances in one machine.

Shell-like UI and ergonomics

fx preserves scroll history by default, produces minimal output, and makes sparing use of complex TUI or paints

Context efficient

Minimal system prompt and tools, to save on token costs and to yield optimal time-to-first-token performance (TTFT).

Embeddable and extensible

Small core, extended via skills, plugins, MCPs, with a Unix-like philosophy to extensibility.

Model and provider agnostic

Designed to work with local models, gateways, direct provider API access or subscriptions.

Claude Opus 5 is now available in AWS GovCloud (US)

AWS GovCloud (US) now offers Claude Opus 5 — the most advanced Opus model yet, and compatible with zero data retention (ZDR) — bringing a step-change in coding, long-running agents, and complex professional work to teams building at the highest level. Claude Opus 5 is available via the bedrock-runtime endpoint in both AWS GovCloud (US) regions, and available via the bedrock-mantle endpoint in AWS GovCloud (US-West)

Claude Opus 5 delivers advances in coding, understanding and navigating codebases like an experienced engineer and writing production-quality code while adapting its strategy as it works. It powers dependable agents that run for hours and even overnight, finding paths around obstacles, recovering from errors, and reaching their objectives. And it brings deeper reasoning to long documents and higher accuracy to complex analysis, with the largest gains on document-heavy enterprise work.

Amazon Bedrock offers Claude Opus 5 with zero data retention (ZDR) enabled by default, giving you Opus' top-tier intelligence while meeting your data governance requirements. It keeps your data within AWS infrastructure with regional data residency and provides access through a unified service with AWS-managed features like Guardrails and Knowledge Bases. To learn more, see the Amazon Bedrock documentation and regional availability.

Acadia is a public-alpha programming language that compiles typed, functional database code into SQL, aiming to bring custom types, compiler-verified migrations, better error messages, and end-to-end type safety to SQLite-backed applications. Developers define tables and transactions with constructs like map, filter, and typed bindings, while Acadia generates and optimizes the underlying SQL and integrates those types with client and server code.

Apple developers can now build and test their applications natively on Apple Silicon in Azure Pipelines. New arm64 macOS agents are available in public preview through the pay-as-you-go GitHub-hosted Agents pool.

Starting with Apple Silicon, Azure Pipelines is bringing over some of the agent sizes already available in GitHub Actions. The preview includes the following macOS images:

Running workloads directly on Apple Silicon avoids the overhead and compatibility limitations of emulating arm64 on Intel hardware. It also lets teams validate applications against the same architecture used by current Apple devices and development machines.

Pay-as-you-go pricing

The new agents use pay-as-you-go pricing with the rate tied to the size of the agent. This means they are charged per minute and no longer on the one-size-fits-all parallelism model. See Azure DevOps pricing for current rates.

Enable GitHub-hosted agents in billing settings

To use the Apple Silicon agents, first enable GitHub-hosted agents in the billing settings for your Azure DevOps organization.

Enabling this option provisions the new GitHub-hosted Agents pool used for pay-as-you-go agents.

Use the Apple Silicon images

Once the pool is provisioned, target the standard macos-26-arm64 image in your YAML pipeline:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64'
steps:
- bash: |
    echo Hello from macOS Tahoe arm64
    uname -a
    sw_vers

For a more powerful agent, target the XLarge macos-26-arm64-xl image:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'macos-26-arm64-xl'
steps:
- bash: |
    echo Hello from XL macOS Tahoe arm64
    uname -a
    hostinfo | grep memory

A new Xcode-based naming convention for macOS images

Every macOS image version contains one major version of Xcode. Beginning with the Xcode 27 public preview, each new image name is based on a major Xcode version rather than the underlying operating system, with one major Xcode version supported per image version.

This model makes it easier to target the exact Apple toolchain a project needs and understand what each agent provides. It also reflects how macOS CI jobs are commonly defined: by their required Xcode toolchain rather than the operating system installed underneath it.

The Xcode 27 preview image is gradually rolling out in the ‘GitHub-hosted agents’ pool over the next few weeks. To use the image, use the xcode-27 and xcode-27-xlarge image labels:

pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'xcode-27'
steps:
- bash: |
    echo Hello from macOS with Xcode 27
    uname -a
    sw_vers
    xcodebuild -version

# Or, for the larger agent:
pool:
  name: 'GitHub-hosted Agents'
  vmImage: 'xcode-27-xlarge'
steps:
- bash: |
    echo Hello from macOS with Xcode 27
    uname -a
    sw_vers
    xcodebuild -version
    hostinfo | grep memory

The Xcode 27 image is available only on arm64 macOS runners and is not supported on Intel agents. It also includes different tools and tool versions than earlier images. Review the image’s installed software here.

Important Xcode images are rolling out at publishing time of this blog post and will reach all Azure DevOps organizations over the next 2-3 weeks.

Monitor per-minute usage

Because pay-as-you-go agents are charged per minute, the updated Analytics tab in the GitHub-hosted Agents pool lets you:

• View the number of minutes used per project.
• Filter usage by image.
• Drill down by agent SKU and pipeline.

Usage is also available in Azure Cost Management. You can track the number of minutes used and break down usage by Azure DevOps organization and project.

Azure Cost Management also supports budgets and alerts, which can help you forecast and monitor spending as teams adopt the new agents.

Get started

1. Enable GitHub-hosted agents in your Azure DevOps organization’s billing settings
2. Wait for the GitHub-hosted Agents pool to be provisioned
3. Select the standard macos-26-arm64, XLarge macos-26-arm64-xl image or corresponding xcode-27/xcode-27-xlarge images once available
4. Validate your dependencies and build scripts for arm64 compatibility
5. Monitor consumed minutes in pool analytics and Azure Cost Management

Apple Silicon support gives Azure Pipelines users a native, scalable way to build and test modern Apple applications, with the flexibility to select an agent size that matches each workload.

Frequently asked questions

Q: How is GitHub-hosted agents billing different from Microsoft-hosted agents?
A: Microsoft-hosted agents use a concurrency-based billing model where you pay for the maximum number of jobs running in parallel. GitHub-hosted agents use pay-as-you-go billing where you’re charged per minute of pipeline execution time. For more information, see Pricing for Azure DevOps.

Q: What is the impact of enabling the ‘GitHub-hosted agents’ pool?
A: Initially, nothing. No existing pipelines use this pool unless you explicitly update them to do so. Existing standard-sized Intel images continue to be available in the Microsoft-hosted ‘Azure Pipelines’ pool. Over time, as you create and update pipelines to use the new ‘GitHub-hosted agents’ pool, you see usage and billing based on the GitHub-hosted agents pool.

Q: Do pay-as-you-go jobs consume existing parallelism settings?
A: No, the ‘GitHub-hosted agents’ pool is a brand new pool where agents are only metered by the minute.

Q: How are GitHub-hosted agents related to GitHub Actions?
A: GitHub-hosted agents run on the same infrastructure and use the same agent specifications and pricing as GitHub Actions do. Over time, more agent types available in GitHub Actions will become available in Azure Pipelines.

Q: Can I still use the Azure Pipelines pool for new versions of operating systems?
A: The Azure Pipelines pool and parallelism pricing continue to be available for the standard size Intel-based agents that use it. New Intel versions of Ubuntu and Windows are available in the Azure Pipelines pool. As Apple indicates macOS 26 Tahoe is the last version with native Intel support, new versions of macOS are available in the GitHub-hosted agents pool only.

Q: If I don’t specify any pool in YAML, what pool is used?
A: If you don’t specify a pool in your YAML pipeline, the default pool used is the Microsoft-hosted ‘Azure Pipelines’ pool.

Q: I enabled GitHub-hosted agents in billing, but don’t see any changes
A: It can take up to 24 hours for the new GitHub-hosted agents pool to be provisioned in your organization. If the pool isn’t provisioned within that time, create a support case.

Q: Some of my jobs get queued. How can I increase the number of virtual agents?
A: During the preview, the number of virtual agents is 8 per agent SKU. Over the period of the public preview, we will gradually increase this number. If you want to have the number of virtual agents for a specific agent SKU raised to a higher number, create a support case.

Q: How can I see how many minutes the new agents are using?
A: In addition to the monitoring available in Azure Cost Management today, we will add an analytics experience on the pool directly. For more information, see Monitor usage.

Q: How can I forecast the usage of pay-as-you-go agents?
A: Forecasting requires making some assumptions on what pipelines will be updated to use pay-as-you-go agents. We will add some usage data on the billing page that can be used before pay-as-you-go billing is enabled, combined with updates to the Azure Pricing Calculator. Together, these will give organization admins some idea of the impact before pay-as-you-go billing is enabled.

Q: I’m trying to use xcode-27 images, but they appear not available
A: The xcode-27 and xcode-27-xlarge images are gradually rolling out in the ‘GitHub-hosted agents’ pool over the next few weeks.

Q: Are there plans for additional agent types?
A: We are planning to add larger Linux and Windows agents to the GitHub-hosted agents pool at a later point in time.

Learn more

• GitHub-hosted agents in Azure Pipelines
• GitHub-hosted agents FAQ
• Azure DevOps Sprint 275 release notes
• Azure DevOps pricing
• GitHub: Xcode 27 runner image now in public preview

Higgsfield raises $400M Series B, quadrupling its valuation in 8 months to $5.4B

Higgsfield announced Monday that it has raised a $400 million Series B at a $5.4 billion valuation. This new round is just eight months after nabbing a $1.3 billion valuation.

Founded by former Snap exec Alex Mashrabov in 2023, Higgsfield lets users create AI images and videos. It made headlines this past year for premiering AI-generated movies at both Cannes and in New York. It has tools like Cinema Studio to help filmmakers direct AI films and Marketing Studio for marketing and advertising teams. In a release announcing the round, the company touted $700 million in annualized revenue and 30 million users across 200 countries.

One growing market for the company has been enterprises. It is now working with 390 of the Fortune 500, it said. Mashrabov told TechCrunch that Higgsfield expects “enterprise adoption of video AI to become much more deeply embedded in everyday marketing and creative workflows.”

The fresh capital will fund the usual business needs like hiring and product development. But it will also help pay for compute. “Video is one of the most compute-intensive domains in AI,” Mashrabov explained. Just one minute of video is like processing 60,000 words. Securing reliable compute capacity has therefore become a necessary expense to remain competitive with others in the industry like Synthesia and Runway.

DST Global led the latest round, with many other investors piling in, including Goldman Sachs Alternatives, Valor Capital, and Tribe Capital.

After years of feeling drained by meetings, documentation, and design process, veteran designer Jamie Rothwell rediscovered his enthusiasm for the craft by building products directly with AI-assisted tools. A side project that went from idea to App Store in six weeks showed him the value of shipping real software instead of producing handoffs and specifications. Following a layoff, he doubled down on this designer-builder approach, arguing that adaptability and staying close to the product matter more than protecting traditional design workflows—and that many designers lost the fun of the job to process long before AI arrived.

Google is adding a Gemini toggle letting users remove visible watermarks from AI-generated images, video, and music, rolling out except where legally required.

GitHub's Secure Open Source Fund invested over $500,000 across 50 projects, helping maintainers strengthen security through expert guidance, GitHub tooling, and AI-assisted workflows.

Google has revealed the full Desktop Camera app ahead of the upcoming Googlebook launch. Designed for tablets, laptops, and desktops, the app features a responsive large-screen interface, support for external USB webcams, ML-powered document scanning with automatic cropping and enhancement, and QR code scanning. The design closely resembles the Pixel Camera experience on tablets, suggesting Google is aiming for a familiar camera workflow across its larger-screen devices.

Instagram's first major brand refresh in 10 years was the result of thousands of small, deliberate decisions rather than a single bold move. Designed for a global audience of billions, the project involved extensive collaboration, research, feedback, and testing to modernize Instagram's identity while preserving its core values of creativity, connection, and self-expression. The team focused on creating a flexible system that can evolve over time, accepted that change would inevitably attract criticism, and believes the best design work is so carefully crafted that it ultimately feels natural and effortless.

Generate texts for posts, articles, product descriptions, and ads.

A Canadian Cineplex in Prince George drew its own Spider-Man: Brand New Day poster by hand after official posters failed to arrive due to shipping issues. The hand-lettered design, made by a staff member and featuring Spidey throwing devil horns, went viral on social media, with fans praising its personality over official artwork.

Illustrator and animator Gaia Alari creates richly tactile, hand-drawn work inspired by art, folklore, and human emotion, using traditional techniques and intuitive storytelling to explore complex feelings through illustration, animation, and film.