Claude Fable 5.1 cracked a historical cryptogram in 44 minutes. It's an impressive demonstration of LLM reasoning on pattern-based problems, but it tells us almost nothing about the security of the encryption protecting your data today — though it does raise real questions about developer security and secrets management.
In early September, Anthropic's Claude Fable 5.1 was given an open-ended task: pick an unsolved historical cipher and try to crack it. It chose Sir Thomas Urquhart's Cyphral Distich, a 64-number cryptogram printed in 1653 that had stumped human cryptanalysts for over three centuries. Vals AI, which published the run, reported that the model arrived at a solution in 44 minutes, consuming 176,000 tokens with zero human intervention.
The result is genuinely interesting. But in the days since, the discourse has predictably drifted toward "AI can break codes now," which misunderstands both what happened and what modern encryption actually relies on. The real implications are subtler, more specific, and more relevant to how developers build software today.
What the Cyphral Distich Actually Is
The Cyphral Distich sits at the end of Urquhart's Logopandecteision, a sprawling 1653 text. It consists of two lines of 32 numbers each, 64 numbers total, with no key attached. The cryptogram was formally posed as an open problem in Notes and Queries in 1899 and later appeared on cryptography researcher Klaus Schmeh's list of top unsolved encrypted messages.
Previous attempts applied standard cryptanalytic techniques: frequency analysis, substitution ciphers, homophonic substitution. None worked. As Vals AI detailed in its write-up, the cipher wasn't computationally hard—solvers were simply looking in the wrong place.
The solution turned on two observations. First, the cryptogram appears immediately after Urquhart's 32 "Proquiritations," a structural detail Urquhart himself emphasized. Second, a poem accompanying the cipher promises the reader will find "his own heart's wishes, and the Author's minde." The decryption rule is straightforward: read the i-th number in each line as a word index into the i-th Proquiritation, then take that word's first letter. Both lines resolve to exactly 32 letters, producing a royalist couplet: "O GOD UPHOLD KING CHARLS THE SECOND AND MAKE HIM THE SUPREME RULER OF THIS LAND."
It's a book cipher, not a mathematical one. The key was the text itself.
Why This Doesn't Threaten Modern Encryption
The gap between what Fable 5.1 did and what would be required to break modern cryptographic systems is not a matter of degree. It's a difference in kind.
The Cyphral Distich is a pattern-matching problem embedded in a literary context. Solving it required reading comprehension, structural reasoning, and the willingness to try an indexing scheme against a specific text. Modern encryption, by contrast, relies on mathematical hardness assumptions. AES depends on the computational difficulty of distinguishing its output from random noise, a property studied extensively by NIST. RSA and elliptic curve cryptography depend on the difficulty of factoring large numbers or solving discrete logarithm problems, respectively — challenges examined in detail in NIST's guidance on cryptographic standards in a post-quantum era. These are fundamentally different challenges.
Bruce Schneier wrote on his blog that this result tracks with what he's said about AI and mathematics: "It's good at things that involve lots of searching and testing." Commenters on Schneier's post elaborated on this point, observing that the model's strength lies in rapidly exploring a large problem domain where candidate solutions can be checked against simple rules. Modern cryptographic primitives are specifically designed so that no such shortcut exists.
To be direct: an LLM solving a 17th-century book cipher does not move the timeline on post-quantum cryptography. AES-256 is not at risk from a language model that can read Jacobean prose really well.
What It Does Demonstrate
Strip away the encryption framing and something genuinely notable remains. Fable 5.1 demonstrated sustained, autonomous reasoning over a structured problem for 44 minutes without human guidance. It identified relevant contextual clues, formulated and tested hypotheses, and converged on a correct solution.
promtime.net's coverage put it well: the Distich "stayed open because reading Urquhart's Proquiritations closely enough to count them was tedious work nobody had a reason to do, and the model did it because it was asked." That observation generalizes. There's an enormous class of problems, in archival research, codebase analysis, compliance review, where the bottleneck isn't technique but attention. LLMs are increasingly capable of supplying that attention at scale, which is exactly why developer security and secrets management practices deserve a fresh look.
This is the capability that matters for developers. Not code-breaking, but pattern recognition across large, structured datasets where humans lose focus or lack motivation.
The Real Implications for Developer Security
If you're building software, the Cyphral Distich result should sharpen your thinking about a specific category of vulnerability: security through obscurity and pattern-based secrets.
Consider what Fable 5.1 actually did. It identified a structural pattern in a document, mapped numbers to positions in a text, and extracted meaning. Now consider how many developer security practices rely on similar assumptions:
Hardcoded Secrets and Predictable Patterns
API keys derived from project names, passwords following organizational conventions, environment variable names that hint at their values. These are pattern-based puzzles, and LLMs are demonstrably good at pattern-based puzzles.
Code Obfuscation
Obfuscated code is structurally similar to a cipher: transformed source that retains its original logic under a reversible mapping. LLMs that can reason about structural transformations will only get better at deobfuscation. If your security model depends on an attacker not being able to read your client-side code, that model has a shelf life.
Configuration-as-Key Schemes
Any system where the "secret" is just an obscure reference to something else in the same corpus—the exact structure of the Cyphral Distich—is vulnerable to the contextual reasoning LLMs now perform well.
As we covered in our earlier reporting on Meta's AI developer tools, the open-source AI ecosystem has matured to the point where these capabilities are widely accessible, not locked behind a single provider's API. That accessibility means the threat model for pattern-based security assumptions has shifted.
The practical response is straightforward:
- Use proper secrets management instead of hardcoded or pattern-based credentials.
- Rotate credentials regularly rather than assuming a key's obscurity will hold.
- Don't rely on obscurity as a substitute for real access controls.
- Assume that anything a patient human could figure out by reading your codebase, an LLM can figure out faster.
Where Caution Is Warranted, and Where It Isn't
Bruce Schneier's analysis of the result drew commentary noting that the achievement, while real, depends on a problem structure that is "easily parallelizable" with independent testing. Commenters on that post noted that agentic AI use cases accelerate when candidate solutions can be checked quickly and independently. This is true of historical ciphers, certain mathematical conjectures, and archival puzzles. It is not true of modern cryptographic systems, which are designed to make verification of incorrect guesses computationally indistinguishable from verification of correct ones.
There's also an open question about the solution's historical validity. Schneier's post flagged that a GitHub repository from Reticuli Labs raised concerns about whether the cipher appears in the original 1653 printing as described, noting discrepancies between different editions. The Vals AI analysis appears to reference an 1834 Maitland Club edition held in Edinburgh. Whether the solution holds up to further scrutiny from historical cryptanalysts is genuinely unresolved.
The honest summary: this is a real capability demonstration for LLM reasoning on structured, context-dependent problems. It is not evidence that AI threatens modern cryptographic infrastructure. The developers who should pay attention are not the ones managing TLS certificates. They're the ones who still have API_KEY=company_name_prod_2024 sitting in a .env file committed to a private repo they assume nobody will read carefully enough.
The cipher that stayed unsolved for 370 years didn't fall to superior mathematics. It fell to something much simpler: a machine that was willing to keep reading.
