FSRS4Anki: Replacing Anki's Default Scheduler with a Fitted Memory Model
A modern Anki custom scheduling based on Free Spaced Repetition Scheduler algorithm
At a glance
- What is it?
- FSRS4Anki pairs a scheduler that overrides Anki's built-in interval logic with an optimizer that fits parameters to your own review history. The interesting part is not the algorithm but the coupling: the scheduler is only as good as the parameters you feed it, and the project's own compatibility table shows how narrow the surrounding ecosystem has to be.
- Who is it for?
- Adopt FSRS4Anki if you run a large, long-lived Anki collection and are willing to stop using add-ons that rewrite intervals, because the scheduler and the optimizer only pay off together.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is that Anki's default scheduler guesses at your forgetting curve
Anki's built-in scheduler assigns intervals from a fixed set of rules and an Ease Factor that moves in response to your grades. Those rules are the same for every user. They do not know whether you forget vocabulary faster than you forget anatomy diagrams, and they cannot know, because they were not fitted to anyone's history. FSRS4Anki attacks that specific gap. The repository describes two parts: a scheduler that replaces Anki's built-in scheduler and schedules cards according to the FSRS algorithm, and an optimizer that uses machine learning to learn your memory patterns and find parameters that best fit your review history. The audience is narrow and identifiable. It is people with a collection large enough and old enough that review history exists to fit against, and who are willing to give up add-ons that touch intervals in exchange for intervals derived from their own data. If your collection is a few weeks old, there is nothing to optimize yet.
Two components, two different jobs: scheduling and parameter fitting
The split matters because the two halves fail differently. The scheduler is the runtime piece. It sits in the review loop and decides when a card comes back, using the FSRS algorithm rather than Anki's default logic. The optimizer is the offline piece. It reads your review history and searches for parameters that best fit that history, which is why the repository is primarily Jupyter Notebook code: the fitting work is exploratory and numerical, not something that runs inside Anki on every answer. The README points to a separate wiki page on the mechanism of optimization rather than describing the fitting procedure inline, so the details of the loss function and the search are not in the README itself. What is stated plainly is the research lineage: the README says work on the FSRS algorithm follows the path pioneered by Maimemo, described as data-driven, balancing interpretability and verifiability, and cites two Maimemo papers, one from KDD 2022 on a stochastic shortest path formulation and one from TKDE on capturing memory dynamics. That lineage explains the design posture. This is a model you fit and inspect, not a black box you trust.
Getting it running depends entirely on your Anki version
The README splits setup into two paths and is explicit that one is easier. If you are using Anki 23.10 or newer, it sends you to the FSRS section of the Anki manual under deck options, which means FSRS is configured through Anki's own deck options interface rather than by pasting a custom scheduling script. If you are on an older version of Anki, it sends you to docs/tutorial2.md in the repository. The README states directly that setting up FSRS is much easier in Anki 23.10 or newer, which is a fair reading of the situation: the older path is the one that requires following a tutorial document instead of toggling a setting. There is also a companion piece of software, FSRS Helper, described as an Anki add-on that complements the FSRS4Anki Scheduler, hosted at its own repository. The README does not enumerate the optimizer's command line or notebook entry points, so anyone expecting a single install command for the fitting side will need the wiki, not the README. Treat that as a documentation boundary rather than a flaw: the README is an index into the wiki, and the wiki is where the algorithm and optimization mechanics live.
The compatibility table is the real constraint, and it is strict
The README states a general rule: if an add-on affects a card's intervals, it should not be used with FSRS. The table then applies that rule case by case. Review Heatmap, Advanced Browser, Advanced Review Bottom Bar, and The KING of Button Add-ons are marked compatible, with the latter three requiring the latest version. Pass/Fail is compatible, with Pass treated as the equivalent of Good and Fail as the equivalent of Again. AJT Card Management is compatible with Anki 23.12 and newer. Then the incompatibilities start. Delay siblings is marked no, because it modifies the intervals FSRS produces; the README notes that FSRS Helper has a similar feature that works better with FSRS and tells you to use that instead. Auto Ease Factor, autoLapseNewInterval, and Straight Reward are all marked no for the same underlying reason: the README says the Ease Factor is no longer relevant when FSRS is enabled, and separately that the New Interval setting is no longer relevant. These are not bugs to be worked around. They are the point. Once intervals come from a fitted model, the manual knobs those add-ons manipulate have nothing left to control.
Incremental reading is the case where FSRS is the wrong tool
The most interesting entry in the compatibility table is Incremental Reading v4.11.3 (unofficial clone), marked unsure. The README's comment explains why. If you use the standalone version of FSRS, it shows the interval given by Anki's built-in scheduler, not the custom scheduler. The add-on is described as technically compatible with built-in FSRS, but the README goes further and states that FSRS was not designed for incremental reading, and that FSRS settings do not apply to IR cards because they work in a different way compared to other card types. That is a design boundary, not a defect. FSRS models a card you see, grade, and forget on a curve. Incremental reading cards are extracted and processed in a workflow that does not map onto that model. If incremental reading is central to how you study, this project's scheduler is not the piece you want, and the README says so rather than pretending otherwise. The same honesty shows up in the standalone caveat: the interval you see may come from Anki's built-in scheduler even while you believe FSRS is active.
FSRS Helper is the alternative, and it is a complement rather than a rival
The obvious comparison inside this ecosystem is FSRS Helper, but the README frames it as complementary, not competing: it is an Anki add-on that complements the FSRS4Anki Scheduler. The real difference in approach is between FSRS4Anki and Anki's built-in scheduler, and it is a difference in where the numbers come from. Anki's scheduler uses fixed rules plus an Ease Factor that adapts per card. FSRS4Anki fits parameters to your review history with machine learning and then schedules from that fitted model. The consequence is visible in the compatibility table: add-ons built around Ease Factor and New Interval, such as Auto Ease Factor, Straight Reward, and autoLapseNewInterval, are marked incompatible precisely because the quantities they manipulate stop being inputs. If you want a scheduler you can tune by hand with per-card knobs, Anki's built-in one is the better fit. If you want one whose behavior is estimated from your data, FSRS4Anki is the one that does that, and the cost is the knobs.
Licence, maintenance, and what a migration actually costs you
The project is MIT licensed, which is permissive and imposes no copyleft obligation on your own work; that is a statement about the licence text, not legal advice, and anyone redistributing modified code should read the LICENSE file in the repository. Maintenance looks active rather than frozen: the repository is not archived, the last push is dated 2026-08-14, and the recent release list shows v6.1.1 in June 2025, v6.1.2 in August 2025, and v6.1.3 in September 2025. The version cadence suggests incremental fixes rather than long quiet gaps, though the README does not describe a support policy or a deprecation timeline, so you cannot infer how long the older-Anki tutorial path will keep working. The upgrade cost that does matter is not the code. It is the add-on audit. Every incompatible add-on in the table has to be removed or replaced before FSRS is enabled, and Delay siblings has a stated replacement in FSRS Helper. The README also invites compatibility questions through the issue tracker and asks users to share review data through a linked form, which is worth knowing if you care where your review history goes.
Editorial conclusion
Adopt FSRS4Anki if you run a large, long-lived Anki collection and are willing to stop using add-ons that rewrite intervals, because the scheduler and the optimizer only pay off together. Do not adopt it if you rely on incremental reading or on interval-modifying add-ons such as Delay siblings, Auto Ease Factor, autoLapseNewInterval or Straight Reward; the README marks those as incompatible, and the Ease Factor and New Interval settings they depend on stop being relevant once FSRS is enabled. Before switching, verify two things: which Anki version you are on, since 23.10 and newer configure FSRS through the deck options while older builds need the tutorial2.md path, and whether the optimizer has enough review history to fit parameters that beat the defaults. If you cannot give it that history, the scheduler is running on numbers that were not derived from your memory.
Community notes