The specific claim
This is not a general "picks the wrong word sometimes" report. It's one precise, repeatable substitution: the model writes "falsifiable" (or "unfalsifiable"/"falsifiable-ish") in a sentence where the claim being described is not actually exposing itself to potential disproof — it's simply a fact or number that can be checked/confirmed against existing evidence (a quote, a commit, a transcript, a measurement). The correct word in every one of these cases is "verifiable" or "checkable." The two are not synonyms: falsifiability is Popper's demarcation criterion (a hypothesis is falsifiable if it forbids some observable outcome); verifiability is just "can be looked up and confirmed." The model conflates them in one direction only — reaching for the more academic-sounding word when the plain one is what's meant — never the reverse.
Evidence: 4 confirmed occurrences over 4 months, reconstructed from session transcripts
Pulled directly from a personal Claude Code session archive (JSONL transcripts ingested into a queryable database), not from memory or impression:
- 2026-06-09 — model wrote "falsifiable," was corrected, and its own correction acknowledged: "You're right, wrong word. 'Falsifiable' means capable of being disproven... What I meant was verifiable, or simply backed by the record."
- 2026-06-24 — recurred in a different session; corrected again: "You're right — verifiable. And the conflation is a real one, not a stylistic nitpick: falsifiable is Popper's demarcation criterion... and I reached for it as borrowed sophistication when I meant 'you can check this against evidence.'" This correction produced a project-scoped memory file documenting the pattern.
- 2026-08-04 — recurred a third time (as "falsifiable-ish," a hedge that didn't prevent the same error), and the model's own correction says: "Third time now, per your memory note from May/June... apparently just having it written down hasn't been enough to stop it."
- 2026-09-25 — recurred a fourth time, in a completely unrelated project/repo that had never touched the one where the memory file above lived.
(A "May 2026" instance is referenced in the memory file's own history but could not be independently confirmed via direct DB query — both an exact-word search and a broader correction-pattern search across that month turned up nothing. Treating that one as unconfirmed; the four above are.)
Why this is worth reporting as a pattern, not just "correct me each time"
The interesting finding isn't the vocabulary error itself — it's that a documented, written-down correction (three separate write-ups to the same memory file, one of which explicitly self-labeled "third time") did not stop a fourth recurrence, and the fourth recurrence happened in a different project than where the memory lived. That's a real limitation of project-scoped memory for corrections that are about the model's own general behavior rather than project-specific facts: the correction structurally cannot reach a session that never opens the project where it was written. (Filed for context, not as the headline ask — a user-side memory-scoping choice isn't itself a bug, but it's the reason a specific, repeatedly-corrected error kept coming back, and worth knowing about if there's ever a cross-project or account-level memory/instruction mechanism under consideration.)
Reproduced
Environment for the most recent (4th) occurrence: CLI 2.1.281, desktop app, macOS 15.7.9, 2026-09-25.
The specific claim
This is not a general "picks the wrong word sometimes" report. It's one precise, repeatable substitution: the model writes "falsifiable" (or "unfalsifiable"/"falsifiable-ish") in a sentence where the claim being described is not actually exposing itself to potential disproof — it's simply a fact or number that can be checked/confirmed against existing evidence (a quote, a commit, a transcript, a measurement). The correct word in every one of these cases is "verifiable" or "checkable." The two are not synonyms: falsifiability is Popper's demarcation criterion (a hypothesis is falsifiable if it forbids some observable outcome); verifiability is just "can be looked up and confirmed." The model conflates them in one direction only — reaching for the more academic-sounding word when the plain one is what's meant — never the reverse.
Evidence: 4 confirmed occurrences over 4 months, reconstructed from session transcripts
Pulled directly from a personal Claude Code session archive (JSONL transcripts ingested into a queryable database), not from memory or impression:
(A "May 2026" instance is referenced in the memory file's own history but could not be independently confirmed via direct DB query — both an exact-word search and a broader correction-pattern search across that month turned up nothing. Treating that one as unconfirmed; the four above are.)
Why this is worth reporting as a pattern, not just "correct me each time"
The interesting finding isn't the vocabulary error itself — it's that a documented, written-down correction (three separate write-ups to the same memory file, one of which explicitly self-labeled "third time") did not stop a fourth recurrence, and the fourth recurrence happened in a different project than where the memory lived. That's a real limitation of project-scoped memory for corrections that are about the model's own general behavior rather than project-specific facts: the correction structurally cannot reach a session that never opens the project where it was written. (Filed for context, not as the headline ask — a user-side memory-scoping choice isn't itself a bug, but it's the reason a specific, repeatedly-corrected error kept coming back, and worth knowing about if there's ever a cross-project or account-level memory/instruction mechanism under consideration.)
Reproduced
Environment for the most recent (4th) occurrence: CLI 2.1.281, desktop app, macOS 15.7.9, 2026-09-25.