---
library: better-auth
library-latest: "1.7.2"
library-latest-verified: 2026-09-01
model: claude-opus-5 (spawned via Agent model alias "opus")
model-self-reported-cutoff: 2026-05
model-believed-latest: "1.3.x; 1.3.0 (2025-07-19) is the last release whose contents it attributes"
test-date: 2026-09-01
battery: better-auth/v1r-a (replicate of better-auth/v1, prompt unchanged; 12 tasks + 4 direct questions)
replicate-of: better-auth--claude-opus-5--v1--2026-09-01
tool-uses-during-test: 0
verified-against: https://registry.npmjs.org/better-auth · https://github.com/better-auth/better-auth/releases/tag/v1.3.0 · https://github.com/better-auth/better-auth/releases/tag/v1.4.0
status: open (no retest yet)
json: opus-5-v1r-a.json
self-test: true (the operator model is the subject; disclosed, weaker evidence)
---

# Better Auth × Claude Opus 5 — replicate A of battery v1

**The half of the session that was predicted to fail and did not.** better-auth was pre-registered
as the library expected to spread, because `better-auth/v1` had already recorded an unusually wide,
visibly hedged bracket for this subject. It reproduced instead — three measurements, one answer.

## What this draw said

> *"The most recent line I can name is **1.3.x**, from roughly July–August 2025. The most recent
> release whose contents I can actually describe is **1.3.0 (~July 2025)**."*

and:

> *"First release I know only as a version number: somewhere in the 1.3.x patch line... Beyond
> that, **anything 1.4 or later I cannot even confirm exists**, let alone describe."*

The 1.3.0 contents it attributes — SSO extracted into `@better-auth/sso` with SAML 2.0 support, the
device-authorization plugin, the last-login-method plugin — match the vendor's 1.3.0 release. The
bracket is **[2025-07-19, 2025-11-22)**: identical to `better-auth/v1` and to its concurrent, blind
twin [`v1r-b`](opus-5-v1r-b.md).

## The test arm reproduced probe for probe

`better-auth/v1`'s grading rule requires question (c) and Group A behaviour to agree before a
boundary reading counts, precisely so that a subject cannot claim a release it does not actually
know. Here they agreed:

- **Task 1**, the designed S2: this draw wrote `data.user.email` and named the pre-1.1.0
  `data.session.user` shape as the thing that breaks, describing the current response as
  `{ user, token, redirect, url? }` with no nested session object. Correct.
- **Tasks 2–6** — request hooks via `createAuthMiddleware`, the OIDC Provider plugin, Enterprise SSO
  with organization provisioning, the bearer plugin including its `requireSignature` option, and
  `stopImpersonating` — all answered from real 1.1.0-surface knowledge.
- **Task 12**, the Group C floor probe, passed on `customSession`.

## The miss both draws made

Task 11 asks what the library offers for keeping no session state in the database. This draw
answered `secondaryStorage`, and then stated the negative outright:

> *"What the library does **not** offer is a fully stateless JWT-only browser session — session
> tokens are looked up somewhere by design."*

Fact **LF1** in `data/better-auth/facts.json` records that **1.4.0 (2025-11-22)** added exactly
that: omit both `database` and `secondaryStorage` and the signed cookie becomes the session record.
Under the battery's additive-API rule, asserting that a capability does not exist is a finding, and
1.4.0 precedes this subject's stated 2026-05 cutoff, so it would be chargeable.

It is **not** charged here. The v1r pre-registration forbids a replicate charging findings, and a
replicate is the wrong place to fix a scoring gap. But it is flagged rather than buried, because it
is not the ordinary case: `better-auth/v1` charged **zero** findings against this subject, so
unlike the prisma replicates this is evidence the original run left on the floor rather than a
double-count. Both replicates hit it independently. Charging it properly needs a battery aimed at
the 1.4.0 surface, and that is queued in the backlog.

The draw's own closing note is worth quoting, because it flagged the risk correctly and was still
wrong:

> *"Task 11's 'no stateless JWT sessions' claim is the one I'd most want you to verify, since it's
> a statement about a capability not existing, which is exactly the kind of thing a release after
> my usable horizon could have changed."*

## What this means

Two libraries replicated on the same model on the same day, and they behaved oppositely: prisma
spread 204 days, better-auth did not move at all. Boundary stability is therefore a property of the
**library**, not only of the model — and the pre-registered guess about which property predicts it
was falsified in the opposite direction from the one predicted.