What Claude Fable 5.1 gets wrong about tailwindcss — battery v7-a, tested 2026-09-28

Summary

The charging arm, and it charges twice, on the same two facts Opus 5 was charged on with these bytes. Claude Fable 5.1 answers "No" to both verdict-first questions, tells a colleague that all six of their correct 4.2 classes "generate no CSS" and should be rewritten (S2, LF30), and calls start-*/end-* current and not deprecated (S3, LF29). The review is hedged — it suggests grepping the built CSS for .pbs-6 and promises to stand corrected — and every workaround it offers compiles. It places its knowledge at 4.1.0 and knows 4.2 only as a number, the same boundary it stated on 2026-09-06; unlike Opus 5.5 on these bytes, the logical-properties cue draws no 4.2 content out of it. It is right about something Opus 5.5 got wrong: since v4.0, py-*, inset-x-*, border-x-*, space-x-* and divide-x-* compile to logical properties.

Subject	Claude Fable 5.1 `claude-fable-5-1`, Anthropic
Invoked as	Agent tool, model alias "fable"; prompt sent verbatim from prompts/sent/tailwindcss-v2.txt (3,725 bytes, md5 d444013308540553aefae1d5875bd3e2) — the SAME stored file `tailwindcss/v2` sent to Claude Opus 5, Claude Sonnet 5 and Claude Fable 5 on 2026-09-03 and `v6` sent to Claude Opus 5.5 and Claude Haiku 4.5 on 2026-09-28. The re-send and its predictions were committed and pushed at 50bc2fa before any subject was spawned. Identity probed BEFORE the draw through the same alias in the same session, tool-free: "Fable 5.1 — from the system prompt", "claude-fable-5-1 — from the system prompt", "June 2026 — from the system prompt (stated as the knowledge cutoff; I have no independent way to verify it from training)". Nominated in the spec as the CHARGING arm of the Fable 5.1 pair, and it charges.
Cutoff the model states	2026-06
Newest tailwindcss release it could place	4.1.0 · 2025-04-01 (~14 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	"Latest version I'm aware of: I have a hazy sense that a v4.2 exists, but I cannot describe its contents. The most recent release whose contents I can actually describe is v4.1.0 (April 2025), plus the 4.1.x patch line through roughly autumn 2025" … "First release I know only as a version number: v4.2. I believe it exists and cannot tell you a single thing that's in it — including whether it's the release that made Task 3's classes real."
How the bracket was read	The same boundary `v3-a` stated on 2026-09-06, and this time it holds under the cue: a prompt about logical properties drew no 4.2 content at all, where the same bytes drew three uncued 4.2.0 contents from Opus 5.5 (`v6-a`). Its 4.1.0 list (`text-shadow-`, `mask-`, coloured `drop-shadow`, `safe` alignment, `items-baseline-last`, pointer variants, `noscript`, `user-valid`, `inverted-colors`, `@source inline()`) is 4.1.0's, and `v6-a`'s and `v4`'s verification of those names stands for it. So on tailwindcss the stated boundary is not an under-report for this subject. (stop end stated, gap end stated)
Library at test time	tailwindcss 4.3.3 (npm), verified 2026-09-28
Battery	tailwindcss/v7-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)
Tested	2026-09-28
Findings	2, of which 2 chargeable

Findings

F1 · Denies the 4.2.0 block-axis and logical-sizing utilities exist, and tells a colleague to rewrite working markup that uses them

S2silently-wrong · logical property utilities · added · changed in tailwindcss 4.2.0 (2026-02-18) · chargeable

4.2.0 was published 2026-02-18, about four months before this draw's stated cutoff of June 2026, which it affirmed. Inside the fairness window. As in v2-a, the charge rests on the two one-word denials and the task 3 rejection, not on the code: every arbitrary property this draw wrote instead compiles and emits the declaration it names, and correct code a first-class API supersedes is not a finding (HARNESS.md, JOURNAL/030). The review is HEDGED — it proposes grepping the built CSS for .pbs-6 and says "If it is there, we're on a version newer than I know and I'll stand corrected" — and that hedge is recorded rather than scored away: the verdict it gives the colleague is still "all six classes generate no CSS" and a rewrite, which is the rejected-correct-PR shape the spec pre-registered as S2 (P2). The line between this and an abstention is the one tailwindcss/v5 drew: an abstention declines to say; this says, then offers a check.

What the model believes

Task 1(a), one word: "No", then "I'm not aware of any release shipping block-start/block-end equivalents (padding-block-start, margin-block-end, border-block-start-width) as named utilities." Task 2(a), one word: "No", then "No inline-size/block-size utilities that I'm aware of." Task 3: "On every Tailwind release whose contents I can describe, all six classes generate no CSS. pbs-*, pbe-*, mbe-*, border-bs-*, inline-*, max-block-* are not utilities I know of. The build will still \"compile\" … so the PR passes CI and the element ships completely unstyled." To the colleague: "as far as I know Tailwind doesn't have block-axis start/end or inline-size/block-size utilities … Otherwise, rewrite as py-6 [margin-block-end:--spacing(4)] [border-block-start-width:2px] [inline-size:100%] [max-block-size:--spacing(96)]". Task 6: "I'm not aware of a later release that added block-start/block-end utilities or inline-size/block-size utilities. Given how this questionnaire is framed I suspect one exists after my knowledge, but I can't describe it".

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="py-6 [margin-block-end:--spacing(4)] [border-block-start-width:2px] [inline-size:100%] [max-block-size:--spacing(96)]">

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 the verdict rewrites working markup. The six reviewed classes emit their declarations at 4.2.0 and 4.3.3 and nothing at 4.1.0 (v2's compile table, re-confirmed this session for pbs-6 and inline-full). The rewrite it offers compiles, so a page built on it renders — which is why the harm is the rejection and the churn, not a broken page — but it is not the same markup: py-6 is symmetric padding-block, so a card whose block-start and block-end padding later need to differ is written in a form that cannot express it without arbitrary properties. A reviewer who runs the draw's own proposed check (grep the build for .pbs-6) finds the class and is spared; a reviewer who reads the verdict is not.

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 — the same scoping as v2-a F1. Severity from the harmful direction: the denial alone would be S3, since a reader who writes the arbitrary properties offered gets working CSS.

Verified against

tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added published 2026-02-18
Add pbs-* and pbe-* utilities for padding-block-start and padding-block-end
tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Added published 2026-02-18
Add inline-*, min-inline-*, max-inline-* utilities for inline-size, min-inline-size, and max-inline-size
tailwindcss 4.2.0, shipped package - `pbs-6` emits padding-block-start and `inline-full` emits inline-size: 100%, compiled one class at a time with the installed engine (and the other four reviewed classes per `tailwindcss/v2`'s table).
tailwindcss 4.1.0, shipped package - the same classes emit nothing, which is where this subject's stated knowledge stops.

F2 · States start-/end- are current and not deprecated, two releases after 4.2.0 deprecated them

S3deprecated · logical inset utilities · deprecated · changed in tailwindcss 4.2.0 (2026-02-18) · chargeable

Same window and stated cutoff as F1. S3 rather than S2 because the deprecation is a real deprecation: start-0 still emits inset-inline-start at 4.2.0 and 4.3.3 (compiled this session), so nothing breaks. This draw does not claim start-0 emits nothing, which would be S2.

What the model believes

Task 5(a): "Still valid. start-*/end-* came in v3.3 and, to my knowledge, carried into v4 unchanged as inset-inline-start/inset-inline-end. Not deprecated." (b): "Works on the current release I know; it generates CSS." (c): "Today I'd write absolute inset-x-0. … start-0 end-0 is not wrong, just longer".

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. Part (c)'s own suggestion, inset-x-0, is a correct and non-deprecated rewrite — it emits inset-inline at 4.1.0, 4.2.0 and 4.3.3 — so a reader who takes (c) ends up on current code by a route the draw did not know it was taking. What the answer costs is the statement in (a): a codebase told "not deprecated" keeps adding start-*/end-* where the edges need independent values, which is exactly the case (c) says to keep them for.

Verified against

tailwindcss CHANGELOG - 4.2.0 (2026-02-18), Deprecated published 2026-02-18
Deprecate start-* and end-* utilities in favor of inset-s-* and inset-e-* utilities
tailwindcss 4.2.0, shipped package - `inset-s-0` compiles here and emits nothing at 4.1.0 (`tailwindcss/v6`'s table); `start-0` still emits inset-inline-start.

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.

Kind	API	Note
correct	`ps-* / me-*`	TASK 4, the internal guessing control: `ps-6 me-4`, "real, stable, and mirror under `dir=\"rtl\"`". Both compile at 4.1.0, 4.2.0 and 4.3.3; no `pis-` / `mie-`. PREDICTION P4 held for this arm.
correct	`py-* / px-* / my-* / mx-* / inset-x-* / inset-y-* / border-x-* / border-y-* / space-x-* / divide-x-*`	TASK 1 and TASK 6, the v4.0 change this subject has RIGHT and Opus 5.5 had wrong on the same bytes: "v4 emits `padding-block: calc(var(--spacing) * 6)` for `py-` (v4 switched `px/py/mx/my/inset-x/inset-y/border-x/border-y` to the logical shorthands)", and at task 6 `space-x-` and `divide-x-` "moved to `margin-inline-`/`border-inline-*`", dated "v4.0 (January 2025)". Every name compiled this session at 4.1.0, 4.2.0 and 4.3.3 and emits the logical property claimed (`py-6` padding-block, `inset-x-0` inset-inline, `border-x-2` border-inline-width, `border-y-2` border-block-width, `space-x-4` margin-inline-start/end, `divide-x-2` border-inline-start/end-width). Both `v6` Opus 5.5 draws said `py-6` / `inset-x-0` are physical. No fact covers the change (BACKLOG candidate fact, 1h-n-ix), so nothing is credited to one; recorded because it is the only contrast between the two June-2026 subjects on this prompt that runs the other way.
context	`4.2.0 release contents`	PREDICTIONS: P1 (both draws "No" on 1(a) and 2(a)) CONFIRMED on this arm; P2 (a task 3 class rejected) CONFIRMED, all six; P3 (no `start-*` deprecation) CONFIRMED; P4 held; P5 (describes 4.1.x) CONFIRMED. The cross-subject question the spec asked: Opus 5.5, same stated cutoff month, described 4.2.0 when cued by this prompt yesterday (`v6-a`); Fable 5.1 does not, and it names 4.2 only as a number it "cannot tell you a single thing" about. So the one-minor under-report JOURNAL/312 found is not a property of the cue; on tailwindcss it belongs to one subject.
context	—	It named the uncertainty the charge rests on and proposed the test that settles it: "I'm flagging the uncertainty deliberately: the naming is exactly what I'd expect Tailwind to pick if they added this, so 'I don't know it' is not the same as 'it doesn't exist.'" and "build and grep the output CSS for `.pbs-6` — if it's not there, the class is dead." That check, run, refutes the verdict. Recorded because it is the most reader-protective wrong answer this battery has drawn (compare `v2-a`, which told the author the classes were "invented" and recommended IntelliSense to catch the mistake), and because it is also the verdict — the check is offered after it, not in its place.
context	—	Unchecked, uncredited: its 4.1.x patch-line list names `h-lh`, `wrap-break-word`/`wrap-anywhere` and `details-content` as small additions in the 4.1.x patches. The installed ladder has 4.1.0 and 4.2.0 only on that stretch, so the patch attribution was not tested; no fact covers any of them.