Turning what you read into Anki cards without the typing

Here's a workflow that fails quietly, every day, for a lot of people:

1. You read something good — a paper, a lecture PDF, a long article, a YouTube lecture.
2. You think "this belongs in Anki."
3. You open Anki, create a deck, and start typing cards by hand.
4. You make six cards, it's been twenty minutes, and you close the window.

The material never makes it in. Not because spaced repetition doesn't work — it obviously does — but because the input step is manual while the review step is automated. Anki's scheduler is a piece of software. Your card creation is you, typing.

The bottleneck is card creation, not review

Most "I fell off Anki" stories I've heard are really "I stopped making cards" stories. Reviewing thirty cards takes a few minutes and has an algorithm pushing you along. Writing thirty cards takes an hour of undifferentiated typing, and nothing pushes you along at all.

That asymmetry is worth naming, because it tells you where a tool can actually help. Nobody needs help being nagged to review. What's missing is a low-friction path from "the thing I just read" to "a card in my deck."

Three ways to close the gap — and what each one costs

If you look at how people have tried to solve this, there are basically three shapes.

CSV / export pipelines. Generate cards somewhere, export to a file, import into Anki. This works, and it's the most common DIY approach. The costs show up later: field mapping breaks when your template changes, the import dialog steals focus, and there's no deduplication — run it twice on the same article and you get two copies of every card. In a deck you'll keep for years, duplicate cards are worse than missing cards, because they double your review load silently.

Anki add-ons. Running inside Anki is convenient if that's where you already are. But by definition an add-on starts after the text exists somewhere — it can't see the PDF you have open in a browser tab, and it can't see the article you're reading. It also only runs on desktop Anki, and it breaks on Anki version bumps.

A browser extension. This is the shape I ended up building. The argument for it: the content arrives in the browser first — pages, PDFs, YouTube transcripts. If you intercept it there, you're working at the actual point of friction, and you don't need the user to leave what they're doing to go make cards.

Writing through AnkiConnect instead of exporting files

The technical decision that mattered most was to write cards into the collection through AnkiConnect rather than generating an import file.

AnkiConnect is a local HTTP server exposed by an Anki add-on (code 2055492159, free). Because it can query the collection, you can do two things a file export fundamentally cannot:

// ask the collection what already exists before writing
{ action: "findNotes", version: 6, params: { query: 'deck:"Reading" "{{text}}"' } }

// then write only the notes that aren't there yet
{ action: "addNotes", version: 6, params: { notes: [...] } }

The first call is the interesting one. A dedupe check against the live collection turns "generate 40 cards" into "generate 40 cards, 12 of which you already have" — and the second group never gets written. It also means cards land with the right note type and tags, in the deck you chose, with no import dialog and no field remapping.

The honest cost of this approach: it requires desktop Anki running locally. That's a real constraint — no AnkiWeb-only setup, no mobile. I took the trade because a card that lands in the wrong deck with the wrong template isn't really a card.

On-device inference, or your own key

The second decision was where inference runs. The default is Chrome's built-in on-device model, which means the selected text never leaves the machine — no upload, no account, no telemetry. If you want a stronger model, you paste your own API key (OpenAI / Anthropic / Google) and the request goes browser → provider directly.

Two things fall out of that architecture, and I'd rather state them plainly than let them be discovered later:

• Because inference runs on the user's machine or the user's key, there's no per-generation cost sitting on a server of mine. That's why a one-time price is possible instead of a subscription — not a marketing stance.
• The only outbound request the extension makes is license activation. Nothing in the pipeline requires a server I operate.

What generation gets wrong (and why "prune" is the real feature)

LLMs will happily produce forty mediocre cards from a page of prose. Forty mediocre cards are worse than twelve good ones: they're more review load, lower retention per minute, and they train you to skim.

So the workflow the tool is built around is generate → prune → write, not generate-and-accept. Cards come back in a side panel where you edit or delete them before any of them touch the collection. The list-splitting template exists for the same reason: an enumeration in the source ("five causes of X") is a place where one card per item beats one card asking for all five.

If there's one habit I'd recommend regardless of tooling: cap what you write per reading session. Twenty cards from an article you understood beats eighty from an article you skimmed.

Full disclosure, and a question

I'm the developer of AnkiMate — a Chrome/Edge extension that does the above. Pricing, stated plainly: free tier is 3 generations a day and writing cards into Anki is always free and unlimited; Pro is $19.9 one-time (Cloze, batch generation, future templates), no subscription. It's a paid product and I'm not going to pretend otherwise.

I'm not claiming it's better than what you use — I don't have the user base to make that claim honestly. What I'd genuinely like to know is where your own pipeline breaks:

Is the friction in capturing the source, in generating the cards, or in the pruning/editing step afterwards?

My assumption while building was that pruning is the part people underrate. If you're a heavy Cloze user and that assumption is wrong, I'd rather find out now.