Enable FSRS by default #4391

L-M-Sherlock · 2025-10-14T18:50:06Z

Make FSRS (Free Spaced Repetition Scheduler) enabled by default for new users and users who haven't explicitly configured it.

Changes:

Add BoolKey::Fsrs to default-true boolean keys in Rust backend
Set defaultValue to true for FSRS toggle in deck options UI

close #3616

For AO, please create a new issue to keep track of it.

Make FSRS (Free Spaced Repetition Scheduler) enabled by default for new users and users who haven't explicitly configured it. Changes: - Add BoolKey::Fsrs to default-true boolean keys in Rust backend - Set defaultValue to true for FSRS toggle in deck options UI

JSchoreels · 2025-10-14T18:59:29Z

Should we include some kind of banner the first time that option will be by default used ? Just in case some people where on SM2 by default but who'd still want to switch back to SM2 if they really want it

Update deckconfig::update::test::updating to use actual config values from get_deck_configs_for_update() instead of hardcoded values. This ensures the test works correctly now that FSRS is enabled by default.

jakeprobst · 2025-10-14T19:03:55Z

its worth noting that with this change you will be enabling fsrs for everyone that has not explicitly turned fsrs on then back off.

anki/rslib/src/deckconfig/update.rs

Lines 212 to 214 in 04a0b10

    
           if fsrs_toggled { 
        
               self.set_config_bool_inner(BoolKey::Fsrs, req.fsrs)?; 
        
           }

There is logic that keeps the variable unsaved in the configuration unless it has changed. And since its unsaved the default-to-true gets triggered even if it is a preexisting deck.
I can see an argument that this might be a desireable interaction but I think this case should be known and discussed.

(I played around with this a few weeks back as I was gonna make this exact PR next april fools day. I thought things would move slowly enough that it would still be a relevant PR to make then)

- Add FSRS boolean config key to protobuf definition - Update generated Rust config mapping code - Disable FSRS in test_schedv3.py tests to maintain legacy scheduler behavior - These tests are designed for the old SM-2 algorithm, not FSRS

L-M-Sherlock · 2025-10-14T19:18:00Z

Should we include some kind of banner the first time that option will be by default used ? Just in case some people where on SM2 by default but who'd still want to switch back to SM2 if they really want it

I'm not good at UI/UX, so PR is welcome.

I can see an argument that this might be a desireable interaction but I think this case should be known and discussed.

Sure.

This test validates legacy SM-2 scheduler behavior and expects specific card states without FSRS memory states. Disable FSRS to maintain test compatibility.

Disable FSRS in review_queue_building and undo tests as they expect legacy SM-2 scheduler behavior for queue ordering and interval calculations.

Add Config import and disable FSRS in getEmptyCol() helper function. This ensures all tests using this helper function have FSRS disabled by default, maintaining compatibility with legacy scheduler tests.

ghost · 2025-10-14T19:32:24Z

FSRS has clear advantages over SM-2, and because of the "Default Effect" most people won't be likely to change the default unless something has gone wrong.

iamllama · 2025-10-14T21:30:48Z

We could perhaps enable it for new collections only by adding a default here:

anki/rslib/src/config/schema11.rs

Lines 27 to 28 in 362d09e

    
               "sched2021": true, 
        
           });

L-M-Sherlock · 2025-10-15T01:09:26Z

We could perhaps enable it for new collections only by adding a default here:

I have tested the PR's code. It has enabled FSRS by default for new collections.

Edit: oh, I know what happened. For a new collection, the config doesn't have the fsrs field. The PR will return true for fsrs by default in this case.

user1823 · 2025-10-15T09:44:46Z

This seems to be a good opportunity to make some changes similar to #3860 so that we don't need to read the config on every card answer.

anki/rslib/src/scheduler/answering/mod.rs

Line 449 in 321e23a

let fsrs_enabled = self.get_config_bool(BoolKey::Fsrs);

Please feel free to ask me to create a separate issue for this.

L-M-Sherlock · 2025-10-15T15:28:26Z

Please feel free to ask me to create a separate issue for this.

Sure, please do that, thank you!

tatsumoto-ren · 2025-10-16T20:28:12Z

@L-M-Sherlock if you want more users to test FSRS, consider shipping Anki with no default scheduler. When a new collection (new Anki profile) is created, force the user to choose one or the other.

Also, a look through the Anki Forums shows many users confused or having problems with FSRS, which indicates it isn't ready yet.

L-M-Sherlock · 2025-10-17T01:41:35Z

if you want more users to test FSRS, consider shipping Anki with no default scheduler. When a new collection (new Anki profile) is created, force the user to choose one or the other.

To be honest, @maimemo has been doing something similar. We shipped different schedulers all the time for A/B tests.

Also, a look through the Anki Forums shows many users confused or having problems with FSRS, which indicates it isn't ready yet.

If there are a lot of users confused or having problems, FSRS will get fixed soon. Just like SM-2 as the default, the community has invented tons of methods to fix it.

tatsumoto-ren · 2025-10-18T20:42:26Z

A less intrusive option is to have a popup on a new collection asking the user which scheduler they want to choose.

501581178-dba09644-7f23-4e2a-84e3-6b002fe35fad

Example how to make a message like this: https://github.com/ankitects/anki/blob/f94d05bcbe17c8d1eacad3178c77f58c9fb3c3bd/qt/aqt/deckbrowser.py#L407C1-L429C4

GithubAnon0000 · 2025-10-18T20:52:39Z

A less intrusive option is to have a popup on a new collection asking the user which scheduler they want to chose.

In that case the message would need to be neutral, without bias. Your message is biased. And inaccurate for that matter. You do not have to optimize FSRS at all, as I already covered in the linked issue. It will improve retention though, if you do. Which is a huge plus compared to a non-dynamic, never adjusting algorithm like SM-2.

Also: The common user has no idea which algorithm is better for them; and probably will not read even a short explaination section. So I reccon it's better to just have a default (which might be FSRS if there are no real disadvatages and if its superior results reported by users are convincing dae) and allow users to change it in the preset options

tatsumoto-ren · 2025-10-18T20:57:09Z

In that case the message would need to be neutral, without bias

Yeah, I think it can be adjusted. The important part is to warn users that FSRS is experimental and that there's no solid data on how it affects retention given the same number of daily reviews. Some users report higher retention, others lower. Including a link to an article that explains the differences would also be helpful.

nezmaka · 2025-11-14T21:13:13Z

Yeah, I think it can be adjusted. The important part is to warn users that FSRS is experimental and that there's no solid data on how it affects retention given the same number of daily reviews. Some users report higher retention, others lower. Including a link to an article that explains the differences would also be helpful.

Iirc, FSRS is based on an algorithm that has had several papers published about it, showing improved retention. Users' so called anecdotal reports about their own retentions are not exactly reliable.

For what it's worth, I find that even without the rather misleading note, the mere calling of the one ‘Anki Scheduler’ and the other ‘FSRS’ biases towards the former. Had I not known anything and just installed Anki for the first time, without the time to look into the different schedulers, I'd have chosen Anki Scheduler while I wish I'd have chosen FSRS.

Enable FSRS by default

ef21890

Make FSRS (Free Spaced Repetition Scheduler) enabled by default for new users and users who haven't explicitly configured it. Changes: - Add BoolKey::Fsrs to default-true boolean keys in Rust backend - Set defaultValue to true for FSRS toggle in deck options UI

Fix test for FSRS default enabled

da9dd4b

Update deckconfig::update::test::updating to use actual config values from get_deck_configs_for_update() instead of hardcoded values. This ensures the test works correctly now that FSRS is enabled by default.

L-M-Sherlock added 3 commits October 15, 2025 03:19

Disable FSRS in state_application test

a137d98

This test validates legacy SM-2 scheduler behavior and expects specific card states without FSRS memory states. Disable FSRS to maintain test compatibility.

Disable FSRS in scheduler queue tests

9d2ab84

Disable FSRS in review_queue_building and undo tests as they expect legacy SM-2 scheduler behavior for queue ordering and interval calculations.

Disable FSRS by default in test helper function

9c8f0ff

Add Config import and disable FSRS in getEmptyCol() helper function. This ensures all tests using this helper function have FSRS disabled by default, maintaining compatibility with legacy scheduler tests.

Update schema11.rs

1ac8769

user1823 mentioned this pull request Oct 16, 2025

Reviewer shouldn't need to read FSRS config on every card answer #4394

Open

tatsumoto-ren mentioned this pull request Oct 16, 2025

Make FSRS the default? #3616

Open

Enable FSRS by default #4391

Are you sure you want to change the base?

Enable FSRS by default #4391

Uh oh!

Conversation

L-M-Sherlock commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JSchoreels commented Oct 14, 2025

Uh oh!

jakeprobst commented Oct 14, 2025

Uh oh!

L-M-Sherlock commented Oct 14, 2025

Uh oh!

ghost commented Oct 14, 2025 • edited by ghost Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iamllama commented Oct 14, 2025

Uh oh!

L-M-Sherlock commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

user1823 commented Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

L-M-Sherlock commented Oct 15, 2025

Uh oh!

tatsumoto-ren commented Oct 16, 2025

Uh oh!

L-M-Sherlock commented Oct 17, 2025

Uh oh!

tatsumoto-ren commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GithubAnon0000 commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tatsumoto-ren commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nezmaka commented Nov 14, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

L-M-Sherlock commented Oct 14, 2025 •

edited

Loading

ghost commented Oct 14, 2025 •

edited by ghost

Loading

L-M-Sherlock commented Oct 15, 2025 •

edited

Loading

user1823 commented Oct 15, 2025 •

edited

Loading

tatsumoto-ren commented Oct 18, 2025 •

edited

Loading

GithubAnon0000 commented Oct 18, 2025 •

edited

Loading

tatsumoto-ren commented Oct 18, 2025 •

edited

Loading