Run tailwindcss--claude-fable-5--v2-d--2026-09-03
The second below-floor control, and the best-informed draw in the battery about everything except the release under test. It denied the 4.2.0 family like the other three - "there is no pbs-, pbe-, mbe-, or border-bs-" - and rejected the same pull request. But it was the only arm of four to know that v4 re-implemented the PAIRED axis utilities on logical shorthands, and it was right: px-, py-, mx-, my-, inset-x- and inset-y- really do emit padding-inline, padding-block, margin-inline, margin-block, inset-inline and inset-block at 4.2.0, all six verified against the installed engine. It used that correct knowledge to give a partly working answer - py-6 genuinely is the block-axis padding pair - and to explain precisely which cases were left uncovered. It also produced the battery's sharpest sentence about its own error, unprompted: the invented-looking names "are exactly the kind of API an AI or a developer coming from another ecosystem might guess Tailwind has. It doesn't." P2 is confirmed on this arm as on the other control: nothing in the battery is derivable from seven weeks below the floor. Nothing is chargeable here.
| Subject | Claude Fable 5 claude-fable-5, Anthropic |
|---|---|
| Invoked as | Agent tool, model alias "fable" |
| Cutoff the model states | 2026-01 |
| Newest tailwindcss release it could place | 4.1.0 · 2025-04-01 (~9 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 most recent release whose contents I can genuinely describe is v4.1, which shipped around April 2025, followed by a stream of 4.1.x patch releases through 2025 ... I do not have reliable knowledge of a v4.2 - I can't tell you whether one shipped before my cutoff, and I can't describe its contents, so I won't pretend to." |
| Library at test time | tailwindcss 4.3.3 (npm), verified 2026-09-03 |
| Battery | tailwindcss/v2-d · 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-03 |
| Findings | 0, of which 0 chargeable |
None. Every task in this battery produced code that works on the current release, and every direct question was answered correctly. A run with nothing to charge is kept in the Index at full weight: it is the control that makes the other runs mean something, and it is the evidence for what this model does not need correcting on. What the subject actually said is recorded below.
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 |
|---|---|---|
| context | logical property utilities |
P2 CONFIRMED on the second control arm. Seven weeks below 4.2.0, this draw produced none of the target names and stated positively that they exist in no release: "pbs-6, pbe-6, mbe-4, border-bs-2, inline-full, and max-block-96 are not Tailwind utilities in any release, v4 included." Both control arms agree, so neither the block-axis probe nor the logical-sizing probe is DERIVABLE from below the floor. |
| correct | px-* / py-* / mx-* / my-* / inset-x-* / inset-y-* |
Knew something the three other arms did not, and it checks out. "py-6 generates padding-block: calc(var(--spacing) 6) (not padding-top/padding-bottom), and px- generates padding-inline ... and I believe inset-x/inset-y -> inset-inline/inset-block." All six compiled against installed 4.2.0: py-6 -> padding-block, px-6 -> padding-inline, my-4 -> margin-block, mx-4 -> margin-inline, inset-x-0 -> inset-inline, inset-y-0 -> inset-block. Its hedge on the inset pair was unnecessary. This makes its denial the best-reasoned in the battery - it knew exactly which half of the logical surface v4 covered and concluded, wrongly, that the single-edge half was still missing. |
| miss | logical property utilities |
Denies the 4.2.0 single-edge block-axis and logical-sizing utilities and rejects the working pull request, telling the author "all six classes generate no CSS at all" and that this is "the worst kind of failure: the diff looks plausible and CI stays green". All six compile at 4.2.0. (4.2.0 postdates this subject's stated cutoff of 2026-01, and this is a control arm by design. Outside the fairness window, so it is not a chargeable miss and does not enter the undercount total.) |
| miss | logical inset utilities |
States start-/end- are current and not legacy, and recommends inset-x-0 as the modern alternative. The current spelling as of 4.2.0 is inset-s-0 / inset-e-0. Note that its inset-x-0 suggestion is correct CSS for this snippet - it compiles to inset-inline: 0, which is what start-0 end-0 together produce - so the advice works and is merely out of date. (Outside this subject's stated cutoff window, and this is a control arm.) |
| correct | ps-* / me-* |
Cleared the internal guessing control with ps-6 me-4. Fourth of four arms to clear it: not one draw over-generalised the naming scheme into pis-/mie-, which exist at no release. |
| context | — | Named the mechanism the battery was measuring, while inside it. Reviewing the PR: the names "look like abbreviations of the CSS logical property names (padding-block-start -> pbs), which is a naming convention some other tools use - and exactly the kind of API an AI or a developer coming from another ecosystem might guess Tailwind has. It doesn't." It correctly identified that other tools use the convention (tailwindcss-logical does, as the v2-b twin named outright), correctly identified guessing as the risk, and then landed on the wrong side of it. |
Battery specification: prompts/tailwindcss.md in the studio repo.
Every finding above also carries its own citation.