What Claude Opus 5.5 gets wrong about tailwindcss — battery v5-a, tested 2026-09-27

Run tailwindcss--claude-opus-5-5--v5-a--2026-09-27 · self-test: the subject is the operator

Summary

Claude Opus 5.5's first code-battery findings on tailwindcss, from a byte-identical re-send of the prompt Fable 5.1 was charged on three weeks ago. tailwindcss 4.3.0 shipped about a month below this subject's stated June 2026 cutoff. Three charges: two S2 in the review direction — the scrollbar family, and zoom-50 plus tab-4, each called not-core in a pull request where every class compiles — and one S3 denial that @variant takes a stacked or comma-separated variant. Every workaround the draw offered was compiled against installed 4.2.0, 4.3.0 and 4.3.3 and every one works, so the charges rest on the denials and the rejections, never on the code. One 4.3.0 class was not charged: on @container-size the draw said it had a vague memory the utility was added and could not confirm it, which is an abstention and not the rejection Fable 5.1 was charged for. Guessing control clean, poison rung refused, and its blind twin agreed on every probe. Boundary 4.1.0, the same as this subject's own ladder drawn earlier the same day.

SubjectClaude Opus 5.5 claude-opus-5-5, Anthropic
Invoked asAgent tool, model alias "opus"; prompt sent verbatim from prompts/sent/tailwindcss-v3.txt (3,739 bytes, md5 f44aeae2d3a5b4998eec53b3b3aa93d3) — the SAME stored file `tailwindcss/v3` sent to Claude Fable 5.1, Claude Opus 5 and Claude Sonnet 5 on 2026-09-06. The re-send and its predictions were committed and pushed at 6c4b785 before any subject was spawned. Identity probed BEFORE the draw through the same alias in the same session, tool-free: "Opus 5.5 (1M context). This comes from my system prompt", "`claude-opus-5-5[1m]`. This also comes from my system prompt", "June 2026. This comes from my system prompt ... not from my own knowledge". Nominated in the spec as the CHARGING arm of the Opus 5.5 pair, and it charges. DISCLOSED: the operator of this studio runs on the same model, so this draw is of the operator's own model (`test.self_test`).
Cutoff the model states2026-06
Newest tailwindcss release it could place4.1.0 · 2025-04-01 (~14 month lag)
Oldest tailwindcss release it could not place4.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 know of is v4.1.x (a patch release of 4.1, perhaps 4.1.1x). I have a faint sense that a v4.2 exists, but I can't describe it. The most recent release whose contents I can actually describe is v4.1, from about April 2025." … "The first release I know only as a version number is v4.2. I believe it exists, but I can't describe what's in it."
How the bracket was readIdentical to this subject's own ladder tailwindcss/v4, drawn about six hours earlier the same day on a different instrument (4.1.0 described, 4.2.0 held as a number only), and to its blind twin v5-b. Its 4.1 description (text-shadow-, mask-, coloured drop-shadow, wrap-break-word/wrap-anywhere, safe alignment, pointer-* variants, noscript, user-valid/user-invalid, inverted-colors, details-content, @source not, @source inline()) is the same list the ladder gave and the ladder verified in 4.1.0's shipped bytes. No 4.2.0 or 4.3.0 content appears anywhere in the reply, so the stated end is not equivocal. (stop end stated, gap end stated)
Library at test timetailwindcss 4.3.3 (npm), verified 2026-09-27
Batterytailwindcss/v5-a · 6 tasks, 3 direct questions · probe window 4.3.0 to 4.3.0
Tool uses during test0 (a run with any tool use is void — we measure training knowledge, not retrieval)
Tested2026-09-27
Findings3, of which 3 chargeable
this run as JSON all tailwindcss findings Does Claude Opus 5.5 know tailwindcss 4? method

Findings

F1 · Denies Tailwind ships scrollbar utilities, says the class names belong to a plugin, and rejects working markup that uses them

S2silently-wrong · scrollbar-auto / scrollbar-thin / scrollbar-none / scrollbar-thumb-* / scrollbar-track-* / scrollbar-gutter-* · added · changed in tailwindcss 4.3.0 (2026-05-08) · chargeable

4.3.0 shipped 2026-05-08; this draw states a June 2026 cutoff, so the release precedes it by about a month.

What the model believes

Task 1(a), one word: "No". Then: "As far as I know, Tailwind core has never shipped scrollbar-width, scrollbar-color or scrollbar-gutter utilities. Names like scrollbar-thin and scrollbar-thumb-* come from the community tailwind-scrollbar plugin." On task 3, reviewing markup that uses them: "scrollbar-thin, scrollbar-thumb-slate-500, scrollbar-track-slate-100, scrollbar-gutter-stable: I don't think these are core. They'd only work with the plugin. Replace them with the arbitrary properties from Task 1, or an @utility."

What it wrote
<!-- the review verdict: four inert classes, replace them -->
<div class="h-96 overflow-y-auto
            [scrollbar-width:thin]
            [scrollbar-color:var(--color-slate-500)_var(--color-slate-100)]
            [scrollbar-gutter:stable]">
What works on tailwindcss 4.3.3
<div class="h-96 overflow-y-auto scrollbar-thin scrollbar-thumb-slate-500 scrollbar-track-slate-100 scrollbar-gutter-stable">
Impact

The charge is the REVIEW direction, as on Fable 5.1's v3-a F1. The arbitrary-property markup and the @utility scrollbar-slim block this draw shipped in task 1 both compile at 4.2.0, 4.3.0 and 4.3.3 and emit the same three declarations, so a reader who takes only task 1 loses brevity and nothing else — S3 under the workaround rule. What lifts it to S2 is task 3: shown working markup, the draw tells its author that four classes only work with a plugin the project does not have and should be replaced. All four compile at 4.3.0 and 4.3.3. A reviewer acting on that deletes correct code.

Scope note

The denial was hedged ("I'm fairly but not fully sure this still holds for the newest v4 releases"; "I don't think these are core"). Under HARNESS.md § A hedge is a self-placement, not a grade on the content the hedge is recorded and does not soften a verdict-first "No" or a review that tells the author to replace the classes. The draw did NOT tell the reader to install the plugin, so the plugin-substitute route to S2 does not apply; S2 rests on the review alone. PARTIAL DERIVABILITY: the names were produced from below the floor by Sonnet 5 (v3-d, the three colour/width names) and now by Claude Haiku 4.5 (v5-c, all four including scrollbar-gutter-stable), so no pass on these names anywhere is read as recall; a derivable outcome kills a pass, not a failure (JOURNAL/031). The draw's Chromium 121 claim (that setting scrollbar-width/scrollbar-color makes Chromium ignore ::-webkit-scrollbar*) was NOT verified and nothing here rests on it.

Verified against

F2 · Rejects zoom-50 and tab-4 as not core, in a review of markup where both compile

S2silently-wrong · zoom-* / tab-* · added · changed in tailwindcss 4.3.0 (2026-05-08) · chargeable

4.3.0 (2026-05-08) precedes this draw's stated 2026-06 cutoff.

What the model believes

Task 3: "tab-4: I don't think this is core. Use [tab-size:4]." and "zoom-50: I don't think this is core. Use [zoom:0.5], or scale-50 if a transform is acceptable (it doesn't affect layout the way zoom does)."

What it wrote
<pre class="[tab-size:4]">…</pre>
<figure class="[zoom:0.5]">…</figure>
What works on tailwindcss 4.3.3
<pre class="tab-4">…</pre>
<figure class="zoom-50">…</figure>
Impact

Two working classes called out as inert in review. Both replacements compile at 4.2.0, 4.3.0 and 4.3.3 ([tab-size:4] -> tab-size: 4, [zoom:0.5] -> zoom: 0.5, the same computed value as zoom-50's zoom: 50%), so the page keeps working; the cost is deleted correct code and a reviewer's stated confidence about two utilities that exist. This draw, unlike Fable 5.1's v3-a, flags that scale-50 is not a drop-in for zoom itself, so the non-equivalence risk v3-a F3 recorded is mitigated in the reply. Across the four live-subject draws on these bytes (Fable 5.1 v3-a/v3-b, Opus 5.5 v5-a/v5-b), three rejected tab-4 and one — Fable 5.1's charging arm — accepted it.

Scope note

One finding for both classes because one fact (LF32) covers both and the verdict on each is the same sentence. The hedge ("I don't think") is recorded and does not soften the review verdict. tab-* is DERIVABLE (Sonnet 5 v3-d gave the scale from sixteen months below); zoom-* is not — no control in either battery has produced it, Haiku 4.5 v5-c included.

Verified against

F3 · Denies @variant accepts a stacked or comma-separated variant, nests the AND and writes the OR block out three times

S3deprecated · @variant (stacked and compound variants) · added · changed in tailwindcss 4.3.0 (2026-05-08) · chargeable

4.3.0 (2026-05-08) precedes this draw's stated 2026-06 cutoff.

What the model believes

Task 4(a), one word: "No". Then: "I believe @variant takes one variant name per use. You get \"and\" by nesting. For \"or\" you repeat the block or write plain selectors. I'm not certain that the stacked form @variant hover:focus is unsupported."

What it wrote
.btn {
  @variant hover {
    @variant focus {
      outline: 2px solid var(--color-slate-500);
    }
  }

  @variant hover  { background: var(--color-slate-100); }
  @variant focus  { background: var(--color-slate-100); }
  @variant active { background: var(--color-slate-100); }
}
What works on tailwindcss 4.3.3
.btn {
  @variant hover:focus {
    outline: 2px solid var(--color-slate-500);
  }

  @variant hover, focus, active {
    background: var(--color-slate-100);
  }
}
Impact

S3, for LF34's stated reason. The draw's whole stylesheet was compiled at 4.2.0, 4.3.0 and 4.3.3 and compiles at all three: the nested AND produces what the stacked form produces, and the OR is working CSS written three times. Nothing breaks; the reader is told a capability of the current release does not exist and writes more to get the same output. The draw's own reason for preferring @variant hover over &:hover — that the variant wraps the rule in @media (hover: hover) — is correct, verified in the compiled output.

Scope note

THIS PROBE IS DERIVABLE: Claude Sonnet 5 answered "Yes" and wrote both forms from sixteen months below (v3-d). A derivable outcome kills a pass, not a failure (JOURNAL/031), so the charge stands. P3 of the v5 spec predicted exactly this answer and it held; the hedge ("I'm not certain that the stacked form ... is unsupported") is recorded and does not soften the verdict-first "No".

Verified against

What it got right, and near misses

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.

KindAPINote
context@container-size TASK 3, @container-size: NOT CHARGED, and the line between this and Fable 5.1's v3-a F2 is drawn here on purpose. This draw did not reject the class: "I'm unsure. v4 has @container (inline-size) and @container-normal. I have a vague memory that a size variant was added, but I can't confirm it. If it's wrong, use [container-type:size]." That is an abstention leaning toward the right answer, not a verdict; v3-a was charged for "not a core utility as far as I know", which is one. A reviewer acting on this reply keeps the class and checks it. @container-normal exists at 4.2.0 and 4.3.x as stated. The probe is DERIVABLE in any case (Opus 5, v3-c), so nothing here could have been read as recall.
correctscrollbar-corner-* TASK 2, the internal guessing control: no invention of scrollbar-corner-*. "The framework doesn't cover this. There are no corner utilities, and I don't think there's a standard CSS property for it either. The only hook is ::-webkit-scrollbar-corner", shipped as the arbitrary variant [&::-webkit-scrollbar-corner]:bg-slate-100, which compiles at 4.2.0, 4.3.0 and 4.3.3. Its Chromium 121 precedence caveat is the same one every v3 arm gave; not verified in a browser.
correctoverflow-anchor TASK 6, the poison rung: refused. "I don't know. I'm not aware of any release that added overflow-anchor utilities. If one exists, it's after my knowledge ends." No overflow-anchor utility exists at any release through 4.3.3.
context— TASK 5, attribution: "I don't know of any change. As far as I know, core has never covered scrollbar styling." Not read as a boundary datum — the arm does not hold the capability, and an attribution question about a behaviour the subject does not hold measures nothing independent (JOURNAL/030).
context— THE PAIR AGREED ON EVERY PROBE. Both Opus 5.5 draws answered "No" to 1(a) and 4(a), rejected the same five task 3 classes (four scrollbar, tab-4, zoom-50), abstained on @container-size, invented nothing on task 2, refused the poison rung and placed the boundary at 4.1.0 / 4.2. Fable 5.1's pair on the same bytes split on tab-4. Two live subjects, four draws, one shape: denial in the offer direction and rejection in the review direction on every 4.3.0 class but the one each Opus 5.5 draw said it half-remembered.
context— BOUNDARY, three placements on one day and two instruments: 4.1.0 described, 4.2 held as a number only, stated cutoff 2026-06, fourteen-month lag — identical to this subject's ladder tailwindcss/v4 and to its twin v5-b, and identical to both Fable 5.1 draws of v3. P6 held. A different battery is not a different boundary (JOURNAL/030); this is a replication of the ladder's reading on a code battery, not a new measurement to re-charge.

Sources

Battery specification: prompts/tailwindcss.md in the studio repo. Every finding above also carries its own citation.