I have a folder on my Mac called notes. About 4,000 .md files. My editor reads it. My terminal reads it. Cursor reads it. Claude Code reads it. ChatGPT reads it when I drop the folder in. Obsidian reads it. Every tool I work with in 2026 reads it because the files are plaintext markdown.
One thing in my workflow doesn't read it: my flashcard app.
That's the problem. And the reason Atomus stores every flashcard as markdown.
Markdown flashcards are spaced repetition cards stored as plaintext .md files instead of a binary database. Unlike Anki's SQLite collection, they're version-controllable, AI-readable, and portable across any text editor or LLM. If you've ever wanted an Anki alternative that fits the way you actually work in 2026, this post is the argument.
The state of memory in 2026
Personal computing changed twice in the last three years.
First, agents got real. Claude, ChatGPT, and Cursor stopped being chat windows and became coworkers that read your files, run your commands, and remember context across sessions. Anthropic shipped persistent memory in Claude. OpenAI's agents started referencing your local context as a first-class input.
Second, the format people use to think with collapsed onto one thing: markdown.
Cursor's rules are markdown. Claude Code's project memory is CLAUDE.md. Every agent skill in Anthropic's open Skills standard is a markdown file. Obsidian crossed several million users without ever shipping a binary format. Notion is fighting to export to markdown because that's what users demand.
If your knowledge lives anywhere else, it lives outside the system that runs your work.
Now look at where flashcards live.
Why Anki's binary format is a dead end
Anki is the most respected spaced repetition tool of the last 20 years. It's also the most user-hostile, and the format is the reason.
An Anki collection is a SQLite database. Open it and you find a table called notes, a table called cards, and a blob of HTML inside each note. The HTML carries inline styles, MathJax, custom card templates, and binary-encoded media references. Cards reference notes through joins. Decks reference cards through other joins. Reviews live in another table entirely.
To do anything with your own flashcards outside Anki, you have to:
- Find the SQLite file (a
.anki2blob inside an.apkgzip). - Decode the schema, which Anki has not documented in any meaningful way for years.
- Strip the HTML and inline CSS to get back to your actual content.
- Hope you don't corrupt the review history.
I've done this. Most people who try stop at step two.
The result: your knowledge is locked. You can't grep it. You can't version control it. Your editor can't open it. Your agent can't read it. If Anki disappears tomorrow, your years of cards are 90% unrecoverable for any practical purpose.
This was a defensible trade-off in 2007. Not in 2026, when every other piece of intellectual work you do is plaintext.
Anki vs markdown flashcards
| Anki (binary) | Markdown flashcards | |
|---|---|---|
| Storage | SQLite + HTML blobs | Plaintext .md files |
| Portability | Locked to app | Any editor, any OS |
| Version control | Effectively none | Native git |
| Agent readable | No | Yes |
| Search | App-only | grep, ripgrep, Spotlight |
| Lock-in | High | Zero |
Markdown is the AI-native format
Something quiet is happening in 2026 that almost nobody is naming directly: large language models think in markdown.
Not because markdown is fancy. Because markdown is the simplest possible structured text. A heading is #. A list is -. Emphasis is **. Nothing to misparse. An LLM trained on the entire internet has seen markdown in every README, every issue, every documentation site. When you ask Claude or GPT-5 to write structured output without specifying a format, you get markdown by default. That isn't a coincidence. It's the model's mother tongue.
The practical consequences:
- You can paste a markdown file into any LLM and the model understands the structure with no instructions.
- You can ask an agent to add a heading, reorder a list, or generate new entries that match an existing pattern, and it returns correct markdown.
- You can build pipelines where your editor, your agent, and your knowledge base all read and write the same files, with no schema translation step.
This is why every tool in the AI-native stack (Cursor, Claude Code, Codex, Linear's recent agent integration) uses markdown for instructions, memory, and config.
If your flashcards aren't in this format, they're outside the loop.
Your flashcards should be readable by your agents
The actual argument. Not "markdown is nicer" (that's aesthetic). The substantive claim:
In 2026, the things you want to remember are also things your agents need to know about you.
Concrete cases I run into every week:
- I'm studying German because I work with a Berlin team. I have an agent that drafts Slack messages for me. It should know which words I'm still learning so it uses them at my level, not above it.
- I'm reading a paper on retrieval-augmented memory. I capture the three claims I need to remember. Next time I ask Claude to summarize a related paper, it should reference what I already understand.
- I onboarded onto a new codebase and made flashcards for the strange parts. When my agent writes a PR description, it should reference the conventions I've committed to memory.
None of this is possible if your flashcards are HTML blobs in a SQLite file. All of it is trivial if your flashcards are markdown files in a folder the agent can read.
The pattern is older than agents. It's the local-first software thesis from Ink & Switch, applied to memory. Andy Matuschak has been writing for years about the gap between how we read and what we actually remember; markdown flashcards close that gap by making your memory a thing your tools can reach. You own the data. The data is in an open format. Tools come and go; your knowledge stays. What's new in 2026 is that "tools" now includes the agent that books your meetings and writes your drafts.
If you're evaluating a memory app and the format isn't something you can grep, walk away. Atomus stores every atom as a single line of markdown in a folder you choose. Your editor sees it. Your agent sees it. You see it. No app to open to read your own memory.
What a markdown flashcard file looks like
Here's a real Atomus file. Not a screenshot of a card UI. The file:
# German A2
Guten Morgen == Good morning
Was bedeutet "Feierabend"? == End of the workday
Es ist {{kalt|warm|heiß}} in Berlin im Januar.
Which conjugation matches "ich"? ==
(x) gehe
( ) gehst
( ) geht
( ) gehen
- [ ] Modal verbs review @2026-05-15
ich {{muss}} arbeiten == I must work
Was bedeutet "können"? == to be able to
Four atom types in one file:
- Single-line QA —
front == back - Cloze with distractors —
{{answer|wrong|wrong}} - Multiple choice — question +
==, then(x)/( )options indented - Deadline —
- [ ] Title @YYYY-MM-DDwrapping atoms below it
The file is checked into git. It opens in any editor. Cursor can edit it. Claude Code can add new cards based on a paper I'm reading. Atomus reads it, schedules reviews using FSRS, and slides them down from the notch when they're due. Nothing locked in anywhere.
If I switch tools in three years, my entire memory still works as a folder of markdown.
Local files plus markdown equals data sovereignty
This used to be a niche concern. In 2026 it isn't.
Every cloud-first knowledge tool now has a section in its terms about training. Some say "we don't train on your data" (and have changed that policy in the past 18 months). Some say "we anonymize and aggregate" (not the same as not having it). Some say nothing, which means yes.
I'm not paranoid about my German vocabulary leaking. I'm annoyed the question even exists. The cleanest way to remove the question is to keep the data on your disk, in a format you can read, with no network round-trip.
Markdown plus local files makes this trivial. No server to trust. No export feature to depend on. No "data ownership" page to read. The data is a file on your machine. You own it the same way you own a .txt you wrote in 1998.
The only reason this isn't the default everywhere is inertia. Every flashcard app shipped in the last decade copied Anki's database model because that's what existed. Newer tools like Mochi started doing the right thing. Atomus is built on it from the first commit.
What changes when memory is markdown
A few things become possible that aren't possible with binary formats:
- Version control. I commit my notes folder. I can see when I learned a thing. I can revert when I make a mistake.
- AI generation. I drop a paper into Claude and ask it to extract the five facts I should remember in Atomus's syntax. It returns markdown I can paste into a file.
- Search. Spotlight, ripgrep, and any editor's find-in-files all work. No separate "card search" feature.
- Pipelines. I can hook a script up to my reading app that turns highlights into atoms automatically.
- Portability. If I want to move to another tool, I rename the folder.
None of this is exotic. It's the default for code, for notes, for documentation, for agent instructions. The only reason it hasn't been the default for memory is that nobody bothered.
Key points
- Markdown flashcards are spaced repetition cards stored as plaintext
.mdfiles instead of a binary database. - They are an Anki alternative built for the AI agent era. Every card is readable by Cursor, Claude, ChatGPT, and any tool that opens text.
- They solve data lock-in, enable git versioning, and let AI agents reason about what you're learning.
- Atomus is a macOS implementation of this approach with FSRS scheduling and notch-based reviews.
FAQ
What are markdown flashcards?
Markdown flashcards are spaced repetition cards stored as plaintext .md files instead of a binary database. They are version-controllable, AI-readable, and portable across any text editor or LLM.
Is markdown enough for complex flashcards like images and audio?
Yes. Markdown supports image links () and audio links the same way. The file references local media; it doesn't embed it. Better for git, better for sync.
Does plaintext mean I lose features like card templates and styling? You lose nothing useful. Card templates were a workaround for the binary model. With markdown, the structure is the content. Atomus renders headings as section labels, lists as multi-card sets, and inline syntax as the right kind of review. No template authoring step.
Can I migrate from Anki?
Atomus has an importer that takes an .apkg and writes one markdown file per deck. The review history comes along. What you end up with is a folder you can read.
Is local-first the same as offline-only? No. Local-first means the local copy is the source of truth. You can still sync, share, and back up. The network is optional, not mandatory.
What if I want my agent to add cards automatically? That's the point of the format. An agent can append a line to a markdown file the same way you would. Atomus picks up the change on the next read. No API call, no auth flow, no schema migration.
How to start with markdown flashcards
If you're using Anki and you're also using Cursor, Claude, or Obsidian, your flashcards are the only thing in your workflow your agents can't see. Worth fixing.
The smallest version: put your flashcards in a .md file. Use any syntax. Treat them like notes. You'll be surprised how much of the friction was the format, not the practice.
The full version: try Atomus. It reads your markdown, schedules with FSRS, lives in your notch, and never sends a byte off your Mac. The folder is yours. The file format is yours. Reviews show up while you work. That's what a memory app should be in 2026.
