I want to see all blue cards before red and green

I’m using Anki for 5 years now and still using multiple filtered decks to fullfill this.

I just want to see all my new (blue) cards before starting the red and greens. I imagine this could be a simple configuration that could be native for all PC and Android app yet it was never made.

My process today is to filter all my subdecks with “is:new” in a separated Deck and use a “rebuild all filtered decks” addon after each study section.

The logic behind it is that I’m making my own medic cards for themes I already studied. I’m not learning from 0, and I want to review all the cards at once. The blue cards “never” enter the schedule once I didn’t surpass the first red cards wave, wich isolates them from the rest. So using the filtered decks I make a “first pass” in all cards before starting review direct from the main deck, wich looks like an extra, annoying, step, especially when I’m using ankidroid, where I don’t have the addons to speed up the process.

___

I asked some IA agents to audit the code of a github’s anki copy trying to identify the root of this. I’m not dev so it was the only way I found to help. I’m sorry if the report contain any slop. (I would attach this as a file, but the forum don’t let me)


Anki

Summary

The “New/review order → Show before reviews” deck option exists and the scheduler code is correct, but in practice due reviews are consumed before new cards. Investigation of the source (tag 25.09.2, commit 3890e12) reveals the root cause is config resolution (silent fallback to MixWithReviews) compounded by a dead global preference. This post documents the issue and proposes a concrete code-level fix for the devs.

What I want

Order: all new (blue) → then reviews (red) mixed with interday learning (green), or red then green. Never green before red.

Correct config (that should produce this order)

Deck options → Display Order:

  • New/review orderShow before reviews (blue first)
  • Interday learning/review orderMix with reviews (green mixed with red) or Show after reviews (red then green)

Other settings: new/day 9999, reviews/day 9999, “New cards ignore review limit” ON, FSRS active, “Review sort order: Descending retrievability”, “New card gather order: Random cards”, “New card sort order: Order gathered”.

Isolated leaf deck: 214 blue / 18 red / 21 green.

Symptom

With new_mix = BeforeReviews, the red counter (18) decreases first — due reviews are consumed before new cards. Blue cards do not appear first.

What the source says (tag 25.09.2 ≡ main 77d61d7 — logic IDENTICAL and CORRECT)

  • rslib/src/scheduler/queue/builder/mod.rs:266-278merge_new() with ReviewMix::BeforeReviewsSizedChain::new(new_iter, review_iter) (all new before all reviews). Correct.
  • builder/mod.rs:251-264merge_day_learning(): Mix with reviewsIntersperser; After reviewsSizedChain(reviews, day_learning).
  • builder/mod.rs:207main_iter = merge_new(with_interday_learn, new, new_review_mix).
  • builder/mod.rs:232-249sort_options() reads config.inner.new_mix() from deck.config_id().
  • rslib/src/scheduler/queue/mod.rs:156-161CardQueues::iter() = intraday_now → main → intraday_ahead.
  • UI: ts/routes/deck-options/DisplayOrder.svelte:158-173 binds $config.newMix; choices.ts:121-136 maps “Show before reviews” → BEFORE_REVIEWS.

So the config should produce blue → (red+green). My stable build (25.09.4) does not reproduce this.

Root cause (3 code-level gaps)

Gap 1 — Silent fallback to MixWithReviews

sort_options() (builder/mod.rs:232-249): when deck.config_id() is None (filtered/custom-study deck) OR the config_id is missing from config_map, it silently returns QueueSortOptions::default()new_review_mix = MixWithReviews. No warning, no parent inheritance, no global fallback. Custom-study/filtered sessions silently ignore the per-deck “New/review order” setting.

Gap 2 — Dead global preference

proto/anki/config.proto:100-109 defines Preferences.Scheduling.new_review_mix (enum NewReviewMix { DISTRIBUTE=0; REVIEWS_FIRST=1; NEW_FIRST=2 }). rslib/src/config/mod.rs:243 has get_new_review_mix() / set_new_review_mix(). But get_new_review_mix() is ONLY called from rslib/src/preferences.rs (round-trip) — never by the scheduler. The v3 builder reads per-deck config.inner.new_mix() instead. The comment in the source says: /// 2021 scheduler moves this into deck config. So the global preference is dead code — users who set it (or migrated collections) get zero effect. There is also no UI binding for it in the Preferences screen.

Gap 3 — No order-assertion test

The existing test new_card_potentially_burying_review_card uses BeforeReviews but never asserts the queue order (new before review).

Proposed fix (code-level, for devs)

Fix A — Robust config resolution + global fallback

File: rslib/src/scheduler/queue/builder/mod.rs, sort_options() (lines 232-249).

Current:

fn sort_options(deck: &Deck, config_map: &HashMap<DeckConfigId, DeckConfig>) -> QueueSortOptions {
    deck.config_id()
        .and_then(|config_id| config_map.get(&config_id))
        .map(|config| QueueSortOptions {
            new_order: config.inner.new_card_sort_order(),
            new_review_mix: config.inner.new_mix(),
            // ...
        })
        .unwrap_or_else(|| QueueSortOptions {
            new_order: NewCardSortOrder::NoSort,
            ..Default::default()
        })
}

Proposed: add global_mix: NewReviewMix parameter; in the fallback branch, use the global preference instead of silently defaulting to MixWithReviews:

fn sort_options(
    deck: &Deck,
    config_map: &HashMap<DeckConfigId, DeckConfig>,
    global_mix: NewReviewMix,
) -> QueueSortOptions {
    deck.config_id()
        .and_then(|config_id| config_map.get(&config_id))
        .map(|config| QueueSortOptions {
            new_order: config.inner.new_card_sort_order(),
            new_review_mix: config.inner.new_mix(),
            // ...
        })
        .unwrap_or_else(|| {
            tracing::debug!(
                deck_id = ?deck.id,
                "deck has no resolvable config; falling back to global new/review mix"
            );
            QueueSortOptions {
                new_order: NewCardSortOrder::NoSort,
                new_review_mix: match global_mix {
                    NewReviewMix::Mix => ReviewMix::MixWithReviews,
                    NewReviewMix::ReviewsFirst => ReviewMix::AfterReviews,
                    NewReviewMix::NewFirst => ReviewMix::BeforeReviews,
                },
                ..Default::default()
            }
        })
}

Call site in QueueBuilder::new (line ~149): thread the global preference:

let sort_options = sort_options(&root_deck, &config_map, col.get_new_review_mix());

Fix 2 — Wire the global preference into the scheduler

File: rslib/src/scheduler/queue/builder/mod.rs, QueueBuilder::new (lines 130-187).

Add global_new_mix to the Context struct and thread it into sort_options(). This makes the legacy Preferences.Scheduling.new_review_mix a real global default for decks without a resolvable preset (or as an override — design decision for the devs: fallback-only vs. global override).

Optionally expose it in the TS Preferences UI (bind newReviewMix) so users can set “new before reviews” once for all decks.

Fix 3 — Add order-assertion test

File: rslib/src/scheduler/queue/builder/mod.rs (test module).

#[test]
fn new_before_reviews_order() {
    let mut col = Collection::new();
    // Add 1 new card + 1 due review card
    CardAdder::new().siblings(2).due_dates(["0"]).add(&mut col);
    col.update_default_deck_config(|c| c.new_mix = ReviewMix::BeforeReviews as i32);
    let q = col.build_queues(DeckId(1)).unwrap();
    let kinds: Vec<_> = q.iter().map(|e| e.kind()).collect();
    assert_eq!(kinds, vec![QueueEntryKind::New, QueueEntryKind::Review]);
}
#[test]
fn fallback_uses_global_new_review_mix() {
    let mut col = Collection::new();
    col.set_new_review_mix(NewReviewMix::NewFirst);
    // Deck with config_id pointing to a missing config
    let q = col.build_queues(DeckId(1)).unwrap();
    let sort = q.sort_options();
    assert_eq!(sort.new_review_mix, ReviewMix::BeforeReviews);
}

Notes

  • Deck options Display Order applies to the selected deck only, not subdecks (see deck-config-display-order-will-use-current-deck).
  • Review sort order (due-date, intervals, ease, retrievability…) is a separate, orthogonal setting.
  • Intraday learning (in-progress green cards) always precedes the main queue (queue/mod.rs:156-161) — this is by design and not controllable via any setting (except burying).

Environment

  • Anki 25.09.4 (d52ca669), Python 3.13.5, Qt 6.9.1, Chromium 122
  • FSRS active, desired retention 82%
  • Preset “UNLP_Estudando” shared by 690 decks

I don’t think anyone is interested in proofreading what your AI/LLM came up with for this, but we can answer some of your general questions.

What you’re describing sounds like it’s working as intended (even if that’s not how you want it to work) – so “a concrete code-level fix for the devs” isn’t needed. There are also good reasons why it works that way (even if that’s not how you want it to work) – so it’s unlikely the scheduler will be changed. [I’m moving this from the Anki > Suggestions category to Anki > Help for that reason.]

The important thing to understand is that Learn/Relearn “red” and Review “green” cards aren’t in the same category for all of this – and there are multiple categories even among Learn/Relearn cards. Separating those out –

It doesn’t look like your AI/LLM understands all of the issues, but this one it got right. This is the setting to make that happen.

  • Deck options → Display Order: New/review order → Show before reviews

If that’s not working in your collection, I suspect there is an identifiable reason for that – but it will be specific to your collection and how you have things set up. No code change will be necessary.

This will give you a “first pass” on your Learn cards before you start your due Review cards, just like you want. Depending on your learning steps and how you grade each card, after that first pass, each card will stay in Learn and come back at the end of its step delay, or graduate to Review and come back another day.

Whether you can do this in a regular deck or not depends on where those Learn/Relearn [red] cards came from. If they are –

  1. Long-step Learn/Relearn cards that crossed the day boundary to be due today? Those are “Interday learning” cards and they will be grouped with the Review “green” cards and follow the setting above. There’s a separate setting to control where they are relative to the Review cards [mix/before/after].

  2. Short-step Learn/Relearn cards that you studied earlier today, each coming due as it reaches the end of its step delay? Those are the highest priority (over Review and New cards), so Anki will try to show them to you as close to the end of the step that you set as possible. If you want them to come due at another time, you can set a different learning/relearning step.

  3. “Leftover” short-step Learn/Relearn cards that you should have graduated to Review on a prior day? Those cards have already reached the end of the step that you set and are now overdue, so they will be shown before anything else.

    • If you have a big accumulation of short-step Learn/Relearn cards that have reached the end of their steps and are waiting to be studied, they will get in the way of studying everything else, including each other (because they are in a queue based on when they reached the end of their steps).

    • That is by design. Your memory on them is the most fragile, so they are the most urgent to study. There’s no point in introducing more New cards because they will immediately become Learn cards, caught in that same accumulation you can’t get through.

    • If this is the situation you find yourself stuck in, the solution isn’t to change Anki, the solution is to study those cards and get them out of your way.

It sounds like the underlying problem is you have too many Filtered decks to reasonably manage, and/or you’re trying to use them as a substitute for things your regular decks are better suited to do.

Thanks for the answer. As I said, I kind of already avoided this problem by using filtered cards.

I still think to see new cards before everything should be an option for the reason I already wrote. As you said I’m probably falling on the accumulation of short-step Learn/Relearn cards wich “blocks” the new cards to appear. For a instant I though it could be a code “problem” that maybe nobody noticed or something, thats why I tried to help somehow with the LLM (Not doing again).

I’m sure the devs have a long line of bigger improvements to take care, so thanks anyway.