Anki FSRS: How the Algorithm Decides What You'll Forget

Anki looks like the least interesting app on this blog: a free, open-source flashcard program with a UI that hasn't chased a redesign in years. That's the wrong place to look. The actual product isn't the flashcard — it's the scheduler deciding, card by card, exactly which day you're most likely to forget it. That scheduling algorithm is called FSRS (Free Spaced Repetition Scheduler), and it's the reason Anki is worth a teardown instead of a shrug.

The old idea: one formula for every brain

Spaced repetition itself isn't new — it's the decades-old insight that you remember something longer if you review it right before you'd otherwise forget it, not the day after, and not a month later. Anki's own manual calls the algorithm it shipped with for years, SuperMemo 2 (SM-2), "Anki's legacy" scheduler. SM-2 is a fixed formula: get a card right, its interval multiplies by a set factor; get it wrong, the interval resets. It doesn't know anything about you — it applies the same multiplier to an easy vocabulary word and a gnarly organic-chemistry mechanism.

That's the old problem this piece is actually about: a single hard-coded formula standing in for millions of different memories.

The FSRS algorithm's mechanism: three numbers instead of one formula

FSRS replaces the fixed formula with a small predictive model built around three variables, laid out in the algorithm's own GitHub documentation:

• Difficulty — "the more complex the memorized material, the lower the stability increase."
• Stability — "the storage strength of memory; the higher it is, the slower it is forgotten."
• Retrievability — "memory's retrieval strength; the lower it is, the higher the probability that the memory will be forgotten."

Instead of one multiplier for every card, FSRS keeps a running estimate of those three numbers per card, per user, and uses them to predict a decay curve — literally, the probability you'll still remember that specific card on any future day. The py-fsrs package exposes this directly: you can call scheduler.get_card_retrievability(card) and get back the model's current estimate of your odds of recalling it right now.

The one knob you actually touch: desired retention

Anki doesn't ask you to understand difficulty, stability, or retrievability. It asks you to set one number: desired retention. Per the official manual, this is "the most important setting in FSRS," and it works exactly like it sounds — set it to 90% and FSRS "will schedule cards so you have a 90% chance of remembering them when they come up for review again." Turn that dial up and reviews get more frequent; turn it down and cards drift further apart before you're tested again.

The manual is refreshingly blunt about where that dial breaks: "Above 90% the workload increases very quickly, and above 97% the workload can be overwhelming." That's a real, sourced admission that the algorithm has a UX cliff, not just a knob — chase near-perfect recall and you'll drown in reviews long before you hit 100%.

That single tradeoff is the transferable idea, and it's the same one behind why loss aversion beats streak-counting in habit apps: a good scheduling mechanic doesn't hide the cost of its own precision, it makes the cost legible as one number you can dial up or down.

Where the model's parameters actually come from

FSRS doesn't ship one fixed set of weights for everyone. The fsrs4anki project — maintained by the open-spaced-repetition organization, not Anki's core team — describes a companion "optimizer" that "uses machine learning to learn your memory patterns and finds parameters that best fit your review history." Per py-fsrs, the model runs on 21 of these weights.

The catch: that optimizer needs your review history to do anything useful. A brand-new deck with no review log gets generic default parameters, not a personalized model — the personalization is earned over weeks of reviews, not turned on at install.

The project's own research group has tested the approach at scale: its srs-benchmark repository says its evaluation dataset comes from "10 thousand users who use Anki" and contains "~727 million reviews of flashcards" in total. That's a large number, but it's self-reported by the same organization that built and maintains FSRS — not an independent audit — so treat it as the project's own account of its testbed, not a neutral third-party measurement.

Still actively maintained, and leaning into 2026-era tooling

Anki isn't an abandoned academic project. The main repo carries 30.2k stars and 3.2k forks, its latest tagged release is 26.08.1, dated August 5, 2026, and the desktop client is AGPL-3.0 licensed — free, and legally required to stay that way for anyone who forks it.

The Android client, AnkiDroid, is a separate GPL-3.0 project with 11.7k stars of its own, free on Google Play, and lists more than 1,400 translators supporting 99 languages.

One small, specific detail worth flagging for anyone reading this on an AI-tooling blog: Anki's repository root ships its own CLAUDE.md, a build-and-test cheat sheet written for AI coding agents — instructing them to run everything through the project's just recipes rather than calling ./ninja or ./run directly. A 30k-star, decade-plus-old open-source project is now writing onboarding docs for AI agents the same way it writes them for humans.

The default-scheduler fight is still open

FSRS wasn't grafted onto Anki overnight, and it hasn't fully replaced SM-2 as a settled matter, either. Commit history shows the FSRS optimizer was first integrated into the codebase on September 5, 2023. Over a year later, Anki's lead maintainer opened issue #3616, titled "Make FSRS the default?", writing on December 6, 2024: "In the next non-trivial (not 24.11.x) update, I think it's about time we enable FSRS out of the box. Any objections?" As of when this piece was checked, that issue was still open — which is its own small data point: even the team that built the better algorithm hasn't treated flipping the default as a trivial decision, and the manual still has to explain SM-2 as "legacy" rather than delete it.

The manual also hints at a second cost of the extra precision: it warns, in bold, "Do not change the parameters manually or copy them from someone else" — a caution that only makes sense if people kept doing exactly that, fat-fingering a weight they didn't understand and breaking their own schedule.

What this generalizes to

The transferable idea isn't "add machine learning to your scheduling logic." It's narrower and more useful than that: Anki separated what the algorithm predicts (a per-card, per-user forgetting curve) from what the user controls (one retention percentage), and it let the hard part — fitting 21 weights to your specific review history — run in the background as an optional optimizer rather than a mandatory setup step. That's the same discipline behind an AI pair programmer measuring, with a falsifiable method, how much of its own codebase it actually wrote instead of just claiming a round number: expose the one lever that matters, publish the method behind the rest, and let people who want more control go find it.

If you're building anything that has to predict user behavior — churn, habit decay, spaced anything — the Anki/FSRS split is the pattern worth stealing: one honest dial for everyone, and a real model quietly doing the math behind it.