FSRS: Spaced-Repetition Scheduling as Parameter Estimation

Why This Matters

Every review-card system has to answer one question: given that a learner correctly recalled an item some number of days ago, what is the probability they can recall it right now, and when should the system ask again? That question is a parametric survival-modeling problem: recall probability decays with elapsed time, the decay rate depends on properties of the item and the learner's history with it, and the parameters governing that decay are estimated from data, not chosen by hand.

FSRS (Free Spaced Repetition Scheduler) is the current reference answer to that problem in the spaced-repetition literature. It replaces the older SM-2 algorithm (the SuperMemo-derived heuristic that was Anki's default scheduler for about three decades) with an explicit three-parameter memory model whose weights are fit by maximum-likelihood optimization over hundreds of millions of real review outcomes. TheoremPath's own ReviewCard layer runs a simplified implementation of this same model. This page treats FSRS as what it is: an applied statistics and measurement problem, not a pedagogy technique, and it is explicit about which parts of the general FSRS project TheoremPath's own code does and does not carry over.

Mental Model

Treat a single flashcard as a unit that emits a Bernoulli outcome (recalled or not) whenever it is reviewed, with success probability that decays over time since the last review. That decay curve is exactly a survival function: recall probability plays the role that survival probability plays in a survival-analysis model, and elapsed days since last review plays the role of time-since-origin. The three FSRS state variables give this survival model a memory: difficulty is a per-item shape parameter, stability is a per-item time-scale parameter, and retrievability is the survival function itself, evaluated at the current elapsed time.

Fitting FSRS parameters to a user's review history is the same kind of problem as fitting a parametric hazard model to censored time-to-event data: you observe partial histories (a card reviewed 3 times, "Good, Good, Again"), and you want the maximum-likelihood parameters of the assumed functional form that best explain those outcomes.

The DSR Model

FSRS represents the memory state of a single card as a triple of state variables, updated after every review.

Definition

Retrievability$R(t,S)$

The probability that the learner can successfully recall a specific card at elapsed time $t$ (days) since the last review, given the card's current stability $S$. Retrievability is a deterministic function of $t$ and $S$, not itself a free parameter; it is the forgetting curve evaluated at the current moment.

Definition

Stability$S$

The number of days required for retrievability to fall from 100% to exactly 90% following a review, holding no further reviews. Stability is not a half-life. By convention, every published version of FSRS defines $S$ so that $R(S, S) = 0.9$, not $R(S,S) = 0.5$. Stability grows after a successful review (more so when the review happened at low retrievability, since a recall against a nearly-forgotten memory is stronger evidence of durable learning) and resets to a smaller value after a lapse.

Definition

Difficulty$D$

An intrinsic scalar in $[1, 10]$ describing how hard a card is to stabilize: higher $D$ means each successful review buys a smaller multiplicative increase in stability. Difficulty is initialized from the first rating and updated after every subsequent review, with mean reversion toward a default-difficulty target so that a long run of "Good" ratings does not drive difficulty toward an extreme (the failure mode Anki users historically called "ease hell" under SM-2).

Watch Out

Stability is not the half-life of a memory

It is tempting to describe stability the way classical memory research describes the Ebbinghaus forgetting curve: as a half-life, the time for retention to fall to 50%. FSRS does not use that convention at any point in its published history. Every version from FSRS v1 through the current FSRS-6 defines stability as the time for retrievability to reach 90%, chosen because 90% is also the field's conventional default target retention. A model, tutorial, or exercise that treats $S$ as a 50%-recall half-life will compute the wrong review interval by roughly a factor of 5-9x depending on which forgetting-curve shape is assumed, because the curves are steep near $t=0$ and flatten out well before they reach 50% retrievability.

The Forgetting Curve Is a Power Law, Not Ebbinghaus's Exponential

A common assumption, carried over from Ebbinghaus's 1885 exponential retention curves, is that forgetting follows $R(t) \propto e^{-t/\tau}$ for some time constant $\tau$. FSRS v1 through v3, including "the first official release of the FSRS algorithm" (open-spaced-repetition/srs-benchmark, README.md, retrieved 2026-07-05), used exactly that exponential form, $R(t,S) = 0.9^{t/S}$. FSRS v4 replaced it with a power-law curve specifically because the new shape fit real review data measurably better, and every FSRS release since has kept the power-law family while re-tuning its shape. The forgetting curve has been the single component of FSRS revised most often across its version history: the DSR state variables and their symbols have stayed the same since FSRS v3, but the functional form of $R(t,S)$ and the number of free parameters have both changed at every major release from v4 onward.

Proposition

The FSRS Power-Law Forgetting Curve

Statement

For elapsed time $t$ (days) since the last review and current stability $S$, FSRS-4.5 and FSRS-5 define retrievability as

$R(t, S) = \left(1 + \mathrm{FACTOR} \cdot \frac{t}{S}\right)^{\mathrm{DECAY}}, \qquad \mathrm{FACTOR} = \frac{19}{81}, \ \mathrm{DECAY} = -\frac{1}{2},$

chosen so that $R(S, S) = 0.9$ by construction. The earlier FSRS v4 curve used $\mathrm{DECAY} = -1$ and $\mathrm{FACTOR} = 1/9$, i.e. $R(t,S) = (1 + t/(9S))^{-1}$. FSRS-6 makes the decay exponent itself a per-user optimizable weight $w_{20}$, with $\mathrm{FACTOR} = 0.9^{-1/w_{20}} - 1$ so that $R(S,S)=0.9$ still holds for every value of $w_{20}$.

Inverting for the interval $t^\star$ that hits a target retention $r$:

$t^\star(r, S) = \frac{S}{\mathrm{FACTOR}}\left(r^{1/\mathrm{DECAY}} - 1\right).$

For the FSRS v4 curve this is $t^\star(r,S) = 9S\left(\frac{1}{r}-1\right)$; at $r = 0.9$, $t^\star = S$ for every version, by construction.

Intuition

None of the FSRS forgetting-curve versions are exponential. An exponential curve has a constant hazard rate: the instantaneous probability of forgetting in the next instant, conditional on not having forgotten yet, does not depend on how long it has been. FSRS's power-law family has a hazard rate that falls over time, matching the empirical pattern that memories which have already survived a long interval are more durable going forward, not equally fragile at every instant. This is the same qualitative shape distinction that separates an exponential survival curve from a Weibull curve with decreasing hazard in classical survival analysis.

Why It Matters

The forgetting-curve family is not incidental detail; it is the object the optimizer fits. Every FSRS version bump that changed DECAY and FACTOR did so because the new shape produced a lower held-out log-loss on the project's benchmark of real Anki review logs (Ye, L-M-Sherlock, "The Algorithm", open-spaced-repetition/awesome-fsrs wiki, retrieved 2026-07-05). Treating the curve as fixed background rather than a fitted object is the single most common source of confusion when comparing FSRS versions or reimplementing the scheduler from a partial description.

Failure Mode

Because $R(S,S)=0.9$ holds for every version by construction, an interval computed at exactly the 90% default target looks identical across FSRS v4, FSRS-4.5, FSRS-5, and FSRS-6 for the same $S$. The versions only diverge away from the 90% point (see the derivation exercise below): a reimplementation that only spot-checks the 90% case can silently ship a stale curve while appearing correct.

report a correction →

Parameter Estimation: A Real Applied-ML Problem

The general FSRS project fits its weight vector by maximum-likelihood estimation over real user review histories, not by hand-tuning. The optimizer treats the ratings and inter-review intervals for each card as a time series, feeds them through the DSR update equations, and backpropagates through the entire sequence (backpropagation through time, BPTT, implemented in PyTorch) to fit the weights that minimize the negative log-likelihood of the observed recall/lapse outcomes:

$\mathcal{L}(\vec\theta) = -\sum_i \Big[p_i \log R(t_i, S_i(\vec\theta)) + (1-p_i)\log\big(1 - R(t_i, S_i(\vec\theta))\big)\Big],$

where $p_i \in \{0,1\}$ is whether review $i$ was a success and $S_i(\vec\theta)$ is the stability implied by the review history up to that point (Ye, "The mechanism of optimization", open-spaced-repetition/awesome-fsrs wiki, retrieved 2026-07-05). This is the same maximum-likelihood machinery used to train any sequence model on binary outcomes; the DSR equations are just a constrained, interpretable parameterization of the per-step success probability, fit with a gradient-based optimizer rather than a closed-form estimator.

The number of free parameters has grown with every version as the training data and the modeling ambition both grew: FSRS v1 used 7 weights, v2 used 14, v3 used 13, v4 and FSRS-4.5 used 17, FSRS-5 (July 2024) uses 19, and FSRS-6 uses 21 (Ye, "The Algorithm," retrieved 2026-07-05). Anki's built-in optimizer (available since Anki 23.10) refits these weights per user, and requires at least 400 reviews (Anki 24.04+) or 1,000 reviews (older versions) before it will produce a per-user fit; below that threshold, Anki falls back to the shipped defaults (open-spaced-repetition/fsrs4anki, docs/tutorial.md, retrieved 2026-07-05).

The Benchmark

The project's own benchmark evaluates every FSRS version, SM-2, half-life regression, and several other algorithms on identical held-out data: 9,999 Anki collections, 349,923,850 reviews after filtering, split by time (TimeSeriesSplit, older reviews train, newer reviews test) so that no algorithm is evaluated on data it could have seen during fitting (open-spaced-repetition/srs-benchmark, README.md, retrieved 2026-07-05). The three reported metrics are Log Loss (calibration of the predicted recall probabilities), RMSE(bins) (a custom binned calibration error), and AUC (discrimination). On the "without same-day reviews" split:

(open-spaced-repetition/srs-benchmark, README.md, "Without same-day reviews" table, retrieved 2026-07-05.) The current benchmark table does not carry an SM-2 row in the same format (SM-2 is evaluated by the same repository's own model code, but reported outside the headline comparison table), so the numbers above should be read as an ordering within the FSRS family, not a direct FSRS-vs-SM-2 log-loss delta.

FSRS vs SM-2

For the direct FSRS-vs-SM-2 comparison, the project's own documentation and wiki make two separate claims, at two different levels of evidence.

Qualitative, from the project's own tutorial: "SM-2: a simple 30-year-old algorithm developed by Piotr Wozniak, the creator of SuperMemo... Even with the default parameters, FSRS is better than the default Anki algorithm (SM-2)" (open-spaced-repetition/fsrs4anki, docs/tutorial.md, retrieved 2026-07-05).

Quantitative, simulation-based: "With FSRS, users have to do 20-30% fewer reviews than with SM-2 algorithm to achieve the same retention level" (open-spaced-repetition/awesome-fsrs wiki, ABC-of-FSRS.md, retrieved 2026-07-05, which itself flags the figure as "based on simulation results," not a randomized head-to-head trial).

SM-2 traces to Wozniak's SuperMemo work; the classical academic reference for the underlying two-component (stability/retrievability) memory model that FSRS's DSR triple descends from is Woźniak and Gorzelańczyk (1994), Acta Neurobiologiae Experimentalis 54(1): 59-62.

How TheoremPath Actually Uses This

TheoremPath's ReviewCard model (prisma/schema.prisma) stores stability, difficulty, due, lastReview, reps, lapses, and an FSRS state code per (userId, questionId) pair. The scheduler is a from-scratch TypeScript implementation at src/lib/fsrs/scheduler.ts (about 190 lines, deliberately dependency-free rather than pulling in the reference ts-fsrs package), with the persistence layer in src/lib/fsrs/card-store.ts. Three things are true about it, stated as precisely as the source lets us be.

It uses a fixed, shared weight vector, not per-user optimization. The 19-parameter weight array W in scheduler.ts is a snapshot of the FSRS-5 default parameters (the file's own comment dates it "2024-07-27," and cites the exact upstream commit they were verified against), used identically for every learner. The code says so directly: "A user-personalization step (Gaussian regression on review logs) is deferred." There is no background job, cron task, or per-user fit anywhere in the codebase; a repository-wide search for the desired-retention constant, DESIRED_RETENTION, turns up exactly one definition site, a module-level const in scheduler.ts, with no /settings override and no per-user column on ReviewCard. This is the single largest gap between what TheoremPath runs and what the general FSRS project does: the reference implementation refits its weights per user once a learner has logged enough reviews (400-1,000, depending on Anki version); TheoremPath does not yet do this for anyone.

Its forgetting curve now matches the current FSRS-5 power law — this was not always true, and the fix is worth stating plainly. scheduler.ts's retrievability and intervalDays functions implement $R(t,S) = (1+19t/(81S))^{-0.5}$ and its inverse $t^\star(r,S) = (81S/19)(r^{-2}-1)$: the $\mathrm{DECAY}=-0.5$, $\mathrm{FACTOR}=19/81$ curve that FSRS-4.5 and FSRS-5 use, matching both scheduler.ts's own header comment and docs/METHODOLOGY.md, which describe the algorithm as FSRS-5. Until a 2026-07-05 correctness audit, this was not the case: the code implemented the earlier FSRS v4 curve, $\mathrm{DECAY}=-1$, $\mathrm{FACTOR}=1/9$, while shipping FSRS-5 difficulty and stability weights fit against the newer curve. At the 90% default target this divergence made no difference (every version agrees there, by construction, per the theorem above); away from 90% it corrupted retrievability reads, including telemetry. This page's own worked exercise below quantifies the size of that now-fixed gap. The same audit also corrected the difficulty mean-reversion target from $D_0(\text{Good})$ to $D_0(\text{Easy})$, the value these weights are actually fit against.

The target retention is a single hardcoded constant, not a per-learner setting. DESIRED_RETENTION = 0.9 in scheduler.ts is used for every learner and every card; intervalDays accepts a retention parameter, but nothing in the codebase ever calls it with a value other than the default. TheoremPath's own in-product transparency panel (src/components/dashboard/transparency-panel.tsx) already states this plainly to users: "Reviews are scheduled by FSRS-5, an open-source spaced-repetition algorithm with default parameters from July 2024... Each card's due time is the moment its predicted retention drops to 90%." The daily review queue is /daily-review; the design is documented in docs/ADAPTIVE_LEARNING_KERNEL.md and docs/METHODOLOGY.md.

None of this makes the scheduler wrong. Fixed, published FSRS-5 defaults are, per the project's own tutorial documentation, already better calibrated than SM-2 for a learner with too little history for a personal fit to be reliable, which describes essentially every TheoremPath user today. The honest framing is narrower: TheoremPath now runs a correct FSRS-5 update rule with no per-user refitting, not the fully current, self-tuning FSRS-6 pipeline that a from-scratch reimplementation might suggest — and, until 2026-07-05, it ran an FSRS-5-labeled scheduler with a stale FSRS-v4 forgetting curve underneath, a divergence a spot-check at the 90% default retention target could not have caught.

What This Page Does Not Claim

This page does not claim TheoremPath's scheduler is miscalibrated in practice; the forgetting-curve divergence described above was a specific, bounded, quantified gap (see the exercise below) that has since been fixed, not a broad claim about scheduling quality. It does not claim per-user parameter optimization would clearly help TheoremPath's current user base: with review counts well below the 400-1,000 threshold the general FSRS project itself uses before trusting a per-user fit, a naive per-user refit would likely overfit 19 parameters to a few hundred data points. It does not claim the "20-30% fewer reviews than SM-2" figure is a measured, randomized-trial result; the project's own wiki labels it a simulation-based estimate.

Summary

• FSRS represents memory as a difficulty-stability-retrievability (DSR) triple; stability is defined as time-to-90%-retrievability, not a 50%-recall half-life.
• The forgetting curve is a power law, not the classical Ebbinghaus exponential: $R(t,S) = (1+\mathrm{FACTOR}\cdot t/S)^{\mathrm{DECAY}}$. The exact (FACTOR, DECAY) pair has changed at every major FSRS version.
• Parameters are fit by maximum-likelihood estimation via backpropagation through time over real review-log time series, the same estimation machinery used to train any sequence model on binary outcomes.
• On the project's own 9,999-collection, ~350M-review benchmark, FSRS-5 and FSRS-6 post materially lower held-out log loss than the earlier FSRS versions; the project documents, but does not print in the same table, a simulation-based "20-30% fewer reviews than SM-2" estimate.
• TheoremPath's scheduler uses fixed FSRS-5 default weights (no per-user optimization) and a hardcoded 0.9 target retention. It ran a stale FSRS v4 forgetting-curve formula under an FSRS-5 label until a 2026-07-05 correctness audit fixed it to the real FSRS-5 curve.

Exercises

ExerciseCore

Problem

A card has FSRS stability $S = 12$ days. Using the older FSRS v4 forgetting-curve formula that TheoremPath's scheduler.ts ran until a 2026-07-05 fix (see Exercise 2 for the current formula), $R(t,S) = (1+t/(9S))^{-1}$, compute the interval at which predicted retrievability drops to (a) 90% and (b) 80%.

Hint

Reveal Solution

ExerciseAdvanced

Problem

FSRS-4.5 and FSRS-5 replaced the $(\mathrm{DECAY}=-1,\ \mathrm{FACTOR}=1/9)$ curve from Exercise 1 — the curve TheoremPath's scheduler.ts ran until a 2026-07-05 fix — with a steeper power law, $\mathrm{DECAY}=-0.5$, $\mathrm{FACTOR}=19/81$, which is what scheduler.ts implements today. For a card with stability $S$ days, derive $t^\star(r,S)$ under the newer curve and compare the interval at $r=0.8$ under both formulas.

Hint

Reveal Solution

ExerciseResearch

Problem

Design what adding real per-user parameter optimization to TheoremPath would require, given that the general FSRS project only trusts a per-user fit once a learner has logged 400-1,000 reviews. Address: (a) what data TheoremPath already logs that a fitter would need (ReviewCard, ReviewEvent), (b) what objective and optimizer you would use, (c) a cold-start policy for learners below the review-count threshold, and (d) the statistical risk of fitting 19-21 parameters per learner with only a few hundred observations.

Hint

Reveal Solution

References

Primary (the FSRS project itself):

• Ye, J. (GitHub: L-M-Sherlock), "The Algorithm", open-spaced-repetition/awesome-fsrs wiki, retrieved 2026-07-05. Forgetting-curve formulas, parameter counts, and update equations for every FSRS version (v1 through FSRS-6).
• Ye, J., "The mechanism of optimization", open-spaced-repetition/awesome-fsrs wiki, retrieved 2026-07-05. Maximum-likelihood estimation and backpropagation-through-time training of the DSR model over real review-log time series.
• Ye, J., "ABC of FSRS", open-spaced-repetition/awesome-fsrs wiki, retrieved 2026-07-05. Plain-language DSR overview; source of the "20-30% fewer reviews than SM-2" simulation-based estimate.
• open-spaced-repetition/srs-benchmark, "README", retrieved 2026-07-05. The held-out benchmark methodology (9,999 Anki collections, 349,923,850 reviews, TimeSeriesSplit) and per-version Log Loss / RMSE(bins) / AUC results.
• open-spaced-repetition/fsrs4anki, docs/tutorial.md, retrieved 2026-07-05. SM-2 attribution and the "even with default parameters, FSRS is better than SM-2" claim.

Academic:

• Su, J., Ye, J., Nie, L., Cao, Y., and Chen, Y., "Optimizing Spaced Repetition Schedule by Capturing the Dynamics of Memory," IEEE Transactions on Knowledge and Data Engineering (2023), doi:10.1109/TKDE.2023.3251721. The closest peer-reviewed treatment of the DSR model and its optimization.
• Ye, J., Su, J., and Cao, Y., "A Stochastic Shortest Path Algorithm for Optimizing Spaced Repetition Scheduling," KDD (2022), doi:10.1145/3534678.3539081. Scheduling as a stochastic shortest-path problem over the fitted memory model.
• Woźniak, P. A., and Gorzelańczyk, E. J. (1994), "Optimization of repetition spacing in the practice of learning," Acta Neurobiologiae Experimentalis 54(1), pp. 59-62, doi:10.55782/ane-1994-1003. Classical two-component (stability/retrievability) memory model that DSR generalizes; SM-2 itself traces to Wozniak's earlier SuperMemo work.
• Settles, B., and Meeder, B., "A Trainable Spaced Repetition Model for Language Learning," ACL (2016), doi:10.18653/v1/P16-1174. Duolingo's half-life regression model, an alternative trainable scheduler cited alongside FSRS in the project's own benchmark.

TheoremPath's own implementation:

• src/lib/fsrs/scheduler.ts: the scheduler this page audits.
• src/lib/fsrs/card-store.ts: the persistence layer around ReviewCard.
• prisma/schema.prisma, ReviewCard model: the per-(user, question) FSRS state.
• src/components/dashboard/transparency-panel.tsx: the in-product disclosure of the default parameters and the 90% target quoted above.
• docs/METHODOLOGY.md, section 2: the internal spec describing R, S, D for TheoremPath's adaptive layer.

Next Topics

• Survival analysis: the general theory of hazard functions and time-to-event modeling that the forgetting curve is a special case of.
• Proper scoring rules: the theory of why the negative log-likelihood FSRS minimizes is a valid, non-gameable calibration objective.