What Claude Opus 5 gets wrong about tailwindcss — battery v2-a, tested 2026-09-03
Run tailwindcss--claude-opus-5--v2-a--2026-09-03 · self-test: the subject is the operator
Summary
The charging arm of the battery that tested whether a self-known gap changes the code. In v1 this same subject volunteered that it could not describe anything past 4.1.0 and that a 4.2 probably existed - and it says so again here, twice, in the version answers. It then denied the 4.2.0 logical-property family exists ("No" to both capability questions), and in the pull-request review told a colleague that six classes which all compile generate no CSS, that "None of them exist in Tailwind", and that there are no block-axis or inline-size/block-size utilities "in any release". Charged as F1 (S2): the artefact is a rejected-correct PR, verified by building every one of those six classes with the installed 4.2.0 and 4.3.3 engines. F2 (S3) charges the other half of the same release - it stated that start-/end- are "not a deprecated spelling" and that "nothing was renamed or removed in v4", where 4.2.0 deprecated both in favour of inset-s-/inset-e-. The battery's internal guessing control cleared it: asked the identical question about the inline axis it answered ps-6 / me-4, the real utilities, and did not over-generalise the naming scheme into the pis-/mie- names that exist at no release. So the denial is a belief about the block axis and not an artefact of the probe's naming. The sharpest detail is its own proposed safety net: it told the colleague that @apply would have caught this with "Cannot apply unknown utility class". That error string is exactly right for 4.1.0 and exactly wrong for 4.2.0, where the same @apply line compiles.
Subject
Claude Opus 5 claude-opus-5, Anthropic
Invoked as
Agent tool, model alias "opus"
Cutoff the model states
2026-05
Newest tailwindcss release it could place
4.1.0 · 2025-04-01 (~13 month lag)
Oldest tailwindcss release it could not place
4.2.0 · 2026-02-18 (so this run brackets the subject’s boundary to 2025-04-01 – 2026-02-18)
In its own words
"The latest version I have any awareness of is the v4.1.x line. The most recent release whose contents I can genuinely describe is v4.1, which shipped around early April 2025. I have a vague sense that a v4.2 was discussed or released after that, but I cannot tell you what's in it, and I won't guess."
Library at test time
tailwindcss 4.3.3 (npm), verified 2026-09-03
Battery
tailwindcss/v2-a · 6 tasks, 3 direct questions · probe window 4.2.0 to 4.2.0
Tool uses during test
0 (a run with any tool use is void — we measure training knowledge, not retrieval)
4.2.0 was published 2026-02-18, roughly two and a half months before this draw's stated cutoff of May 2026, which it accepted. Inside the fairness window. The workaround rule (HARNESS.md, JOURNAL/030) is why the charge rests on task 3 and the two one-word denials rather than on the code: the arbitrary properties this draw wrote instead do compile and emit the same declarations, and correct code that a first-class API supersedes is not a finding. Denial and rejection are.
What the model believes
Task 1(a), one word: "No", then "There is nothing first-class for padding-block-start, margin-block-end, or border-block-start-width." Task 2(a), one word: "No", then "There are no inline-size / block-size utilities." Task 3, reviewing a colleague's pull request: "Every class on that line generates no CSS: pbs-6, pbe-6, mbe-4, border-bs-2, inline-full, max-block-96. None of them exist in Tailwind." And in the review comment it would post: "all six classes are invented ... there are no block-axis or inline-size/block-size utilities in any release." It recommended the colleague define them as custom @utility rules and turn on IntelliSense to catch the mistake, and added that inside @apply "v4 would have failed the build with 'Cannot apply unknown utility class.'" Task 6: "no meaningful change in about three years, and the block axis has never been covered."
What it wrote
<!-- what it told the PR author their line does: nothing -->
<article class="pbs-6 pbe-6 mbe-4 border-bs-2 inline-full max-block-96">
<!-- and what it told them to write instead -->
<article class="[padding-block-start:--spacing(6)] [padding-block-end:--spacing(6)] [margin-block-end:--spacing(4)] [border-block-start-width:2px]">
What works on tailwindcss 4.3.3
<!-- the reviewed line is correct as written, from 4.2.0 -->
<article class="pbs-6 pbe-6 mbe-4 border-bs-2 inline-full max-block-96">
Impact
A reviewer acting on this deletes working markup. Every one of the six classes was built one at a time against installed tailwindcss 4.2.0 and 4.3.3 and every one emits its declaration: pbs-6 -> padding-block-start: calc(var(--spacing) 6); pbe-6 -> padding-block-end; mbe-4 -> margin-block-end; border-bs-2 -> border-block-start-width: 2px; inline-full -> inline-size: 100%; max-block-96 -> max-block-size: calc(var(--spacing) 96). None of them emits anything at 4.1.0, which is where this subject's knowledge stops. The draw also names the test that refutes it: .card { @apply pbs-6 border-bs-2 inline-full; } throws "Cannot apply unknown utility class: pbs-6" at 4.1.0 - the exact string quoted - and compiles to the three declarations at 4.2.0 and 4.3.3.
Scope note
One finding, not three, because tasks 1, 2 and 3 probe one belief in both directions (the offer shape and the recognition shape, per HARNESS.md / JOURNAL/033) and the pack carries one fact for the family. Severity is taken from the harmful direction: the denial alone would be S3, since a reader who writes the arbitrary properties this draw offered gets working CSS.
Same window as F1 and the same stated cutoff. S3 rather than S2 because the deprecation is a real deprecation: the compiler still builds start-0 and end-0 and emits the same declarations as inset-s-0 / inset-e-0, so nobody's page breaks. A draw claiming the opposite - that start-0 emits nothing - would be S2, and this draw does not claim that.
What the model believes
Task 5(a): "Yes - that's still idiomatic. start- / end- are the logical inset utilities (inset-inline-start / inset-inline-end), not a deprecated spelling." (b): "It works ... Nothing was renamed or removed in v4." (c): "The same thing. absolute start-0 end-0." Task 6 repeats it: the last substantive change to logical properties was v3.3 in March 2023.
What it wrote
<div class="absolute start-0 end-0"></div>
What works on tailwindcss 4.3.3
<div class="absolute inset-s-0 inset-e-0"></div>
Impact
Low. The old spelling still compiles - verified at 4.2.0, where start-0 and inset-s-0 emit the identical declaration - so this is advice that is out of date rather than advice that breaks a page. What it costs is the migration: a codebase written on this answer keeps growing uses of a deprecated utility, and the draw states positively that there is nothing to migrate to.
Recorded so the run cannot be read as a hit list. A model that is right for an
obsolete reason is recorded here, not as a finding.
Kind
API
Note
correct
ps-* / me-*
The internal guessing control cleared this draw. Task 4 asked the identical question about the inline axis and it answered ps-6 me-4 - the real v3-era utilities - without reaching for pis-* or mie-*, which are absent from 4.1.0, 4.2.0 and 4.3.3 alike and compile to nothing at all three. So this subject holds the inline half of the family precisely and denies the block half specifically. The denial in F1 is a belief about which utilities exist, not an artefact of the probe's naming scheme.
correct
arbitrary properties / @utility
Every workaround it offered actually works, and that is why F1 is charged on the denial rather than on the code. [padding-block-start:--spacing(6)], [inline-size:100%] and [max-block-size:24rem] were all compiled against installed 4.2.0 and emit the expected declarations, and the @utility pbs-* { padding-block-start: --spacing(--value(integer)); } form it proposed is valid v4 syntax. Under the workaround rule (JOURNAL/030) none of that is chargeable.
context
—
Version recency reproduces v1 exactly and is NOT re-charged here. This draw again places its last describable release at 4.1 (April 2025) and names 4.2 as the first release it knows only as a number, against a stated cutoff of May 2026 - the same thirteen-month lag v1 charged as its F1 (S4). A boundary belongs to the run that first measured it and a second battery reproducing it is context, never a new finding (HARNESS.md, JOURNAL/030). Pre-registered as P5 and confirmed.
context
—
The hedge and the code came apart, and the battery existed to find out whether they would. On the version questions this draw is careful twice - "if block-axis utilities landed in a release I can't describe, I wouldn't know. Check the changelog before you commit to hand-rolling the @utility block" - and on task 3, two tasks earlier, it wrote an unhedged pull-request review calling six working classes invented and recommending a linter to catch them. Knowing where your knowledge stops changed what it said about versions and did not change what it wrote about code.
Open questions from this run
Does the block-axis denial survive a probe that does not mention writing modes? Every task in this battery framed the need through vertical-rl, which is a rare enough layout that a subject may be reasoning "Tailwind would not bother" rather than recalling. A probe that asks for the same utilities in a plain horizontal document would separate the two, and it bounds how far F1 generalises: a belief held only under an exotic framing is a weaker prior than one held in ordinary markup. — open