DEV Community: stepinto.dev

The EU Has an AI Act, the UK Has Regulators and No Bill

stepinto.dev — Fri, 13 Nov 2026 07:20:59 +0000

Say you are building an AI product on a model you did not train, calling it through another company's API, and you sell the product in the UK and the EU. Which legislation applies to it, and who is responsible under it, you or the company that trained the model?

Both regimes apply, and for the product the responsible party is you. The EU AI Act calls you the provider of an AI system, and the company that trained the model has separate duties of its own. The UK has no AI act, so there the answer comes from the laws and regulators that already covered your sector. The rest of this post sets out both regimes and where your product sits in each.

Two approaches to the same product

The EU has one regulation of 113 articles that applies in every member state: Regulation (EU) 2024/1689, amended in July by the Digital Omnibus, Regulation (EU) 2026/1744. The UK regulates AI through the laws and regulators it already had.

The AI Act applies to UK companies with EU customers. Article 2(1)(a) covers providers who place a system on the EU market "irrespective of whether those providers are established or located within the Union or in a third country", and Article 2(1)(c) covers providers and deployers in a third country "where the output produced by the AI system is used in the Union". A product built in the UK with customers in Germany is covered, and software sold in both markets has to satisfy both regimes.

The difference shows up in the work. The Act's duties are written as requirements on the system: what it logs, what it tells the user, how its output is marked, and what documentation exists before it goes on the market. The UK's duties arrive through whichever regulator covers the sector, and the one part written at that level of detail is the rules on automated decisions.

Reading the legislation as an engineer

I am an engineer and not a lawyer, and I am reading this legislation to find out what it asks me to build. Since last week, Fridays on this blog are for that: one article of the AI Act, or one of the UK's rules, each week, verbatim, with every clause annotated for the engineers who have to build to it. A single article is hard to follow without knowing where it sits, so this week is an overview of both regimes, with a sample of the annotated format near the end.

What the Act asks of you depends on who you are, what your system does, and when.

Who you are

Almost every duty in the Act is addressed to a provider or a deployer, so the two definitions in Article 3 decide most of what follows. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, outside personal non-professional activity. Both definitions are annotated in full further down.

You can be a provider without training a model. If your product calls a model API and shows the result to people under your name, you developed an AI system and put it on the market. The company that trained the model is the provider of a general-purpose AI model, which is a separate role with separate duties.

There are four more roles. An authorised representative is a person or company in the EU with a written mandate to act for a provider outside it. An importer brings a non-EU company's system onto the EU market. A distributor is anyone else in the supply chain who makes a system available. A product manufacturer puts an AI system on the market inside its own product. The Act calls all six "operators" (Article 3(8)).

What the system does

The Act sorts AI systems by what they are used for, and the duties rise with the risk.

Prohibited practices (Article 5). Banned outright since 2 February 2025: manipulative techniques that cause harm, social scoring, untargeted scraping of faces, emotion recognition at work and in schools, and several more. The Omnibus adds two more: systems that generate non-consensual intimate imagery, and systems that generate child sexual abuse material.
High-risk systems (Article 6). There are two ways a system becomes high-risk. The first is being a safety component of a product already regulated under the laws in Annex I, such as medical devices, machinery and toys. The second is a use listed in Annex III, which has eight areas, among them biometrics, employment, education, law enforcement and access to essential services, which is where credit scoring sits. Most of the Act's length is about these systems: risk management, data governance, logging, human oversight, technical documentation and a conformity assessment before the system goes on the market.
Transparency duties (Article 50). Chatbots have to say they are AI, generated content has to carry a machine-readable mark, and deep fakes have to be labelled. This applies whatever the risk tier.
General-purpose AI models (Articles 51 to 55). Duties on the companies that train the models: technical documentation, a summary of the training content, a copyright policy, and more for models classified as carrying systemic risk.
Everything else. No obligations beyond AI literacy (Article 4), with voluntary codes of conduct encouraged under Article 95.

The fines follow the same order (Article 99). A prohibited practice costs up to €35 million or 7% of worldwide annual turnover, whichever is higher. Most other breaches, Article 50 included, cost up to €15 million or 3%. Giving a regulator incorrect or misleading information costs up to €7.5 million or 1%. For SMEs, and since the Omnibus for small mid-caps too, it is whichever figure is lower.

When it applies

The Act arrives in stages, and the Omnibus moved the biggest one. The high-risk obligations for Annex III systems were due on 2 August 2026 and now apply from 2 December 2027.

Date	What applies
2 February 2025	The prohibitions in Article 5, and AI literacy in Article 4
2 August 2025	Duties for general-purpose AI models, the governance bodies, and penalties
27 July 2026	The Omnibus in force. Article 4 now asks providers and deployers to "take measures to support the development of AI literacy" and no longer to ensure it
2 August 2026	The Act's general application date, which brings in Article 50, and the Commission's power to fine model providers
2 December 2026	The end of the grace period for marking content from generative systems already on the market on 2 August, and the two new prohibitions
2 August 2027	Each member state has at least one AI regulatory sandbox running. General-purpose models already on the market before August 2025 have to comply
2 December 2027	High-risk obligations for Annex III systems
2 August 2028	High-risk obligations for systems in Annex I products
2 August 2030	Older high-risk systems intended for use by public authorities have to comply

The Commission fills in the detail with guidelines and codes of practice. For Article 50 there are guidelines published on 20 July 2026 and a Code of Practice finalised on 10 June. For general-purpose models there is a code of practice from July 2025. The guidelines on what counts as high-risk under Article 6 were published as a draft on 19 May 2026 and were still a draft when I checked on 12 November.

Who enforces it

Each member state names market surveillance authorities, and they enforce the Act for most systems. The AI Office, inside the Commission, has exclusive power over general-purpose AI models. The Omnibus gave it more: it is now also the only enforcer for AI systems built on a general-purpose model by the same provider, with exceptions that include products under Annex I and critical infrastructure, and for AI systems that are part of a very large online platform or search engine (Article 75(1)). A company that builds on its own model and sells across the EU is regulated by the AI Office rather than a national authority.

The UK has no AI act

The UK's approach comes from a white paper of March 2023, A pro-innovation approach to AI regulation. It gives existing regulators five principles to apply in their own sectors: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; contestability and redress. The principles are not law. The ICO applies them to personal data, the FCA to financial services, the CMA to competition, Ofcom to communications and the MHRA to medical devices, each using the powers it already had.

A bill has been discussed for two years and has not appeared. The King's Speech of 13 May 2026 contained no AI bill. Parliament's Joint Committee on Human Rights recommended one in September, and this month the AI minister said the government would look at regulation for the most advanced models if it turned out to be needed. I could find no bill, consultation or timetable.

Three things in the UK are more definite: the new rules on automated decisions, the AI Security Institute and copyright.

Automated decisions. Section 80 of the Data (Use and Access) Act 2025 replaced Article 22 of the UK GDPR with Articles 22A to 22D, in force since 5 February 2026. They cover decisions "based solely on automated processing", meaning with "no meaningful human involvement", that have a legal or similarly significant effect on the person. Article 22B restricts such decisions when they use special category data. Article 22C sets the safeguards for the rest: tell the person, let them make representations, let them obtain human intervention, and let them contest the decision. The ICO's updated guidance went out for consultation on 31 March 2026 and has not been published in final form. For an engineer, 22C is the closest thing the UK has to an AI Act article.

The AI Security Institute. It tests frontier models before and after release and publishes research. It was renamed from the AI Safety Institute in February 2025 and is now part of the Cabinet Office. It is not set up in law and has no powers over anyone.

Copyright. UK law has no exception for commercial text and data mining, so training on copyrighted work for commercial use needs a licence. The Data (Use and Access) Act required the government to report on copyright and AI, and the report and impact assessment came out on 18 March 2026. They changed nothing in the law, and the government no longer has a preferred option.

Earlier posts

I wrote about these two regimes in February, from the architecture side. Architecting for Two Europes with Compliance-as-Code builds one platform for both, with the jurisdiction split in middleware, and its logging and oversight patterns are the ones to build towards for the high-risk date. What It Actually Takes to Fine-Tune an LLM in Europe covers copyright and text and data mining on both sides, and when fine-tuning makes you the provider of a new general-purpose model. The March copyright report left UK law as it was, so that post's advice to license for the UK and treat that as the standard for both markets still holds. A Practical Guide to the European Sovereign Inference Stack routes requests between the EU GDPR and the UK GDPR, and Securing the Open Source AI Supply Chain maps the technical documentation in Article 11 and Annex IV to MLOps tooling.

How each article will be read

From next Friday each post takes one article in the format below: the text verbatim, with a plain reading and notes for every clause. Select any part of the text and they open underneath. The two samples here show the format, and neither is a full treatment of its article.

The first is the pair of definitions from Article 3 that answers the question at the top of this post.

The second is the first paragraph of Article 50, which has applied since August and is the part of the Act most products built on a model API meet first.

What to take from this

If your product calls a model API and goes out under your name, you are the provider of an AI system under the Act. The company that trained the model has its own duties, and they do not replace yours.
With customers in the EU, the Act applies to you wherever the company is based.
Article 50 already applies. Generative systems that were on the market on 2 August have until 2 December 2026 to mark their content.
Check your use case against Annex III before 2 December 2027, when the high-risk obligations start for those systems.
In the UK, find out which regulator covers your sector. If the product makes decisions about people with no meaningful human involvement, Article 22C applies: tell the person, let them make representations, let them obtain human intervention, and let them contest the decision.
Training on copyrighted work for commercial use in the UK needs a licence.

Next Friday

Next Friday, 20 November, is Article 50 in full, with every clause selectable and the Commission's guidelines and the Code of Practice cited by paragraph. Article 6, which decides whether a system is high-risk, follows on 27 November. Each post takes one article and works out what it asks of the software.

This is an engineer's reading and no substitute for legal advice.

A Claude Client in One Rust File, and the First Dependency

stepinto.dev — Thu, 12 Nov 2026 07:21:42 +0000

Bash, C# and Go all had HTTP and TLS in their standard libraries, but unfortunately Rust doesn't. The spec lets a language without them use one named library for the transport, and that library counts towards size, so this is the first time the leaderboard has to price a dependency. The transport is ureq with rustls, the parsing is serde_json, and together they bring in thirty-six crates. The result is still the smallest thing on the board so far.

The code is at github.com/AndyCross/claude-hot-path, and the leaderboard is at /claude-hot-path/.

Choosing the transport

The usual answer for HTTP in Rust is reqwest, which is async and brings tokio and hyper with it. For a client that makes two sequential requests and streams the reply to stdout, async buys nothing and costs a runtime. ureq is the blocking alternative, it defaults to rustls so there is no OpenSSL to link, and version 3 exposes the response body as a Read, which is all the SSE loop needs.

One configuration line matters. By default ureq turns a 4xx or 5xx response into an Err, which would throw away the body that holds the API's error message. The spec wants that message on stderr, so the agent is built with status errors off and the client reads the status itself:

let agent: ureq::Agent = ureq::Agent::config_builder()
    .http_status_as_error(false)
    .build()
    .into();

The loop

The body reader goes into a BufReader and lines() does the rest. The let else on the prefix strip is doing the same job as the continue in Go, skipping event: lines, pings and blank separators:

let reader = BufReader::new(resp.body_mut().as_reader());
for line in reader.lines() {
    let line = line.unwrap_or_default();
    let Some(data) = line.strip_prefix("data: ") else { continue };
    let ev: Value = serde_json::from_str(data).unwrap_or_else(|e| {
        eprintln!("error: bad event: {e}");
        exit(1)
    });
    let index = ev["index"].as_u64().unwrap_or(0) as usize;
    match ev["type"].as_str() {
        Some("content_block_start") => {
            content.push(ev["content_block"].clone());
            partial.push(String::new());
        }
        Some("content_block_delta") => match ev["delta"]["type"].as_str() {
            Some("text_delta") => {
                let text = ev["delta"]["text"].as_str().unwrap_or("");
                out.write_all(text.as_bytes()).unwrap();
                out.flush().unwrap();
                let existing = content[index]["text"].as_str().unwrap_or("").to_string();
                content[index]["text"] = Value::String(existing + text);
            }
            Some("input_json_delta") => partial[index].push_str(ev["delta"]["partial_json"].as_str().unwrap_or("")),
            _ => {}
        },
        Some("content_block_stop") => {
            if content[index]["type"] == "tool_use" && !partial[index].is_empty() {
                content[index]["input"] = serde_json::from_str(&partial[index]).unwrap_or(json!({}));
            }
        }
        Some("message_delta") => stop = ev["delta"]["stop_reason"].as_str().map(str::to_string),
        _ => {}
    }
}

serde_json::Value with index syntax is the Rust equivalent of C#'s JsonNode, and I used it for the same reason: the shapes are dynamic and a typed struct per event would be longer than the client. Indexing a Value that lacks the key returns Null rather than panicking, so the as_str().unwrap_or chains read a missing field as empty and move on.

The out is a locked stdout, flushed after every delta. Rust's Stdout is line-buffered, and a text delta rarely ends in a newline, so without the flush the words would sit in the buffer until the stream ended. The harness catches that: the runner records when the first visible byte reached stdout and the mock records when it wrote each chunk, and a client whose first text lands after the stream finished fails conformance. With the flush removed it failed by a millisecond, and with it there are eleven to spare.

The one thing the library does not have

Timezones are the gap again. Rust's standard library has no zoneinfo reader and chrono-tz or jiff would be a third dependency carrying a copy of the database. The platform has one at /usr/share/zoneinfo, in the TZif format from RFC 8536, and reading it is sixty lines: skip the version 1 block, take the 64-bit transition times from the version 2 block, find the last transition before now, and apply its offset. The civil date comes out of Howard Hinnant's days-to-date algorithm, which is nine lines of integer arithmetic. It is more code than any other part of the client, and it is part of why the turnaround is 0.7 ms.

What it measures as

	Rust	Go	C# Native AOT	bash and curl
Artefact	1.4 MB	5.8 MB	5.4 MB	3.7 KB
Runtime	2.0 MB	0	2.4 MB	23.7 MB
Ship	3.3 MB	5.8 MB	7.8 MB	23.7 MB
Cold start, median of 100	1.1 ms	1.7 ms	3.0 ms	7.0 ms
Turnaround, median of 100	0.7 ms	1.2 ms	1.4 ms	19.1 ms
Client total, median of 100	3.2 ms	4.8 ms	7.1 ms	35.3 ms
Peak RSS	3 MB	6 MB	7 MB	11 MB
Lines of code	184	156	102	75
Third-party crates or packages	36	0	0	0

rustc 1.99.1, linux/arm64, Apple M4 Max under Docker. Release profile with opt-level = "z", fat LTO, one codegen unit, panic = "abort" and symbols stripped.

The binary is 1.4 MB with a complete TLS stack inside it, and rustls and its crypto provider are most of that. The 2.0 MB runtime is glibc, libgcc_s and the loader, the same bill .NET paid, and a musl build would fold most of that into the binary. I haven't measured whether the total would come out smaller. I have left it dynamic because the Debian image is what someone would actually deploy, and because the leaderboard already has one static entry to compare against.

Three megabytes of peak memory is half of Go's, the cold start is the fastest so far, and the turnaround is the fastest on the board by a clear margin, though it didn't start out that way: the first version shelled out to date for the timezone and measured three milliseconds between turns, and when I replaced the process with the TZif reader above it only came down to about two. The rest was ureq: it resolves the hostname on every request, before it checks the connection pool, so each turn paid a DNS round trip to Docker's resolver for a socket it then reused. Pointing the client at the mock's IP instead of its name was how I found that, and the fix is the caching resolver, plugged in through Agent::with_parts. Thirty-six crates is the cost, and it is the first non-zero number in that column. Go and .NET got their HTTP stacks from a standard library maintained by one organisation. Rust's comes from thirty-six crates with separate maintainers, which is more to audit and keep patched. The column is there so you can weigh that yourself.

How to run it

git clone https://github.com/AndyCross/claude-hot-path
cd claude-hot-path
./bench/bench.sh rust

Docker and Python 3, no key. The release build takes about fifteen seconds in the container. Next is Zig, which has HTTP and TLS in its standard library and a reputation for binaries measured in kilobytes.

Your Name on a Seville Street Sign, Painted by Rule

stepinto.dev — Wed, 11 Nov 2026 12:01:13 +0000

I have been building a series of pages where the computer generates the pattern: tin-glazed tiles painted by rule, cut tile and poured cement, heraldry, knotwork, a piece that breaks another piece, brick in raking light, the seventeen ways a wall can repeat, iron and silk and clay in clay. Every one of those grows a repeat from a seed. This one starts from a word, which does not repeat: Azulejos de letras is the Seville street sign, with the street name typed in.

Calle Betis. The word painted across the joints, a vine of leaves and grapes round the edge, cut at forty-five degrees in the corners, all in the one cobalt.

Every street in Seville is named on a plaque of tiles. They are cobalt capitals on a white tin glaze, painted across the grid as one word so the joints run through the letters, with a border of vines or scrolls round the lot that turns the corners. The potteries of Triana, across the river, made them by the thousand through the early twentieth century, and made the shop fronts too, so a bodega or a pharmacy announced itself in the same letters as the street it stood on. The letters are a nineteenth-century serif with a lot of contrast between the thick strokes and the thin ones, painted by hand onto the raw glaze, so no two are quite alike and the blue pools a little where the brush stopped.

A typeface made of strokes

The page does not use a font. Each capital is a short list of strokes in a box one cap-height tall: a stem, which is thick; a hairline, which is thin; a thick diagonal; a bowl, which is an arc; a dot; and a tilde for the Ñ. An A is a hairline up the left, a thick stroke down the right and a hairline across. A B is a stem, two bowls and three hairlines joining them. An S is two bowls back to back. That is the whole alphabet, the digits, Ñ and the accented vowels a Spanish street needs, in about sixty lines.

The whole typeface. Every glyph is a list of strokes; the serifs, the contrast and the wobble come from the rules, not the glyph.

The contrast is a rule rather than a drawing. A bowl's width depends on the angle of the point along it: full stem width where the tangent is upright, hairline width at the top and bottom, which is how a Didone letter is cut and what makes an O look like an O rather than a ring. Every stem and every foot gets a bracketed slab serif, a short bar with a small curve into the stroke, drawn by the same rule whatever the letter. Change one number and every serif on the wall changes with it.

The brush comes next. Each stroke becomes a polygon, the engine's wobble runs along its edges in proportion to the hand slider, and the colour goes on the way the tile pages' washes do: a dark pass slid a little down and right, where the glaze pools against the raised edge of a stroke, then the cobalt, then a thinner pass slid the other way. A heavier brush widens the stems and leaves the hairlines alone. The same letter on two tiles is painted twice from two seeds, so the plaque never has two identical Ls.

Across the joints, or one to a tile

The street signs paint the word across the tiles as if the grid were not there, and that is the default: the letters are set at their own widths, each line centred on a row of tiles, and the joints are drawn back over them afterwards so a stem can stop at a grout line and carry on the other side. Letters painted this way are set a little heavier, the way the real ones are. Some shop fronts did it the other way, one letter to a tile or two, and the page does that as well; when it pairs, it pairs within a word, so a space is a blank tile rather than a tile with half a word on it.

Two letters to a tile, the shop-front way, in the santa ana colours with the acanthus border.

A drop cap is the first letter at nearly twice the height, with the rest of the first line hugging it and the second line beside it. In the one-to-a-tile lettering it takes a tile four times the size. It is the same glyph at a larger cap height, and the serifs scale with it.

A drop cap, manganese on an old cream, with age on. The chain border's rings run through each other across every joint.

The border is a repeat after all

The one thing on the plaque that does repeat is the border, and it repeats in one dimension, the way Rejería's frieze runs along its rail. A border tile is drawn once, in a square with the outside of the plaque at the top and the words at the bottom, and then laid along every side turned a quarter each time, so the design always faces inward.

The corner was the hard part. A rosette on a square tile is what I did first, and it stops the border dead at each corner, where the real plaques carry the vine round. So the corner tile is the border tile bent: the strip is warped into a quarter-annulus about the tile's inner corner, the distance from that corner becoming how far into the border a point sits and the angle round it becoming how far along, so the strip's right edge becomes the corner's right edge, its left edge becomes the corner's bottom edge, and the vine turns through a quarter between them and meets its neighbours on both sides. That is a general operation on any border tile, so it went into the engine as bendCorner, and the outer corner the bend does not reach is filled with fresh glaze.

Most of the real plaques are squarer than that. Their borders are cut the way a picture frame is, at forty-five degrees, with the strip running into the corner from both sides and meeting on the diagonal. That is the other corner, mitreCorner, and it is the default: the strip clipped to the triangle above the diagonal, then turned three quarters and clipped to the triangle below it. The bent corner stays as an option for the plaques with a rounded frame.

The two borders the real plaques wear are the vine and the acanthus. The vine is Jerez's: a stem waving across the tile, a five-lobed leaf on each crest with its veins left in the glaze, a bunch of grapes hanging in each trough, a smaller leaf and bunch the other way, and tendrils curling off the joints. The acanthus is the baroque cartouche: a thick C-scroll curling in on itself with leaf fronds off its back, one turning each way per tile, and a bud where they meet at the joint.

The vine, close. Leaves, bunches and tendrils in one blue, the veins and the lights left in the glaze.

The acanthus, close. Two scrolls to a tile, fronds along the outside of each sweep, a bud at the joint.

Plaza del Salvador on albero render, with the ribbon. Both ribbons meet their own ends at the joint, so the border is continuous round the plaque.

The rest are simpler. One is a flat yellow band with a sprig on every tile, a five-petal flower with a white heart, a leaf each side and dots round it, for the shop signs that put one letter to a tile inside a strip. Those signs use half-height border tiles, two to each letter tile, so the border has a size of its own, whole or half, and with the band on, every letter tile gets a small curl and dots in its corners so the letters and the band read as one set. Another is a chain of rings, where the ring on the joint passes through the ring in the middle of each neighbour. There is a ribbon in two blues, which is two sine waves half a turn apart, and the last is the ruled lines on their own. Each one has to meet itself at the tile's edge, so the design is built from the edge inward, the same constraint Fajalauza's branch had and the reason it looks right at any length.

Casa. One letter to a tile with a curl in each corner, inside a band of half tiles with a sprig on each, in the santa ana colours, the corners mitred.

The one thing not drawn by rule

The Portuguese plaques go further than a border of tiles. The whole frame is one painting, a rococo cartouche of C-scrolls and shells that ignores the grid entirely and is cut into tiles afterwards. There is no repeat in it to write a rule for, so for that one border the page does what Fajalauza and Delft did for their birds and figures and uses a drawing: an image model was asked for a flat cobalt cartouche on white with an empty centre, and the page lays plain tiles, multiplies the painting over them so its white disappears into the glaze, draws the joints back through it and paints the word in the middle. It is the only border on the page that is a picture.

The cartouche: a painted frame cut into tiles, the one border on the page that is a picture rather than a rule.

The wall behind it is whitewash, an ochre render, a blue wash or a field of plain glazed tiles, and the plaque stands proud of the render with a shadow. Age crazes a few tiles, warms some and chips a corner, and stains the lime.

A banner tool

I built this one partly because I wanted it. The text goes in the query string, so a link like letras.html?text=STEP%20INTO&border=roleo&field=anil is a banner, and the save button gives you the PNG.

This site's name, as a plaque on añil. The ?text= query string makes it.

The typeface stayed on the page, because nothing else has wanted letters painted by rule yet, and a thing moves into the engine the second time a page asks for it. Sutton Hoo is next, garnet cloisonné in gold cells, the cutter's third customer.

A Faster C# Claude Client, by Breaking the Rules

stepinto.dev — Wed, 11 Nov 2026 07:21:39 +0000

Last week I wrote the C# client for the hot path the way Microsoft's templates say to write it: HttpClient, System.Text.Json nodes, a StreamReader, Console.Out, Native AOT with the size-oriented settings. That was the point of it, since the series measures what each language gives you out of the box, and out of the box C# landed at 7.1 ms on the path against Go's 4.4. I put the extra down to the loader resolving glibc and the AOT runtime starting up, and left it there, though it nagged at me all week.

I wanted to know how much of that gap is C# and how much is the defaults. So this is the same spec, the same mock, the same harness, with the "out of the box" rule removed and one of the leaderboard's own rules bent: HTTP is no longer coming from the platform. It comes from a hundred lines of hand-written HTTP/1.1 over a socket that libc opened. The result is 3.35 ms, a millisecond under Go, and the fastest row on the board as it stands. It has its own row on the leaderboard, next to the stock C# row rather than replacing it, because the two answer different questions.

The code is at github.com/AndyCross/claude-hot-path, 344 lines once blanks and comments are taken out, against 102 for the stock client.

Where the seven milliseconds went

strace -f -r on the stock client against the mock is the whole diagnosis. The run is 1,729 lines of syscalls. Before the first request leaves the process it has:

loaded glibc and libm through the dynamic loader, the 2.5 MB the leaderboard's runtime column charges it for,
started nine threads: a finalizer, a signal handler, a timer, a thread pool gate and three pool workers, and two .NET Sockets threads with an epoll instance each, because HttpClient is asynchronous all the way down even when nothing else in the program is,
opened seven probe sockets to learn which address families and options the kernel supports,
resolved the name and connected.

After the last byte of the second reply it writes a newline, returns from Main, and the runtime shuts down: the HttpClient is disposed, the connection pool is torn down, the finalizer runs, the threads are joined. The harness's tail column, from the mock finishing to the process exiting, was 2.9 ms for C# and 1.8 for Go.

None of that is slow in absolute terms. It is a few hundred microseconds here and there, and a service that lives for a day would never see it. The leaderboard counts all of it, so this client removes what it can.

HTTP by hand, over libc's socket

The spec says HTTP and TLS come from the platform where the platform has them, and .NET has them. HttpClient is a connection pool, a request pipeline, HTTP/2 and HTTP/3 negotiation, proxy detection, cookie handling and an async engine, which suits a service and is far more than a process needs when it will make two requests on one connection and exit. So this client does not use it. It calls getaddrinfo, socket, connect, read and write directly, through LibraryImport, and the project file's DirectPInvoke item makes those links resolve at build time instead of through dlopen at run time:

static unsafe partial class Native
{
    [LibraryImport("libc", StringMarshalling = StringMarshalling.Utf8)]
    private static partial int getaddrinfo(string node, string service, AddrInfo* hints, AddrInfo** res);
    [LibraryImport("libc")] private static partial int socket(int domain, int type, int protocol);
    [LibraryImport("libc")] private static partial int connect(int fd, byte* addr, uint len);
    [LibraryImport("libc")] public static partial nint read(int fd, byte* buf, nuint len);
    [LibraryImport("libc")] public static partial nint write(int fd, byte* buf, nuint len);
    [LibraryImport("libc", EntryPoint = "_exit")] public static partial void Exit(int code);

    public static int Connect(string host, int port)
    {
        var hints = new AddrInfo { Family = 2 /* AF_INET */, SockType = 1 /* SOCK_STREAM */ };
        AddrInfo* res;
        if (getaddrinfo(host, port.ToString(), &hints, &res) != 0) throw new IOException("cannot resolve " + host);
        try
        {
            for (var ai = res; ai != null; ai = ai->Next)
            {
                int fd = socket(ai->Family, ai->SockType | 0x80000 /* SOCK_CLOEXEC */, ai->Protocol);
                if (fd < 0) continue;
                int one = 1;
                setsockopt(fd, 6 /* IPPROTO_TCP */, 1 /* TCP_NODELAY */, &one, 4);
                if (connect(fd, ai->Addr, ai->AddrLen) == 0) return fd;
                close(fd);
            }
        }
        finally { freeaddrinfo(res); }
        throw new IOException("cannot connect to " + host);
    }
}

The hints ask for IPv4 only, so the resolver sends one query instead of an A and an AAAA. On top of the descriptor sits a Stream subclass whose Read and Write are read(2) and write(2) and nothing else, so that SslStream has something to wrap when the base URL is https. Over plain http, which is what the mock speaks, that class is the entire transport.

The HTTP itself is the smallest thing that correctly reads what Go's net/http sends back when a handler flushes: a status line, headers, and a chunked body. The reader finds \r\n\r\n, reads three digits out of the status line, scans the headers for transfer-encoding: chunked or content-length, and then hands the body back in decoded pieces, one chunk at a time, straight out of its own buffer:

public ReadOnlySpan<byte> Next()
{
    if (done) return default;
    if (chunked && remaining == 0)
    {
        int nl;
        while ((nl = buf.AsSpan(start, end - start).IndexOf("\r\n"u8)) < 0)
            if (Fill() == 0) { done = true; return default; }
        var sizeLine = buf.AsSpan(start, nl);
        int semi = sizeLine.IndexOf((byte)';');
        remaining = long.Parse(Encoding.ASCII.GetString(semi < 0 ? sizeLine : sizeLine[..semi]), NumberStyles.HexNumber);
        start += nl + 2;
        if (remaining == 0) { done = true; return default; }
    }
    if (start == end && Fill() == 0) { done = true; return default; }
    int n = remaining < 0 ? end - start : (int)Math.Min(remaining, end - start);
    var piece = buf.AsSpan(start, n);
    start += n;
    if (remaining > 0) remaining -= n;
    if (remaining == 0)
    {
        if (chunked) { while (end - start < 2) if (Fill() == 0) break; start += 2; }
        else done = true;
    }
    return piece;
}

The request goes out as one write: the fixed header bytes, built once in the constructor, then the key, the content length and the body. The connection stays open for the second turn. There is no pool, no timeout, no redirect handling and no HTTP/2, and if the API ever sends something this reader does not understand it will throw an IOException rather than cope.

Reading events without building a tree

The stock client parses each data: line into a JsonNode and walks it with indexers. That allocates a tree per event and a string per property, and then unescapes the text into another string before Console.Out encodes it back to UTF-8. This client runs a Utf8JsonReader over the line's bytes, matches property names with ValueTextEquals against UTF-8 literals, and copies the one value it cares about into a scratch buffer with CopyString, which unescapes straight into bytes:

var r = new Utf8JsonReader(line[6..]);
int kind = 0, index = 0, valLen = 0;
string sub = "", id = "", name = "";
r.Read();
while (r.Read() && r.TokenType != JsonTokenType.EndObject)
{
    if (r.ValueTextEquals("type"u8))
    {
        r.Read();
        kind = r.ValueTextEquals("content_block_start"u8) ? 1 : r.ValueTextEquals("content_block_delta"u8) ? 2
             : r.ValueTextEquals("message_delta"u8) ? 3 : 0;
    }
    else if (r.ValueTextEquals("index"u8)) { r.Read(); index = r.GetInt32(); }
    else if (r.ValueTextEquals("content_block"u8) || r.ValueTextEquals("delta"u8))
    {
        r.Read();
        while (r.Read() && r.TokenType != JsonTokenType.EndObject)
        {
            if (r.ValueTextEquals("type"u8)) { r.Read(); sub = r.GetString()!; }
            else if (r.ValueTextEquals("id"u8)) { r.Read(); id = r.GetString()!; }
            else if (r.ValueTextEquals("name"u8)) { r.Read(); name = r.GetString()!; }
            else if (r.ValueTextEquals("text"u8) || r.ValueTextEquals("partial_json"u8)) { r.Read(); valLen = r.CopyString(scratch); }
            else if (r.ValueTextEquals("stop_reason"u8)) { r.Read(); if (r.TokenType == JsonTokenType.String) stop = r.GetString(); }
            else { r.Read(); r.Skip(); }
        }
    }
    else { r.Read(); r.Skip(); }
}

A text delta then goes from the scratch buffer to file descriptor 1 in one write(2), and is appended to the block's own byte buffer for the echo. Tool input fragments are appended to a second buffer as they arrive and never parsed until the tool runs, when a second Utf8JsonReader pulls out the one timezone field. The request body on the way out is a Utf8JsonWriter over an ArrayBufferWriter, with the tool declaration as a u8 literal written through WriteRawValue and the assembled tool input written the same way, so the fragments the model sent are the bytes the model gets back.

The streaming check in the harness still passes, since there is no buffer between the socket and stdout to forget to flush.

No Console, no Uri, no shutdown

Console.Out on Unix sets up an encoder, a synchronised writer and a StreamWriter with a buffer that has to be flushed after every delta. Console.In does the same in the other direction. This client wraps descriptors 0 and 1 in the same read/write stream the socket uses, and the prompt is read as bytes and written back into the request body as bytes, never becoming a string.

System.Uri is a lot of machinery to split one string in three places. The base URL is parsed with IndexOf.

And when the last reply is in and the newline is written, the client calls _exit(0) instead of returning from Main, which skips the runtime's orderly shutdown. I expected that to show in the tail column, and it did not. The same static build with the _exit line commented out measured 3.43 ms to 3.35, which is inside the run-to-run noise, and its tail was 0.97 ms to 1.0. With no sockets engine, no pool and no thread pool, there is nothing left for the shutdown to do, and the kernel's teardown of the process is the whole tail either way. The line stays because it says plainly what the program wants, and it costs nothing.

The project file

The stock client's .csproj is tuned for size. This one is tuned for speed:

<OptimizationPreference>Speed</OptimizationPreference>
<InvariantGlobalization>true</InvariantGlobalization>
<UseSystemResourceKeys>true</UseSystemResourceKeys>
<EventSourceSupport>false</EventSourceSupport>
<StackTraceSupport>false</StackTraceSupport>
<ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
<IlcDisableReflection>true</IlcDisableReflection>
<IlcDehydrate>false</IlcDehydrate>
<StaticExecutable>true</StaticExecutable>
<PositionIndependentExecutable>false</PositionIndependentExecutable>
<StaticOpenSslLinking>true</StaticOpenSslLinking>

ConcurrentGarbageCollection off means the runtime does not start a background GC thread for a heap that will never be collected. IlcDehydrate off stops the compiler packing the runtime's type data into a compact form that the process unpacks before Main, at the price of a larger binary. IlcDisableReflection drops the reflection stack, which this client never touches. I measured those three plus Speed on the untouched stock code before changing a line of it, and they bought nothing: 6.31 ms became 6.37. Whatever the stock client is spending its time on, it is not the GC thread or the type data. They stay in the project file because they are the right settings for this program, even though they did not move the number.

The last three are the ones that change what ships. StaticExecutable on the linux-musl-arm64 runtime identifier links the whole thing against musl with no dynamic loader at all, so the image is FROM scratch and the runtime column on the leaderboard reads zero. StaticOpenSslLinking pulls OpenSSL into the binary too, because a static musl executable cannot dlopen the libssl the TLS stack would otherwise load, and that is where most of the 10.9 MB comes from. It rebuilds the crypto shim from source during publish, so the SDK image needs cmake, openssl-libs-static and zlib-static installed before dotnet publish will succeed. PositionIndependentExecutable off is the one I would not have found without running file on the output: the first static build was static-pie, which means the process relocates itself on every start, and for a binary this size that is a measurable number of page faults before the first instruction of Main. Turning it off gives a plain statically linked ELF that the kernel maps and runs.

The finished strace of a run is 260 lines, down from 1,729. One thread is created, the finalizer, because the runtime insists. After that it is one DNS query, one socket, one connect, one write per request, one write per text delta, and exit_group.

What each step bought

Every row is the same spec, the same mock and 100 runs, measured one after another on the same evening. The Go and stock C# rows on the leaderboard were measured on earlier evenings and read a little slower (4.42 and 7.09); the machine was in a better mood tonight, and the comparison that matters is between rows in this table.

	Cold start	Turnaround	Tail	On the path	Artefact	Runtime	Peak RSS	Lines
Stock C#, as posted	3.33 ms	0.92 ms	1.95 ms	6.31 ms	5.6 MB	2.5 MB	7.2 MB	102
Stock code, tuned project file	3.19 ms	0.94 ms	2.02 ms	6.37 ms	7.5 MB	2.5 MB	8.1 MB	102
Rewritten, glibc, dynamic	2.07 ms	0.76 ms	1.20 ms	4.25 ms	7.4 MB	2.5 MB	6.6 MB	344
Rewritten, static musl, orderly exit	1.59 ms	0.69 ms	0.97 ms	3.43 ms	10.9 MB	0	4.3 MB	343
Rewritten, static musl, `_exit`	1.67 ms	0.73 ms	1.00 ms	3.35 ms	10.9 MB	0	4.3 MB	344
Go, for reference	2.01 ms	0.70 ms	1.30 ms	4.11 ms	6.1 MB	0	6.3 MB	156

The rewrite is worth two milliseconds, and most of that is cold start: no sockets engine, no thread pool, no probe sockets, no Console, no Uri. On glibc, still dynamically linked, it is within a fraction of a millisecond of Go. Going static is worth most of another millisecond, takes the loader out of the cold start and the shared libraries out of the ship size, and halves the memory. The project file knobs and _exit are inside the noise.

3.35 ms on the path puts this client at the top of the board as it stands, with Go at 4.42 and the stock C# client it started from at 7.09. The languages still to come may beat it, and the C# row that matters for the series is still the stock one.

What it shows

I would not ship this client. I would ship the stock one: it is 102 lines, it uses the HTTP stack that handles proxies, HTTP/2, timeouts and certificate revocation, and nobody has to know what a chunk size line looks like to maintain it. This one has AddrInfo laid out by hand to match a C struct, a handful of constants from socket.h with comments saying which is which, and a reader that will throw on a trailer it has not seen. It is 10.9 MB because it carries its own OpenSSL, against 5.6 for the stock binary plus the 2.5 of libraries that binary borrows from the image.

The gap between the stock C# client and Go came from what the defaults build on top of the runtime. The bare start of the static binary, execve to exit_group with nothing to do, is level with Go's, and every piece on top of it can be taken away in C# with no unsafe code outside the P/Invoke class and the two stream methods that call it, because the pieces underneath (Utf8JsonReader, LibraryImport, Stream, Native AOT's static linking) are all in the box too. That is a different answer to the one the first C# post gave, and I think it is the more useful one.

How to run it

git clone https://github.com/AndyCross/claude-hot-path
cd claude-hot-path
./bench/bench.sh csharp-tuned

Docker and Python 3, no key. The build runs in the Alpine SDK image and takes about a minute, most of it compiling the OpenSSL shim. The TLS path was checked against the real API from the image with an invalid key, which returns the 401 the spec's error case wants, over HTTPS, through the same hand-written reader.

Clay in Clay

stepinto.dev — Mon, 09 Nov 2026 12:52:55 +0000

I have been building a series of pages where the computer generates the pattern: tin-glazed tiles painted by rule, cut tile and poured cement, heraldry, knotwork, a piece that breaks another piece, brick in raking light, the seventeen ways a wall can repeat and iron and silk. We've been travelling round Europe, mostly round Spain, borrowing from the art and the history of each place. This one is from England, which has its own tile, made by pressing a pattern into one clay and filling it with another.

Encaustic, the town hall preset. Buff and black and blue clay pressed into a red body, the leopard of England traced from the drawing Leonor's shields use, and the Garter motto round it.

Rosa y Granada

Rosa y Granada came first, in October, and never had a post of its own. Catherine of Aragon arrived in England in 1501 with the pomegranate of Granada as her badge, and for twenty-odd years it was carved and painted beside the Tudor rose wherever the king's works went. The page puts the two on a floor in the English medieval way, which is the inlaid tile. A red earthenware tile was pressed with a wooden stamp, the recess filled with white pipeclay slip, the surplus scraped off level, and the whole glazed with lead and fired. The lead glaze turns the white yellow and the red a deep brown. There are two colours and no brush, so the only hand in it is the stamp, cut once and pressed a thousand times, and the slip, which goes on thick in one place and thin in another.

On the page, an inlaid tile is two operations. A recess is filled with another clay, and a line of the body is left standing between two fills. Every painter on the page is one or the other. The rose is five heart-shaped petals inlaid in slip with a smaller rose of five more left standing in the red body inside it, which is how you get a red rose on a white one with only one colour to fill with. The pomegranate is the one traced for Leonor: its silhouette goes in as slip and the drawing's black lines are reserved in red.

Six hundred years later

Inlaid tiles died out in the sixteenth century and came back in the nineteenth. Samuel Wright of Shelton patented a way of making them in 1830, Herbert Minton bought a share of the patent in 1835, and A. W. N. Pugin wanted floors for the Gothic churches he was building and, from the late 1840s, for the new Palace of Westminster. Minton made them to his designs. They were called encaustic, from the Greek for burnt in, and within a generation they were in every church porch, town hall and hallway in the country.

The idea is the same and nearly everything around it changed. The body was pressed in a plaster mould and the hollows filled with liquid clay. There were four or five colours instead of two: red, buff, black, blue, sometimes white or green. The surface was left unglazed. The inlay went deep enough to outlast a century of boots, where the slip on a lot of medieval tiles was thin enough to walk off. And the tiles came out of the factory by the hundred thousand, all one size, to be set out with a string line by a contractor rather than bedded in lime by a mason.

Westminster from Rosa y Granada, westminster from Encaustic, and zaguán from Hidráulico. A medieval floor, a Victorian one, and a Barcelona one from a generation later.

One file, two recipes

The medieval material lived in Rosa y Granada's page, because nothing else needed it. Encaustic does, and a material that two pages share belongs in a file of its own rather than in the engine, which every tile page imports. The engine takes a material object with hooks for how a shape is filled, how the ground is laid, how far a tile strays from its cell, what the joint is and what age does, and it doesn't need to know that two of its pages are made of clay.

So the stamp operations, the rose and the lily moved into clay-assets/clay.js, and the material became two recipes. Each one says what the clay looks like up close (the colour functions are trimmed here):

const RECIPES = {
  // white slip in red clay under lead, 1250 to 1550
  medieval: {
    mottle: mottleOf(1501, 60, [4, 14], dark, light),
    speck: speckOf(1254, 160, [0.3, 0.8], dark, light),
    // the glaze pools against the edge of the inlay as a dark hairline
    pool: (pal, col) => hexA(pal.tint, 0.45),
    poolW: 1.1,
  },
  // clays pressed into clay in a mould, 1840 to 1900
  victorian: {
    mottle: mottleOf(1840, 40, [6, 18], dark, light),
    speck: speckOf(1851, 110, [0.25, 0.5], dark, light),
    // two plastic clays pressed together bleed a hair into each other
    pool: (pal, col) => hexA(col, 0.5),
    poolW: 0.7,
  },
};

The medieval one is heavier everywhere: more mottle where the slip went on thick and thin, more iron coming up through the glaze, a dark line where the lead pooled against the inlay. The Victorian one is flatter and finer, and the line at the edge of an inlay is the inlay's own colour, a hair of one clay pressed into the next. Around those sit the two materials. The medieval one has a glossy surface, a wide lime joint and tiles turned and shifted by hand. The Victorian one is matte, with a thin cement joint and tiles that sit almost exactly in their cells.

Moving the material is a refactor of a page that people can link to by seed, so it had to change nothing. I hashed every preset's canvas and the card thumbnails before the move and after it, and they came out byte for byte the same.

The cousins of Hidráulico

Hidráulico was the first page to use the material hook: the Azulejería engine with the glaze swapped for pigmented cement, the way every hallway in Spain was floored between 1880 and 1960. Put the three side by side and Encaustic sits between them. Like the medieval tile it is clay inlaid in clay and fired. Like the cement tile it is pressed, matte, many-coloured, made in a factory and laid by the square metre, and it wears rather than crazes. A cement tile's colours meet with no outline at all, because the brass divider lifts out and leaves them butted together. A Victorian tile's colours meet with that faint line where two wet clays touched, and a medieval tile's meet with a dark one where the glaze pooled.

The wear shows the difference best. Age on the medieval floor takes the glaze off along the walked line and the slip off the middle of each tile, so the pomegranates fade to brown ghosts. Age on the Victorian floor dulls it, works dirt into the joints, scratches it and cracks a few tiles straight across, but the pattern stays.

Nave from Rosa y Granada and porch from Encaustic, both with wear on. The medieval slip walks off; the Victorian inlay doesn't.

Gothic nouns

The motifs are the Victorian Gothic ones. Quatrefoil puts a four-lobed Gothic foil round the corner where four tiles meet, lobes on the diagonals, a lily in each lobe pointing out, and a circle round the lot. Each foil is a ring of circles whose outer arcs run from one cusp to the next, and the band is that outline at two radii filled even-odd, with a field of another clay inside when the seed wants one. Diaper is Pugin's lilies in a net of lozenges, the lozenges' points at the middle of each edge so the net runs on across the floor.

The westminster preset. Four tiles make each quatrefoil; the small foils between them are where four far corners meet.

The pugin preset: gold on red, lilies in lozenges.

A word has a right way up

The other two motifs were the hard ones, because they have a right way up. The engine's module repeat mirrors every other tile, which is how a design that only fills a quarter becomes a pattern four tiles wide. Mirror a rose and it is still a rose. Mirror a lion and he faces the other way, and mirror a motto and it is mirror writing. The single repeat lays every tile the same way up, but it builds the tile itself from four mirrored quarters, so even there a word drawn in the design comes out backwards in two of them.

So the lion and the motto are drawn once, whole, by a painter that works out where it is. The engine paints the four quarters in a fixed order, and the last of them is turned half round, so it is the only one that isn't mirrored. The painter reads the canvas transform, does nothing on the first three quarters, and on the last one throws the transform away and draws the roundel square to the tile in device pixels:

medal(el, b) {
  const { g } = b;
  const m = g.getTransform(), W = g.canvas.width;
  const quarter = Math.abs(m.e * 2 - W) < 2 && Math.abs(m.f * 2 - W) < 2;
  if (quarter && !(m.a < 0 && m.d < 0)) return;
  const cx = quarter ? 0 : 0.5, cy = cx;
  const k = Math.hypot(m.a, m.b), R = (quarter ? el.r : el.r / 2) * k;
  g.save();
  g.setTransform(1, 0, 0, 1, m.a * cx + m.c * cy + m.e, m.b * cx + m.d * cy + m.f);
  // ...the band, the motto, the field and the device, upright
  g.restore();
}

Nothing else can stop the wall itself mirroring or turning the tile, so those two motifs lay the single repeat whatever you choose, and the repeat menu changes to say so, which is also how a Victorian tiler would have laid a lettered tile.

The lettering is MedievalSharp, which is near enough to the Lombardic capitals Pugin used. A motto runs clockwise round the band from a small lozenge at the bottom, so it reads up the left side and across the top. Each letter is measured, the gaps are spread so the motto fills the ring, and a short motto goes round twice rather than spacing its letters out to the width of a tile. My first try used an uncial face, which draws H like a d, and a town hall floor that said HONI SOIT read rather differently. Where a Victorian chancel floor had scripture, mine says LOVE IS ENOUGH, after William Morris's poem of 1872, and the other roundels carry NULLIUS IN VERBA, SAPERE AUDE, NO GODS NO MASTERS and E PUR SI MUOVE. The lion is Leonor's traced leopard of England in buff, with its claws and tongue in blue on the palettes that have a blue.

The chancel preset. Words round a foil on a blue ground, laid with plain black, the cheapest tile a Victorian church could buy.

Trying it

Encaustic has six presets: westminster, pugin, town hall, chancel, a cream and chocolate Dorset church, and a porch with a hundred and fifty years of boots on it. The advanced tab has the four motifs, five palettes, the four repeats, and a mould slider that sets how loose the press was, which for a Victorian tile is not very. Double-tap for a new design. Rosa y Granada is unchanged apart from sharing its material file with Encaustic.

Azulejos de letras is next: Seville's blue-on-white street-name tiles, where the lettering is the whole tile rather than a band round the edge.

How a World Model Differs From an LLM, and Why You Want Both

stepinto.dev — Mon, 09 Nov 2026 07:24:02 +0000

The last post ended by saying the next one would put the heater model next to an LLM. This series has drawn that line twice already. The first post said that if you ask a chatbot what happens when you turn the heater on, "you'll get a fluent, plausible story about the room warming up", and the 101 post put it in a table: for "what if?", an LLM "narrates a plausible story" and a world model "rolls the trajectory forward".

I meant to repeat that comparison with the room from 104 as the example. Before writing it down a third time I thought I had better check it, so I gave Claude Opus 5.5 the same room, the same readings and the same questions I had asked the thirteen-weight model, and scored the answers against the simulator. The table in 101 turned out to be wrong, and the way it was wrong shows where each kind of model belongs.

Everything below ran on 27 October 2026 against claude-opus-5-5 at its default settings, three runs per question. Every answer, with its token count and cost, is in heater-llm-runs.csv.

The door, asked of Claude

The test room is the one from 104: 22 degrees inside, minus four outside, heater on throughout. At step 10 someone opens a door that no log records, and it stays open until step 20. In 104, at step 13, the latent model had watched the room fall three steps in a row, its private field read 0.81, and it forecast five steps ahead almost exactly.

Claude got the same fourteen readings as a CSV and nothing else.

step,room_c,outside_c,heater_until_next_step
0,22.00,-4,on
1,21.39,-4,on
...
11,13.14,-4,on
12,10.10,-4,on
13,7.76,-4,

The question was to forecast steps 14 to 18 with the heater on, and to end with the five numbers as JSON. Here is what came back, next to the real room and the 104 model.

step	real room	104 model	Claude, run 2	Claude, run 3
14	6.03	6.52	6.00	6.02
15	4.76	5.41	4.67	4.69
16	3.67	4.41	3.66	3.69
17	3.10	3.51	2.90	2.92
18	2.65	2.71	2.32	2.34
RMSE		0.53	0.18	0.16

Two runs out of three beat my model. Claude did it by spotting that the drops after step 10 shrink by a constant ratio and fitting a decay curve to them:

The behaviour changed sharply, with drops of 4.05, then 3.04, then 2.34 °C. Each drop is about 0.75–0.77 times the previous one. That is classic exponential decay toward a new, much colder equilibrium.

It put the new equilibrium at about half a degree. The true figure, from the constants hidden in the simulator, is 0.8. Then it guessed at a cause the log never mentions: "something changed around step 10. Possibly the heater failed or weakened, or a large heat loss opened up, such as a window or door."

The 104 model has a field that tracks the door but cannot name it, and Claude can name it but keeps no field, which matters again further down.

Run 1 matched the others for four steps and then forecast 1.2 degrees for step 18. It had read my "the heater stays on from step 13 to step 17" as the heater going off for the last step, said so, and gave 2.25 as the answer if it stayed on. That one is my wording, and I have left it in the scores.

With the log pasted in

The 104 model learned from 4,800 logged steps, so the fair comparison gives Claude the same 4,800 steps. As CSV that is 77,142 input tokens per question. Two of the three answers came back with the room's constants written out. Run 1 put the closed-room leak at 0.067 of the gap per step and the heater at 1.2 degrees, then found the door:

During these events the loss rate rises to about 0.25 × (room − outside), while the heater still adds about 1.2 °C.

realRoom uses 0.07, 1.2 and 0.25. Run 3 got the same three numbers and cited two episodes from the log where the door had opened ("episode 3 from 17.80 °C and episode 22 from 17.58 °C"). I checked both against the simulator's private trace, and the door was open in each.

	run 1	run 2	run 3
forecast for steps 14 to 18	6.0, 4.75, 3.85, 3.25, 2.9	6.0, 5.0, 4.6, 4.6, 4.9	6.0, 4.7, 3.8, 3.1, 2.7
RMSE against the real room	0.15	1.28	0.07

Run 3 is the best forecast anything has made of this room in the series. All three runs noticed that door events in the log end after somewhere between two and eighteen steps, and allowed for this one ending. Runs 1 and 3 nudged their last steps up a little. Run 2 leaned on it hard and blended the two cases into a forecast that levels off at 4.6 and turns back up. Its reasoning was sound, but the door stayed open. It was answering a question about a distribution with one number, which is a problem the heater model has too, and one this series comes back to.

This is what system identification looks like when the system is a textbook one. Newton's law of cooling is in every physics course Claude read, so the form of the model came for free, and the log only had to supply three numbers. My thirteen weights had to discover the form as well as the numbers, from the same rows, with no prior at all.

The same question as a decision

The reason to have a world model is to choose what to do, so the second question was a small planning problem, posed at step 5 of the same room while the door was still shut and the room was at 19.15:

I want the room at or above 12 °C at every reading from step 6 to step 25, with the heater on for as few steps as possible. Which of steps 5 to 24 should the heater be on for, and what is the lowest the room gets? And could the heater hold the room at 16 °C or above for those 20 steps if it ran the whole time?

Because I wrote the room, I know the answer. With the true constants the fewest is fifteen: coast for five steps while the room falls to 12.11, then heat for the rest. And no, the heater cannot hold 16, because at minus four outside a closed room with the heater on settles at 13.1.

This time there were three versions of Claude. One got the six readings and no tools. One got the readings and the 4,800-row log. The third got the readings and the 104 model, wrapped as a tool.

const simTool: Anthropic.Tool = {
  name: "simulate_room",
  description: "Run the room's fitted world model forward from the current reading (step 5) under a heater schedule, without touching the real heater. Returns the predicted reading at each following step.",
  input_schema: {
    type: "object",
    properties: {
      heater: {
        type: "array",
        items: { type: "string", enum: ["on", "off"] },
        description: "Heater setting from step 5 onwards, one entry per step. Entry i is the setting from step 5+i to step 6+i.",
      },
    },
    required: ["heater"],
    additionalProperties: false,
  },
  strict: true,
};

Behind the tool is the 104 model. It observes the room up to step 5, so its private field is set, and then runs act blind under whatever schedule Claude asks for, which is the rollout from 101 with learned weights.

function simulate(from: number, heater: boolean[]): number[] {
  const m = new WorldModel(latent.w); m.reset();
  for (let i = 0; i < from; i++) m.observe(truth[i], script[i], truth[i + 1]);
  let s = truth[from]; const out: number[] = [];
  for (const on of heater) { s = m.act(s, on ? "turnHeaterOn" : "turnHeaterOff"); out.push(+s.roomTemp.toFixed(2)); }
  return out;
}

The loop around it is the standard tool-use loop: send the question, run any simulate_room calls Claude makes, send the predictions back, and repeat until it answers. Each plan was then run in the real room 200 times, with fresh draughts each time and the door shut.

	heater steps	lowest, as Claude said	real lowest, mean of 200	stays at 12 or above
true optimum	15		12.08	125 of 200
Claude, readings only (all three runs)	16	12.9	13.00	200 of 200
Claude with the log, run 1	15	12.11	12.08	125 of 200
Claude with the log, runs 2 and 3	16	12.9, 12.7	13.00	200 of 200
Claude with the 104 model, runs 2 and 3	13	12.04	10.61	0 of 200
Claude with the 104 model, run 1	13	12.27	10.95	0 of 200

Every run answered the 16 degree question correctly. On the schedule, Claude with six readings fitted a leak of 0.076 and a heater of 1.30, worked out that the heater settles the room at about 13.2, and chose to coast for four steps and heat for sixteen, leaving a margin of about 0.9 degrees, "which allows for some error in the fitted model". Claude with the log found the true optimum once, to the hundredth of a degree, and noted that its margin was 0.1 and that switching on a step earlier would be safer. The other two log runs took that safer option.

Claude with my world model as a tool did worst. It made seven to nine calls, reasoned carefully about each result, and settled on thirteen heater steps with a predicted low of 12.04. In the real room that plan drops to 10.6, every time.

Why the tool made it worse

Claude's search was fine. I tried all 1,048,576 schedules against the 104 model, which took about two seconds, and the fewest heater steps it allows is thirteen as well. Claude found a thirteen-step plan in seven to nine calls. The model's optimum is wrong.

One run's second call was the heater off for all twenty steps. The model said the room would end at 5.25 degrees. The real room ends at about 1.4. Every outside temperature in the training log was between 2 and 12 degrees. At minus four, with the heater off for long stretches, the model is well outside anything it has seen, and its weights do not extrapolate the way physics does. The 104 post noted that the latent model's room and outside weights were no longer equal and opposite, and that the gradient had found "a different split that fits the log just as well". That split fits the log, and it does not fit minus four. The five-step forecasts in 104 were close because five steps is not long enough for the error to build up, and twenty steps is.

The heater left off for twenty steps from the step 5 reading, door shut. The 104 model agrees with the room for about five steps and then cools too slowly, ending almost four degrees warm. The green line is the model from the next section.

Download the data (CSV)

So the world model gave confident, wrong numbers, and Claude believed them, as it should have done with nothing to say otherwise. The tool returned a list of temperatures with no sign that the last fifteen of them were guesswork. The plan that is cheapest on a flawed model is the one that runs closest to the model's flaws, because that is where the model is most generous. Any search does this, whether the searcher is an LLM or a loop over every schedule there is.

Claude on its own did better because it brought a prior. A leak proportional to the temperature difference, plus a constant from the heater, is the right shape for this room, and Claude knew that shape before it saw a reading. My thirteen weights had no prior to bring, and away from their data that cost them.

Giving the model Claude's shape

The first thing I tried was more data. Refitted on logs that include days down to minus six, the thirteen weights swung the other way and predicted a heater-off room colder than the outside air, which no room can be. The problem was the shape of the model, which more data does not change.

Claude had already described the right one. The runs that saw the log, between them, spelled it out: a leak proportional to the gap between inside and outside, a constant from the heater, and a second, bigger leak that comes and goes. The 104 model can have that shape without giving up anything that made it a world model. The private field stays, observe stays, and the backwards walk through each episode stays. Only act changes.

act(state: State, action: Action): State {
  const w = this.w, heaterOn = heaterAfter(state, action);
  const gap = state.outsideTemp - state.roomTemp;
  const change = (w.leak + w.doorLeak * this.#field) * gap + (heaterOn ? w.heat : 0);
  return { roomTemp: state.roomTemp + change, outsideTemp: state.outsideTemp, heaterOn };
}

That is three prediction weights instead of seven, nine weights in all, trained on the same 4,800 rows for the same three thousand epochs, in under half a second. It has no bias term. The physics has none, and with one in, the fit traded the bias off against the leak and ended up more than five degrees too cold after twenty steps with the heater off. I made that choice after seeing round one, so weigh the result knowing it was not decided in advance.

What came out reads like the inside of realRoom. With the field at its door-shut level the leak works out at 0.072, against a true 0.07. With the door open the field goes to 0.97 and the leak to 0.245, against a true 0.25. The heater is 1.16, against 1.2. The field became the door again, and this time the weights around it are the room's own constants.

	door forecast RMSE	heater off for twenty steps, step 25 (real 1.42)	fewest heater steps on the model	that plan in the real room
104 model	0.53	5.25	13	lowest 10.83, safe in 0 of 200
physics-shaped model	0.10	1.15	16	lowest 13.00, safe in 200 of 200

Every forecast of steps 14 to 18 with the door open, as the root mean square error against the real room. Claude's runs spread from 0.07 to 1.28. Each model gives one answer, every time.

Download the data (CSV)

The door forecast of 0.10 beats five of Claude's six forecasts, and the model gives the same answer every time it is asked. Then I gave Claude this model as the tool instead, with the same question. All three runs settled on sixteen heater steps after three to five calls, and the plan held the room above 12 in all 200 draws. Claude also explained the plan better than I would have:

One step of heating is worth most at the end, because its warmth has less time to leak away before step 25. An off step is cheapest early on.

The plan Claude chose with each model as its tool. Dashed is what the model said would happen, solid is the real room, averaged over 200 runs with the door shut. The strip underneath shows which steps had the heater on. The 104 model promised the room would stay above 12 and it fell to 10.6; the physics-shaped model was slightly pessimistic, and the room stayed above 13.

Download the data (CSV)

Sixteen is one more than the true minimum. The model is about six tenths of a degree pessimistic at the bottom of the plan, so it asks for an extra step. The fifteen-step plan leaves a tenth of a degree to spare and dips below 12 in 75 of the 200 draws, so I would take the extra step anyway, though the model did not choose it for that reason.

What each answer cost

With the right shape, the world model matches Claude on accuracy and is a long way ahead on cost.

	input tokens	output tokens	seconds	dollars at list price
forecast, readings only	270	1,410 to 1,833	14 to 19	0.03 to 0.04
forecast, with the log	77,142	2,266 to 2,290	25 to 26	0.35
plan, readings only	297	2,423 to 3,863	26 to 42	0.05 to 0.08
plan, with the log	77,169	5,235 to 8,713	59 to 97	0.41 to 0.48
plan, with the 104 model as a tool	15,005 to 16,777	3,164 to 3,995	43 to 53	0.13 to 0.14
plan, with the physics-shaped model as a tool	4,184 to 10,744	2,148 to 2,912	34 to 36	0.06 to 0.10
either model, all 1,048,576 schedules			about 2	0

A twenty-step rollout of either model takes about two microseconds. A forecast from Claude with the log takes 25 seconds and 35 cents. That is a factor of more than ten million in time. Planning properly means rolling the model forward thousands of times per decision, and a thermostat makes a decision every step. Monitoring means running the model alongside every device, all the time.

Then there is the size of the log. The 4,800 rows of one simulated room were 77,142 tokens. A real device logging once a minute produces 525,600 rows a year, about 8.4 million tokens at the same rate. That is eight times Claude's context window for a year of one device, before anyone mentions a second device or a second sensor channel. Nine weights are a summary of the log that never needs re-reading. Claude re-reads the whole log on every question, which is the 102 post's point about the LLM equation made literal: the condition on the right of the bar is the entire history, and every call pays for all of it.

The usual objection is that you cannot train an LLM on your telemetry. That turned out to be beside the point, because Claude did not need training to fit this room. It needed the log pasted in, and pasting is where the trouble is. Every question sends the customer's telemetry to someone else's servers, and the thing answering lives behind an API that, as this June showed, can stop answering overnight. A heater controller that needs a call across the Atlantic to work out what to do next has a single point of failure in another jurisdiction.

Where each one belongs

Round one went to Claude, and round two went to the world model with Claude's help. What the two have is different sets of properties, and the system you want puts each kind of model where its properties fit.

The world model belongs in the loop. It is small, fixed, local and fast enough to be called a million times per decision, on the device, with nothing leaving the building. Its weakness is that it knows only its data and the shape it was given, and it does not know where either stops being true.

The LLM belongs at the edges, and the experiment showed three edges where it was the better tool.

Intent. "At or above 12 at every reading, as few heater steps as possible" is how a person states a goal. Claude turned it into a constraint and an objective without being asked to, and its answer to the 16 degree question was correct every time. A planner needs that translation done before it can start, and a person should not have to write the objective function themselves.
Names. The latent model's field went to 0.9 when the door opened, and nothing in the model can say what 0.9 means. Claude, shown the same readings, said "a window or door". Nobody acts on a monitor that says "the field has risen", but "this looks like a window has been left open" gets the window closed.
Structure. The form Claude proposed from the log (a leak proportional to the difference, a constant heater gain and a second, larger leak that comes and goes) turned out to be a better model of this room than my thirteen weights. Round two is the small version of letting an LLM propose the shape and then fitting and running that shape locally on the real data, which puts its prior and the world model's speed in the same system.

The LLM takes the goal in and the explanation out, and proposes the model's shape once. Everything inside the dashed box runs on the device, every step, with no network.

So the shape is an LLM on the outside, a world model on the inside, and a planner between them. A person states a goal. The LLM turns it into an objective. The planner rolls the world model forward as many times as it needs. The LLM explains the plan, says when the model's predictions and the room have parted company, and puts a name on the reason. Only the middle of that has to run every step, and none of the middle needs a network connection.

Round one showed the condition the whole arrangement depends on. A world model handed to an LLM as a tool gets believed. If it does not say how sure it is, the LLM cannot tell its good predictions from its bad ones, and a better LLM will only exploit the bad ones more efficiently. The physics-shaped model was right this time, and it would have been believed just as readily if it had been wrong.

The 101 post said that an LLM asked "what if?" narrates a plausible story. For a room whose physics is in the textbooks, that is no longer true. Given the readings, Claude fitted a model and rolled it forward in its reasoning, and did it well. The part of 101 that held up is the part this post kept running into: Claude keeps no state between calls, so every answer starts again from the readings and pays for the whole log.

The next post builds the physics-shaped model properly, into the playground next to the 104 one, and puts a planner on top of it. Claude's three to five tool calls were a search done by hand, and the planner runs thousands of rollouts per decision, with a plan button to go with it. After that comes the warning the tool here never gave, which is a model that can say where its own predictions stop being worth trusting. Every answer from this post, with its token count and cost, is in heater-llm-runs.csv.

Iron and Silk

stepinto.dev — Fri, 06 Nov 2026 15:58:54 +0000

I have been building a series of pages where the computer generates the pattern: tin-glazed tiles painted by rule, cut tile and poured cement, heraldry, knotwork, a piece that breaks another piece, brick in raking light and, this morning, the seventeen ways a wall can repeat. The brick piece, Sebka, drew nothing in shadow. The wall had three heights, the sun was a direction, and every shadow was a level's own outline moved along the sun's slant. That rule turned out to have two more pieces in it, and they are about as different as two materials can be: wrought iron, which is all shadow, and embroidered silk, which is all shine.

Mantón de Manila, the feria preset. Every petal is satin stitch with a direction, and the direction is what the light sees.

Rejería

Every window in Seville and Córdoba has a reja, and the balconies have grilles. Bars, rails, a frieze of scrolls along the rail, rivets where the bars pass through, and a twist in each bar where the smith heated it and turned it. The repeat is one-dimensional. A frieze is one motif set out once per bay and going on for ever, with a rosette every few bays, and the bars are the other direction's repeat. The two together are the whole grille.

The motifs are all one function. A scroll is a bar that leaves a root along a heading and winds in, tightening as it goes:

function scroll(rx, ry, heading, R, turns, sense) {
  const cx = rx + R * Math.cos(heading + sense * Math.PI / 2);
  const cy = ry + R * Math.sin(heading + sense * Math.PI / 2);
  const a0 = Math.atan2(ry - cy, rx - cx), pts = [];
  for (let i = 0; i <= 40; i++) {
    const t = i / 40, phi = t * turns * TAU, r = R * (1 - 0.72 * t * t - 0.1 * t);
    pts.push([cx + r * Math.cos(a0 + sense * phi), cy + r * Math.sin(a0 + sense * phi)]);
  }
  return pts;
}

Two of those from a root at the middle of a bay's edge, one heading up and one down, is a C. Two from the bay's centre heading opposite ways with the same sense is an S. Two from the bottom point heading up and outward and curling in at the top is a heart, and from the same point curling the other way, with a bar between, a lyre. The rosette is a ring with eight of them radiating, alternately turning.

The córdoba preset. Hearts along the rail, an ochre patio wall, the sun low at half past five.

The grille is one path

The piece is the shadow. The grille stands off the wall by a distance you set, from a finger's width to half a bay, and the sun is Sebka's sun: along the wall from the left at six, in front at one, along it to the right at eight. Everything the grille is made of, the rectangles of bars and rails, the polylines of scrolls, the discs of rivets, is one path. It is drawn once in the sky's shade colour onto a layer, moved along the sun's slant by the stand-off, blurred in proportion to the stand-off, and multiplied onto the wall. Then it is drawn again in iron, with a highlight down the side toward the sun, which is the only lighting the iron gets.

The sevilla preset at three stand-offs. The geometry and the sun are the same; only the gap between iron and wall changes.

That is the whole trick and it took one afternoon, which is what a rule you already have should cost. The second afternoon went on the iron being iron: the twist drawn as alternating lit and dark stripes clipped to the bar, the rivets as domes lit on the sun's side, gilt on the scroll tips for the cathedral preset, and rust running down the lime from under every rivet when age is on.

The catedral preset, up close. Black iron and gilt on the tips of the scrolls, after the big rejas of Seville cathedral.

Mantón de Manila

The shawl of the feria is a square of silk, black or cream or red, embroidered edge to edge with roses, peonies, leaves and the odd bird, finished with a knotted net and a long fringe. It came from Canton by way of Manila on the galleon to Seville, and Seville made it its own.

The material is thread. Satin stitch lays silk side by side in one direction across a shape, and silk shines where the light falls across the thread rather than along it. So every shape in the embroidery carries one number beyond its outline and colour: the angle its stitches run at. A petal is stitched from the centre outward, so its direction is its angle round the flower. A leaf is two halves, each stitched at an angle to the midrib, so the two faces never shine together. The swallow is traced from a flat drawing, the way Fajalauza's bird was, and its body, wings and tail are each stitched along their own line. The brightness of a shape is how far its stitch angle is from the light:

const lit = (d, L) => Math.abs(Math.sin(d - L));

Nothing is shaded by hand. The fill is the thread's colour pulled toward its dark face by how little it is lit, and over it the threads themselves are drawn, lines along the stitch direction with a shine between them whose strength is that same number. Turn the light slider and the roses light up petal by petal as each one's angle comes round, and the leaves swap which half is bright.

The same bouquet under three lights. The petals that shine are the ones whose stitches run across the light.

Black on black

A mourning shawl is black silk embroidered in black, and it is the best test of the idea, because colour cannot help. The luto preset turns the sheen all the way up and gives every thread the same near-black. The flowers are there only because their stitches run in different directions from the silk and from each other.

The luto preset. No colour at all; every shape is told from the ground by the angle of its thread.

The silk itself gets a broad shine along the light's direction and a weave of fine lines across it. The shawl hangs from a rail along its top edge, with its shadow on the wall behind, so the knotted net and the fringe fall down the sides and below. Each thread of the fringe is its own line with a wave in it, lit by the same rule, which for a hanging thread means it shines when the light is from the side.

The tarde preset on cream silk with the light low from the left. The dark outer petals and the bright inner ones are the same colour pair at different angles.

What the two share

Rejería has no lighting model beyond a highlight; the sun's whole job is to move a shadow. The mantón has no shadows beyond the one the shawl throws on the wall; the light's whole job is to pick which threads shine. Both pages are the same shape underneath: a geometry built once from a seed, a light that is one angle, and a rule that turns the angle into what you see. Sebka had three heights and a slant. Rejería has one height and a slant. The mantón has no heights at all, just a direction per stitch. The sheen pass is the thing this one leaves behind, and it will come back the next time a page needs metal to catch the light.

The Seventeen Ways a Wall Can Repeat

stepinto.dev — Fri, 06 Nov 2026 14:09:10 +0000

I have been building a series of pages where the computer generates the pattern: tin-glazed tiles painted by rule, cut tile and poured cement, heraldry, knotwork, a piece that breaks another piece, and last time brick in raking light and Granada's green and blue. The tile walls in that run all repeat the same way. A square design is laid four times, mirrored or turned, and the wall is that block over and over. It worked for every wall so far, and it is one of seventeen.

One sprig, the same seed, and the seventeen groups. The sprig never changes. The group is what the wall does with it.

Every repeating pattern in the plane has one of seventeen symmetry groups. This was proved in 1891 by Evgraf Fedorov, a crystallographer who was after the 230 groups of three dimensions and did the plane on the way, and the groups are called the wallpaper groups because wallpaper is where most people meet them. A wallpaper is a repeating pattern, so it has one of these seventeen symmetries whether its designer knew or not. William Morris did not know, as far as I can tell, and his papers still sort neatly into the groups: a mirror here, a glide there, a trellis with mirrors both ways. Papel Pintado draws one sprig in a square and makes the group a control.

What a group is, on a wall

A symmetry of a pattern is a movement that leaves it looking the same. Slide a wallpaper by one repeat and it looks the same, so translation is a symmetry of every wallpaper. The seventeen groups are the seventeen ways you can add to that: a half turn, a quarter turn, a third of a turn, a mirror, a glide (reflect and slide along the mirror by half a repeat), and the combinations of those that are consistent with a lattice. There is no fifth of a turn because pentagons do not tile, which is also why Çini has to work so hard for its stars.

The engine's old repeats are three of the seventeen in disguise. Lay a diagonal-symmetric tile four times mirrored and you have pmm; lay it four times turned and you have p4; and because the tile is symmetric across its own diagonal, the mirrored module is actually p4m, the kaleidoscope. The new page's sprigs are deliberately asymmetric, because a symmetric design hides the group. Give p1 a tile with a mirror in it and what you see is cm.

Each group in the engine is three things:

pgg: {
  cell: [[2, 0], [0, 2]],
  domain: null,
  copies: [I, glide, rotate(PI, 1, 1), mul(translate(2, -2), mul(glide, rotate(PI, 1, 1)))],
  lattice: 'rectangular', note: 'glides both ways and never a mirror',
},

The cell is the lattice, two vectors in tiles. The domain is the part of the tile that is drawn: the whole square for twelve of the groups, half of it cut along a diagonal for cmm, p4m and p4g, and for the five hexagonal groups the 60° rhombus whose long diagonal runs from corner to corner, or a third, a sixth or a twelfth of it. The copies are the matrices that lay the domain out inside one cell. Lay the cell at every lattice point and the plane is covered exactly once. The wall's painter walks the cells a window touches, and for each copy sets the transform, clips to the domain, and draws the tile image into it.

pm, pg and cm with the willow inks. A mirror, a glide, and a mirror on a lattice whose rows step by half.

Every domain keeps the design's main corner. For the hexagonal groups that matters, because the twelfth of a rhombus that p6m draws is a thin wedge, and it is the wedge with the root of the sprig in it. Twelve copies of that wedge about a point is a rosette, and the cuts heal, because wherever the domain is cut by a mirror line the two halves of a cut bloom meet their own reflection and close. Only a cut across a translation leaves a seam, and that is the seam every tile wall has had from the start.

Checked before it was looked at

I did not trust myself to get seventeen groups right by eye, and some of the pairs are easy to confuse. p3m1 and p31m both have thirds of a turn and mirrors; the difference is whether every centre of rotation sits on a mirror line. pmg and pgg both have half turns; one has a mirror and the other only glides. So before the page existed, two scripts checked the module.

The first drops thousands of random points on the plane and counts how many copies of the domain each one falls in. The answer has to be one, for every group, every time, and it was. The second takes three asymmetric points in the domain, generates their orbit under the group, and then tries candidate symmetries against it: rotations of every order about a grid of centres, and reflections in lines at every multiple of fifteen degrees. For each group it reports the highest rotation order, how many mirror directions there are, and whether the rotation centres sit on mirrors. That table matched the textbook for all seventeen, once I had taught the checker to look at fifteen degrees and at the irrational centres the hexagonal groups use.

p3m1 and p31m, same seed, same inks. Both have thirds of a turn and mirrors. In the first every centre is on a mirror; in the second one kind of centre is not, and the blooms gather there in threes.

Block print

The material is wallpaper, which was printed from blocks: one block per colour, pressed by hand down the length of the paper, and the blocks never land quite where the last one did. On the page each colour's block is given a small random offset per tile, and the key block, the dark outline, has its own. The register slider is how far they stray. At the far end of it the outline sits visibly beside the colour it was meant to enclose, which is how a Morris paper looks if you get close to it.

The trellis preset with the register slider all the way up. Each colour is its own block and none of them agree.

The inks are flat, because block printing is flat. The paper has fibres lying every way, drawn once per tile, and clouds of tint laid over the whole sheet rather than per tile, since a sheet of paper is one sheet and nothing on it may show where a tile ends. The first version put the clouds on the tile, and the lattice showed through as hexagons behind the jasmine. Age foxes the paper with brown spots, yellows it, and fades it where the sun has been.

The strawberry preset, pgg: glides both ways and never a mirror. Red and cream on indigo, after the paper of the same name.

The presets are named for Morris papers because the groups they use are the groups those papers use. Trellis is pmm. Willow Bough glides, so willow is pg. Daisy is p6m, which turns the sprig into a snowflake, and honeysuckle is cm, mirrors with every row stepped by half.

What it leaves behind

The groups went into the engine as a module of their own, groups.js in azulejeria 2.4.0, and any wall built on the engine can now set its repeat to a group's name. The four classic repeats and the whole-tile picture are untouched: every preset on every existing page renders byte for byte as it did before, which was checked the way the engine's notes insist on, by hashing every canvas before and after.

There is a second new piece this week, Rejería, wrought iron and its shadow on whitewash, where the repeat is one-dimensional, a frieze of scrolls along a rail, and the piece is the shadow the grille throws. It gets its post together with the embroidered silk it will share a light with.

Rejería, the úbeda preset. The grille stands half a bay off the wall and the sun is at seven in the evening.

Reading the AI Act One Article at a Time

stepinto.dev — Fri, 06 Nov 2026 09:24:19 +0000

The two posts I wrote in February about building AI platforms under European law, compliance-as-code and fine-tuning, stop at the architecture. They say where the compliance layer sits and not much about what goes in it. The AI Act is written in clauses, and each clause ends up as something specific in the code: a field in a log, a state in the UI, a test in CI. Most of what I read about the Act is written for lawyers or for the board, and very little of it gets as far as a pull request.

So from today, Fridays on this blog are for AI law. Each week I take one article of the EU AI Act, or one of the UK's rules on automated decisions, put the text up verbatim, and annotate every clause for the engineers who have to build to it. The first is Article 50, on 20 November.

The Digital Omnibus came into force on 27 July and moved the high-risk obligations for Annex III systems (recruitment, credit scoring, education, essential services) to 2 December 2027. Most teams now know the date and have not started building, which makes this a good year to read the text properly.

What a page looks like

Each post is one whole article, with the text front and centre. Click a clause, or tap it on a phone, and a panel opens with the clause quoted with its pinpoint, a plain reading of what it means, and the notes. Notes come in five kinds, each with its own colour, and you can filter by kind: software, contested, guidance, elsewhere in the law, and dates.

This is one clause from the Article 50 page, as the panel shows it.

Article 50(2), the standard editing exception

"This obligation shall not apply to the extent the AI systems perform an assistive function for standard editing"

What it means. Tools that only help prepare existing content for publication (grammar, spelling, formatting, compression, red-eye removal) need not mark their output as AI-generated. Once the change affects meaning, style or intent, it is no longer standard editing.

Software. One system can be exempt for some outputs and not others. "Fix grammar" is standard editing, while "Rewrite in a formal tone" changes style and must be marked, and the Commission's guidelines confirm the exception applies to the altered content rather than to the system as a whole. So the code that applies the mark needs to know which feature produced each output. A single marked: true at the API gateway either over-marks the spellchecker or under-marks the rewriter. (Guidelines ¶92)

Contested. The guidelines' own list of standard editing includes "AI-generated translations of text", next to spellchecking. A translation can change meaning, and the same guidelines say editing stops being standard when it does. A translation that localises tone and idiom for a market is rather close to the rewriting they say must be marked. (Guidelines ¶90, ¶92)

The Article 50 page has 33 clauses and 38 notes like that. Every clause and note has its own link, which is handy when you want to send someone the exact sentence you are arguing about.

Notes keep arriving after a post goes out

Publishing a post doesn't freeze the page. When new guidance comes out, or someone tells me I have read a clause wrong, I add a note with the date it went in, and the log at the foot of the page lists every change by date. A few lawyers I know are reading the drafts, and when they correct me the correction goes in as a dated note with their name on it.

The first three

20 November. Article 50, the transparency duties: telling people they're talking to an AI, and marking generated content. It has applied since 2 August, and the grace period for marking output from systems already on the market ends on 2 December.
27 November. Article 6, which decides whether your system is high-risk, with its four exceptions at the centre.
4 December. Article 26, the duties of deployers, the companies that use a high-risk system rather than build it.

I am an engineer, not a lawyer, so treat all of this as an engineer's reading and not as legal advice.

A Claude Client in One C# File, Compiled Ahead of Time

stepinto.dev — Thu, 05 Nov 2026 07:21:51 +0000

Last week's client was Go: a 5.8 MB static binary that starts in under two milliseconds, which is a high bar for any language with HTTP in its standard library. This week it's C#. .NET has had everything the spec needs in the box for a decade, and since .NET 8 it has had Native AOT, which compiles the whole program to a single native executable with no runtime to install. I wanted to know whether that gets a C# client anywhere near Go on size and cold start. It gets closer than I expected, though the runtime column on the leaderboard shows what the binary size leaves out.

The code is at github.com/AndyCross/claude-hot-path, and the spec every client passes is at /claude-hot-path/.

JsonNode, not source generators

The idiomatic way to do JSON in AOT .NET is System.Text.Json with a source-generated JsonSerializerContext, so the serialiser knows every type at compile time and nothing needs reflection. For a client this small I went the other way and used JsonNode, the DOM API, because the request body and the event payloads are built and read dynamically anyway and a context class would have doubled the file.

That choice runs into AOT's trimming analysis in one place. JsonArray.Add<T>(T) is generic, and when T is JsonObject the compiler warns that creating a JsonValue from a non-primitive type needs runtime code generation. It is a false alarm here, because a JsonObject is a node and gets added as one, but the fix is to say so with a cast:

messages.Add((JsonNode)new JsonObject { ["role"] = "assistant", ["content"] = content.DeepClone() });

Four casts and the publish is warning-free. The rest of the project file is the usual AOT size settings:

<PublishAot>true</PublishAot>
<StripSymbols>true</StripSymbols>
<OptimizationPreference>Size</OptimizationPreference>
<InvariantGlobalization>true</InvariantGlobalization>
<UseSystemResourceKeys>true</UseSystemResourceKeys>
<EventSourceSupport>false</EventSourceSupport>
<StackTraceSupport>false</StackTraceSupport>

InvariantGlobalization is the big one. Without it the binary carries ICU for culture-aware string handling, and a client that compares a few ASCII event names does not need any of it.

Headers first, then the stream

The one line that makes streaming work in HttpClient is the completion option. By default SendAsync buffers the whole response body before returning, which for an SSE stream means waiting for the model to finish before printing anything, and the harness fails a client that does that:

using var resp = await http.SendAsync(req, HttpCompletionOption.ResponseHeadersRead);

With headers-read completion the body is a live stream, and a StreamReader over it gives the same line loop as Go's scanner:

using var reader = new StreamReader(await resp.Content.ReadAsStreamAsync());
while (await reader.ReadLineAsync() is { } line)
{
    if (!line.StartsWith("data: ", StringComparison.Ordinal)) continue;
    var ev = JsonNode.Parse(line.Substring(6))!;
    var index = (int?)ev["index"] ?? 0;
    switch ((string?)ev["type"])
    {
        case "content_block_start":
            content.Add(ev["content_block"]!.DeepClone());
            partial.Add(new StringBuilder());
            break;
        case "content_block_delta":
            var delta = ev["delta"]!;
            if ((string?)delta["type"] == "text_delta")
            {
                var text = (string)delta["text"]!;
                stdout.Write(text); stdout.Flush();
                content[index]!["text"] = (string?)content[index]!["text"] + text;
            }
            else if ((string?)delta["type"] == "input_json_delta")
                partial[index].Append((string?)delta["partial_json"]);
            break;
        case "content_block_stop":
            if ((string?)content[index]!["type"] == "tool_use" && partial[index].Length > 0)
                content[index]!["input"] = JsonNode.Parse(partial[index].ToString());
            break;
        case "message_delta":
            stop = (string?)ev["delta"]?["stop_reason"];
            break;
    }
}

The stdout.Flush() is there because Console.Out is buffered when it is not a terminal, and under the harness it never is. Go's os.Stdout is unbuffered and the bash client's printf goes straight out, so this is the first client where streaming could have silently become batching.

The second turn echoes the assistant content back with DeepClone(), because a JsonNode can only have one parent and the same array is about to be the content of a message inside messages and the source of the tool_result blocks. TimeZoneInfo.FindSystemTimeZoneById takes IANA names on Linux directly, so the tool is three lines and no conversion table.

What it measures as

	C# Native AOT	Go	bash and curl
Artefact	5.4 MB	5.8 MB	3.7 KB
Runtime	2.4 MB	0	23.7 MB
Ship	7.8 MB	5.8 MB	23.7 MB
Cold start, median of 100	3.0 ms	1.7 ms	7.0 ms
Turnaround, median of 100	1.4 ms	1.2 ms	19.1 ms
Client total, median of 100	7.1 ms	4.8 ms	35.3 ms
Peak RSS	7 MB	6 MB	11 MB
Lines of code	102	156	75

What each row means:

Artefact is the file the build produces: the native executable for C# and Go, the script for bash.
Runtime is everything else that has to be in the image for it to run. For C# that's glibc, libgcc_s and the dynamic loader. Go needs nothing. Bash needs bash, curl and every library they link.
Ship is the two added together, which is what you actually deploy.
Cold start is from the process spawning to the first request reaching the mock API.
Turnaround is from the first reply finishing to the second request arriving: parsing the stream, running the tool and sending the next request.
Client total is every millisecond of the run when the mock wasn't streaming, including the tail after the last reply.
Peak RSS is the most memory the process held at once.
Lines of code counts the non-blank, non-comment lines of the one source file.

The timings are medians of 100 runs, taken from timestamps the mock recorded, with nothing subtracted.

.NET SDK 10.0.402, linux/arm64, Apple M4 Max under Docker. Published with -r linux-arm64 and the project settings above, run from the runtime-deps image.

The binary is smaller than Go's, which surprised me and will surprise more people. It is also not the whole story, and this is the reason the leaderboard has a runtime column. The Go binary is static. The .NET one links glibc, libgcc_s and the dynamic loader, and ldd on it finds 2.4 MB of shared libraries that have to be in the image. Add them and .NET ships 7.8 MB to Go's 5.8. Leave them out and you have an image that does not start. The runtime-deps base image exists for exactly this reason. Its chiseled variant is smaller still, and has no shell, which is why the harness measures from the exported image rather than by running commands inside it.

Cold start is three milliseconds against Go's under-two. The extra millisecond is the loader resolving those libraries and the AOT runtime initialising its GC, and it is a long way short of what a JIT-compiled .NET console app spends before it reaches Main. The turnaround between the two requests is within a fraction of a millisecond of Go's, and peak memory is about the same. For a language that spent twenty years needing a runtime installed on the box, that table is a remarkable place to have got to.

How to run it

git clone https://github.com/AndyCross/claude-hot-path
cd claude-hot-path
./bench/bench.sh csharp

Docker and Python 3, no key. The AOT publish needs clang and zlib1g-dev in the SDK image, which the Dockerfile installs, and takes about a minute. Next week is Rust, the first client in the series without HTTP in its standard library.

Light on Brick, Paint on Cream

stepinto.dev — Wed, 04 Nov 2026 10:51:39 +0000

Then the light's gone over the fence to someone else's garden,
And the flowers stand there in the blue, keeping the colour to themselves

Last Light

I've been building a series of pages where the computer generates the pattern: tin-glazed tiles painted by rule, then cut tile and poured cement, heraldry, knotwork and, last time, a piece that breaks another piece. They've been travelling round Europe, borrowing from the art and the history of each place, and trying to capture something about how patterns repeat across the whole of the artistic world. These two are Andalusia again, Seville and Granada, and they sit at opposite ends of what a page can do with a pattern. Sebka paints nothing and lights everything. Fajalauza lights nothing and is all paint.

The tarde preset. The Giralda's net at half past six in the evening, the sun low on the right and every lobe throwing a long tooth of shade.

One shape on a lozenge grid

The net on the upper storeys of the Giralda is called sebka, and it turns up on the Mudéjar towers of Teruel and Calatayud, on the Hassan tower in Rabat and the Kutubiyya in Marrakech. Lobed arches spring from a row of columns and go on crossing each other up the wall, so the face becomes a lattice of rhombi with every side scalloped.

It's the simplest rule I've written for any of these pages. Set out a lozenge grid. Take each lozenge, shrink it by the width of the band, scallop its sides inward with the number of lobes you've asked for, and cut it out of a brick face as an opening. The lattice is whatever brick is left between the holes. The bottom row are the same shape with their lower halves dropped down to the imposts, on jambs, so the net ends on a row of marble colonnettes the way the real ones do. Pilasters and string courses stand in front and divide the wall into panels. The geometry stops there, and everything else on the page is light.

Every shadow is cast

The face has three heights: the sunk openings and the fields of the arcade, the brick face itself, and the courses and pilasters standing proud of it. The sun is a direction. The wall faces south, the sun comes up on the left at six, stands highest at one and sets on the right at eight, and from its angle the page works out a slant: how far along the wall a point standing one unit proud throws its shadow.

Nothing on the page is drawn in shadow. Each level's shadow on the level below is that level's own outline, moved along the slant by the drop between them, with the caster cut back out of it. On an offscreen canvas that comes to a handful of compositing operations:

// the face onto the openings, one drop down
pathAll(lg, sunk); lg.fill();
lg.globalCompositeOperation = 'destination-out';
pathAll(lg, mv(sunk, 1)); lg.fill();
// courses and pilasters onto the openings, two drops down
lg.globalCompositeOperation = 'source-over';
lg.save(); pathAll(lg, sunk); lg.clip();
pathAll(lg, mv(proud, 2)); lg.fill();

Filling the opening and then punching out the same opening moved along the sun leaves a crescent on the side the light comes from, which is the shadow of the brick lip on the floor of the hole. A course standing two units proud throws its shadow twice as far into the openings below. The layer is laid over the wall with multiply, softened by a small blur so the edge isn't a knife cut, and made deeper the more squarely the sun strikes, without ever reaching black.

The giralda preset at half past seven, half past twelve and half past six. The geometry is identical in all three; only the sun has moved.

A shadow on a sunny wall isn't a darker version of the wall. It's the wall lit by the sky instead of the sun, so it goes blue, and it goes bluer when the sun is low and orange. The sun on the page has a colour of its own, near white at height and gold at the horizon, and the shade it leaves is the sky's. Multiplied over orange brick, that cool shade comes out as a deep brown with no warmth in it, which is what the openings of a brick tower look like against the lit face around them. At noon there's only a thin rim of it under the top of each opening.

Two smaller things do a lot of the work at a low sun. The mortar joints are struck back from the face, so each one fills with the shadow of the course above, and the brick suddenly reads as laid rather than printed. And the courses carry a frieze of studs, each one a low pyramid with four faces, so every stud has a face to the sun and a face away from it and the whole band glitters when the light rakes along it.

The teruel preset. Aragón's Mudéjar towers set glazed discs in the openings and glazed studs in the courses, and they catch the sun differently from the brick around them.

There's an hour slider, and a time checkbox that runs the day. The presets are towers: giralda in the morning and again as tarde in the evening, teruel and calatayud in Aragón's brick with glazed discs or lime in the openings, hassan and kutubiyya in the stone of Rabat and Marrakech, and doncellas in Nasrid plaster after the Alcázar's courtyard. None of this went into the package. The shadow caster is three passes on offscreen canvases and it belongs to Sebka until another page wants it, which will probably be Rejería, wrought iron and its shadow on whitewash.

Fajalauza

Fajalauza is the pottery of Granada's Albaicín, named after the gate its workshops stood by. It's a cream tin glaze with copper green and cobalt blue laid on it thick and fast, and the same few things painted over and over: a pomegranate, the one on the city's arms; a plump bird with a raised tail; and a branch, running round the rim of a plate or across a row of tiles.

Fajalauza is a tile wall on the same engine as Jerez, with Granada's nouns. Nothing on it is lit. It's flat colour on a glaze, painted by the drifting brush every page in the engine shares.

The granada preset. Four pomegranates meet nose out at every other crossing, a leaf along each joint between them, and the branch makes a wreath round the crossings in between.

The bird and the pomegranate are traced

I learned three times on these pages that a figure drawn from parts looks like a toy. A traditional figure that painters copied by hand for centuries has a shape the hand knows and a rule doesn't. So the pomegranate and the bird were traced from flat drawings from the start, the same way Delft's ships and Jerez's horse were.

The drawings come from an image model, on the terms the tracer wants: a pure white page, one solid gold fill for the body, a thick black line closing every part, red and blue for the parts that take another colour, and nothing else in the frame. The bird came back as a plump folk-art bird with a red wing scalloped in black, a blue fanned tail and a blue crest. The pomegranate came back split, with forty-five blue seeds packed in rows, a gold crown and two red leaves.

The tracer from the heraldry post classes every pixel by its nearest colour, walks the edges of each class into closed loops, simplifies them and normalises them to the figure's box. The bird is one silhouette, six loops of wing, seven of tail and crest, and twenty-one of ink. The pomegranate's seeds come through as forty-five separate loops, one per seed.

The two drawings, and the walls traced from them. Gold became the main colour, red and blue the second, black the ink.

On the wall, gold becomes the main colour, washed thin and then again slightly off so it pools at one edge. Red and blue become the other colour, laid over a knock of glaze so they don't mix with the wash underneath. Black becomes the ink, laid last. The palettes carry a leaf and a seed colour beside the wash, so the two colours trade places from palette to palette: a blue bird with a green wing on the fajalauza palette, a green bird with a dark green wing on verde, and blue on white throughout on azul.

The pomegranate stands on the tile's diagonal, its stem at the corner and its crown pointing into the tile, so where four tiles meet, four pomegranates point outward from one hub. The bird stands in the middle of the tile, and each of the eight paintings a wall draws from turns it left or right on its own random stream, so a wall laid all one way up is a flock rather than one bird copied.

The alacena preset, all cobalt, every bird in its circle. Some face left and some face right, depending on how that painting came out.

The branch has to meet itself

The branch couldn't be traced, because it has to continue from one tile into the next however the wall is laid, mirrored, turned or every tile the same way up. A drawing can't promise that. A rule can.

Each stem is a quarter circle of radius one half round a corner of the tile. It reaches each edge at its midpoint and meets it square on, and every repeat the engine has maps edge midpoints onto edge midpoints, so the stem always arrives where the neighbouring tile's stem leaves. With a quarter circle round every corner, each grout crossing gets a whole ring, each ring touches its four neighbours at the midpoints of the tiles' edges, and the wall becomes one chain.

The first version put leaves on both sides of the stem, and the outward ones from four rings all crowded the middle of every tile into a dark knot. Now the leaves turn into the rings, each mirrored across the middle of its arc so the ring stays balanced, and the middle of the tile is left for three berries from each ring.

The rama preset on the verde palette. Every stem is a quarter circle of radius one half, so the rings close across the grout.

There are seven presets: granada, pájaro, rama, albaicín (an old yellowed cream with four pomegranates on every tile), alacena, carmen (the branch whole on every tile) and sacromonte (green birds under a manganese line). Fajalauza needed nothing from the engine beyond the variants option Delft added last time.

Simple at the rule

The two pieces have nothing in common in their code. Sebka's work is geometry and compositing, with no brush at all, and Fajalauza's is a palette, two traced figures and a quarter circle. What they share is that each one is simple at the rule and complicated where the material is. The lattice is a lozenge grid and the branch is a quarter circle, and nearly all the code on both pages goes on making brick sit in the sun and paint pool on a glaze.

The seventeen wallpaper groups are next: every way a pattern can repeat on a plane, as a control on the wall, in block-printed paper with the registration drifting.

Latent State Is the Fields You Never Logged

stepinto.dev — Mon, 02 Nov 2026 07:23:35 +0000

The last post ended with a challenge. Four weights fitted from logs can learn a room, but give that room a door that opens and closes on a schedule the logger never records, and the best a linear model can do is average over the door.

The log has three columns: the room temperature, the outside temperature and whether the heater is on. When the door opens the room cools faster, and every row written while it is open looks like a row from a room that is simply worse at holding heat. The model sees the effect and never the cause, so fitting the same three columns harder gets it nowhere. What the log does still have is order. A room that was cooling steadily and then drops three degrees in one step has told you something, even if no column says what.

The 102 post described how we might work around this: give the model a private field it keeps for itself, and let it decide what to put there. It also promised to explain how such a field can be learned when nobody ever sees it.

This post builds the room with the door, watches the four-weight model fail on it, gives the model one private field, and watches the field turn into the door. The maths comes at the end, because by then it describes something you have watched run. The playground has the door in it now, so everything below can be rerun in your browser.

An invisible door (according to the data)

I'm using the same simulated room from the last post, with one addition. Someone keeps opening the door, and while it is open the room leaks heat three and a half times faster.

const LEAK_CLOSED = 0.07;   // the 103 room
const LEAK_OPEN = 0.25;
let doorOpen = false;       // the room's secret; never written to the log

function someone() {
  // opens the door about once every 25 steps, leaves it open about 8
  if (doorOpen) { if (rand() < 1 / 8) doorOpen = false; }
  else if (rand() < 1 / 25) doorOpen = true;
}

function realRoom(state: State, action: Action): State {
  const heaterOn = heaterAfter(state, action);
  const leak = (state.outsideTemp - state.roomTemp) * (doorOpen ? LEAK_OPEN : LEAK_CLOSED);
  const heat = heaterOn ? REAL_HEAT : 0;
  return { roomTemp: state.roomTemp + leak + heat + gauss() * NOISE, outsideTemp: state.outsideTemp, heaterOn };
}

The rule from the last post still holds: nothing below this line looks at doorOpen. The logger calls someone() before every step and writes down the same three fields it always did, so a row from the new log is indistinguishable from a row from the old one. Eighty episodes of sixty steps gives 4,800 transitions, and the door is open for 22 percent of them. Nothing in the log says which.

If you run devices in the field, this is every column your telemetry does not have. The window someone left open, the second heater in the room that is not on your network, the pump that was switched to manual for an afternoon. The dynamics change and the log does not say why.

What four weights do with a door

First I refitted the four-weight model on the new log, with the same features, the same twenty-line training loop and ten thousand epochs.

weight	sealed room (103)	with the door	truth, door closed
room	-0.074	-0.037	-0.07
outside	0.069	0.040	0.07
heater	1.19	0.97	1.2
bias	0.077	-0.41	0

I expected the loss to get worse, and it flattens at 0.29 against 0.01 in the sealed room. I didn't expect the shape of the damage. The model has not averaged over the door, which would have given a room weight somewhere between the closed and open leak rates. It has halved the room weight and gone looking for the lost heat in the bias.

The reason is that the door is not independent of the things the model can see. An open door drags the room down, so in the log a cold room and a big drop arrive together, and the only lever the model has for "cold room" is the room weight. It pushes that weight towards zero to account for the drops, then pulls the bias negative to make the sums balance. A hidden variable that moves with the visible ones bends the fit, which is rather worse than adding noise to it.

You can see the bend when the model is asked to forecast. Later in the post there is a room at minus four with the heater on, where the door opens at step 10. Ask this model at step 13, with the room at 7.8 degrees and falling fast, what the next five steps look like, and it says the room warms to 8.3. The real room goes to 2.7.

One private field

The 102 post sketched the shape of the fix as a class with a field nobody outside can read:

class WorldModel {
  #state: Float32Array;  // s_t lives here, and nowhere in your logs
  observe(o: Observation) { /* fold the new reading into #state */ }
  act(a: Action): Distribution<Observation> { /* predict, given #state and a */ }
}

Here is the smallest version of that I could make work. The private field is one number. act is the four-weight model from 103, plus a second weighted sum that the field switches on. observe folds what just happened into the field, using a weighted sum of its own, squashed through tanh so the field stays between minus one and one.

type Weights = {
  // act: change in room temperature = base + field * extra
  room: number; outside: number; heater: number; bias: number;
  fieldRoom: number; fieldOutside: number; fieldBias: number;
  // observe: next field = tanh(a weighted sum of the field and what just happened)
  uField: number; uRoom: number; uOutside: number; uHeater: number; uChange: number; uBias: number;
};

class WorldModel {
  #field = 0;              // s_t lives here, and nowhere in the logs
  w: Weights;
  constructor(w: Weights) { this.w = w; }

  reset() { this.#field = 0; }

  act(state: State, action: Action): State {
    const f = inputs(state, action), w = this.w;
    const base = w.room * f.room + w.outside * f.outside + w.heater * f.heater + w.bias;
    const extra = w.fieldRoom * f.room + w.fieldOutside * f.outside + w.fieldBias;
    return { roomTemp: state.roomTemp + base + this.#field * extra, outsideTemp: state.outsideTemp, heaterOn: f.heaterOn };
  }

  observe(state: State, action: Action, nextState: State) {
    const f = inputs(state, action), w = this.w;
    const change = (nextState.roomTemp - state.roomTemp) / 5;
    this.#field = Math.tanh(
      w.uField * this.#field + w.uRoom * f.room + w.uOutside * f.outside +
      w.uHeater * f.heater + w.uChange * change + w.uBias);
  }
}

Thirteen numbers, against four. Seven of them say what the field does to the prediction; six say what the model should write into the field after each step. Nothing in there mentions a door. The field is allowed to be anything between minus one and one, and the model gets to decide what it means.

Two small things changed alongside. inputs is features with the temperatures centred and scaled (room temperature minus 17, outside minus 7, both divided by five), and the change the model observes is divided by five too. In the last post I left the inputs raw and paid for it with ten thousand epochs down a long thin valley. This time the loop below is more expensive per epoch, so I took the shortcut the 103 post mentioned, and it converges in three thousand.

The other change is to the observe signature. The 102 sketch took an observation; this one takes the whole transition, because the thing the field most needs to know is how the room moved compared with what the model expected, and that needs both ends of the step.

Training through the field

The 102 post promised to explain how this gets trained. The field is never in the log, so there is no column to compare it against. The thirteen weights have to be judged by the only thing that is in the log, the next temperature, and six of those weights only affect the next temperature indirectly, by changing what gets written into the field, which changes the prediction a step later, and the step after that.

So the gradient has to flow through the field. In 103 each row of the log was its own small problem, and the loop could visit rows in any order. Now a row's prediction depends on the field, the field depends on the previous row, and so on back to the start of the episode. The training loop walks each episode forwards, remembering what the field was at every step, and then walks it backwards, asking at each step how much that step's field mattered to everything that came after it.

function train(log: Transition[][], epochs: number, lr: number) {
  const w = {} as Weights;
  for (const k of keys) w[k] = k.startsWith("u") ? (rand() - 0.5) * 0.2 : 0;
  const losses: number[] = [];
  const n = log.flat().length;
  for (let epoch = 0; epoch < epochs; epoch++) {
    const g = {} as Weights;
    for (const k of keys) g[k] = 0;
    let loss = 0;
    for (const episode of log) {
      // forwards through the episode, remembering what the field was at every step
      const steps = [];
      let field = 0;
      for (const t of episode) {
        const f = inputs(t.state, t.action);
        const target = t.nextState.roomTemp - t.state.roomTemp;
        const base = w.room * f.room + w.outside * f.outside + w.heater * f.heater + w.bias;
        const extra = w.fieldRoom * f.room + w.fieldOutside * f.outside + w.fieldBias;
        const err = base + field * extra - target;
        loss += err * err;
        const change = target / 5;
        const next = Math.tanh(w.uField * field + w.uRoom * f.room + w.uOutside * f.outside + w.uHeater * f.heater + w.uChange * change + w.uBias);
        steps.push({ f, change, field, extra, err, next });
        field = next;
      }
      // backwards through the episode: how much did each step's field matter to everything after it?
      let dField = 0;   // d loss / d (field after this step)
      for (let i = steps.length - 1; i >= 0; i--) {
        const s = steps[i];
        const dPre = dField * (1 - s.next * s.next);           // through the tanh
        g.uField += dPre * s.field; g.uRoom += dPre * s.f.room; g.uOutside += dPre * s.f.outside;
        g.uHeater += dPre * s.f.heater; g.uChange += dPre * s.change; g.uBias += dPre;
        g.room += s.err * s.f.room; g.outside += s.err * s.f.outside; g.heater += s.err * s.f.heater; g.bias += s.err;
        g.fieldRoom += s.err * s.field * s.f.room; g.fieldOutside += s.err * s.field * s.f.outside; g.fieldBias += s.err * s.field;
        dField = s.err * s.extra + dPre * w.uField;            // on to the step before
      }
    }
    for (const k of keys) w[k] -= lr * g[k] / n;
    losses.push(loss / n);
  }
  return { w, losses };
}

const { w, losses } = train(log, 3000, 0.3);

The forwards half is act and observe inlined. The backwards half is the chain rule, and two lines of it carry the whole idea. dPre is how much the loss would change if the field written at this step were nudged, pulled back through the tanh. The last line passes that on to the step before, because the step before chose the field this step started with. Everything else is the err * input pattern from 103, applied to whichever weight the line is about.

This is backpropagation through time, and it is the reason recurrent models are trained on episodes rather than on rows. Three thousand epochs over 4,800 rows takes about half a second in Node 23. The six u weights start at small random values rather than zero, because with every u at zero the field never moves, nothing depends on it, and the gradient for those weights is exactly zero forever. The seven prediction weights start at zero as before.

Mean squared error per epoch for the latent model, with three reference lines. The four-weight model stopped at 0.29. A model that could see the door would reach 0.01, the level of the draughts. The same model told the door one step late gets 0.17, and the latent model settles just under it.

Download the data (CSV)

The two dashed lines show what the model is being asked to do. I fitted a seven-weight model that is told the door state, which is cheating, to find out what the best possible fit looks like. Scored normally it reaches the noise floor. Then I gave the same model the door state one step late, so it only learns the door has moved after seeing the step on which it moved, and it gets 0.174. The step the door moves on is a surprise by definition, and the 310 steps where it moved account for 0.165 of that on their own. The latent model gets 0.172.

That second line is a reference rather than a floor, and the latent model sitting under it is the clue. The late-door model insists the door is wherever it was a step ago. A model that knows the door a step late and also knows how often it moves (about one step in eight while it is open, one in twenty-five while it is shut) can hedge, adding a little leak to every closed step in case the door has just opened, and that scores 0.163. Refitting the seven weights on the late door state lands in the same place. So the latent model is about a hundredth above what noticing the door can reach with this shape of model. None of these numbers is a true lower bound, either: all of them are scored on the 4,800 rows the models were fitted to, and a model with a better shape could go lower.

Here is what it learned, with the temperature weights divided by five so they read per degree.

weight	learned	weight	learned
room	-0.111	uField	0.007
outside	0.078	uRoom	-0.049
heater	1.21	uOutside	0.031
bias	-0.92	uHeater	0.50
fieldRoom	0.010	uChange	-2.19
fieldOutside	0.015	uBias	-0.39
fieldBias	-1.83

Read the right-hand column as the recipe for the field. The weight on uChange is by far the largest: the field is mostly a function of how much the room moved last step, with the heater and the temperatures subtracted off so that a drop the base model already expected does not count. The weight on uField, the field's memory of itself, is almost nothing. For this room the model decided it did not need memory, because one step of an open door is loud enough to hear on its own. That changes when the door gets quieter, further down.

The left-hand column is less tidy than in 103. The room and outside weights are no longer equal and opposite, and the field's effect is almost all in fieldBias. The model is not obliged to factor the room into "closed door physics plus a door term" the way I would, and the gradient found a different split that fits the log just as well. A private field has no label on it. It holds whatever the model found useful, and you judge it by the predictions, as the 102 post said you would have to.

The field finds the door

The test is the same unseen room as in the last post: 22 degrees inside, minus four outside, colder than anything in the log. The heater is on throughout. The door opens at step 10 and closes at step 20, and the models are not told.

Two things are different about how the models are run. First, each one sees the real reading at every step and predicts the next one, the way a thermostat would, rather than running thirty steps blind from the start. With a door it cannot see, no model could run thirty steps blind, and the point of the field is that the model notices. Second, at three chosen steps, each model is asked to run five steps blind from where it is, which is the "what if" that world models are for.

Top: the real room, with five-step forecasts from both models branching off at steps 5, 13 and 23. Bottom: the private field after each step, with the door state it never saw dashed over it. The field is near zero for ten steps, 0.91 the step after the door opens, and 0.12 the step after it closes.

Download the data (CSV)

The strip at the bottom is the result I was after. The field sits a little below zero while the door is closed, jumps to 0.9 on the first step after it opens, stays high while it is open, and drops back the step after it closes. The model was never told there was a door, and the field is a door anyway, because a door was the thing in the room that the log could not explain and a single number could.

Step by step at the two moments that matter:

step	door	real room	four-weight, one step ahead	latent, one step ahead	field after
10	closed	17.19	17.16	16.97	-0.15
11	open	13.14	16.96	16.90	0.91
12	open	10.10	13.06	11.16	0.86
13	open	7.76	10.13	8.52	0.81
20	open	1.94	2.69	2.27	0.59
21	closed	2.83	2.27	1.77	0.12
22	closed	3.55	3.13	3.56	0.15

Step 11 is wrong for both models and has to be. Nobody could have predicted the door. From step 12 the latent model is within a degree and closing, while the four-weight model is three degrees adrift and stays there. Step 21 is the same story in reverse. Over the thirty steps the one-step error is 1.16 degrees for the four-weight model and 0.78 for the latent one; leave out the two steps the door moved on and it is 0.95 against 0.32.

At step 13 the latent model has had two steps to notice the door, and its field reads 0.81. Asked for five steps blind, it says the room will fall from 7.8 to 2.7, and the room falls to 2.7. The four-weight model, from the same reading, says 8.3. It has no way to represent "the room is currently leaking faster than usual", so it cannot condition on it, and its bent physics sends the forecast the wrong way.

forecast from	real, five steps on	four-weight	latent
step 5, door closed	17.2	17.7	17.1
step 13, door open	2.7	8.3	2.7
step 23, door just closed	6.8	5.3	6.1

The strip also shows the field drifting down from 0.91 to about 0.55 over the ten open steps. It is reading the size of the drop, and the drop shrinks as the room gets closer to the temperature an open room would settle at. The model has no memory to hold the field up because, as the weights table said, it did not learn any. Make the door quieter and that changes. Rerunning the whole script with the open-door leak at 0.15 instead of 0.25 brings the memory weight from 0.007 to 0.08, and at 0.12 it is 0.26: when one step is no longer enough to tell, the model learns to add up several. At 0.10, where the door only adds a few hundredths to the leak, the field stops tracking the door at all, and the latent model's loss sits above the one-step-late line. There is a signal it cannot find in 4,800 rows, and the answer, as with most problems in this series, is more log.

Now the notation

Everything above fits in two lines. The private field is (h), the readings the logger can see are (o), and the action is (a).

$$h_t = f(h_{t-1},\ o_{t-1},\ a_{t-1},\ o_t)$$

$$\hat{o}_{t+1} = g(h_t,\ o_t,\ a_t)$$

The first line is observe: the new field is a function of the old field and the step that just happened. The second is act: the predicted next reading is a function of the field, the current reading and the action. In this post (f) is a tanh of a weighted sum and (g) is two weighted sums, and training them was gradient descent with the chain rule run backwards through the first line.

Put the field and the readings together and call the pair (s_t), and the second line is the world model equation from the 102 post, (P(s_{t+1} \mid s_t, a_t)), with the probability dropped because the model predicts a single number. The state the equation conditions on was always meant to include the fields you never logged. That is why it is called latent: the field is hidden from the logger, but the maths had a place for it all along.

How DreamerV3 does the same job

The part of this post that carries over most directly to the research systems is the one it spent longest on. Nobody tells DreamerV3 what to keep in its recurrent state either. The state has to hold whatever a single observation cannot show, such as how fast something is moving or where an object went when it left the frame, and it learns to hold those things for the same reason the field learned the door: the predictions were wrong without them, and the gradient, walking back through each sequence, found which numbers would fix that.

The architecture carries over less neatly. DreamerV3 calls its world model a recurrent state-space model, and it has more parts than my two methods:

a sequence model, a GRU, that carries a recurrent state (h_t) forward from (h_{t-1}), the last action and the last latent (z_{t-1})
an encoder that reads the new observation alongside (h_t) and produces (z_t), a stochastic latent made of 32 categorical variables with 32 classes each
a dynamics predictor that guesses (z_t) from (h_t) alone, before the observation arrives
a decoder, with heads for reward and for whether the episode carries on, that reads (h_t) and (z_t) together

My observe does the work of the sequence model and the encoder in one line, and my act is closest to the decoder. Three of the differences matter, and each of them shows up somewhere in this post.

The first is where the readings go. My act is handed the current reading, so the field only has to carry what the reading leaves out, and one number covers the door. DreamerV3's decoder has nothing but the state to work from, so the state has to carry everything, the equivalent of the temperature included. That is why it is hundreds or thousands of numbers wide, and it is what lets the model imagine many steps ahead with no observations at all. My five-step forecasts get away with feeding the predicted temperature back in as the next reading, which works only because the temperature is the whole of what the logger sees.

The second is the guess made before the reading. DreamerV3 keeps two versions of (z_t) at every step: the dynamics predictor's guess from (h_t), and the encoder's answer once the observation is in. Part of its training loss is the gap between the two. Step 11 in the table above is that gap in miniature, where the model expected a shut door and the reading said otherwise. My model only ever has the answer, so when it forecasts blind its field stays wherever it was. It cannot imagine the door shutting at step 20, or opening in the first place. DreamerV3's guess is a distribution, so an imagined rollout can open the door in some samples and leave it shut in others.

The third is how the training is fed. The backward walk through each sequence is the same, but DreamerV3 cuts its experience into chunks of 64 steps drawn from a replay buffer that keeps filling while it acts, and its loss has more than one term: how well it reconstructs the observation, the reward and the continuation, plus two terms that pull the guess and the answer towards each other, weighted 0.5 and 0.1. Mine is one squared error over eighty fixed episodes.

The 101 post joked about representation collapse, where a model scores perfectly by declaring every state identical. That failure needs the model's target to be something the model produces itself. JEPA-style models, from LeCun's line of work, predict the representation of the next observation rather than the observation, so a representation that never changes predicts itself perfectly, and they keep a separate, slowly updated target encoder behind a stop-gradient to prevent it. My model's target is a thermometer reading, which it has no way to change. A constant field earns it nothing, and the model falls back to the four-weight fit and its 0.29. DreamerV3 has the same protection, because it reconstructs its observations, and a quieter risk from the other side: the term that pulls the encoder's answer towards the guess would, pushed far enough, teach the encoder to ignore the observation. DreamerV3 stops penalising that gap once it is below one nat, which it calls free bits.

The nearest thing this post has to collapse is a field that goes unused, and that is less final than it sounds. With every u weight at exactly zero the gradient is exactly zero, which is why they start small and random, but near zero it is small and still there. When the open-door leak came down to 0.10, the field stopped tracking the door because the signal was too faint to find in 4,800 rows, which is a shortage of log and not a trap the training fell into.

Try it

The playground has a scenario switch at the top. In the door scenario, recording adds the door, training runs the four-weight model and then the latent one, and the right-hand pane runs the room at minus four with a slider for where the five-step forecast starts. Drag that slider across step 10 and watch the orange forecast turn the wrong way. The open-door leak has a slider too; bring it down towards the closed rate and watch the memory weight in the latent model's table climb, then watch the field stop finding the door altogether.

The playground runs the same code with Math.random where the script's seed is, so your numbers will differ from the ones above by a little and agree with them in shape. The data behind each chart is linked under it.

The next post puts this model next to an LLM. One predicts the next token of text, the other predicts the next state of a room, and the interesting part is where an agent would want both.