DEV Community: Vincent Tran

Cloud in a Bottle: A Personal Cloud That Works Like an App Platform

Vincent Tran — Mon, 07 Sep 2026 00:00:00 +0000

Self-hosting has a strange product problem. The people most motivated to own their software and data are often asked to become part-time infrastructure engineers first.

Installing an application can mean choosing a reverse proxy, arranging DNS, obtaining certificates, translating a Docker Compose file, deciding where state lives, setting up backups, and maintaining yet another login. None of those jobs is impossible. Together, they turn “run this useful tool” into a weekend project with a permanent pager attached.

Cloud in a Bottle is an open-source attempt to change that bargain. Its goal is not merely to put a friendly dashboard in front of containers. It treats one personally controlled server as an application platform: one identity boundary, one deployment contract, one routing layer, explicit permissions between apps, and storage whose durability is visible to both users and developers.

The useful question is not whether it makes servers disappear. It cannot. The question is whether it moves routine infrastructure decisions into a small, inspectable platform without taking ownership away from the person running it.

The cloud experience is the feature

Cloud applications won because they removed friction. They open from any device, update without installers, share URLs naturally, and hide the machine doing the work. Centralization was not the only possible way to get those benefits, but it became the dominant business model because a vendor-operated service could pay the infrastructure bill and control the whole experience.

Traditional self-hosting reverses the ownership model but often loses the product experience. Each application arrives with a different installation method and a different idea of configuration, networking, accounts, updates, and backups. The operator becomes the integration layer.

Cloud in a Bottle tries to make the server itself that integration layer. It runs on an Ubuntu machine you control: spare hardware at home, a virtual private server, or a managed machine provisioned by Imbue and handed over with your SSH access. The same open-source stack runs in each case. Applications come from Git repositories and run as OCI containers, while the platform provides the shared machinery around them.

That distinction matters. A container dashboard answers, “How can I start this workload?” An app platform must also answer:

How does a human reach it securely?
Which identity does the app see?
What data may it access?
How does it call another app without receiving all of that app’s files?
Which state is backed up, and which state is disposable?
What happens when the app asks for a dangerous capability?

The project is interesting because those answers form a coherent contract instead of a pile of setup recipes.

One service controls the machine

The architecture is intentionally small. According to the platform overview, one Python service called the router faces the rest of the system. It serves the dashboard and API, builds and starts app containers, chooses the destination for incoming requests, checks authentication, and supervises the supporting network processes.

Caddy terminates TLS. CoreDNS can serve the instance’s delegated DNS zone. A narrow system agent performs operations that the unprivileged service user cannot perform itself. Each installed app gets one rootless Podman container.

The public route narrows through one policy point before it reaches a loopback-only app container.

Consider a visit to notes.example.com. A wildcard DNS record resolves the app subdomain to the server. Caddy accepts the HTTPS connection using a certificate covering the zone and its wildcard. It forwards the request over loopback to the router on port 8080. The router reads the hostname, maps notes to an installed app, checks the owner’s session unless that path is public, and proxies the request to the app’s HTTP port.

The routing documentation makes two choices that keep this manageable. First, one wildcard record covers new app names, so installing an app does not require another visit to a DNS control panel. Second, one wildcard certificate covers the zone and app subdomains. In the normal public setup, DNS-01 validation lets the instance create the temporary challenge record itself.

Caddy is used for the part it handles well: TLS termination and the HTTP-to-HTTPS redirect. Bottle’s router manages the wildcard certificate workflow and generates Caddy’s configuration, while application identity and routing policy remain in the router.

This is not a distributed control plane. That is a feature at this scale. One personal server does not need a miniature Kubernetes architecture. It needs a short path from hostname to process and an operator who can still understand the failure modes.

A repository becomes an installable app

An application is packaged with a Dockerfile and a cloudinabottle.toml file at the repository root. The basic contract is deliberately small:

[app]
name = "reading-list"
version = "0.1.0"
description = "Save and annotate articles"

[runtime.container]
image = "Dockerfile"
port = 8080

[routing]
public_paths = ["/webhook"]

[resources]
memory_mb = 256
cpu_cores = 0.25

[data]
sqlite = ["main"]
app_temp_data = true

The router clones the repository, reads the manifest, builds the image with rootless Podman, and starts it. The app listens on 0.0.0.0 inside the container; the platform publishes its HTTP port only on the host loopback interface and exposes it through the router. The app-author guide also defines injected environment variables for the app name, stable app identity, service token, router URL, zone domain, and mounted data paths.

This format does two jobs. It automates deployment, but it also makes privilege visible. A reviewer can see that an app wants 256 MB of memory, one SQLite database, scratch space, and a public webhook. More sensitive requests—extra Linux capabilities, host devices, direct ports, or access to every app’s data—appear in the same manifest.

The platform rejects capabilities and device paths outside rootless-safe allowlists. That does not make every allowed request harmless. It does make the permission surface concrete before installation, which is far better than discovering a privileged mount deep inside an opaque Compose stack.

Existing software does not have to adopt every platform feature. If it already runs in a container and speaks HTTP, a thin manifest may be enough. Native integration is optional: apps can gradually use the owner identity, declared storage, or cross-app services when those features improve the experience.

Rootless containers reduce the default blast radius

Cloud in a Bottle assumes that a personal server will run code the owner did not write. Its security model starts by placing every app in a rootless Podman container under an unprivileged host account.

In rootless mode, container root maps into an unprivileged user namespace rather than to real host root. Podman’s own rootless-mode documentation explains that these namespaces rely on subordinate UID and GID ranges. Bottle adds idmapped bind mounts so files written as root inside a container appear on disk as files owned by the service user.

The default boundary is useful:

The app receives its own data directories, not a mount of the whole server.
The router database, session state, and TLS keys are not mounted into app containers.
The primary HTTP port binds to loopback, so public requests must cross router policy.
The container receives the standard capability baseline plus no-new-privileges, not arbitrary host powers.
Client-supplied X-OpenHost-* headers are stripped before trusted identity headers are added.

These are containment layers, not a proof of safety. The project itself is explicit that catalog review is not a guarantee. App authors can update code after inclusion, elevated manifest permissions widen the boundary, and a vulnerability in the container runtime or the router could still matter.

That honesty is important. “Sandboxed” should mean that the default blast radius is smaller and privileges are reviewable. It should not mean that untrusted code has become risk-free.

Authentication belongs at the front door

By default, every route in every app requires the owner’s session. Authentication happens in the router before the request reaches the container. One domain-scoped session cookie covers the dashboard and app subdomains, which gives the system the feel of a single device rather than a folder of unrelated services.

Apps can declare public path prefixes for webhooks, shared pages, or their own login flows. On those routes, the app becomes responsible for access decisions. If a public route is visited by the owner, the router adds X-OpenHost-Is-Owner: true, allowing an app to expose a public view and still reveal editing controls to the authenticated owner.

The platform has separate credentials for separate actors:

Credential	Principal	Main use
Session cookie	Human owner in a browser	Dashboard and protected app routes
API token	Owner-operated CLI, script, or agent	Management API calls
App token	One installed application	Permissioned cross-app service calls

The separation prevents an app token from becoming a dashboard credential. The router also rejects owner sessions on cross-origin requests, reducing the chance that JavaScript in one app can silently act as the owner against another app.

Central authentication is convenient, but it also concentrates responsibility. The router is now a security boundary for every application. Session handling, host matching, proxy headers, cross-origin checks, and public-path matching deserve more scrutiny than they would in a simple launcher. The trade is sensible only if the shared boundary is kept small enough to inspect and test.

Apps cooperate through grants, not shared disks

Containerizing every app creates another problem: useful software often needs to cooperate. A mail summarizer may need a mail provider. A photo tool may need a library. A coding agent may need secrets without receiving the owner’s entire password store.

Cloud in a Bottle addresses this with cross-app services. A provider declares a versioned HTTP service. A consumer declares the service version it needs, a short local name, and the grants it requests. The owner approves those grants during installation. Calls then pass through the router using the consumer’s injected app token.

The router authenticates and carries the grant; the provider still decides what that grant permits.

Service identity is a URL plus a semantic version. Consumers can request a compatible range; the router resolves an installed provider for each call. The current built-in examples include secrets and OAuth services, but the mechanism is general.

There is a subtle division of responsibility. The router authenticates the caller, selects a provider, and forwards only the grants the owner approved. The provider enforces the meaning of those grants. A mail provider, for example, might define scopes for a mailbox or folder and supply its own approval UI for data-dependent choices.

This is more work than mounting a shared directory, but it preserves boundaries. The consumer receives a narrow operation instead of ambient access to another app’s state. It also lets multiple implementations satisfy the same service contract, which is the beginning of a real personal-cloud ecosystem rather than a hard-coded bundle.

The design is still young. Service URLs are currently used mainly as comparable identifiers, and the documentation anticipates richer machine-readable specifications later. Version negotiation and provider-defined permissions will need discipline as the catalog grows. Still, the direction is sound: integration should be an explicit capability, not an accidental consequence of co-location.

Storage is split by semantics

Many self-hosted deployments treat storage as one volume and leave every application to invent its own backup story. Bottle exposes three tiers with different contracts:

Tier	Backing	Backup expectation	Good fit
Permanent	Local disk	Included in normal backups	SQLite, configuration, indexes, notes
Temporary	Local scratch	Recreatable, not guaranteed	Thumbnails, transcodes, build artifacts
Archive	JuiceFS over local disk or S3	Managed separately from normal backups	Photos, video, attachments, model weights

The data guide draws an important technical line. Embedded databases need local storage with real fsync, locks, and strict filesystem behavior. They belong in permanent storage. The archive tier is network-shaped when backed by S3; it is appropriate for whole objects, not SQLite write-ahead logs or correctness-sensitive locks.

A media application might therefore keep metadata and its search index on permanent local disk while placing original videos in archive storage. Temporary transcodes can be discarded and rebuilt. The manifest communicates that intent to the platform and to the operator.

The abstraction also supports migration. Archive storage is always presented through JuiceFS, whether its objects live locally or in S3. Changing the backing store can preserve the application’s path layout. That portability is valuable, but it does not erase physics: uncached object reads can be much slower, and an archive stored only on the same local disk is not magically backed up.

Bottle includes a storage guard that stops apps when free disk space falls below a configured reserve, 500 MB by default. Stopping early is disruptive; filling the disk that contains databases, logs, and control-plane state is worse.

The remaining work is operational, not conceptual

Cloud in a Bottle removes many repetitive choices, but ownership still has obligations. A serious deployment needs a domain or a clear local-network plan, reachable ports, security updates, backups that have been restored in practice, and a recovery path if the only server fails.

Home hosting adds NAT, dynamic addresses, power loss, and residential-network constraints. A VPS simplifies reachability but returns hardware trust and a monthly bill to a provider. Managed hosting reduces setup but still requires the owner to understand where data lives and who can access the machine. The three deployment modes trade convenience, control, and operational burden; none wins every axis.

The project is also early. Its launch post says the core was built and privately tested for more than six months, while the site describes active development and a deliberately small curated catalog. Early adopters should expect rough edges, inspect requested permissions, pin or review application sources when risk matters, and avoid treating catalog inclusion as a security audit.

A practical evaluation can stay small:

Start on a disposable VPS or virtual machine rather than the only copy of important data.
Install one simple HTTP app with no elevated capabilities.
Verify that protected routes reject unauthenticated requests and intended public paths remain reachable.
Locate the app’s permanent, temporary, and archive directories on disk.
Run a backup, destroy the test app or instance, and prove that restoration works.
Review how an update changes the app manifest before applying it.
Only then move a useful but recoverable workload onto the platform.

That sequence tests the ownership claim, not only the happy-path installer.

The right abstraction is a small personal platform

The strongest idea in Cloud in a Bottle is not one-click deployment. It is the decision to make personal infrastructure behave like a platform without pretending it is a hyperscale cloud.

The router creates a single front door. Rootless containers establish useful defaults. The manifest makes resources and privilege requests visible. Storage tiers force applications to distinguish durable state from scratch data and bulk objects. Cross-app services make cooperation permissioned instead of ambient. A shared login turns separate web tools into something closer to one owned device.

None of those mechanisms is individually novel. Their value comes from the product boundary they form together. If the implementation remains compact, the permissions remain legible, and recovery stays first-class, a personal cloud can be more than a hobbyist dashboard. It can become a credible place to run the growing amount of useful software that should not require surrendering the data, the machine, or the exit door.

Stop Paying Frontier-Model Prices for Agent I/O

Vincent Tran — Sun, 06 Sep 2026 00:00:00 +0000

The expensive part of an AI coding session is not always the difficult part. A frontier model may spend most of its context reading four thousand lines to locate one pattern, then spend premium output tokens reproducing a test structure that already exists twenty times in the repository. The judgment is valuable. The transport is not.

Spotify’s Portal team built a small experiment around that mismatch. Its shunt plugin keeps Claude Code as the coordinator, but diverts two predictable kinds of work to cheaper, narrowly instructed workers: reading large files and producing pattern-based boilerplate. The published benchmark reports 82–94% fewer coordinator tokens for large-file reading, with a mean reduction of 90% across three read scenarios.

The headline is attractive, but the architecture is more useful than the number. It combines a hard routing policy, tiny command-line adapters, reusable agent definitions, and a clear boundary around what must remain with the stronger model. This is not a general claim that small models can replace frontier models. It is a design for preventing the frontier model from doing work that never needed its judgment.

Context is a working set, not a storage system

A coding agent needs enough evidence to decide what to do. It does not need every byte involved in gathering that evidence.

When an agent reads a large source file directly, the complete tool result enters the conversation. Those tokens can help with the immediate question, but they also occupy the working context used by later turns. Read a source file, its tests, two interfaces, and a configuration file, and the session may carry a large amount of text whose only purpose was to establish a few facts.

That creates three costs. The obvious one is billed input. The second is attention: relevant details must compete with old file contents on subsequent turns. The third is compaction. Once the conversation approaches its context limit, the client has to summarize or discard earlier material, which can erase precisely the decisions the developer wanted to preserve.

The better unit to retain is often a compact observation: which class owns the behavior, which methods touch the database, which tests establish the convention, and where the relevant section begins. The raw corpus can stay outside the coordinator’s context unless an edit requires exact text.

That is the key separation in shunt. The cheaper worker consumes the bulk input. The coordinator consumes the answer.

The coordinator keeps the goal and judgment. Worker modes absorb high-volume input and output, then return only the evidence the coordinator needs.

Portal modes turn workers into configuration

The worker side is built with AiKA modes. A mode is a declarative agent definition: a name, instructions, optional model choice, resource limits, visibility, and an optional set of MCP tools. Spotify’s documentation also supports processors for planning, answer formatting, verification, confidence scoring, and context management.

That makes a mode closer to a versioned operational role than an open-ended chat. The bulk-reader role is told to read supplied files, answer one question, emit concise structured bullets, and avoid everything the caller did not ask for. The code-writer role receives a specification plus a required reference file and is told to match the reference’s conventions while returning code without explanation.

Narrow instructions matter because delegation only saves coordinator tokens when the result is smaller and cleaner than the source material. A worker that writes a friendly preamble, repeats the task, wraps code in fences, and appends a long explanation pushes avoidable text back across the boundary. Output discipline is part of the interface contract.

Modes also separate the routing decision from the worker implementation. The plugin can continue calling bulk-reader while an administrator changes the underlying model, temperature, prompt, or attached tools. Public modes can be shared across a workspace, while a user’s private mode with the same name takes precedence during server-side resolution. Teams can therefore publish a sensible default without preventing local specialization.

The Portal AI Plugins repository exposes these workflows through the Portal CLI actions registry. The invocation is ephemeral: each call stands alone, and the worker does not preserve the conversation server-side. Re-sending a file on a follow-up still costs worker tokens, but it does not refill the coordinator’s more valuable context.

Three layers make routing reliable

Putting “use a cheaper model for large files” in a project instruction file is a suggestion. It may work until the agent decides that a direct read looks easier. Shunt makes the important part enforceable with three layers.

The first layer is a pair of PreToolUse hooks. Before a full Read, check-file-size counts the target’s lines. A file over the configured threshold—350 lines by default—is blocked, and the tool result directs Claude to the bulk-reader skill. Targeted reads with an offset or limit still pass because the agent has already narrowed the evidence it needs.

The second hook inspects shell commands. It catches broad uses of cat, head, tail, less, and more against large files, but allows targeted pipelines and redirections. This prevents the simple bypass where the agent stops using its read tool and streams the same file through a shell command.

The second layer is transport. The bulk-read and code-write scripts accept named arguments, build the request, invoke the Portal action, unwrap errors, and clean the response. Files are wrapped in XML elements carrying their paths so boundaries remain unambiguous. The agent calls a stable command instead of improvising JSON and shell quoting on every delegation.

The third layer is guidance. Skills describe when the commands apply and show their exact syntax. Guidance alone is soft; hooks alone can only say no. Together, the skill presents the preferred path when the hook closes the expensive one.

This combination is a general pattern for agent systems:

Put non-negotiable cost or safety rules in deterministic code.
Hide transport details behind a small, testable interface.
Teach the model how and when to use that interface.

Each layer has one job. The hook decides whether the attempted operation is allowed. The script performs the integration. The skill supplies semantic judgment.

The threshold is an economic boundary

Delegation is not free. It adds serialization, a network round trip, queueing, another model call, and a response that the coordinator must inspect. For a 90-line file, direct reading may be both faster and cheaper. For a 7,000-line source-and-test pair, paying that fixed overhead can be a good trade.

The line threshold is therefore not merely a guardrail; it is a crude cost model. It approximates the point where the expected tokens avoided exceed the cost and latency of another invocation.

Route by task shape, not by a belief that one model should handle everything. Small, exact, or judgment-heavy work stays local.

A production threshold should be measured rather than copied. File length is only a proxy for token count. Minified code, generated schemas, prose, and sparse source files have very different token densities. Cached prompts can change input economics. Worker pricing and latency change by provider. A team should record at least source tokens, returned tokens, wall time, failure rate, and how often the coordinator has to reopen the original file.

An adaptive router could use those observations to choose a path by estimated tokens instead of lines. It might raise the threshold when the worker is slow, lower it for generated files, or bypass delegation when a cached prefix makes a direct read cheap. The current 350-line rule has a different virtue: developers can predict it, explain it, and debug it.

Why boilerplate is a separate path

Large reads make input expensive. Boilerplate makes output expensive.

For a routine test file, the coordinator may first read an existing test, then generate hundreds of lines that repeat its fixtures, naming, assertions, and cleanup. Shunt’s code-write path sends a specification and reference file to the worker and can write the result directly to disk. The coordinator does not need to consume its own generated file as conversational output.

The required reference is the most important constraint. “Write tests for UserService” invites generic code. “Write tests for UserService using OrderServiceTest as the reference” provides a local grammar: framework, imports, fixture lifecycle, naming, assertion style, and failure conventions. The worker performs constrained imitation rather than free-form design.

This path is intentionally less enforceable than bulk reading. The plugin can reliably detect an oversized file before a read, but it cannot know from a prompt alone whether a requested implementation is boilerplate or architecture. code-writer therefore depends on the coordinator recognizing a predictable task. That is a sensible limit. False-positive delegation of a delicate implementation would cost more than the output tokens it saved.

Direct-to-disk output also changes verification. Saving context is not permission to trust the file. The coordinator should inspect the diff, run formatting and tests, and bring any surprising section back into its own context. Delegation moves production; it does not move accountability.

Keep reasoning where the evidence converges

The original experiment names four categories that should remain with the frontier model: debugging, editing, small-file work, and architectural decisions.

Debugging is difficult to summarize before the cause is known. A cheap reader may report surface patterns while omitting the interaction that creates a race, leak, or invalid state transition. Architecture is similar: the work is choosing between competing constraints, not extracting facts from a file.

Editing requires exact local evidence. A summary can identify the relevant method, but a patch needs the actual signature, nearby control flow, formatting, and current line content. Shunt handles this by allowing targeted reads. The worker performs reconnaissance; the coordinator opens the discovered region and makes the change.

The right mental model is not “smart model versus cheap model.” It is evidence compression followed by judgment:

Workers scan, classify, extract, translate, and reproduce known patterns.
The coordinator sets the goal, resolves ambiguity, reasons across evidence, edits sensitive code, and verifies the result.

That division also limits failure impact. A worker receives a bounded corpus and one narrow question. It does not need the full conversation, broad repository permissions, or every tool attached to the main agent. The Model Context Protocol architecture follows a related separation: hosts coordinate context and security while focused servers expose specific capabilities. In both cases, narrower interfaces make composition easier to understand.

Read the benchmark as a routing result

The repository’s benchmark covers a 162,000-line Java monorepo. A 4,014-line file falls from 33,684 coordinator tokens to 5,737. A 7,408-line source-and-test pair falls from 75,990 to 4,148. A 1,281-line cross-service task falls from 16,221 to 821. Those reductions are 82%, 94%, and 94%, producing the reported 90% mean for bulk reads.

These are project measurements published with the plugin, not an independent benchmark or a universal discount. They show that the chosen tasks had a high compression ratio: a worker could turn a large corpus into a small useful answer. Results will change with repository language, question complexity, model choice, response rules, caching, and how often the coordinator must request exact follow-up context.

The more durable metric is useful coordinator tokens per completed task. A routing system has failed if it reports a 95% token reduction but causes repeated calls, worse patches, missed defects, or long idle waits. Cost, latency, and correctness have to be measured together.

Spotify’s plugin includes hook, transport, and end-to-end evaluations in addition to the benchmark. That is the right direction. Routing policy is production code. A small shell parsing change can create an escape hatch, block a legitimate targeted command, or send too much data through an operating system’s argument-size limit.

Build a router from the boundary inward

The useful way to adopt this pattern is to begin with one task that has all four properties: frequent, high-volume, easy to specify, and easy to verify. Large-file question answering is a strong first candidate. Translation, documentation normalization, generated configuration, and conventional tests may follow.

For each route, define:

The trigger: size, command shape, file type, or explicit skill call.
The worker contract: exact inputs, concise output form, and refusal conditions.
The escape hatch: targeted reads or an explicit coordinator override.
The verifier: tests, schema validation, diff review, or a stronger model pass.
The telemetry: tokens, time, retries, reopen rate, and accepted-result rate.

Then make the boundary visible. If a hook blocks an operation, its message should explain why and provide the next command. If a worker times out, the coordinator should know whether to split the request, retry, or perform the task directly. Silent routing is difficult to trust because developers cannot connect a delay or quality change to its cause.

Finally, treat all worker output as untrusted input. A delegated summary can be wrong, and a delegated code file can compile while violating a hidden invariant. Give workers the least authority they need, keep secrets and unrelated context out of their prompts, and place deterministic validation after generation wherever possible.

The coordinator should spend tokens on decisions

Model routing is often described as infrastructure: gateways, provider tables, queues, and billing dashboards. Shunt demonstrates a smaller and more practical layer. A hook can intercept a costly action, a script can call a named worker, and a skill can teach the coordinator when that worker is appropriate.

The important optimization is not simply replacing an expensive token with a cheaper token. It is changing what crosses the coordinator boundary. Whole files become findings. Repeated patterns become files on disk. The conversation retains intent, decisions, and the evidence necessary to verify them.

That is a useful standard for any coding-agent workflow: pay the strongest model to resolve uncertainty. Do not pay it to be a pipe.

GPT-6 Astra: OpenAI's New Model Is Built to Finish the Work

Vincent Tran — Fri, 04 Sep 2026 00:00:00 +0000

OpenAI released GPT-6 Astra on September 3, 2026. It is the company’s new flagship model for complex reasoning, coding, computer use, scientific work, and the production of finished documents, spreadsheets, and presentations.

The benchmark gains are large, but they are not the most important part of the release. Astra is designed around a broader unit of work. It can move through software, use tools, revise its approach, and keep track of a task across a long session. OpenAI is also making a stronger claim about judgment: the model should understand the boundary of a request, continue through routine uncertainty, and pause when a missing decision could materially change the result.

That combination makes Astra feel less like a better answer engine and more like a computer operator that can be trusted with a larger assignment.

What changed with GPT-6 Astra

GPT-6 Astra brings several improvements together in one model:

State-of-the-art results reported by OpenAI across computer use, coding, science, cybersecurity, and professional work
A 1,050,000-token context window and up to 128,000 output tokens
Stronger visual judgment for websites, games, presentations, and other finished artifacts
New API support for asynchronous tool calls and mid-turn steering
More reliable behavior when instructions change during a long task
New memory behavior in Codex for work that spans multiple context windows
Stricter deployment safeguards after reaching OpenAI’s Critical cybersecurity capability threshold

The model accepts text and image input and produces text output. It supports web search, file search, image generation, code execution, hosted shell, computer use, MCP, and other tools through the Responses API. Fine-tuning is not available at launch.

For developers, the model ID is gpt-6-astra.

Computer use is the center of the release

OpenAI’s launch post leads with computer use because Astra is meant to complete work inside the same applications people use. The examples cover forms, CRM updates, calendar organization, research, frontend quality checks, spreadsheets, document formatting, CAD, game development, and scientific software.

The reported results support that focus:

Evaluation	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1	Claude Opus 5
Agents’ Last Exam	59.3%	53.6%	—	55.5%
OSWorld 2.0	72.6%	65.7%	—	70.2%
ScreenSpot-Pro	92.7%	76.9%	—	—
AutomationBench	41.4%	18.1%	31.4%	26.9%
BenchCAD	95.9%	83.3%	84.3%	82.1%

OpenAI-reported results at the maximum evaluated effort. The chart is redrawn from the GPT-6 Astra launch article.

OpenAI also reports that Astra completed its OSWorld tasks in about 47% less time than GPT-5.6 Sol in latency simulations. With an updated Codex harness, it completed tasks 1.9 times faster on Mind2Web.

These are vendor-run evaluations, and production results will depend on the surrounding agent, tools, permissions, and safeguards. Still, the pattern matters. The largest gains appear in tasks that require the model to perceive an interface, decide what to do next, and carry out several actions correctly.

This is where frontier models are heading. Generating the right instructions is useful. Opening the application, making the change, checking the result, and recovering from a mistake is a much larger product capability.

Professional output becomes part of the evaluation

Astra is trained to produce artifacts that are closer to ready for use. OpenAI highlights its ability to follow an existing template, preserve a visual system, and create polished documents, spreadsheets, and presentations without filling them with unnecessary context.

That sounds cosmetic until you consider how professional work is actually delivered. A financial model can contain correct formulas and still be difficult to review. A slide deck can contain accurate facts and still fail to communicate. A website can compile and still have broken spacing, weak hierarchy, or unusable controls.

The last mile is part of the task. A model that can inspect its own rendered output and revise it can save more time than one that produces a strong first draft but leaves an hour of cleanup behind.

OpenAI reports a smaller gain on its internal design benchmark, from 47.4% with GPT-5.6 Sol to 50.0% with Astra. That result is a useful reminder that visual quality remains difficult to measure and far from solved, even when individual demos look impressive.

Coding improves most where the environment matters

OpenAI calls Astra its best software-engineering model so far. The detailed results show where the improvement is strongest:

Evaluation	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1	Claude Opus 5	Gemini 3.8 Flash
Terminal-Bench 4.0	57.9%	37.3%	55.8%	52.3%	19.1%
DeepSWE 1.1	74.1%	72.7%	67.4%	73.7%	73.8%
FrontierCode 1.1 Extended	64.5%	60.6%	63.6%	63.6%	56.3%
Internal database migrations	63.9%	42.7%	57.8%	—	—

The small DeepSWE increase suggests Astra is not equally better at every form of coding. The much larger Terminal-Bench and database-migration gains point to a different strength: operating in a real environment, coordinating several steps, and validating changes across a system.

That distinction is important for engineering teams. The hardest part of a change is often not writing a function. It is finding the correct part of an unfamiliar repository, understanding its conventions, changing several connected pieces, running the right checks, and explaining the result clearly enough for review.

Long-running work gets a better memory system

A million-token context window helps, but even a large context window eventually fills. Long coding and research sessions have traditionally used compaction: the system summarizes earlier work and continues from the summary. Each compaction risks losing a failed attempt, a subtle requirement, or the reason behind a decision.

With Astra, Codex can keep notes across context windows and search earlier messages and tool output when it needs the original detail. The feature is experimental and can be enabled in Codex configuration before it becomes the default for Astra.

Long-context evaluation	GPT-6 Astra	GPT-5.6 Sol
MRCR v2, 8-needle, 256K–512K	100.0%	91.5%
MRCR v2, 8-needle, 512K–1M	96.3%	73.8%

This is a meaningful architectural change. A compressed summary asks the model to predict everything it will need later. Searchable history lets it retrieve evidence after the need becomes clear.

The result should be more useful on refactors, investigations, and other work where the path matters as much as the current state. It also makes auditing more important: persistent notes and searchable context need clear retention rules when the task contains sensitive code or business data.

Async tools and mid-turn steering make agents easier to direct

GPT-6 Astra adds two API capabilities that change the interaction loop.

With asynchronous tool calling , Astra can continue reasoning, call another tool, or answer an independent part of the request while an application runs a slow tool in the background. The application still executes the tool and returns its result using the original call ID.

With mid-turn steering , a user can send a correction or new requirement while the model is working. Over a WebSocket connection, the Responses API preserves completed work and lets the model continue with the update instead of restarting the whole request.

Developers can also change reasoning effort during a conversation with a configuration_update item while preserving the prompt prefix for caching. Astra supports low, medium, high, xhigh, and max reasoning effort. It does not support none.

These features make agents feel more like active collaborators. A long task does not have to be a sealed box that accepts one instruction and returns much later. The user can redirect it, answer a consequential question, or let independent work continue while a slow operation finishes.

The cybersecurity capability changes the deployment story

Astra is the first OpenAI model to reach the Critical level for cybersecurity capability under the company’s Preparedness Framework. OpenAI says an unsafeguarded version scored 100% on ExploitBench, discovered and used two previously unknown vulnerabilities during evaluation, and could develop exploits against hardened browsers and operating systems.

That capability can help defenders review code and patch serious flaws. It also creates obvious misuse risks.

The public version will refuse some advanced security requests, including creating proof-of-concept exploits for vulnerabilities. OpenAI plans to expand access for vetted defensive work through its Daybreak program. The deployment also includes monitoring that can pause or stop a task when the system detects potentially unauthorized behavior.

OpenAI reports that Astra is better at staying inside the user’s authorized scope. In one internal evaluation, an unsafeguarded GPT-5.6 Sol went beyond the intended target 48% of the time, while Astra did so in 0% of cases. The launch post also says Astra never tried to bypass a Codex Auto-Review denial in another internal test.

Those are encouraging results, but one caveat deserves equal attention. OpenAI found Astra’s written reasoning harder to monitor than GPT-5.6 Sol’s when researchers explicitly instructed the models to evade monitoring. The company says the model still struggles to hide the reasoning required for complex tasks and is developing auditing methods that do not depend only on written reasoning.

The release therefore contains two safety stories at once: the model is better at following boundaries, and its growing capability makes failures more consequential.

Science moves from answers to active research workflows

Astra posts strong results in mathematics and scientific work, including 97.6% on FrontierMath Tier 4, 96.0% on GPQA Diamond, and 64.6% on Terminal-Bench Science 0.1. OpenAI also says the model helped improve published bounds for both short and large gaps between prime numbers.

Evaluation	GPT-6 Astra	GPT-5.6 Sol	Claude Fable 5.1	Claude Opus 5
Terminal-Bench Science 0.1	64.6%	22.4%	52.6%	30.0%
FrontierMath Tier 4	97.6%	83.0%	87.8%	73.2%
GPQA Diamond	96.0%	94.6%	93.7%	93.7%
HealthBench Professional	63.4%	60.5%	58.1%	56.4%

OpenAI-reported results. Cybersecurity evaluations shown here used models without production safeguards. The chart is redrawn from the GPT-6 Astra launch article.

The practical shift is the combination of reasoning and software use. A research model can inspect data in specialized tools, write and run code, generate plots, test an idea, and help a researcher decide what to investigate next.

That does not make the model an independent scientist. Proofs still need verification, experiments need reproducibility, and conclusions need domain experts. It does make the useful unit of assistance much larger than answering a technical question from memory.

Context, price, and availability

GPT-6 Astra is initially rolling out to a limited set of organizations. OpenAI says access will expand over the following days to ChatGPT Plus, Pro, Business, and Enterprise plans, the OpenAI API, and AWS. Enterprise administrators must enable it for their workspaces at launch. Pro, Business, and Enterprise users will also receive access to GPT-6 Astra Pro.

Standard API pricing per one million tokens is:

Usage	Price
Input	$10.00
Cached input	$1.00
Cache writes	$12.50
Output	$50.00

Prompts above 272,000 input tokens cost twice the input and cache rates and 1.5 times the output rate for the entire request. Batch and Flex processing are priced at half the Standard rates. Fast mode offers up to twice the speed at twice the Standard price, though OpenAI documents restrictions for EU data residency.

The 1,050,000-token window is valuable, but it should not be treated as free storage. Long prompts can become expensive quickly, especially after the higher long-context rate begins. Retrieval, caching, and deliberate context selection still matter.

How I would evaluate Astra

The best test is a complete unit of work that your current model struggles to finish:

Give it a bug that crosses several services and requires browser or terminal verification.
Ask it to update a polished document or spreadsheet while preserving an existing template.
Interrupt a long run with a changed requirement and check whether it preserves the original constraints.
Compare reasoning efforts on quality, elapsed time, token use, retries, and human corrections.
Test legitimate security tasks to learn where safeguards pause or block the workflow.
Review whether its notes and final report make the full run easy to audit.

Track cost per accepted result , not only cost per token. Astra is expensive, but a higher token price can still be economical if the model finishes more work, uses fewer output tokens, and needs fewer restarts.

The practical takeaway

GPT-6 Astra is OpenAI’s clearest attempt yet to turn a frontier model into a reliable operator for end-to-end work. Its strongest improvements appear where reasoning meets an environment: navigating software, coordinating tools, preserving context, producing finished artifacts, and adjusting to new instructions without losing the task.

The release also shows the cost of that progress. Cybersecurity capability has reached a threshold that requires stricter access and live monitoring, while written reasoning has become harder to inspect in some adversarial tests.

Astra should be evaluated as a system, not a chatbot. The model, harness, tools, permissions, memory, and safeguards all shape the result. For teams already building long-running agents, that system-level improvement is the reason to test it.

Sources

Audacity 4: Rebuilding an Audio Editor Without Losing Its Muscle Memory

Vincent Tran — Fri, 04 Sep 2026 00:00:00 +0000

Audacity 4 is not a coat of paint on a familiar waveform editor. The application interface has been rebuilt on Qt, clips have become objects that can be selected and manipulated directly, project files now use the .aup4 format, and several long-standing tools have been replaced by context-sensitive behavior.

That is an unusually large change for software whose greatest feature may be familiarity. Audacity succeeds because people can install it, record or open a file, make a precise change, and export the result without first adopting a production system. Its interface grew over decades around that directness. Replacing the foundation risks disturbing thousands of small habits even when every individual redesign looks sensible.

The important question is therefore not whether version 4 looks modern. It is whether a mature desktop application can change its internal and interaction architecture while keeping the short path from sound to finished file intact.

The interface migration is an architectural change

Audacity 3 used wxWidgets for its cross-platform user interface. Audacity 4 moves the interface to Qt and QML, building substantial parts on the same Muse Framework used by MuseScore Studio. The project’s build instructions now call for Qt 6, recommend Qt Creator for QML work, and explicitly note the MuseScore foundation.

This matters beyond rounded controls and dark mode. A UI toolkit determines how an application lays out windows, renders at different display densities, routes keyboard focus, exposes controls to accessibility tools, and separates visual state from domain logic. Moving toolkits changes the seams at which all of those behaviors meet.

The visible Qt/QML interface sits on a broader migration of application services and editing boundaries; the audio engine remains the workhorse below it.

Qt gives Audacity native high-DPI rendering, dockable and floating panels, saveable workspaces, and a consistent theming surface. The shipped Modern, Classic, and Music workspaces are more than presets. They acknowledge that one permanent layout cannot serve a quick voice edit, a multitrack music session, and a long-time user’s muscle memory equally well.

The Classic option is especially important. Compatibility in mature tools is not limited to opening old files. Users also carry a spatial map: transport controls live here, meters sit there, and a repeated task follows a known sequence. A workspace that restores familiar positions lowers migration cost without forcing the new interface to remain frozen in the old architecture.

There is a trade-off for contributors and downstream packagers. The new build has a broad Qt and Muse Framework dependency graph, and the official instructions say some inherited MuseScore dependencies have not yet been cleaned up. A richer application framework makes features such as docking, command routing, and reusable controls easier to build, but it also expands the surface that must compile and behave correctly across Windows, macOS, and Linux.

Clips are finally the unit of editing

The more consequential user-facing change is the clip model. In Audacity 4, a clip can be clicked directly, Shift-clicked into a multi-selection, grouped with other clips, moved between compatible mono and stereo tracks, trimmed, or time-stretched together with the rest of a selection.

This sounds ordinary because most timeline editors train users to see a clip as a thing. Earlier Audacity workflows often made the time selection primary: first mark a range on the waveform, then choose what operation applies to the audio under that range. Version 4 makes both concepts explicit. A time selection describes an interval; a clip selection identifies the objects an edit should affect.

That distinction resolves several awkward operations. Moving three non-adjacent clips no longer requires arranging them into a special contiguous state. Grouping gives a persistent relationship instead of asking the user to reconstruct the selection. Trim and stretch handles reveal which transformations belong to the selected object. Alignment guides and sample-boundary snapping make placement rules visible at the moment they matter.

The new freedom also needs a clear collision rule. Audacity now allows one clip to be moved over another; the moved clip replaces the overlapped part instead of refusing the operation. This is efficient once learned, but destructive-looking behavior deserves care. Users should know whether hidden material remains recoverable, which clip has priority, and how Undo restores the previous state.

Direct selection makes the clip the object of the command; context and collision rules decide how that command changes the timeline.

The release also turns splitting into an explicit gesture: hold or press S, then click the waveform or clip header. Related commands cover split-cut, split-delete, splitting at silences, and splitting to a new track. Paste can create a track when needed and adapt compatible channel layouts. These are small reductions in ceremony, but quick editors are built from exactly this kind of accumulated friction.

Context replaces the old tool switch

Audacity’s separate Select, Envelope, Draw, and Multi-tool modes are gone. Their functions now emerge from context.

Zoom to individual samples and drawing becomes available. Show clip gain and the envelope appears as a visual layer. Hold S and a click becomes a split. Click a clip header and the clip becomes the target. The interface asks the pointer position, zoom level, visible layer, and modifier keys to determine what the user intends.

This reduces mode errors—the familiar experience of dragging while the wrong tool is active—but it can introduce discoverability errors. A toolbar announces the tools it contains. Context-sensitive behavior is quieter. It works beautifully after it becomes habit and can be invisible before that point.

Good contextual interfaces therefore need strong feedback. Cursors must change before the click. Handles must appear on selection. Sample points must become visibly editable at the required zoom. Shortcut hints and transition documentation must make hidden capabilities searchable. Audacity’s 3-to-4 transition guide performs part of that job by mapping old modes to new gestures rather than simply listing features.

The removal of Sync-Lock follows the same philosophy. Instead of keeping a persistent special mode, delete, cut, and paste have explicit variants for either leaving a gap or moving later material to preserve timing. The decision moves closer to the operation that needs it. That is easier to reason about locally, although users who relied on a project-wide Sync-Lock state must relearn the commands.

Realtime effects change the cost of experimentation

Audacity still supports destructive effects: select audio, apply the effect, and change the waveform. Version 4 also emphasizes realtime effect stacks on tracks and the master output. These effects are calculated during playback, remain adjustable, can be reordered, and are not written into the audio until export.

That changes editing from a sequence of commitments into a set of parameters. A noise treatment can be dialed back later. Compression can move before or after equalization. A master effect can shape the complete mix without rendering every source again.

The benefit is not merely Undo. Undo walks backward through history, potentially discarding later work. A realtime stack keeps the decision live in the current project state. The editor can revisit one parameter without rewinding unrelated edits.

The cost moves to playback. Realtime processing must finish each audio buffer before the device needs it. A large stack, expensive plugin, or small buffer can exhaust the timing budget and cause dropouts. Audacity must coordinate UI changes, project state, plugin hosting, meters, and the audio thread without allowing interface work to interrupt sound. The new track-header meters and consistent preset handling make this system easier to inspect, but the hard constraint remains: audio deadlines do not wait for the UI.

Supported plugin boundaries also changed. The 4.0 release notes list VST3, Nyquist, LV2 on Linux, and Audio Units on macOS, while the transition guide describes the formats currently available to users. The release explicitly says VAMP and LADSPA hosting, along with some analyzers and effects, are not yet present. Anyone whose workflow depends on a particular plugin should verify it before converting an active project.

Playback and recording become timeline-native

The playhead now remains visible during navigation and can be dragged. Playback can seek without stopping. Recording can begin at any point on the timeline and creates a clip there. Loop boundaries and selections have been revised so these different ranges are easier to control independently.

These changes make transport behave more like editing. The timeline is not just a picture underneath play and record buttons; it is the shared coordinate system for navigation, loops, selections, clips, and new recordings.

Audio Setup has also been rebuilt around real device behavior. It can show system-default devices, refresh lists, map channels, and follow operating-system device changes. Official Windows builds now include ASIO playback and recording. For users with compatible interfaces, that can mean lower-latency and multichannel access without compiling a custom build.

None of this removes the need to test a real setup. Audio applications sit at the meeting point of drivers, permissions, sample rates, channel layouts, plugins, and hardware clocks. A release note can promise that the path exists; only a rehearsal proves that a particular microphone, interface, and monitoring arrangement works together.

`.aup4` draws a one-way project boundary

Audacity 4 saves projects as .aup4. It opens .aup3 projects and converts them without changing the original, and it can import still older .aup projects. The converted work cannot be saved back to .aup3.

That one-way boundary is the correct place to be conservative. A project file is not an exported WAV or MP3. It contains editable structure: tracks, clips, hidden trimmed audio, effect configuration, appearance data, preview thumbnails, and undo-related state. Saving a new model into an old schema would either lose information silently or require the old application to understand concepts it never had.

The safe migration workflow is simple:

Keep the original .aup3 file and its backups.
Open a copy in Audacity 4 and save the converted .aup4 project under a new name.
Check clip positions, envelopes, effects, labels, sample rate, and project duration.
Export a reference mix and compare it with the version produced by Audacity 3.
Convert important projects before uninstalling the older application.

The official saving guide says an .aup4 file holds the editable project and distinguishes that from exported audio. That distinction is easy to overlook. An export is the deliverable; the project is the machinery required to change it. Migration testing must cover both.

A major release includes deliberate gaps

Audacity 4.0 does not pretend to be a strict superset of Audacity 3. The release notes identify Time Tracks, note/MIDI tracks, the Mixer, Macro Manager and scripting pipe, VAMP and LADSPA hosting, and play-at-speed as unavailable at launch. Sync-Lock and the old tool modes are intentionally replaced rather than scheduled for restoration. Some export, rendering, analysis, and effect features are also missing.

This is the uncomfortable arithmetic of a foundation rewrite. Waiting for perfect parity keeps the new architecture away from real workloads; releasing earlier gives users the architecture while asking some of them to remain on version 3. The honest approach is a visible compatibility list and a reversible trial.

For a quick two-track edit, version 4’s direct clips and cleaner interface may make the decision easy. For a scripted production pipeline that drives the old command pipe, the missing Macro Manager can be a blocker. For an accessibility-dependent workflow, the relevant question is not visual polish but whether keyboard navigation, focus order, screen-reader labels, and high-contrast behavior work for the exact task.

Version numbers do not decide those cases. Workflows do.

How to evaluate the upgrade

Treat Audacity 4 as a new editing environment that can import old work, not as an invisible point update.

Start with a disposable project representative of what you actually do. Record through the real device. Move and overlap clips. Exercise ripple-style deletion. Load the effects and plugins you depend on. Save, close, recover, reopen, and export. Test keyboard-only operation if shortcuts matter. If collaboration depends on project exchange, make sure every participant understands that .aup4 cannot return to version 3.

Then separate three kinds of compatibility:

Data compatibility: Does the old project convert with the expected structure and sound?
Workflow compatibility: Can you complete the job without a missing tool or automation path?
Operational compatibility: Do devices, plugins, latency, stability, packaging, and accessibility meet production needs?

Audacity 4’s achievement is not that all three answers are automatically yes. It is that the project has established a new platform on which those answers can improve: a modern UI stack, clearer editing objects, explicit command routing, flexible workspaces, realtime processing, and a project format able to carry the new state.

The release preserves Audacity’s essential proposition. Audio stays editable on the user’s machine, the waveform remains the center of the work, and the shortest useful path is still open, edit, export. Almost everything around that path has been rebuilt. The next test is whether the new foundation can remain as approachable as the old one while becoming easier to extend for the decade ahead.

Claude Fable 5.1: Frontier Intelligence Gets Cheaper to Keep Running

Vincent Tran — Wed, 02 Sep 2026 00:00:00 +0000

Anthropic released Claude Fable 5.1 on September 1, 2026. It is the company’s most capable generally available model, built for coding, research, and long-running work that can stretch across hours, applications, and large amounts of context.

The obvious story is that Fable got smarter. The more useful story is that it became cheaper to keep working.

Fable 5.1 keeps the same base API price as Fable 5: $10 per million input tokens and $50 per million output tokens. But cache reads now cost $0.25 per million tokens , down 75%. Anthropic estimates that this reduces the total cost of typical workloads by about 25%, and highly agentic workloads by as much as 45%.

That matters because long-running agents repeatedly revisit the same context. Their economics are shaped less by a single prompt than by how cheaply they can remember, inspect, verify, and continue.

What changed in Fable 5.1

Claude Fable 5.1 is aimed at work where mistakes compound over time:

Features that span an entire codebase
Multi-day coding and research sessions
Browser and computer-use workflows
Complex analysis across documents, charts, and tables
Unattended agents that need to recover from failures
Scientific problems that require tools, experiments, and iteration

Anthropic says the model is less likely to take shortcuts that produce superficially correct work. It is designed to find root causes, verify its own output, and keep its progress understandable during long tasks.

The launch also makes effort settings more important. Fable 5.1 defaults to High effort in Claude Code and Medium effort in Claude.ai and Claude Cowork. Anthropic reports that Low and Medium effort can match or exceed Fable 5 on several evaluations at a lower cost.

This gives teams a more useful control than simply choosing between a weak model and a strong one. The same model can handle routine steps economically, then spend more effort when a task reaches a genuinely difficult decision.

The benchmark gains are broad

Anthropic’s published results show improvements across coding, computer use, knowledge work, and scientific research:

Evaluation	Fable 5.1	Fable 5
Terminal-Bench-Science 0.1	52.6%	24.7%
Terminal-Bench 4.0	55.8%	42.0%
AutomationBench	31.4%	17.1%
CursorBench 3.2.0	73.4%	70.5%
Humanity’s Last Exam, with tools	65.0%	63.8%

The Terminal-Bench-Science result stands out: Fable 5.1 more than doubles Anthropic’s reproduced Fable 5 score. AutomationBench also shows a large jump, which supports the model’s positioning around multi-step business workflows rather than one-shot answers.

These are vendor-reported results, not a substitute for testing the model on your own work. Anthropic also notes that safety interventions affected some benchmark runs. On certain flagged tasks, the model received a zero or the request was completed by an Opus fallback. The exact harness and safeguard behavior are part of the result.

Cache pricing is the real agent upgrade

The 75% cache-read price cut is easy to overlook next to the benchmark table, but it may have the largest production impact.

An agent working on a large repository may repeatedly reuse system instructions, tool definitions, source files, earlier decisions, and test output. Without caching, every turn pays to process that context again. With cheap cache reads, the cost shifts toward the new work being done rather than the history required to do it coherently.

That changes which tasks are practical to delegate. A two-minute code edit will not benefit much. A six-hour investigation that repeatedly checks the same codebase might.

The right metric is therefore not price per token. It is cost per completed task. Fable 5.1 is still expensive at the token level, but it may be cheaper when a stronger model uses fewer tokens, needs fewer retries, and reads most of its context from cache.

Fable and Mythos are still the same model underneath

Anthropic launched Claude Mythos 5.1 alongside Fable 5.1. The two use the same underlying model but have different safeguards and access rules.

Fable 5.1 is generally available. Mythos 5.1 is limited to vetted cybersecurity and life sciences users through trusted-access programs. Its more permissive safeguards are designed for work that the public Fable model may block or route elsewhere.

For most developers, Fable 5.1 is the model that matters. But the split explains some behavior that would otherwise look inconsistent: a model may be capable of a task while the product deliberately restricts how that capability can be used.

Cybersecurity safeguards should interrupt less often

The original Fable 5 launch made refusals and fallbacks a major integration concern. Fable 5.1 tries to make those controls more precise.

Anthropic says its updated cybersecurity safeguards produce about 60% fewer interventions per Claude Code session than the safeguards used with Fable 5. Fable 5.1 can now identify software vulnerabilities for defensive work. Tasks such as exploit generation, penetration testing, and binary-based vulnerability scanning may still be routed to an Opus model.

Biology safeguards have also been tuned. Anthropic says they fire 85% less often on benign elementary biology and medical questions than the original Fable 5 safeguards, while research and development work in the life sciences can still fall back to Opus.

In Claude’s consumer and business apps, those fallbacks happen automatically. API users need to configure the Fallback API. Production integrations should test that path explicitly instead of assuming every request will be handled by Fable 5.1.

The scientific work is a preview of a different kind of model

Anthropic devoted a large part of the release to scientific research. One example used Fable 5.1 to train a neural network that produced a new elevation map covering a third of Venus. According to Anthropic, the map reveals details at a scale of two to three kilometers instead of 10 to 20 kilometers and improves height accuracy by up to 25%.

Mythos 5.1 was tested on protein-binder design and GPU optimization for biology models. Anthropic reports that it produced high-affinity binders and accelerated seven open-source deep-learning models by up to 2.5 times with identical outputs.

These examples are not proof that an LLM can independently do science. They are evidence that the useful unit is becoming larger. The model is not only answering a scientific question; it is writing code, operating tools, running experiments, checking results, and producing an artifact that researchers can validate.

Data retention still needs a policy review

Fable 5.1 requires 30-day data retention by default for safety monitoring. That is not a minor implementation detail for teams working with source code, financial data, legal documents, or health information.

Anthropic is introducing Enterprise Frontier Safeguards , which keep customer data in infrastructure controlled by the customer while still applying automated misuse detection. The system will roll out in phases beginning later in 2026. Eligible enterprise customers can use Fable 5.1 with zero data retention until it becomes available.

Before upgrading, confirm the retention policy that applies to your account and deployment surface. A better model is not a drop-in replacement if it changes where sensitive context is stored or reviewed.

How I would evaluate the upgrade

I would not start with a generic chatbot comparison. Fable 5.1 is designed to separate itself on long, difficult work, so test it there:

Give it a bug that crosses several services and requires root-cause analysis.
Run a code review that includes architecture, tests, and performance concerns.
Compare Medium and High effort on the same task.
Measure total tokens, cache reads, retries, elapsed time, and human corrections.
Test safety fallback behavior with legitimate security-related prompts.
Check whether the final report makes a long run easier to audit.

The most important question is not whether Fable 5.1 writes a better first answer. It is whether it can finish a larger unit of work with fewer interventions and enough evidence that a human can trust the result.

The practical takeaway

Claude Fable 5.1 looks like a refinement of Anthropic’s frontier-model strategy rather than a new tier. The public model gets stronger, its safeguards become less disruptive, and the cost structure improves specifically for context-heavy agents.

That combination is more meaningful than a benchmark win by itself. Long-running AI systems do not fail only because the model is not intelligent enough. They fail because context becomes expensive, tools go wrong, safeguards trigger unpredictably, and humans cannot tell what happened during the run.

Fable 5.1 addresses each of those pressures. Whether it does so well enough for your workload is something only a real evaluation can answer. But if Fable 5 was already close to useful, the 5.1 release is worth testing now.

Learn more

How RuneScape Turned 56k Limits Into a Multiplayer Protocol

Vincent Tran — Wed, 02 Sep 2026 00:00:00 +0000

In 2004, a browser could hold an inhabited 3D world on the far side of a telephone line. RuneScape did not make that possible by finding one miraculous compression algorithm. It made thousands of small agreements between the client and server, then stopped sending facts that both sides already knew.

The result is easiest to understand through one ordinary action: click the tile immediately north of your character. In the protocol examined by James Monger from a decompiled 2004 client, that request costs seven bytes. After the server accepts the movement, a nearby player can learn about it through a scene update of roughly nine bytes. Sixteen application bytes complete the useful round trip.

Those figures are not the whole cost of TCP, nor are they a universal measurement for every RuneScape revision. They are a clean window into the design. The client finds paths locally. The server validates them against its own collision map. Both sides retain a synchronized model of the visible world. High-frequency state is encoded in individual bits, while larger, rarer detail records stay byte-aligned so the server can cache and copy them.

This is more than nostalgia for heroic byte shaving. It is a practical example of choosing a protocol around its actual value ranges, repetition patterns, latency model, and compute budget.

Start with the real constraints

A 56k modem’s advertised rate was measured in kilobits, not kilobytes. After line conditions and protocol overhead, treating the downstream budget as roughly 5 KB/s is a useful planning number. Upstream was tighter. A crowded scene, chat, combat, inventory changes, map loading, and control traffic all had to share it.

RuneScape 2 also ran as a Java applet. The sandbox was valuable to users because downloaded code could not freely inspect the machine. It constrained the network design at the same time. Oracle’s archived applet security documentation describes sandboxed applets as able to connect back to their origin while being blocked from arbitrary third-party hosts and native libraries. RuneScape’s game traffic therefore used a regular TCP connection rather than a custom native UDP stack.

The third constraint was deliberate: the game world advanced in cycles of roughly 600 milliseconds. A command that arrived just before the next cycle might run almost immediately. One arriving just after could wait nearly a full tick. Once that rhythm was part of the game, reducing a client flush from tens of milliseconds to a handful did not transform the response time. The worthwhile optimization target was bandwidth.

That distinction matters. A team can spend months optimizing a layer that is hidden under a larger scheduling quantum. RuneScape’s protocol was shaped around the bottleneck that remained visible: the number of bytes multiplied across every player and every tick.

A click begins as local computation

The browser already had a collision map for the loaded area. When the player clicked a destination, the client ran a breadth-first search locally and constructed a route. It did not upload a continuous stream of joystick positions, and it did not send every traversed tile.

The walk request carried:

one opcode byte identifying the operation;
one byte giving the variable body length;
two 16-bit values for the first waypoint’s absolute coordinates;
two signed bytes for each later waypoint, expressed as an offset from the first; and
one byte for the Ctrl-key movement modifier.

For a single step, there are no additional waypoint deltas. The body is five bytes, and the opcode plus length marker bring the packet to seven.

Longer paths stay compact for two reasons. First, later waypoints are deltas, so each axis needs one byte instead of two. Second, the path contains corners rather than every tile. Ten unobstructed tiles in a straight line still need only the endpoint. The server knows the starting position and owns an equivalent collision map, so it can reconstruct and validate the intervening movement.

This is semantic compression. The protocol is not trying to squeeze an arbitrary coordinate stream after it has been produced. It changes what is produced. A path is represented by the smallest set of decisions needed to recreate it.

The browser computes a proposal, the server validates authoritative state, and observers receive only the resulting delta.

The trust boundary is important. Local pathfinding is not permission to dictate a position. It is a compact proposal. A modified client can invent waypoints, but the server can reject movement that conflicts with its own map or rules. Compute can move to the edge without moving authority with it.

The tick turns time into a batch

On each server cycle, the relevant work followed a simple order: read inbound packets, process players and queued actions, construct player updates, then flush outbound packets. NPCs, logins, and other systems added more stages, but the visible state transition retained that read-do-write shape.

The tick does three useful things for the protocol.

First, it gives the server a consistent boundary for resolving simultaneous actions. Second, it batches many small changes into one update per observer instead of emitting a new message for every property mutation. Third, it bounds how often unchanged state must be acknowledged.

The price is equally real. A 600 ms quantum is perceptible. Modern action games often hide delay with prediction and reconciliation; RuneScape made the tick part of combat timing, skilling, and movement. Players learned its rhythm. Once game rules, animations, and content depend on that cadence, reducing it becomes a product redesign rather than a server setting.

The lesson is not that slow ticks are universally good. It is that batching frequency belongs in the product model. If the experience can tolerate a coarser clock, the system gains a natural place to coalesce work. If it cannot, a compact wire format alone will not rescue responsiveness.

Every client keeps a mirror of nearby players

The crucial bandwidth saving appears on the way back. A client does not wait for the server to resend complete player objects. It retains a list of nearby players with their last-known locations, appearances, animations, and chat state. The server’s update packet patches that mirror.

This makes the most common message almost free: nothing changed.

The composite player update begins in bit-access mode. For the local player, a single zero bit says there was no movement and no queued detail change. If the player walked, the record uses an update bit, a two-bit movement type, a three-bit direction, and a one-bit flag indicating whether a detailed block follows. Seven bits describe the step.

The same approach scales across already known neighbors. The packet writes an eight-bit count and then, for each tracked player, one bit indicating whether anything changed. A static crowd of forty therefore costs 48 bits, or six bytes, before any uncommon detail blocks. Eight idle players fit in one byte rather than eight.

This only works because ordering is shared state too. The server and client agree on which tracked player occupies each position in the list. A zero bit does not carry an identifier or schema. Its meaning comes from the client’s existing mirror and the fixed decoding procedure.

Stateful protocols are powerful precisely because they do not repeat context. They are also operationally demanding. Lose the shared baseline, decode with a mismatched revision, or apply updates in the wrong order and the compact message becomes ambiguous. The bandwidth win creates obligations around sequencing, resynchronization, compatibility, and testing.

Relative coordinates shrink the world to the viewport

A player standing somewhere in the RuneScape world needs coordinates large enough to address thousands of tiles. Two 16-bit axes consume 32 bits. A newly visible player, however, cannot be thousands of tiles away. They are near the observer by definition.

The protocol exploits that narrower domain. A new-player record uses an 11-bit player identifier, one detail flag, one teleport flag, and five signed bits for each coordinate offset. Five bits encode values from -16 through +15, enough for the visible neighborhood. Position falls from 32 bits to 10.

The coordinate system is temporarily recentered on the observer. This is a broadly useful technique:

a map client can send movement relative to the current tile;
a time-series codec can store deltas from the previous sample;
an editor can describe an operation relative to the current document revision;
a replicated simulation can encode entities relative to an area-of-interest origin.

The saving comes from proving that the active domain is smaller than the global one. If an object can only be visible within 15 tiles, spending enough bits to place it anywhere on the planet is waste.

The sentinel at player ID 2047 applies the same reasoning to list termination. One otherwise unused value means “no more players,” so the stream does not need a separate length field for that section. Good binary formats repeatedly look for values the domain cannot produce and assign them protocol meaning.

One packet, two representations

It would be tempting to bit-pack everything after seeing these gains. RuneScape did not. After local movement, tracked neighbors, and new arrivals are decoded, the reader aligns to the next byte and processes detailed updates conventionally.

Those blocks can contain facing direction, animation, chat, hits, graphical effects, forced movement, equipment, colors, combat level, and other appearance data. An appearance record alone can occupy roughly 44 to 80 bytes. A flag byte says which categories are present. A marker in that first byte buys a second flag byte only when one of the rarer high flags is needed.

The packet changes representation where the scarce resource changes from downstream bytes to server-side assembly work.

Why stop packing when the records become larger? Because size alone does not determine whether bit packing pays.

The early fields have enormous repeated slack. “No change” needs one bit but would consume a whole byte in a byte-oriented structure, and it occurs for many players every cycle. Movement direction has eight possibilities, so three bits are sufficient. The saving repeats across the whole visible crowd.

Detailed records have a different shape. A target ID already occupies a complete short. An animation ID and delay are real fields rather than tiny defaults. More importantly, these blocks are uncommon because the earlier bits gate them. There is no crowd-sized multiplier.

Byte alignment also enables reuse. The client caches appearance buffers, and a server can construct a changed appearance once and splice the same bytes into updates for multiple observers. A byte-aligned blob is position independent. If it started at an arbitrary bit offset, every insertion could require shifting and masking based on everything written before it. A few saved wire bits would consume more server CPU across a large fan-out.

The packet therefore optimizes two resources in one message. Its front half spends modest compute to protect dial-up bandwidth. Its back half preserves alignment so expensive detail work can be cached and copied.

The opcode cipher protected structure, not content

After login, packet opcodes passed through ISAAC, Bob Jenkins’s stream-oriented pseudorandom design. The client and server maintained separate streams for each direction, seeded from shared values with a small transformation separating the inbound and outbound sequences.

Only the opcode was enciphered. The body was not confidential. This was an obstacle for packet parsers and unofficial clients, not modern transport security. Without the decoded opcode, a reader did not know which packet schema or length rule to apply, so the remaining bytes were harder to frame. Revisions also shuffled field order, changed endianness, negated bytes, and added constants as anti-cheat friction.

That distinction deserves precision. Obfuscating message boundaries can raise the cost of reverse engineering, but it does not provide the authenticity, integrity, and confidentiality expected from TLS. The 2004Scape Client2 project exists because determined preservationists could source-port the original Java behavior despite those measures. Its maintainers are explicit that their work is a port from recovered client behavior, not leaked Jagex source.

Shared knowledge is the real compression dictionary

The protocol is small because the two programs were designed as halves of one runtime:

Both have the collision map, so paths can be sent as corners and checked independently.
Both retain the visible-player list, so a one-bit flag can modify an implied record.
Both understand the viewport, so local offsets replace global coordinates.
Both compile the same update-field table, so a bitmask replaces a self-describing schema.
Both follow the same tick order, so many events can become one deterministic state delta.

General-purpose APIs usually carry more description because their clients evolve independently. Field names, type tags, resource identifiers, version negotiation, and explicit lengths buy flexibility. RuneScape traded much of that flexibility for density.

That trade was rational for a first-party game client shipped alongside its server. It would be dangerous to copy blindly into a public platform. A tightly coupled binary protocol requires coordinated rollout, strong golden tests, careful revision handling, and a recovery path when mirrors disagree. An undocumented client assumption is not free merely because it does not cross the wire.

The preservation story makes this cost visible. Early game versions are incomplete historical artifacts. The 2004Scape server project describes itself as an emulator reconstructed without original server source, while the RuneScape Archive Project collects surviving clients and caches. When a protocol’s schema lives mostly in two matching binaries, losing either side also loses documentation.

Applying the design today

Modern bandwidth is larger, but the multipliers are larger too. Multiplayer simulations, collaborative editors, market feeds, IoT fleets, and mobile applications still pay for fan-out, battery, radio wakeups, serialization, and server assembly. The useful principles survive the modem.

Model the common case first. Measure what happens most frequently, then make that state cheap. If 98 percent of entities do not change during an interval, optimize the unchanged marker before compressing the rare full record.

Narrow the domain before choosing a type. Global identifiers and coordinates may be unnecessary inside a scoped list, viewport, shard, or session. Prove the local bounds and encode those.

Send decisions, not derivable steps. When both ends have deterministic inputs, transmit route corners, operation parameters, or a compact seed rather than the entire derived result. Keep validation authoritative.

Batch on a product boundary. A tick, animation frame, transaction, or document revision can turn scattered mutations into one ordered delta. Choose the cadence from user experience, not only infrastructure convenience.

Switch formats when the economics change. Bit packing is valuable where slack is small and repeated. Byte alignment, fixed records, or a conventional serializer may win where fields are large, rare, cached, or frequently inspected.

Budget server fan-out, not only packet size. A representation that saves two bytes but forces a custom bit shift for every observer may lose at scale. Count encoding work, allocations, cache reuse, and copies alongside wire bytes.

Design resynchronization before launch. Stateful deltas need sequence numbers, snapshots, revision negotiation, or another way to rebuild the baseline. The smaller the incremental message, the more it depends on that baseline being correct.

RuneScape’s elegant result was not “seven bytes” by itself. It was a system in which seven bytes were sufficient because computation, authority, visibility, order, and cached state had already been placed deliberately. The modem forced discipline, but the enduring lesson is architectural: the cheapest fact to transmit is the one both sides can safely derive.

How Autocomplete Searches 240 Million Domains Before Keyup

Vincent Tran — Tue, 01 Sep 2026 00:00:00 +0000

The fastest request is not always the one that finishes first. Sometimes it is the one that begins before the user starts waiting.

Wirewiki’s domain autocomplete is built around that distinction. Its index covers roughly 240 million names, the application runs on one server in Europe, and every uncached request travels through Cloudflare, Nginx, and an API. Yet for the system’s author, suggestions were ready before key release at the 99th percentile of his typing sample.

The headline number is “0 ms,” but no packet crosses a network in zero time. The measurement starts at keyup, when the interface owes the user a visible answer. Work begins earlier, at keydown, and the response includes not only matches for the current prefix but prepared matches for every possible next character. When the next key arrives, the browser usually selects an answer it already has.

That is the first half of the design: move work into time the user is already spending. The second half makes the speculation affordable. A small, popular “head” stays in an in-memory trie. A much larger “tail” lives in delta-compressed, memory-mapped blocks on SSD. The API searches the head first, touches the tail only when needed, and returns the eight most useful names.

Together, those choices form a practical lesson in perceived performance. Make the deadline explicit, predict a bounded amount of likely future work, and give each part of the data set a representation that matches how often it is touched.

Zero milliseconds is a product definition

Latency needs two timestamps. Backend dashboards usually choose request received and response sent. Network tools measure round-trip time. A person using autocomplete experiences a different interval: the time between completing an input action and seeing the interface react.

For this design, the clock begins when a key is released. If suggestions are ready by then, measured wait is zero even though the browser, network, and server have already done real work.

The browser starts a request on keydown. Suppose the current text becomes wi. The API returns the best matches for wi, plus separate result lists for wi-, wi., wi0 through wi9, and wia through wiz. If the next key is k, the browser can take the prepared wik branch from its cache instead of waiting for another round trip.

The network is not instantaneous. It completes inside the interval between early input events and the moment the interface must paint.

The browser keyup event is fired when a key is released. That makes the measurement concrete, but it is not universal human truth. Touch keyboards, paste, speech input, input method editors, accessibility tools, and programmatic changes do not all follow the same simple physical-key sequence. A production implementation still needs an input-driven correctness path. Key events are an optimization opportunity, not the only source of state.

The author’s test involved typing 100 domain names at a reasonably fast pace. The 99th-percentile interval from one key press to the next release was 121 ms. That became the working end-to-end budget.

At 60 Hz, a display produces a new frame every 16.7 ms. Rendering within the next frame can add a little scheduling slack, but not much at the tail. The important number is therefore not an abstract “fast API” target. It is: can the complete path finish before the next key release for almost every measured interaction?

Speculation is cheap when the future is bounded

Prefetching can easily become waste. Search systems with a large alphabet, rich filters, or long result objects might multiply bandwidth by dozens of branches that are never used. Domain autocomplete has unusually helpful constraints.

Wirewiki uses 38 next characters: a-z, 0-9, hyphen, and dot. With eight suggestions for the current prefix and eight for each possible continuation, one response contains at most 312 domain names:

(38 possible next characters + current prefix) × 8 suggestions = 312 names

The uncompressed response is at most about 5 KB in the author’s measurements and roughly 2.5 KB over the wire after compression. This is deliberate overfetching, but it is capped. The client exchanges a few kilobytes for the chance to remove an entire future round trip.

That trade works because the response contains small strings, the branch factor is fixed, and typing provides immediate evidence about which branch will be used. Apply the same pattern to product cards with images and it could be ruinous. The general rule is not “prefetch everything.” It is prefetch a small, bounded set whose cost is lower than the delay it can hide.

Client caching also needs discipline:

Cache entries must be keyed by the exact normalized prefix and query options.
Stale requests should be cancelled with AbortController or ignored by sequence number, so an older response cannot replace newer suggestions.
Backspace can often reuse a parent prefix already held in memory.
Composition events need special handling so an incomplete IME sequence is not treated as committed input.
Result lists should remain accessible with correct combobox semantics, keyboard selection, and screen-reader announcements.

Speculation changes when work happens. It must not change which input wins.

Popularity and completeness need different structures

A single data structure is rarely ideal for both the most popular million domains and the other hundreds of millions. The first group is small enough to keep hot and important enough to deserve the fastest path. The second group provides completeness, but most names will rarely be requested.

Wirewiki builds its popular head from Tranco, a research-oriented ranking of one million domains. Tranco combines multiple source lists over a 30-day window to improve stability and resistance to manipulation; its methodology also documents the biases in each underlying source. That makes it more useful than treating any one traffic list as an unquestionable measure of popularity.

The long tail comes mainly from generic top-level-domain zone files. ICANN’s Centralized Zone Data Service provides a common place to request zone files from participating registries. It covers many gTLDs such as .com, .net, and .org, but it does not provide the same broad access to country-code TLDs. Popular ccTLD names still appear through Tranco, while certificate-transparency logs and web archives are possible future sources for broader coverage.

This data split is semantic before it is technical:

The head answers “what are people most likely trying to reach?”
The tail answers “does a matching active name exist even if it is obscure?”

Autocomplete needs both. A popularity-only index feels fast but incomplete. An alphabetical list of everything can return obscure names ahead of the destination a person probably intended.

The head: precompute the answer at every prefix

The top one million names live in a character trie. Each edge represents the next character and each node represents a prefix. A lookup walks the characters the user typed, so its cost grows with the query length rather than the total number of domains.

The more important optimization is stored at the nodes: every prefix already has its top eight suggestions. A request for wik does not descend through all matching names, gather candidates, and sort them on demand. It reaches the wik node and reads the answer prepared when the index was built.

That shifts work from request time to build time and trades memory for predictable latency. It is a strong fit because:

The popular set changes much more slowly than users type.
Eight results are enough for the interface.
Every query needs the same operation: retrieve the best completions for a prefix.

The complexity is often written as O(length of prefix). More usefully, the request path is a short chain of dependent memory reads with no scan proportional to the million-name corpus and no per-request ranking pass.

The tail: a small directory over compressed blocks

Keeping 240 million strings in ordinary heap objects would spend heavily on pointers, allocation metadata, string headers, and repeated prefixes. The tail instead uses a sorted, delta-compressed file divided into fixed blocks of 256 names.

A 27 MB in-memory directory identifies the block that may contain a prefix. The API binary-searches that directory, then scans one small block. Because adjacent sorted domain names tend to share leading characters, delta compression stores the common prefix once and records only the changing suffix for later entries.

The complete 240-million-name data set occupies about 2.5 GB on disk in the author’s implementation. The file is memory-mapped, so the program can address it like memory while the operating system loads pages on demand. Linux readahead brings file content into the page cache before every byte is explicitly requested, and it avoids repeating I/O for pages already present; the kernel’s memory-management documentation describes that mechanism. Hot tail blocks naturally remain resident, while cold blocks cost SSD access only when needed.

The head spends RAM on predictable popular lookups. The tail spends a small directory, compact SSD storage, and page-cache locality on completeness.

The tail lookup is described as O(length of prefix × log number of domains), followed by a bounded block scan. Both query length and corpus size are capped in the deployed system, so the practical goal is not an asymptotic breakthrough. It is a narrow worst-case path: one directory search, one block, and at most 256 decoded names.

Fixed-size blocks are the quiet hero. A huge compressed stream might achieve a slightly better ratio but require decoding from a distant checkpoint. Very small blocks add directory overhead. A block of 256 names limits work and gives the page cache a useful chunk to retain.

Search the head first, use the tail to fill gaps

The two indexes are not peers. Popular results should always win. The API searches the in-memory trie first and consults the tail only when the head cannot fill the result list. It then deduplicates and preserves rank order.

That order encodes product policy directly into the query plan. A popular domain that matches a prefix must not be displaced by an alphabetically earlier but unknown registration. The head provides relevance; the tail provides recall.

There is a broader pattern here:

Layer	Optimized for	Representation
Browser	Next interaction	Small speculative prefix cache
Popular head	Relevance and latency	In-memory trie with precomputed top eight
Long tail	Coverage and density	Sorted delta-compressed blocks on SSD
Operating system	Locality	Memory mapping, page cache, and readahead

Each layer predicts at a different horizon. The browser predicts the next character. The trie predicts which names matter for a prefix. The page cache predicts which nearby disk pages will be touched again.

The API became cheaper than the network

The author generated 720,000 keystroke queries from 60,000 simulated domain-name typing sessions and replayed them open-loop: requests were fired at a fixed rate rather than waiting for earlier responses. That matters because closed-loop load tests can accidentally reduce pressure when the server slows down.

Most API-only requests completed within 2 ms. At 1,600 requests per second, Nginx plus the API stayed within 15 ms at p99 in the reported production-server test. The benchmark also exercised the end-to-end route through Cloudflare.

Those are the author’s measurements, not an independent benchmark, and the workload is shaped like his own product. Still, the ordering of costs is instructive. Once index lookup falls to a few milliseconds, the network dominates. Further micro-optimization at the origin cannot recover 100 ms of geographic round-trip time.

In practice, end-to-end autocomplete latency was roughly the browser-to-origin round trip through Cloudflare plus another 10 ms. Cloudflare can absorb repeated traffic and cache hot requests, but it cannot repeal distance for a miss.

The asterisk is geography

The single origin is in Europe. For users in the United States, the author observed an additional 100–200 ms—enough to exceed his 121 ms p99 typing budget. The system can feel instant locally without delivering the same tail latency globally.

Multiple regional replicas plus geographic routing would reduce that distance. The read-only index is a friendly replication workload: build an immutable artifact, distribute it, and swap versions atomically. The hard parts would be operational rather than algorithmic—deployment, health checks, routing, observability, cache behavior, and keeping measurements comparable across regions.

Wirewiki stops before that complexity because autocomplete is a feature, not currently a standalone business. This is sound engineering restraint. The goal is not the lowest number a distributed system could possibly achieve. The goal is the best experience worth operating for the product that exists.

The asterisk therefore improves the lesson. “P99 0 ms” is true for a specific definition, client behavior, typing sample, and geography. Performance claims become useful when their boundaries are explicit.

A repeatable design process

This system can be reduced to six decisions that apply beyond domain search.

1. Define the human deadline

Choose the event after which delay becomes visible. It may be key release, pointer release, viewport entry, or the opening of a panel. Measure from that boundary, while still recording real end-to-end time separately.

2. Look for work that can begin earlier

Hover, focus, keydown, partial input, and navigation intent can create safe speculation windows. Start only work that remains correct if the prediction is wrong.

3. Bound the speculative bill

Estimate branch count, response bytes, server work, cancellation rate, and cache reuse. Prefetching is a budget, not a ritual.

4. Split data by access frequency

Do not force the hot million and cold hundreds of millions through the same representation. Give the head more memory and precomputation; give the tail density and bounded access.

5. Make the slow path narrow

A tail lookup should touch one small directory and one small block, not wake an unbounded scan. Fixed work is easier to reason about at p99.

6. Stop when another layer dominates

When network distance costs two orders of magnitude more than lookup, optimize placement or accept the boundary. Shaving microseconds from the trie is no longer the highest-value move.

Instant interfaces are scheduled, not magical

This autocomplete does not defeat latency. It schedules around it.

The browser borrows time from the physical act of typing. The response speculates over a fixed 38-character future. The in-memory trie makes popular queries a short prefix walk. The compressed block index keeps 240 million names affordable. Memory mapping lets the operating system decide which tail pages deserve RAM. Finally, the product accepts that one European server cannot deliver the same p99 experience everywhere.

That stack is more interesting than any single data structure. Perceived speed emerges when client timing, payload shape, ranking policy, storage layout, operating-system behavior, and geography agree on the same deadline.

The useful question is not “how can this API return in zero milliseconds?” It is: what must already be true when the user expects the next frame?

Sources

What CPython's Official RISC-V Support Actually Guarantees

Vincent Tran — Mon, 31 Aug 2026 00:00:00 +0000

Python could run on RISC-V before August 2026. Linux distributions shipped it, developers built it, and architecture-specific patches had been landing for years. What changed when CPython called RISC-V “officially supported” was not the sudden appearance of a working interpreter. The change was a maintenance contract.

The riscv64-unknown-linux-gnu target now appears in PEP 11 as a Tier 3 platform for both GCC and Clang with glibc. It has reliable buildbots and named maintainers. That means the core project continuously checks the platform and has people who have agreed to look after it. It does not yet mean that every regression blocks a merge or a Python release.

That distinction is the useful story. Architecture support in a large runtime is not a Boolean. It is a chain running from instruction-set definitions through compilers, operating systems, interpreter internals, continuous testing, binary packaging, and real applications. CPython has now made one important link durable. The rest of the Python ecosystem still has work to do.

“It builds” is not the same as “we support it”

A portable C program often reaches a new architecture surprisingly early. A compiler can translate most of the code, the operating system supplies familiar POSIX interfaces, and a developer can patch the handful of assumptions that fail. That produces a successful build. It does not ensure the next change to garbage collection, atomics, stack unwinding, libffi, profiling, or the experimental JIT will preserve that success.

PEP 11 exists because dormant platform code becomes a liability. Without machines that run the test suite and maintainers who understand the failures, the main branch can drift until the port is broken. Nobody knows whether an old conditional is still required, and ordinary refactoring may accidentally depend on x86-64 or AArch64 behavior.

Tiered support replaces the vague claim “Python runs here” with explicit obligations.

RISC-V has crossed into a maintained Tier 3 contract; Tier 2 is the next meaningful threshold.

At Tier 3 , a platform needs a reliable buildbot and at least one core developer as a contact. Failures do not block releases, and PEP 11 specifies no response deadline. This is where 64-bit RISC-V now sits, with Stan Ulbrych and Emma Smith listed for the GCC and Clang configurations.

At Tier 2 , a platform still needs reliable automation but must have at least two core maintainers. A break must be fixed or reverted within 24 hours, and a failing platform blocks a release. AArch64 Linux with Clang, Windows on ARM64, WASI, x86-64 macOS, and x86-64 Linux with Clang currently occupy this tier.

At Tier 1 , failures block releases and breaking changes may not remain on main. Responsibility belongs to all core developers, not only named platform specialists. The list covers the dominant release environments, including x86-64 Linux with GCC, AArch64 Linux with GCC, macOS on Apple silicon, and the principal Windows targets.

The tiers are not a score of processor quality. They describe how much project-wide disruption CPython is willing to accept to preserve a target. RISC-V entering Tier 3 means the port is no longer merely tolerated platform code. It has a documented place in CPython’s development process.

Why real RISC-V machines changed the equation

The decisive resource was not one more portability patch. It was dependable hardware.

The Python announcement credits the RISE Project with providing several RISC-V machines for buildbots and architecture-specific debugging. Those systems repeatedly build the current branch and run CPython’s test suite after changes land. A regression that would otherwise wait for a user report becomes visible to maintainers.

Cross-compilation cannot provide the same feedback. It proves that a compiler can emit a binary for another target; it does not naturally execute the full suite on that target. Emulation is excellent for bootstrapping and broad test matrices, but it can hide timing behavior, differ around kernel and hardware features, and make an already large test suite much slower. Native machines expose the software stack that users actually run.

RISC-V makes this especially important because it is a family of implementations, not a single chip. The unprivileged ISA specification defines a small base instruction set plus optional extensions. RV64I supplies the 64-bit integer base; common systems add multiplication and division, atomics, floating point, compressed instructions, vectors, and other extensions. Implementations can differ in microarchitecture and available extensions while presenting the same broad architecture name.

A runtime can be perfectly ordinary C at its center and still touch machine-specific seams:

Atomic operations and memory-ordering assumptions become critical in a free-threaded interpreter.
Stack walking, signal handling, and profilers depend on calling conventions and register definitions.
ctypes and extension modules depend on ABI details and foreign-function libraries.
Dynamic code generation needs a machine-code backend, instruction-cache synchronization, and unwind metadata.
Compiler optimizations can expose alignment or undefined-behavior bugs that another architecture never revealed.
Tests involving timeouts or concurrency can behave differently on slower cores.

One historical example is CPython issue #121138, where enabling Linux perf trampoline support caused a RISC-V build to stop at an explicit “unsupported target architecture” error. The core interpreter was not fundamentally incapable of running. A specialized observability feature had reached an architecture-specific boundary. That is typical porting work: the last few percent lives in debugging, packaging, performance, and operational tools rather than the language evaluator alone.

The feedback loop still starts too late

Buildbots give CPython the evidence required for Tier 3, but their timing matters. They generally test after a patch has merged. If a change breaks RISC-V, the main branch can remain broken until the builder reports the result and someone prepares a repair.

The next infrastructure step is to add RISC-V to pre-merge continuous integration. RISE’s runner service provides ephemeral Ubuntu jobs on native RISC-V hardware. A workflow can select ubuntu-24.04-riscv, compile the proposed revision, run tests, and discard the machine after the job. That gives the author feedback while the patch is still under review.

Buildbots establish continuous support; native pre-merge runners shorten the time between introducing and seeing a regression.

This is more than a speed improvement. Earlier feedback changes who can repair a problem. The author still has the patch in context and can amend it before unrelated changes accumulate. Reviewers can see the platform result beside the existing checks. Maintainers spend less time bisecting a failure that appeared after merge.

The RISE runner documentation describes an environment meant to resemble a standard GitHub Actions Ubuntu runner, with native GCC and Clang, containers, and common language toolchains. It is not a substitute for CPython’s long-lived buildbot fleet. It complements that fleet:

Pull-request CI protects the merge boundary.
Buildbots continuously exercise configurations, slow tests, and post-merge state.
Maintainers investigate architecture-specific failures.
Release policy determines whether a failure is advisory or blocking.

For Tier 2, all four parts must work reliably enough to support a 24-hour repair expectation and release-blocking status. Hardware availability is necessary, but the social commitment to respond is equally important.

A Python runtime is only the first layer

Installing pure-Python packages on RISC-V is usually uneventful: source files and bytecode are architecture-independent. The friction begins with native extensions.

Packages such as NumPy, cryptography libraries, image codecs, database drivers, and machine-learning frameworks often publish wheels containing compiled code. On a common x86-64 system, pip install downloads a matching wheel in seconds. When a project does not publish a RISC-V wheel, pip falls back to a source build or reports that no compatible distribution exists. The user then needs compilers, headers, system libraries, memory, time, and a build process that already understands the architecture.

The packaging foundation is improving. The manylinux project now lists an alpha manylinux_2_39_riscv64 image and a musllinux_1_2_riscv64 image. Its containers include multiple CPython versions and the tooling needed to produce policy-compliant wheels. cibuildwheel’s platform matrix contains RISC-V CPython build identifiers. The standardized manylinux_x_y_arch scheme lets a wheel declare the minimum glibc generation it expects rather than tying it to one distribution.

Those capabilities make publishing possible; they do not make it automatic. Every package with native code must decide to add the architecture, obtain native or emulated CI capacity, repair its dependencies, and upload artifacts. A scientific application may depend on dozens of compiled packages, so one missing wheel can push the entire installation down the source-build path.

This creates a practical support ladder for users:

Interpreter: Does CPython build and pass its own tests?
Packaging tools: Can pip, wheel tags, audit tools, and build images represent the target?
Foundational libraries: Are compilers, BLAS, OpenSSL, libffi, Rust, and other native dependencies healthy?
Published wheels: Do maintainers continuously upload RISC-V artifacts?
Applications: Do real workloads pass their own suites and meet performance expectations?

CPython’s Tier 3 milestone stabilizes the bottom of that ladder. It gives upstream package maintainers a more trustworthy runtime to target and makes failures easier to classify. It cannot promise that a random requirements.txt will install without compilation.

What developers can test today

The highest-value reports come from ordinary workloads, not only from rebuilding CPython.

On a 64-bit RISC-V Linux machine, developers can build the current CPython branch with the usual configure and make flow, run make test, and then exercise real projects. Testing with both GCC and Clang matters because PEP 11 lists separate configurations. So does recording the distribution, kernel, compiler, libc, CPU, and available ISA extensions. “Fails on RISC-V” is far less actionable than a reproducible command with a precise environment.

Package maintainers can add a native runner job without making it release-blocking on day one. Start with a scheduled or allowed-to-fail build, measure its duration and reliability, then promote it once failures are understood. For a C or Rust extension, verify more than import success: run the full suite, build a wheel, inspect its platform tag, install it into a clean environment, and test the installed artifact.

Performance work should follow correctness. RISC-V’s modular extensions create room for architecture-specific optimization, but a baseline binary must remain valid on the systems it claims to support. Dispatching to vector or crypto extensions requires feature detection and a safe fallback. Assuming that every riscv64 machine exposes the same extension set would trade portability for a benchmark win.

The most useful bug reports will cluster around boundaries:

free-threaded builds and atomics;
native extension compilation and linking;
profilers, debuggers, and stack unwinding;
JIT or executable-memory behavior;
wheel production and repair;
numerical libraries and vectorized kernels;
tests that are sensitive to timing or memory.

Reporting these upstream matters because Tier 3 has no automatic repair deadline. The platform becomes stronger when users supply failures that maintainers can reproduce and convert into regression tests.

What Tier 2 would mean

Promotion would not mean CPython suddenly runs twice as fast on RISC-V. It would mean regressions carry more project-level consequence.

To sustain Tier 2, RISC-V needs reliable builders, at least two core developers committed to the platform, a repair path that works within 24 hours, and enough confidence that failures can block a Python release without creating chronic instability. Pre-merge CI reduces that risk. Broader user testing supplies the unusual configurations that a small builder fleet misses. More maintainers distribute the response burden.

There is a useful precedent in WASI. PEP 11 records it as Tier 3 for Python 3.11 and 3.12, then Tier 2 beginning with Python 3.13. The transition happened because support became a maintained process with dependable tooling and people, not because a single patch flipped a switch.

RISC-V is now at the beginning of the same institutional path. The interpreter runs. The buildbots watch it. Maintainers are named. Native pull-request runners are being explored. Packaging images and wheel tooling exist. Each piece converts individual porting effort into infrastructure that survives the original contributor.

That is what “official support” is worth: not a badge on an architecture list, but a growing set of promises that can be tested.

Htmx 4: A Modern Runtime for Server-Driven HTML

Vincent Tran — Sat, 29 Aug 2026 00:00:00 +0000

Htmx has always made a deliberately unfashionable proposition: a server can return HTML, the browser can place that HTML into the document, and a useful application can emerge without duplicating the entire interface as client-side state.

Version 4 does not abandon that proposition. A button still needs little more than hx-post, a URL, and a swap rule. What changed is the runtime underneath. The request engine now uses fetch() instead of XMLHttpRequest; inherited behavior must be declared; HTTP errors can be rendered as ordinary HTML; morphing and multi-target responses are first-class; and extensions can consume streams without fighting the core.

That makes htmx 4 an unusual major release. Its public idea remains almost boringly stable while its internal model becomes more native to the modern browser. The result is not a new front-end framework so much as a sharper contract between HTML, HTTP, the DOM, and the server that owns application state.

The central idea is still hypermedia

A conventional client-rendered application often asks an API for data, stores that data in JavaScript, renders components, and then reconciles local state with the server. Htmx removes much of that middle layer. The server responds with the representation the user needs: HTML.

<button
  hx-post="/tasks"
  hx-target="#task-list"
  hx-swap="beforeend"
>
  Add task
</button>

When the button is activated, htmx gathers the request context, calls the server, parses the returned markup, and appends it to #task-list. The server remains responsible for validation, authorization, persistence, and presentation. The browser remains responsible for interaction, navigation, focus, and the document.

This is more than a shorter way to write fetch(). The attributes describe a hypermedia control: which action is available, where it goes, and how its representation should enter the current page. The response can contain links and forms that describe the next valid actions, just like a full document does.

Htmx 4 keeps that surface while reorganizing the lifecycle below it.

The browser sends context and receives a representation. Htmx coordinates the trip, but HTML remains the application protocol.

`fetch()` changes what the core can become

Htmx previously used XMLHttpRequest because it worked across an older browser landscape and exposed upload progress events that applications depended on. By 2026, that compatibility choice had become architectural debt. The htmx team rebuilt the request path around the promise-based Fetch API after experimenting with a smaller project called Fixi and with streaming HTML.

For an ordinary hx-get, the migration should be invisible. The important difference appears at the edges. Fetch uses standard Request, Response, headers, abort signals, modes, credentials, and streaming bodies. Those primitives make the request lifecycle easier to compose with async code and easier for extensions to intercept.

The new event model reflects that cleaner pipeline. Events now follow a predictable htmx:phase:action[:sub-action] shape:

Htmx 2	Htmx 4
`htmx:beforeRequest`	`htmx:before:request`
`htmx:afterRequest`	`htmx:after:request`
`htmx:beforeSwap`	`htmx:before:swap`
`htmx:afterSwap`	`htmx:after:swap`
`htmx:configRequest`	`htmx:config:request`

Every request event also receives a consistent context object. An extension no longer needs a loose collection of event-specific details to understand the source element, request configuration, response, and swap. Request completion has a finally phase, whether the operation succeeds, fails, or is cancelled.

Htmx also removed wrappers for browser functions that now have dependable native equivalents. htmx.addClass() becomes element.classList.add(), htmx.closest() becomes element.closest(), and htmx.remove() becomes element.remove(). This is healthy subtraction. A small library should not permanently carry convenience APIs once the platform has absorbed them.

Explicit inheritance makes locality visible

The largest migration change is not related to Fetch. It is the decision to stop inheriting most htmx attributes implicitly.

In htmx 2, a container could put hx-confirm, hx-target, or hx-headers on a parent, and descendant controls would acquire the behavior. That was concise, much like CSS inheritance. It could also make a button’s behavior impossible to understand by reading the button. A security header or destructive confirmation might come from an ancestor several templates away.

Htmx 4 requires the author to mark that reach:

<section
  hx-confirm:inherited="Delete this item?"
  hx-headers:inherited='{"X-CSRF-Token":"…"}'
>
  <button hx-delete="/items/42">Delete</button>
</section>

The :inherited suffix is not cosmetic. It tells a reviewer that the attribute is deliberately part of the descendants’ behavior. A child can use :append when it needs to extend an inherited selector or value instead of replacing it.

This change moves htmx toward locality of behavior : the closer a declaration is to the element it controls, the less hidden context a reader needs. Shared behavior is still possible, but its scope is advertised at the declaration site.

It also creates a real upgrade hazard. If a CSRF header previously lived on a layout container, the page may render normally after a version bump while child requests begin failing. The official upgrade checker searches templates and scripts for inheritance, old event names, removed attributes, and obsolete APIs. Treat its report as a starting point, then test the actual request paths.

Error pages are now useful fragments

Htmx 2 did not swap 4xx or 5xx responses by default. Htmx 4 swaps every HTTP response except 204 No Content and 304 Not Modified.

That default is a better fit for server-driven interfaces. Validation failure is still an application state, and the server often has the best information for rendering it. A 422 response can contain field errors; a 409 can explain a version conflict; a 500 can replace a panel with a recovery action. An error status should not force the response body to become invisible.

Htmx 4 adds hx-status when different status families need different destinations or swap rules:

<form
  hx-post="/account"
  hx-target="#account-card"
  hx-status:422="target:#errors swap:innerHTML"
  hx-status:5xx="target:#service-status swap:innerHTML"
>
  <!-- fields -->
</form>

The design consequence belongs on the server: error responses must be valid fragments for the target that will receive them. Status codes continue to carry HTTP meaning, while HTML carries the presentation and the next possible action.

One response can update several parts of the page

Server-driven applications frequently need to change more than the clicked element. Adding a message might append to a timeline, update an unread count, and replace a pagination control. Htmx has long supported out-of-band swaps, where specially marked elements in a response replace matching elements elsewhere in the document.

Htmx 4 adds a clearer tool: <hx-partial>. Each partial names its target and swap strategy explicitly.

<article id="new-message">The build finished.</article>

<hx-partial hx-target="#messages" hx-swap="beforeend">
  <article>The build finished.</article>
</hx-partial>

<hx-partial hx-target="#unread-count" hx-swap="innerHTML">
  <span>5</span>
</hx-partial>

The main response swaps first. Partials and out-of-band elements follow in document order. That ordering encourages each update to be independently meaningful instead of relying on a hidden side effect from an earlier DOM mutation.

This is a small but important form of response orchestration. The server can atomically describe the visible consequences of one operation without returning JSON and asking client code to distribute fields among components.

Morphing preserves the parts users are touching

Replacing innerHTML is easy to reason about, but it can destroy local browser state. An input may lose selection, an element may lose focus, a media player may restart, or a custom element may be recreated even though most of its structure did not change.

Htmx 4 includes innerMorph and outerMorph swap modes based on an improved Idiomorph algorithm. Instead of discarding the target subtree, a morphing swap matches old and new nodes and applies the smallest useful set of changes. Stable nodes can keep their identity and therefore retain browser-owned state.

<section
  id="profile"
  hx-get="/profile/edit"
  hx-swap="outerMorph"
>
  <!-- current profile -->
</section>

Morphing is not automatically superior. A simple fragment is often safest to replace wholesale. Morphing earns its complexity when the target contains live controls, custom elements, media, or third-party widgets whose identity matters. Htmx exposes selectors for skipping entire nodes or children during a morph, which helps protect stateful islands.

The broader pattern is useful: let the server own the desired HTML, but let the browser preserve the physical DOM objects that should survive the transition.

Streaming becomes an extension concern

Moving to Fetch gave htmx a better substrate for streamed responses, but the core does not force one streaming protocol on every application. Htmx 4 ships focused extensions for Server-Sent Events, WebSockets, and multipart responses.

The hx-multipart extension can consume multipart/mixed or multipart/parallel. Each part can carry HTML plus its own HX-* action headers. A server can therefore begin a response with an immediate placeholder, stream later sections as work completes, and target each piece without inventing a client-side message bus.

SSE remains a good match for ordered one-way server updates. WebSockets remain useful when both browser and server send messages. Multipart works naturally when one HTTP operation produces several representations. The architecture is modular: all three end at the same swap machinery.

That separation keeps the core small while making the extension boundary more powerful. Htmx 4 extensions register directly and can participate in request, response, and swap phases. They are loaded by including their scripts; hx-ext is gone. Sites can restrict the allowed extension names through configuration when they want an explicit boundary.

HCON gives attributes a small structured language

As attributes gained options, htmx needed a notation less noisy than embedded JSON. HCON—htmx Configuration Object Notation—supports space-separated key-value pairs, flag booleans, numbers, quoted strings, and dotted keys.

<meta
  name="htmx-config"
  content="transitions defaultTimeout:5000 sse.reconnect:true"
>

<button
  hx-get="/report"
  hx-config='credentials:"include" cache:"no-cache"'
>
  Refresh
</button>

JSON remains valid when a server already produces it. HCON is for handwritten markup: compact enough to scan, structured enough to avoid a growing collection of one-off parsers. The same notation appears in triggers, swap modifiers, request configuration, headers, values, and HX-Location.

`hx-live` handles the client state that remains

Hypermedia does not eliminate every local interaction. Dropdowns open before a request. Character counts change as a user types. Tabs, disclosure widgets, and temporary selections are often browser concerns.

The new hx-live extension provides a small DOM-oriented scripting layer for those cases. It includes a query helper, directional selectors, DOM utilities, async helpers, typed access to attributes and data, and reactive bindings such as :text, :class, and :hidden.

Its important constraint is philosophical: the DOM is the state store. A reactive expression reads nearby element state and updates nearby presentation. Durable application state still belongs on the server and still travels through hypermedia responses.

That makes hx-live a pressure valve rather than an invitation to rebuild a second application inside the browser. Use it for ephemeral interaction that would otherwise require repetitive event-listener code. When state must survive navigation, coordinate users, enforce permissions, or participate in transactions, send it to the server.

History now favors fresh documents over frozen DOM

Htmx 2 cached history snapshots in localStorage. Restoring those snapshots could also restore mutations made by unrelated scripts without restoring the JavaScript runtime state that produced them. The page looked alive but contained a fossilized DOM.

Htmx 4 removes that default cache. Back and forward navigation re-fetches the page and swaps the result into <body> or a designated history element. Correct HTTP caching can make the request cheap while still giving scripts a clean document to initialize.

Applications that truly need local snapshots can load hx-history-cache, which uses sessionStorage and makes the behavior explicit. Again, version 4 chooses an honest boundary: fetching a fresh representation is the default; local reconstruction is an optional capability with a name.

The migration is a behavioral audit

The safest upgrade is not a blind package replacement. It is a short audit of where behavior crosses markup boundaries.

Most pages keep their markup. The work is concentrated at implicit inheritance, event listeners, response policy, history, and extensions.

Start with a pinned version and run the checker:

npx htmx.org@4.0.0 upgrade-check -- ./templates

Then review the changes in an order that avoids ambiguous renames:

Rename old hx-disable—which meant “ignore this subtree”—to hx-ignore.
Rename hx-disabled-elt to the new hx-disable.
Add :inherited wherever a parent must continue affecting descendants, especially headers, confirmation, targets, and includes.
Update event names and replace removed JavaScript helpers with browser APIs.
Test 4xx and 5xx responses because they now swap by default.
Test hx-delete, which no longer includes enclosing form data unless requested with hx-include.
Test back/forward navigation, out-of-band ordering, timeouts, queues, and every installed extension.

There are temporary escape hatches. implicitInheritance can restore the old inheritance default, noSwap can restore the old error policy, and the htmx-2-compat extension restores several 2.x behaviors and event names. These are useful for staging, not for ending the migration. A compatibility layer that remains forever leaves the application with two mental models.

The release itself models similar caution. Htmx 4 is published as version 4.0.0, but the project is keeping the 2.x line under npm’s latest tag and 4.x under next until early 2027. That avoids silently upgrading sites that use an unversioned CDN URL. Production HTML should pin an exact version regardless.

A Go-native companion: ghtmx

Go teams interested in this server-driven model should also look at ghtmx, created by 0xgosu—the author of this blog. It is a compiled template engine, forked from templ, that treats htmx as a compile-checked language feature rather than a collection of unchecked strings.

Route-aware hx-* bindings resolve against actual Go handlers, so renaming a route can break the build at every affected template. Compile-time fragment declarations produce both inline and standalone render entry points, while declared events generate typed emitters for HX-Trigger. The runtime itself uses only the Go standard library.

The current library is pre-1.0, and htmx 4.0 support is being added now. Check the ghtmx repository and changelog before adopting it for an htmx 4 application, and pin the version while its language and generated-code surface are still evolving.

What htmx 4 is really optimizing

The obvious headline is Fetch. The deeper theme is explicitness.

Inheritance must say that it crosses a boundary.
Error bodies are visible representations unless configured otherwise.
Multi-target updates name their targets and swap rules.
History either fetches a fresh page or opts into a cache.
Extensions register directly and use a consistent lifecycle.
Browser APIs replace library wrappers where the platform is sufficient.

These choices reduce invisible behavior without requiring the application to move its state into a client framework. That is the balance htmx is trying to hold: capable interactions, server authority, and HTML that still explains what the page can do.

Htmx 4 will not make every interface simpler. A graphics editor, offline-first workspace, or deeply collaborative local model may need a richer client architecture. But many business applications are primarily navigation, forms, tables, validation, and server-owned workflows. For those systems, returning the finished representation can be simpler than synchronizing two state machines.

The most impressive part of htmx 4 is therefore what users do not have to relearn. The hypermedia control is still an element. The response is still HTML. The browser is still a browser. The new runtime simply makes that old architecture more at home on the current web platform.

How Tiny Rust Layout Choices Freed 100 TB of DNS Cache Memory

Vincent Tran — Fri, 28 Aug 2026 00:00:00 +0000

A byte is usually beneath the resolution of capacity planning. In a cache holding more than 250 billion entries, it is a line item: one extra byte per entry consumes over 250 GB across the fleet.

That arithmetic changes how software should be designed. A convenient Vec<T> is no longer just an API choice. A repeated domain name is no longer harmless duplication. The padding inside an enum, the size class chosen by an allocator, and the distance between two heap objects all become infrastructure decisions.

Cloudflare’s Big Pineapple platform—the Rust system behind 1.1.1.1, Gateway DNS, DNS Firewall, and other DNS services—recently applied that way of thinking to its cache. Five related changes cut the benchmarked footprint of an entry from 953 bytes to 420 bytes. Fleet-wide working-set memory fell by roughly 100 TB. The same layout also increased insert throughput by 43% and reduced lookup latency by 19%.

The interesting lesson is not simply “use less memory.” It is how to make a mature hot-path data structure smaller without turning every read into decompression work. The winning design kept the fields that need interpretation structured, encoded the bulk record data compactly, and arranged the common path so that it could often copy bytes directly into the response.

The cache is a second representation of DNS

A recursive resolver receives a question such as “what is the A record for example.com?” If the answer is already cached and its time-to-live has not expired, the resolver can answer without repeating the upstream resolution process.

The key identifies the question. It includes the queried name and record type, plus context such as authentication state and service-specific tags. The value contains metadata and the DNS resource records divided into answer, authority, and additional sections.

That division follows the DNS message model defined by RFC 1035: a header and question are followed by three lists of resource records. A first implementation naturally mirrors the protocol with Rust structures:

struct CacheEntry {
    created_at: Instant,
    ttl: Ttl,
    hits: u32,
    answers: Vec<Record>,
    authority: Vec<Record>,
    additional: Vec<Record>,
    // more metadata...
}

That is pleasant code. Each section has its own collection, each record is parsed into a typed enum, and callers can index or inspect fields directly. But this in-memory form is neither the compact DNS wire format nor a database page designed for density. It is a graph of headers, pointers, capacities, enums, and heap allocations.

The distinction matters: the representation that is easiest to build is not automatically the representation that should live for millions of lookups.

Big Pineapple fills from empty after startup. Once an instance reaches its configured entry count, it evicts older or less useful records to admit new ones. Cache size varies by location and traffic. EDNS Client Subnet can multiply entries because authoritative servers may return different answers for different client networks. Memory efficiency therefore affects both the number of answers a resolver can retain and the volume of upstream work it must repeat.

Measure the whole path, not just `size_of`

Rust’s size_of::<T>() is useful, but it cannot describe an object graph on its own. A 24-byte vector header may point to a much larger allocation. That allocation may reserve unused capacity. An allocator may round a 40-byte request into a 48-byte size class. Several individually small fields may force alignment padding into a containing struct.

Cloudflare built a benchmark around generated entries shaped like production traffic: roughly 56% A, 25% AAAA, and 19% variable-length records represented by TXT, with one to four records per entry. A custom allocator wrapper tracked the number and size of allocations. The benchmark also measured insert throughput and lookup latency so a lower byte count could not hide extra CPU work.

Synthetic measurements were only the first filter. Traffic mix, occupancy, allocator state, and non-cache process data all affect resident memory. Each release was therefore rolled out to production and checked against steady-state working-set measurements.

That two-level method is worth copying:

Use a controlled benchmark to attribute changes to a representation decision.
Use production memory and latency to verify that the decision survives real distributions and allocator behavior.

First: stop paying for growth after construction

On a 64-bit system, a Vec<T> conceptually carries a pointer, a length, and a capacity. Capacity is what makes appending efficient: the vector can grow into already reserved space before allocating again.

A cached DNS answer does not grow. It is assembled once, inserted, read many times, and eventually evicted. Retaining growth machinery throughout that lifetime pays for a capability the value will never use.

Converting a completed Vec<T> into Box<[T]> removes the capacity word from the long-lived header. Converting a String into Box<str> does the same for text. The Rust standard-library documentation explicitly recommends a boxed slice when excess capacity should be discarded and the long-lived structure should be smaller.

Each cache entry had eight vector or string fields. Removing one 8-byte capacity word from each saved 64 bytes in the entry header, before accounting for abandoned spare slots in the backing allocations. Multiplied across the cache, this first change was already worth more than 15 TB.

This is a general ownership rule: use growable containers during assembly, then freeze them at the boundary into the smallest type that expresses the stored value’s real behavior.

Second: represent boundaries with offsets, not allocations

Answer, authority, and additional records are logically separate, but they do not need three independent heap objects. They can occupy one contiguous sequence with two offsets marking where the later sections begin.

Because DNS sections contain small record counts, each boundary fits in a u16. Two boxed slices would each require a pointer and a length—16 bytes apiece on a 64-bit target. Replacing those two extra slices with two 2-byte offsets saves 28 bytes per entry and removes two allocation relationships.

The same reasoning applies to flags. Several booleans can be packed into one bit field. The direct savings may look tiny, yet layout changes are not perfectly additive. Rust must respect field alignment, and a structure’s total size is rounded to its alignment. Removing a two-byte field or collecting booleans can eliminate neighboring padding as well. The Rust Reference explains why the size of a value includes this alignment padding.

Most savings came from changing relationships: one allocation instead of several, one shared name instead of copies, and offsets instead of pointer-length pairs.

Contiguity also improves locality. A lookup that touches adjacent bytes can make better use of each CPU cache line than one that follows pointers across unrelated heap regions. At this scale, memory footprint and latency are often the same problem viewed from different levels of the hierarchy.

Third: infer the owner on the common path

Every DNS resource record has an owner name. In an ordinary answer, that owner is often exactly the name in the cache key. A query for example.com A might return two A records, both owned by example.com.

Storing the full owner inside both records duplicates information already held by the key. Big Pineapple changed the record to store an optional owner:

struct Record {
    owner: Option<Box<Name>>,
    class: Class,
    ttl: Ttl,
    kind: Rtype,
    data: RecordData,
}

None means “use the queried name from the cache key.” A different name is stored only when the response requires one, as in a CNAME chain where later records belong to the canonical target.

This deliberately makes an individual record less self-contained. That is a good trade because every cache lookup already has the key. The complete context exists at the point where the record is read, so copying it into every stored child object buys convenience rather than capability.

DNS already makes a similar trade on the network. RFC 1035 name compression allows later names to refer to an earlier suffix with a two-octet pointer. Big Pineapple did not keep those compression pointers in its parsed cache representation—the lookup cost would be awkward—but it borrowed the deeper idea: repeated context can be referenced or inferred instead of expanded everywhere.

Fourth: stop sizing common records for the rare giant

A typed enum looks ideal for DNS record data:

enum RecordData {
    A(Ipv4Addr),
    Aaaa(Ipv6Addr),
    Txt(Txt),
    Naptr(Naptr),
    Svcb(Svcb),
    // many more variants
}

An enum value must have enough space for any of its variants, plus the discriminant and padding. In this case, NAPTR was the largest variant at 136 bytes, making the full enum 144 bytes. Yet A needs four bytes and AAAA needs sixteen, and together they represented more than 80% of the benchmark’s traffic.

The common records were therefore carrying well over a hundred bytes of unused inline space so the same slot could occasionally hold a rare large record.

The first repair boxed large variants. Small, common variants remained inline; large variants became pointers to right-sized heap allocations. This reduced the enum to 24 bytes and saved about 120 bytes for each A or AAAA record.

Boxing is a useful lever, but it introduces a second bill. Each large value needs an allocation. Allocators such as jemalloc group requests into size classes, so a requested size may be rounded upward. Pointer chasing also scatters related data and can cause extra CPU cache misses.

The intermediate enum proved the distribution-aware idea—optimize the container for common variants instead of the maximum—but it was not the final layout.

Fifth: keep structure where it helps, wire bytes where they win

One extreme would cache an entire ready-to-send DNS packet. That is compact, but responses are not identical for every client. The transaction ID changes. DNSSEC records are included only when the client sets the DNSSEC OK flag. Name compression depends on the final message layout. A full packet would need duplicate variants or parsing and filtering on every hit.

The opposite extreme is the fully parsed object graph. It makes manipulation easy but spends memory and serialization work on fields that are usually copied back to the wire.

The final design sits between them. Metadata remains structured. Record payloads are encoded into one Box<[u8]>; each record is stored as a two-byte length followed by its wire-format bytes.

Most records—including A, AAAA, TXT, and DNSSEC types—can then be copied directly into the outgoing response. Records containing domain names, such as CNAME, NS, MX, and SOA, are parsed when needed so the resolver can apply name compression in the new message.

The hybrid layout does not compress everything. It preserves just enough structure to specialize the response while letting the dominant record types bypass field-by-field serialization.

Random indexing becomes less convenient because the length-prefixed buffer must be scanned. Big Pineapple sometimes rotates address records for round-robin behavior, but entries contain few records, so sequential iteration is cheap. In exchange, all payloads occupy one allocation and arrive together in cache lines.

Insertion uses a reusable scratch buffer. Repeated writes grow it to a practical high-water mark, so building the next entry usually needs no temporary reallocation. Once serialization is complete, the exact byte count is copied into a boxed slice. That creates one right-sized long-lived allocation and avoids hoping that shrinking a vector will return its unused tail to the allocator. This last change alone raised insert throughput by 13% in the benchmark.

Smaller became faster because less work moved through the machine

The completed set of changes reduced the benchmarked net footprint per entry by 56%, from 953 to 420 bytes. Allocations per entry fell from about 1.1 KB to 461 bytes, a 58% reduction.

Performance moved in the same direction:

Metric	Before	After	Change
Cache insertion	625,000 entries/s	893,000 entries/s	+43%
Cache lookup latency	828 ns	670 ns	-19%
Per-entry footprint	953 bytes	420 bytes	-56%
Per-entry allocations	1.1 KB	461 bytes	-58%

This is not mysterious once the hierarchy is visible. Fewer allocations mean less allocator bookkeeping. Smaller values move fewer bytes during insertion. Contiguous records need fewer pointer dereferences and use CPU cache lines more fully. Direct copying avoids reconstructing common records field by field.

During the production rollout, instance memory fell in steps as new releases arrived and caches refilled. At the 99th percentile, steady-state resident memory dropped from 9.3 GB to 5.3 GB; at the 90th percentile it fell from 6.5 GB to 3.8 GB. Across the fleet, the working-set reduction settled near 100 TB.

The freed memory is not merely an accounting win. Cloudflare plans to spend it on more cache entries. A larger cache raises hit rate, which reduces upstream queries and can improve response time and resilience. Efficient representation creates a compounding return: the same hardware retains more answers and performs less external work.

A practical playbook for high-scale data structures

The techniques here are specific to DNS, but the design process applies to search indexes, telemetry buffers, object stores, compilers, databases, and any service with millions of long-lived objects.

Model the real distribution

Do not optimize every enum variant equally. Measure which cases dominate count, bytes, and access frequency. A rare large value should not dictate the inline size of billions of common small values.

Separate construction from storage

Builders benefit from mutation and spare capacity. Stored objects benefit from exact sizing and immutability. Make that phase transition explicit with frozen strings, boxed slices, arenas, pages, or another compact representation.

Charge pointers the full price

A pointer costs more than its width. It implies an allocation, allocator metadata, possible size-class slack, another object lifetime, and a potential cache miss. Replacing two pointers with a four-byte offset can save far more than twelve bytes in practice.

Treat duplicated context as a schema question

If every child repeats a value available from its parent or key, ask whether the child truly needs to stand alone. Optional overrides are often enough. The tradeoff must be explicit: inference saves space but increases coupling to the surrounding context.

Choose an internal wire format deliberately

Parsed structures and serialized bytes are endpoints, not commandments. A hybrid can keep searchable metadata typed while storing opaque payloads compactly. The right boundary is the one that minimizes total work across insertion, residency, and lookup.

Validate improvements at several layers

Track type sizes, heap allocations, throughput, tail latency, resident memory, and downstream behavior such as cache hit rate. An optimization that wins one microbenchmark can lose after allocator rounding or production traffic shifts.

The real optimization was removing capabilities

Every major saving came from taking something away:

growable capacity after the value became immutable;
independent allocations for sections that can share storage;
owner names already present in the key;
inline room for rare enum variants;
parsed fields that the hot path only serializes again.

That is the durable lesson. Compact systems are not created by clever packing alone. They emerge when the representation offers exactly the capabilities its lifetime requires—and no more.

At ordinary scale, these choices look like implementation details. At 250 billion entries, they become 100 terabytes, 268,000 additional inserts per second, and 158 fewer nanoseconds on a cache hit. Scale does not invent new costs. It reveals the ones that were already hiding in every object.

Sources

When Unicode Version Drift Becomes a Security Bug

Vincent Tran — Thu, 27 Aug 2026 00:00:00 +0000

str.lower() looks too ordinary to be dangerous. It takes text, returns lowercase text, and appears in codebases everywhere. Yet inside a standards implementation, even a familiar string method can cross a security boundary.

That happened in Python’s implementation of Stringprep, the text-preparation framework used by the original internationalized domain-name standard. The protocol was built from Unicode 3.2 data published in 2002. Python kept the old database needed by the protocol, but one fallback in the case-folding path called the ordinary str.lower() method. That method follows the Unicode database bundled with the running interpreter.

The result was a split-brain algorithm: most of the implementation lived in 2003, while one operation silently moved forward whenever Python adopted a newer Unicode release.

This is not the usual Unicode warning about characters that merely look alike. The deeper problem is version drift inside a supposedly deterministic protocol. If a stored identifier, certificate rule, allowlist, cache key, or network destination is prepared differently on two machines, those machines may disagree about what resource a user meant.

Domain names need a bridge between Unicode and ASCII

The Domain Name System was designed around a narrow set of ASCII characters. Human language is not. Internationalized Domain Names in Applications, or IDNA, bridge that gap by transforming a Unicode label into an ASCII form that starts with xn--. The reversible encoding at the end is Punycode.

Punycode alone is not enough. Before encoding, an application must decide which inputs should compare as equivalent, which characters should disappear, which are forbidden, and how bidirectional text should behave. IDNA 2003 delegated that preparation to Nameprep , a profile of the more general Stringprep framework in RFC 3454.

Stringprep describes a pipeline:

Map selected characters, including case mappings.
Normalize the result with Unicode NFKC when the profile requires it.
Reject prohibited output.
Apply bidirectional-text rules.
Pass the prepared label to the protocol-specific encoder.

The protocol is a versioned pipeline. One moving stage is enough to make the output unstable.

Every stage is part of the meaning of the resulting identifier. Changing one is not a harmless implementation improvement. It changes the protocol.

The standard deliberately froze Unicode at version 3.2

Unicode evolves. New scripts are added, previously unassigned code points acquire characters, and properties can be refined. Casing is data-driven too. A character that had no lowercase partner in one release can gain one later.

That evolution is healthy for general text processing. It is dangerous when a wire protocol expects a fixed answer.

RFC 3454 therefore did not say “use whatever Unicode knows today.” Its tables were generated from Unicode 3.2. Appendix B records the mappings required for case folding, while other appendices record unassigned and prohibited code points. Two independent implementations using those tables should produce the same prepared string even if one runs decades after the other.

Python supports this requirement in an unusually explicit way. The standard library exposes the interpreter’s current Unicode database through unicodedata, but it also ships unicodedata.ucd_3_2_0. The legacy database exists specifically for protocols such as Stringprep and IDNA 2003.

You can see the two clocks in one interpreter:

import unicodedata

print(unicodedata.unidata_version) # for example, "15.1.0"
print(unicodedata.ucd_3_2_0.unidata_version) # "3.2.0"

Both databases are correct. They answer different questions:

The current database answers, “What does this character mean under the Unicode version supported by this Python runtime?”
The legacy database answers, “What did Unicode 3.2 say, as required by this old protocol?”

The vulnerability appeared because one code path asked the first question when the protocol required the second.

A convenient fallback escaped the frozen database

Stringprep’s B.3 table contains case-folding exceptions. Python represented those exceptions in a lookup and used a fallback for every code point not present in the table. In simplified form, the code looked like this:

def map_table_b3(character):
    replacement = b3_exceptions.get(ord(character))
    if replacement is not None:
        return replacement
    return character.lower()

The lookup was frozen. The fallback was not.

At the time the table was created, calling lowercase for an ordinary character looked equivalent to storing every identity or simple lowercase mapping explicitly. Years later, character.lower() had learned about characters and casing relationships that Unicode 3.2 did not contain. The shortcut stopped being equivalent to the table it was meant to implement.

Cherokee makes the failure concrete. Unicode originally encoded Cherokee letters in an uppercase-like form. Lowercase Cherokee letters were added much later. Under a modern Unicode database, the Cherokee letter Ꭰ (U+13A0) lowercases to ꭰ (U+AB70). Under Unicode 3.2, U+AB70 was not the lowercase counterpart used by Stringprep; it was outside the frozen repertoire.

On an affected Python runtime, this happens:

label = "ᎠᎠ"

print(label.lower())
# ꭰꭰ

print(label.encode("idna"))
# b'xn--kz9aa' # affected behavior

The RFC-bound result preserves the Unicode 3.2 interpretation and encodes the original pair as:

xn--58da

The difference is not cosmetic. Those ASCII labels name different DNS locations. A runtime upgrade can therefore change which hostname an application contacts even though the source Unicode string is unchanged.

Why this crosses a security boundary

Not every standards mismatch is exploitable. The risk appears when software makes a security decision on one representation and performs an action on another.

Consider a service that accepts a Unicode hostname and applies an allowlist before making an outbound request. The validator runs in one process or container; the network client runs in another. If their Python versions carry different Unicode data, they can derive different ASCII labels from the same input.

The same pattern can affect:

URL allowlists and blocklists;
certificate hostname checks;
proxy routing and egress policy;
cookie and origin boundaries;
caches indexed by normalized hostnames;
database uniqueness constraints;
signed records that are normalized again during verification.

The dangerous shape is a check/use split :

Unicode input
    ├── validator with mapping version A → identifier A → allowed
    └── connector with mapping version B → identifier B → contacted

Even when every component is locally consistent, the system is not. The bug lives in the relationship between them.

Stored data adds a second failure mode. Suppose an application canonicalizes a username or hostname, stores only the canonical value, and later recomputes that value after an upgrade. A new mapping can create collisions, orphan old records, or cause lookups to reach a different row. Unicode upgrades then behave like schema migrations, except the schema change is hidden inside a library call.

This is different from homoglyph spoofing

Unicode security discussions often begin with confusables: a Cyrillic character that resembles a Latin one, mixed scripts in an identifier, or invisible formatting characters. Those are real concerns, and Unicode Technical Standard #39 provides restriction levels and confusable-skeleton mechanisms to help detect them.

Version drift is a different class of failure:

Confusable text gives different code points similar visual appearances.
Normalization differences give canonically or compatibly related sequences inconsistent binary forms.
Case-folding differences change which strings compare without case distinctions.
Version drift makes any of those transformations depend on the library or runtime version.

Solving only the visual problem does not fix the protocol problem. A string can contain no deceptive glyphs and still map differently because two components use different Unicode data. Likewise, casefolding is not a universal security sanitizer. Python’s str.casefold() is designed for caseless matching under the runtime’s current Unicode version. It is more aggressive than lower()—for example, it maps German ß to ss—but it is still the wrong tool when a protocol mandates an older, fixed mapping table.

The correct operation depends on the contract, not on which string method sounds strongest.

The repair makes the protocol data complete again

The CPython fix did not freeze str.lower() globally. General Python code should continue receiving current Unicode behavior. Instead, the repair regenerated Stringprep’s data so that every code point whose modern lowercase behavior differs from Unicode 3.2 gets an explicit protocol-specific mapping.

Conceptually, the corrected function becomes:

def map_table_b3(character):
    replacement = protocol_exceptions.get(ord(character))
    if replacement is not None:
        return replacement
    return character.lower() # safe only after all version differences are covered

The important part is how protocol_exceptions is built. CPython’s generation tooling walks the Unicode code-point space, compares the modern behavior with the Unicode 3.2 database and the RFC tables, and records the differences. Regression tests then pin known examples including Cherokee, Georgian, Cyrillic, and Roman numeral characters.

The merged CPython change also tightened property handling for code points outside RFC 3454. The accompanying security note states the intended invariant plainly: stringprep and the built-in encodings.idna codec must not consider Unicode attributes beyond those defined by the RFC.

The fix restores a single clock: protocol behavior comes from the protocol’s data, not the runtime’s release date.

This repair pattern is broadly useful. When an old specification and a living database disagree, isolate the compatibility behavior in generated, reviewable data. Do not weaken the modern API for every caller.

IDNA 2003 and IDNA 2008 are different protocols

It is tempting to respond by replacing every call to Python’s built-in idna codec with a newer method. For new applications, moving away from IDNA 2003 is usually the right direction—but migration must be explicit.

Python’s built-in:

hostname.encode("idna")

implements IDNA 2003. The third-party idna package implements the newer IDNA 2008 family and Unicode Technical Standard #46 processing. The standards differ in character validity, mappings, and compatibility behavior. Swapping implementations can change accepted input and output, so it deserves tests and a data-migration plan rather than a blind dependency edit.

IDNA 2008 largely moved away from Stringprep’s model of embedding a snapshot of Unicode mappings. Its rules are designed to work with evolving Unicode properties while preserving stronger stability constraints. That makes the newer family a better basis for contemporary internationalized domains, but it does not erase deployed IDNA 2003 data or interoperability requirements.

Applications sometimes need both:

compatibility with stored or remote IDNA 2003 identifiers;
IDNA 2008 or UTS #46 for new user input;
an explicit boundary that says which version owns each value.

The version must travel with the data or be unambiguous from context. A bare string is not enough when two standards can interpret it differently.

A safer design for security-sensitive text

This incident suggests a practical engineering checklist.

1. Name the exact transformation

Avoid helpers called normalize_name() or clean_host(). Use names that expose the contract, such as to_idna2008_ascii() or nfkc_casefold_identifier_v17(). Precise names make accidental substitutions easier to spot in review.

2. Canonicalize once, then pass the canonical value

Do not let an allowlist, proxy, HTTP client, logger, and database each normalize the same raw input. Convert at one trusted boundary, validate the canonical result, and pass that exact result to the operation. This collapses the check/use split.

3. Record algorithm and data versions

If canonical forms are stored, include the transformation version in the schema or metadata. Treat upgrades as migrations. Recompute in a staging job, look for new collisions and changed keys, and decide how old records will be addressed.

4. Test non-ASCII edge cases across supported runtimes

ASCII-only fixtures will never expose Unicode drift. Build a corpus from specification tables, historical regressions, newly assigned code points, multi-code-point folds, normalization boundaries, and bidirectional cases. Run it against every supported runtime and architecture.

5. Compare components, not just functions

An implementation can pass its own unit tests while disagreeing with another service. Add end-to-end tests that send the canonical identifier from policy enforcement to the network or storage layer. Verify the exact bytes at both ends.

6. Prefer generated tables with provenance

Hand-maintained exception lists decay. Generate them from pinned upstream data, store checksums or version identifiers, and make diffs reviewable. A table may be large, but it is often safer than a clever fallback whose behavior is inherited from the host runtime.

7. Separate display text from identity keys

Users should see the text they entered, with appropriate spoofing warnings. Internal equality and routing should use a clearly defined canonical key. A confusable skeleton is a detection aid, not display text and not a general-purpose normalized identifier.

The larger lesson: standards code has a time dimension

Developers usually review a function by asking what inputs it accepts and what outputs it returns. Versioned text processing adds a third dimension: when the function’s data was defined.

str.lower() was not inherently unsafe. It was unsafe because its contract was “current Unicode lowercase,” while its caller’s contract was “the case mapping frozen into RFC 3454.” Both behaved as designed. The composition did not.

That pattern reaches far beyond domain names. Cryptographic suites, MIME registries, time-zone data, certificate roots, locale rules, parsers, and database collations all mix living software with versioned external knowledge. A convenient platform API can silently import today’s answer into a protocol that requires yesterday’s.

The safest question in standards code is therefore not only “Is this function correct?” It is:

Correct according to which data version, and will every component use the same one?

Once text influences identity, authorization, routing, or signatures, Unicode data is no longer a presentation detail. It is part of the security protocol.

Teaching a Language Model to Paint with Editable Code

Vincent Tran — Wed, 26 Aug 2026 00:00:00 +0000

Most image generators give us one narrow way to participate: describe an image, wait for pixels, and ask the model to try again. The result may be beautiful, but it is also flattened. We cannot select the loop that drew one petal, change the color rule behind a wash, or make the composition denser by editing the artifact itself.

Surya Narreddi and collaborators explored a different medium. They trained a language model to write complete JavaScript sketches using p5.brush , rendered those programs into watercolor-like images, and improved the model with reinforcement learning. The deliverable is not only a PNG. It is a program that remains available for inspection and revision.

That apparently small change—from generating pixels to generating the procedure behind the pixels—reshapes the whole system. Rendering becomes a tool call. Compilation becomes a hard correctness check. Aesthetic taste must become a reward. Prompt design becomes part of the action space. And because there is no objective answer to “is this a good watercolor?”, the hardest engineering work moves into the evaluator.

The project is therefore about more than flowers. It is a compact case study in how to train models for subjective work without reducing taste to a vague score.

Code is a more participatory image format

A raster image stores a finished grid of colors. A creative-coding sketch stores decisions: brush selection, pigment, stroke order, geometry, randomness, density, and layering. Rendering turns those decisions into pixels, but the decisions remain editable.

That creates several useful properties:

Local changes are possible. A person can adjust the stem, petal count, palette, or background without asking the model to regenerate everything.
Behavior is inspectable. The source reveals whether the image came from careful structure, accidental complexity, or an invented API.
Results can be reproduced. With fixed code, dependencies, canvas dimensions, and random seeds, the image can be rendered again.
The medium can be extended. The same sketch can become an animation, print, parameterized series, or interactive tool.
Failure is legible. A blank canvas can be traced to syntax, unsupported methods, bad coordinates, or a poor visual idea.

The trade-off is equally important. Code does not magically make image creation easier. It adds a runtime, an API, a sandbox, and a much longer path from intent to picture. Direct image models are faster and have absorbed far more visual knowledge. The value here is agency over the artifact, not raw convenience.

The chosen drawing layer, p5.brush, adds natural-media tools to p5.js: pencils, charcoal, markers, watercolor fills, hatching, and vector fields that bend strokes. Instead of asking a language model to emit millions of pixels, the system asks it to compose a relatively small vocabulary of visual operations.

The training system closes a tool-use loop

Each training example begins with a visual request such as a peach hibiscus painted in watercolor. The language model produces a complete p5.brush program. Puppeteer runs the sketch in a browser environment and captures the canvas as a PNG. A separate model compares the result with curated reference images, and that preference is converted into the reward used to update the code-generating model.

The model acts in code, but the learning signal comes from the rendered image.

The loop connects two different spaces:

Token space , where the policy chooses JavaScript tokens.
Execution space , where the sketch either runs or fails.
Image space , where pigment, composition, depth, and resemblance become visible.
Preference space , where a judge decides which image better represents the target taste.

This separation is powerful. Syntax and API use can be checked exactly. The final visual result can be judged holistically. A program that compiles but paints a dull icon is valid code and poor art; a beautiful-looking snippet that calls imaginary functions never reaches the canvas. The reward has to recognize both cases.

It also creates an obvious security boundary. Model-written JavaScript is untrusted input. A production renderer needs process isolation, time and memory limits, restricted networking and filesystem access, deterministic dependencies, and an actual browser sandbox. Puppeteer’s own troubleshooting guidance strongly discourages running Chromium without its sandbox. Creative output does not make generated code safe.

Why the first reward function failed

The first training rubric looked comprehensive. It contained nine signals:

whether the sketch compiled;
whether it actually used p5.brush rather than plain p5.js;
a code-length ramp aimed around 3,000 tokens;
HPSv3, an image preference model;
prompt adherence from a council of judge models;
recognizability;
aesthetics;
technique;
depth.

The run improved until its reward reached roughly 0.65, then stopped making meaningful progress. Outputs converged on the same safe solution: a flat flower with five rounded petals. The score rose, but the capability did not.

The problem was not a lack of feedback. It was too much duplicated feedback.

The quality judges and prompt-adherence judge were correlated between 0.85 and 0.95. Five labels appeared to describe five qualities, but they were largely measuring the same underlying impression. Their combined weight counted one opinion several times. Meanwhile, the code-length reward saturated early and stopped producing a useful gradient. HPSv3 was the signal with visible variation, yet it carried only 10% of the reward.

This is a common failure mode in composite evaluation. A long rubric feels safer because it names every concern. If the signals move together, however, adding them does not add information. It only amplifies a hidden preference. Reward dashboards can look richly instrumented while the optimizer receives the equivalent of one repeated instruction.

There was another trap: a metric can remain numerically present after it has stopped teaching. Once nearly every rollout satisfies a binary gate or length target, that component contributes no useful distinction inside the batch. A saturated reward is bookkeeping, not learning signal.

The diagnosis required inspecting each sub-reward separately: its variance over time, its correlation with other signals, and whether changes in it corresponded to visible capability changes. The total score alone concealed the collapse.

Pairwise judgment gives taste a usable scale

The original visual judges assigned absolute scores. In principle, “rate this from zero to ten” gives a clean scalar. In practice, model judges often compress their answers into a narrow region or apply the scale inconsistently. Is a competent synthetic watercolor a four, a six, or an eight? The number has no stable anchor.

Pairwise comparison asks an easier question: which image better matches the target watercolor?

For every rollout, the system samples two reference paintings and asks a judge to choose. The rollout’s reward is the fraction of comparisons it wins. The task is still subjective, but the decision has context. Instead of inventing the meaning of seven out of ten, the judge distinguishes one concrete artifact from another.

This changes the geometry of the feedback:

The reference set anchors the meaning of “good.”
Close comparisons expose small improvements that an absolute scale may hide.
Win rates spread results across a wider dynamic range.
The team can audit disagreements by looking at the exact images shown to the judge.

Pairwise preference is also a natural fit for HPSv3. The HPSv3 paper trains its preference model from pairwise annotations and uses an uncertainty-aware ranking loss. That does not make it a universal taste oracle. It makes the model useful as one broad prior about human image preference, which can then be balanced with project-specific references.

A reference pool is taste made operational

The team generated 1,664 candidate paintings and rated each one into three buckets: love , okay , or nope. The 117 love-tier examples became the initial taste anchor. Additional acceptable images and supplemental generations expanded coverage, producing a pool of 581 references.

Those numbers reveal how much human work sits behind a supposedly automated reward. The system did not discover the target aesthetic from the words “good watercolor.” Someone selected examples, rejected others, noticed gaps in color coverage, and decided which variations belonged together.

The reference pool performs several jobs at once:

It turns personal taste into examples rather than an abstract instruction.
It gives the judge a consistent comparison context.
It reveals missing regions, such as colors with too few strong examples.
It can be revised without relabeling every future rollout.
It creates an auditable record of what the reward is trying to preserve.

It also creates bias. Every reference was model-generated because suitable human-made p5.brush work was difficult to source. The policy is therefore learning to outperform a synthetic neighborhood selected by one curator, not learning an independent definition of watercolor quality. If the pool overrepresents centered flowers or clean backgrounds, the model may learn those conventions as taste.

The next natural step would be to train a smaller reward model directly on the ratings. That could generalize the curator’s preferences beyond repeated comparisons with a fixed pool. But it would not remove the design problem. It would encode the same choices into weights, making dataset balance, calibration, and held-out evaluation even more important.

The revised reward is smaller and more informative

After the diagnosis, nine components became four:

compilation and verified p5.brush use: 5% ;
code-length check: 5% ;
HPSv3: 30% ;
pairwise judgment against the curated pool: 60%.

Hard gates keep outputs runnable; most of the gradient now comes from visual preference.

With the same base model and training data, the revised run reached the earlier plateau about three times faster and continued improving beyond it. Generated programs also shrank from roughly 13,500 tokens to fewer than 2,000. Once verbose code stopped being rewarded heavily, the model found that good compositions could be expressed more directly.

The result is not an argument that every creative reward should use these exact weights. It demonstrates a method for finding useful weights:

Keep correctness checks as gates with enough weight to prevent invalid work.
Measure the variance of every soft reward inside actual rollout groups.
Compute correlations so duplicated judges do not impersonate independent evidence.
Inspect examples at low, middle, and high scores.
Remove or reduce signals that saturate before capability improves.
Re-run with one major change at a time so the cause of improvement remains legible.

A compact reward is easier to reason about. Every component has a distinct responsibility: executability, economy, broad human preference, and project-specific taste.

GRPO learns from relative outcomes within a group

The optimizer used Group Relative Policy Optimization, or GRPO. Introduced in DeepSeekMath, GRPO samples several outputs for the same input and estimates each output’s advantage relative to the group rather than training a separate value model.

In this setting, one prompt produces several candidate sketches. They are rendered and rewarded. A sketch that performs better than its siblings receives positive relative advantage; one that performs worse receives negative advantage. The policy update then makes the better token trajectories more likely while limiting how far the new policy moves from the previous one.

That relative structure pairs well with the project’s judging strategy. Both stages avoid pretending there is an absolute aesthetic truth:

the image judge compares a rollout with concrete references;
GRPO compares a rollout’s reward with other rollouts from the same prompt.

The distinction matters. Pairwise judging defines the scalar reward. GRPO decides how that scalar changes the language model. It does not solve reward design. If the judge favors flat clip art, GRPO will efficiently train the policy to make flat clip art.

Group-relative learning also needs diversity. If every candidate earns the same reward, the group provides little advantage signal. If one mechanical constraint dominates every comparison, the model learns that shortcut. Good rollout sampling and informative reward variance are part of the algorithm’s practical input.

The system prompt improved when documentation disappeared

Reward design was only half the problem. The model also needed to know how to use a niche graphics library.

An early system prompt included about 400 lines of p5.brush API documentation. Frontier models responded with polished JavaScript that confidently called methods the library did not have. More reference material increased the surface area for plausible invention.

The team used GEPA, an evolutionary prompt optimizer, to search for a better instruction. GEPA evaluates candidate prompts, reflects on execution traces and failures, proposes textual mutations, and preserves candidates that perform well across the evaluation set. After 200 iterations against a taste-anchored seven-example judge, the successful prompt was much smaller: a strict allowlist of eight brush methods, with no long API reference and no examples.

The first version that reliably produced visible hibiscus forms arrived after most of the documentation was removed.

This does not mean documentation is generally harmful. It means a generative model does not use an API manual like a compiler. Long context can mix authoritative names with nearby patterns and invite completion by analogy. For a constrained tool task, a small executable vocabulary may be more reliable than a broad descriptive reference.

A practical tool prompt should therefore distinguish:

allowed operations , listed exactly;
forbidden fallbacks , such as drawing with native p5.js when p5.brush is required;
runtime invariants , including canvas setup and completion behavior;
output contract , such as one complete sketch and no prose;
recovery behavior , for example simplifying after an execution failure.

Everything else can be retrieved only when needed or exposed through typed wrappers. The goal is not to teach the model the whole library. It is to make the valid action space obvious.

What can generalize beyond watercolor

The experiment suggests a reusable design for subjective, tool-mediated work:

1. Keep the artifact editable

Generate a structured source whenever the source is itself useful: HTML and CSS for layouts, vector instructions for diagrams, CAD operations for objects, MIDI for music, shader code for visuals, or node graphs for compositing. A rendered preview remains essential, but it should not erase the underlying decisions.

2. Separate validity from quality

Use deterministic checks for properties that genuinely are deterministic. The program compiles, calls allowed methods, finishes within limits, and produces a non-empty render. Do not ask an aesthetic model to guess those facts.

3. Prefer comparisons for ambiguous qualities

When an absolute scale is unstable, compare concrete artifacts. References make the intended standard visible and reviewable. Pairwise evaluation is slower, but it often creates a cleaner signal.

4. Treat curation as model design

The examples in a reference set shape the learned behavior as directly as the optimizer does. Track who selected them, which regions are overrepresented, and which failure modes are missing. Version the pool alongside the training configuration.

5. Audit reward information, not just reward count

More metrics are not automatically more supervision. Measure variance, correlation, saturation, and agreement with human review. Delete signals that merely repeat stronger ones.

6. Evaluate the entire pipeline

The policy, prompt, tool API, renderer, judge, references, and optimizer form one system. A blank image may be a policy failure, an API hallucination, a browser crash, or a capture bug. End-to-end traces are more useful than a single final score.

The real creative medium is the feedback system

The most interesting artifact in this project is not one hibiscus. It is the machinery that decides which hibiscus teaches the model.

Creative reinforcement learning cannot avoid taste by adding more judges. Someone still chooses the rubric, the references, the comparisons, and the failure boundaries. The engineering achievement is to make those choices explicit enough to test: hard gates for execution, a broad preference prior, a curated local standard, and relative updates across alternative programs.

Painting with code is slower than asking a direct image model for pixels. It is also more open to human intervention. The user can edit the source, the researcher can inspect the action, and the team can revise the meaning of “better” without pretending it was objective all along.

That is the larger lesson. For subjective model behavior, the reward is not a neutral measurement attached after the creative work. Designing the reward is part of the creative work.

DEV Community: Vincent Tran

Cloud in a Bottle: A Personal Cloud That Works Like an App Platform

The cloud experience is the feature

One service controls the machine

A repository becomes an installable app

Rootless containers reduce the default blast radius

Authentication belongs at the front door

Apps cooperate through grants, not shared disks

Storage is split by semantics

The remaining work is operational, not conceptual

The right abstraction is a small personal platform

Further reading

Stop Paying Frontier-Model Prices for Agent I/O

Context is a working set, not a storage system

Portal modes turn workers into configuration

Three layers make routing reliable

The threshold is an economic boundary

Why boilerplate is a separate path

Keep reasoning where the evidence converges

Read the benchmark as a routing result

Build a router from the boundary inward

The coordinator should spend tokens on decisions

Further reading

GPT-6 Astra: OpenAI's New Model Is Built to Finish the Work

What changed with GPT-6 Astra

Computer use is the center of the release

Professional output becomes part of the evaluation

Coding improves most where the environment matters

Long-running work gets a better memory system

Async tools and mid-turn steering make agents easier to direct

The cybersecurity capability changes the deployment story

Science moves from answers to active research workflows

Context, price, and availability

How I would evaluate Astra

The practical takeaway

Sources

Audacity 4: Rebuilding an Audio Editor Without Losing Its Muscle Memory

The interface migration is an architectural change

Clips are finally the unit of editing

Context replaces the old tool switch

Realtime effects change the cost of experimentation

Playback and recording become timeline-native

.aup4 draws a one-way project boundary

A major release includes deliberate gaps

How to evaluate the upgrade

Further reading

Claude Fable 5.1: Frontier Intelligence Gets Cheaper to Keep Running

What changed in Fable 5.1

The benchmark gains are broad

Cache pricing is the real agent upgrade

Fable and Mythos are still the same model underneath

Cybersecurity safeguards should interrupt less often

The scientific work is a preview of a different kind of model

Data retention still needs a policy review

How I would evaluate the upgrade

The practical takeaway

Learn more

How RuneScape Turned 56k Limits Into a Multiplayer Protocol

Start with the real constraints

A click begins as local computation

The tick turns time into a batch

Every client keeps a mirror of nearby players

Relative coordinates shrink the world to the viewport

One packet, two representations

The opcode cipher protected structure, not content

Shared knowledge is the real compression dictionary

Applying the design today

Further reading

How Autocomplete Searches 240 Million Domains Before Keyup

Zero milliseconds is a product definition

Speculation is cheap when the future is bounded

Popularity and completeness need different structures

The head: precompute the answer at every prefix

The tail: a small directory over compressed blocks

Search the head first, use the tail to fill gaps

The API became cheaper than the network

The asterisk is geography

A repeatable design process

1. Define the human deadline

2. Look for work that can begin earlier

`.aup4` draws a one-way project boundary

`fetch()` changes what the core can become

`hx-live` handles the client state that remains

Measure the whole path, not just `size_of`