Forem: Fisher Shen (Fisher)

Cal Newport's Reading System for Your Read-Later Pile

Fisher Shen (Fisher) — Fri, 24 Apr 2026 04:40:30 +0000

This post originally appeared on burn451.cloud. Republished here for syndication.

I have been reading Cal Newport for eight years and he still does not have an X account. That is not a bio detail. It is the argument. The man who wrote Deep Work (2016), Digital Minimalism (2019), A World Without Email (2021), and Slow Productivity (2024) refuses to participate in the platform that most of his readers cannot stop checking. He writes a blog. He records Deep Questions. He shows up on Tim Ferriss occasionally. That is the whole footprint.

I built Burn 451 because my read-later pile had stopped being a reading list and become a guilt list. Yesterday I shipped a curated Cal Newport vault — 26 essays, talks, and podcasts. This post is the system I extracted from his work, built into a tool, and now use every day.

What is Cal Newport's reading system?

Cal Newport does not have a single named "reading system," but across his books and essays he describes the same shape: a small number of carefully chosen long-form sources, read with a notebook open, with an explicit decision at the end about what stays. The opposite of grazing. The opposite of saving for later and never reading.

His method shows up in three places. Deep Work gives you the time block — protected, single-task, no inputs. Digital Minimalism gives you the source filter — you do not consume what does not pass a personal value test. Slow Productivity gives you the pace — fewer items, longer engagement, no manufactured urgency. Read-later apps usually fail all three. They optimize for capture. Cal optimizes for completion. The asymmetry is the whole game — capture is one click, completion is forty minutes of focused attention, and any system that makes the cheap action easier than the valuable one will accumulate debt forever.

How does Slow Productivity apply to read-later apps?

Slow Productivity has three principles: do fewer things, work at a natural pace, obsess over quality. Applied to reading, that means saving fewer articles, finishing them at a human pace, and treating what you read as something you will think about — not check off. The read-later app is the wrong shape for this by default. It is a list. Lists encourage adding.

Cal explained this on Tim Ferriss episode #722 in early 2024. The interview is the cleanest version of the Slow Productivity thesis if you want it spoken. The phrase that stuck with me was that productivity culture had collapsed into "pseudo-productivity" — visible activity standing in for real output. My old read-later list was pseudo-reading. Saving felt like reading. It was not. I had 1,400 articles in Pocket when it shut down. I had read maybe 80 of them. The other 1,320 were a museum of intentions.

What is the difference between additive and extractive reading?

Cal's 2025 essay On Additive and Extractive Technologies draws a line: additive technologies give you back more than you put in. Extractive technologies take more than they give. A read-later app that grows your unread pile faster than you finish it is extractive. A reading system that forces you to decide — finish, vault, delete — is additive.

Most save-for-later tools are extractive by design. They reward the save. They never punish the un-read. The pile grows, the guilt grows, you eventually mass-delete or migrate to a new app and start the cycle again. Burn flips the polarity. Articles auto-delete after 24 hours unless you finish them or vault them. The forcing function is the point. You stop saving things you will not read because the system will not let you pretend. The first week using a 24-hour timer feels punishing — you watch articles disappear that you "would have" read. By week three the pile is half the size and your read-rate has tripled. The constraint manufactures the discipline you could not summon on your own.

How do I apply Cal's "Notebook over Chatbot" rule to bookmarks?

Cal's Forget Chatbots. You Need a Notebook. (2025) argues that the deepest cognitive work happens when you write things down by hand, in your own structure, with your own tags. Chatbots invite passive consumption — you ask, it answers, you forget. Notebooks invite active engagement. Read-later apps default to chatbot mode. They should default to notebook mode.

A notebook-shaped read-later app makes you do something with what you saved. It asks: what is in this article that you want to remember? What concept does it connect to? Burn's vault is the notebook layer — when you save an article into a vault, you are deciding it belongs next to other things, you are giving it a category, you are committing to revisit it. The 26-tool MCP server lets me query my own vault from any AI client and pull a quote into whatever I am writing. That is a notebook, not a feed.

What's a 5-step Cal Newport-inspired reading system?

A practical version: (1) 24-hour triage on every save, (2) vault-or-burn at the end of that window, (3) weekly review of what is in the vault, (4) one slow week per quarter where you only re-read vaulted items, (5) monthly purge of vault items you have not opened in 90 days. Each step maps to one Cal idea.

Step 1 ties to Digital Minimalism — the source filter. If the article cannot earn 24 hours of your attention, it does not deserve the save. Step 2 ties to Slow Productivity — finish or commit, do not let things drift. Step 3 is the Deep Work time block — a recurring protected window. Step 4 is the natural pace — re-reading is reading. Step 5 is the additive principle — the vault should give back more than it takes, so prune the dead weight.

Should I use Burn 451 for this system?

Honest answer: the system matters more than the tool. Burn's 24-hour delete is the forcing function Cal would recommend, and it is what I built it to do. But Wallabag with manual discipline works. Karakeep self-hosted works. Notion plus a calendar reminder works if you actually open the calendar reminder. If you want a tool that enforces the system by default, that is what Burn 451 is for.

What Burn does that the others do not: the deletion is the default, not the exception. Wallabag keeps everything forever unless you act. Karakeep keeps everything forever unless you act. Pocket kept everything forever — and then shut down because nobody was reading. Burn deletes everything unless you act. The asymmetry changes behavior. I went from saving 40 articles a week and reading 4, to saving 12 and reading 9. That is the only metric I care about.

How do I build a Cal Newport-style reading vault?

A vault in Burn is a curated stack of articles around one author or topic, AI-summarized and searchable through the MCP server. To build one Cal-style: pick a thinker whose body of work rewards re-reading, collect 20-30 long-form pieces across years, write a one-paragraph rationale for each, and treat the vault as a living document you prune quarterly.

I built /vault/cal-newport exactly this way. 26 items spanning 2024-2026 — essays from his blog, Deep Questions episodes, the Tim Ferriss interview, his New Yorker pieces. Each one earned its slot. The vault page is the index, but the value is in the act of curation — choosing what stays says more than saving everything. You can browse mine, or build your own around whoever you read seriously. The MCP server makes the vault queryable from Claude, ChatGPT, Cursor — anywhere you write.

The 5 essays from Cal Newport that change how you read

These are the five I would hand to anyone who asks me where to start. I picked them because each one has a portable mental model — you can apply the idea the same day you read it.

On Ultra-Processed Content (2024) — Cal extends Michael Pollan's food framework to media. Ultra-processed content is engineered to be maximally compelling and minimally nutritious. This is the essay that made me build Burn.
Forget Chatbots. You Need a Notebook. (2025) — The cleanest argument I have read for why AI tools that talk back are weaker thinking aids than tools that make you write.
Avoiding Digital Productivity Traps (2026) — A 2026 update to the Slow Productivity thesis with new traps that emerged after AI agents became common.
Why Hasn't AI Made Work Easier? (2026) — Cal applies Jevons paradox to AI: when something gets cheaper, we use more of it, not less. AI made writing emails free, so we write more emails.
The Original Attention Crisis (2026) — Cal traces the modern attention economy back further than smartphones, to the 19th-century telegraph.

Full vault with deep-links to each: /vault/cal-newport

Why Cal Newport doesn't have an X account

Cal's silence on X is the argument his books make in fewer words. Every minute on X is a minute of attention residue dragged into the next task. Every "save for later" is a deferred attention debt — the article you did not read is still costing you, in the small open loop it leaves in your head. Same logic. Different surface.

Cal has explained the no-X stance in interviews going back to 2018. Short version: the cost of a social media presence is not the time spent posting, it is the cognitive cost of caring about the response. He would rather spend that bandwidth writing the next book. I think about this every time I save something to read later. The save is cheap. The open loop is expensive. The system has to close the loop or the loop closes you.

The bottom line

Read fewer things. Finish more of them. Build a vault around the people whose work compounds. The tool is secondary, but if you want one that defaults to deletion, try Burn 451 free.

Burn 451 vs Raindrop.io: AI Digest vs Bookmark Organizer

Fisher Shen (Fisher) — Fri, 24 Apr 2026 02:12:25 +0000

This post originally appeared on burn451.cloud. Republished here for syndication.

Burn 451 and Raindrop.io both let you save links. That's where the similarity ends. Raindrop is a bookmark organizer. Burn is a reading system. Choosing between them isn't about features — it's about what you believe the problem actually is.

I built Burn 451 because my Chrome had 4,700 bookmarks I never opened. I tried Raindrop first. It was beautiful. I organized everything into nested folders. I still never read anything. That's the honest setup for this comparison — one tool made my bookmark library prettier; the other was what I had to build to actually read.

What Is Raindrop.io Best At?

Raindrop.io is the best general-purpose bookmark manager available in 2026. It has the most generous free tier in the category, the cleanest visual design for organizing large libraries, and rock-solid browser extensions across every platform. If you want to save, sort, and find links — Raindrop is hard to beat.

Nested collections. Folders inside folders, with drag-and-drop sorting.
Visual previews. Thumbnails, screenshots, and article excerpts.
Browser extensions everywhere. Chrome, Firefox, Safari, Edge, Opera, Brave.
Free tier. Unlimited bookmarks. Pro is $3/month.
Smart collections (Pro). AI-assisted auto-sorting based on tags and content.
Full-text search (Pro). Searches across saved article contents, not just titles.
Shareable collections. Public links, permissions, collaborative folders.

Raindrop has been around since 2015 and has 15 million users. That stability matters. If you're coming from Pocket after its shutdown in July 2025, Raindrop is the closest like-for-like replacement — you save, you sort, you find things again. The UX is polished. The sync is reliable. The free tier is genuinely useful, not a trial.

What Is Burn 451 Best At?

Burn 451 is designed for people who save too much and read too little. Its 24-hour burn timer forces daily decisions, its AI digest synthesizes your reading queue, and its MCP server connects your reading to AI coding workflows. It's a content digestion system, not an organizer.

24-hour burn timer. Save a link. You have 24 hours to read it, vault it, or let it burn.
Three-layer flow. Flame (24h) → Spark (30 days) → Vault (permanent).
AI digest. Every article gets a summary and three bullets on save.
MCP server. 26 tools Claude Desktop, Claude Code, and Cursor can call on your vault in real time.
CLI and REST API. Programmatic access for developers who script their reading.
Free. Everything above is included — vaults, AI digests, MCP server, iOS app. No paywall today.

The opinionated 24-hour delete is the product. Without it, Burn would just be another read-later app. With it, the feed forces a daily decision: is this article worth my attention right now? If yes, finish it or vault it. If no, let it burn. The constraint is the feature.

Feature-by-Feature Comparison

Feature	Raindrop.io	Burn 451
Free tier depth	Unlimited bookmarks	24h flow + vaults + AI digests
Pro price	$3/mo	Free today
AI summary on save	Pro only	Included, no limit
AI digest across queue	No	Yes
Automatic expiry	No	24h default
Nested folders	Yes	No (vault + tags only)
Visual previews	Yes, rich	Minimal, text-first
Browser extensions	Chrome/Firefox/Safari/Edge/Opera/Brave	Chrome (Safari/Firefox in roadmap)
Mobile apps	iOS + Android	iOS (Android in roadmap)
Full-text search	Pro	Free tier
Public collections	Yes	Yes (vaults)
CLI	No	Yes
MCP server	No	Yes (26 tools)
REST API	Yes	Yes
Export format	HTML/CSV	Markdown/JSON
Self-hosted option	No	No (Karakeep does that niche)

The table makes the philosophy clear. Raindrop leans into depth of organization UI. Burn leans into integration with how you already work (AI assistants, scripts, agents).

Pricing in Detail

Raindrop.io free tier is unlimited bookmarks, basic sort/tag, all browser extensions. Pro at $3/month adds smart collections, full-text search, nested search filters, permanent backup, and 10GB media upload.

Burn 451 is free today — the whole product. 24-hour flow, unlimited vaults, AI summaries on save with no hard limit, AI digest across your queue, 26-tool MCP server, CLI, REST API, iOS app. A paid tier may show up later; the free experience is not a trial with features disabled.

On pricing alone, free beats $3. On AI features inside the free tier, Burn wins by default because Raindrop gates the interesting AI behind Pro.

Do Burn 451 and Raindrop.io Solve the Same Problem?

No. Raindrop solves "I need to organize and find my saved links." Burn solves "I save links and never read them." These are fundamentally different problems with opposite design solutions.

Your problem is organization if: you save links for reference, frequently search old bookmarks, share collections → Use Raindrop.

Your problem is reading discipline if: you have 500+ unread articles, feel guilty about growing piles, save in bursts you never return to → Use Burn.

One way to self-diagnose: look at your bookmark bar right now. How many of those links have you opened in the last 30 days? If the answer is most of them, you have an organization problem. If the answer is under 10%, you have a reading problem. Raindrop and Burn are designed for different answers.

Who Each Tool Is Wrong For

Raindrop is wrong for you if: your primary complaint about your current bookmark tool is "I never read anything." A better organizer will not fix that — it will just organize the pile more beautifully. Raindrop's free tier has no forcing function for attention.

Burn is wrong for you if: you need a permanent reference library with deep folder hierarchies. Burn has vaults, but they are topic-curated, not everything-bucket. If you need to save 200 docs for a client project and sort them into subfolders, use Raindrop.

Also: Burn is wrong for you if you hate the idea of things deleting automatically. Some people find the 24-hour timer stressful. That's a legitimate taste disagreement, not a flaw — it's just not for everyone.

Can I Use Both Raindrop and Burn Together?

Yes. Use Raindrop as your permanent reference library for bookmarks you need to find later, and use Burn as your reading inbox for articles you want to actually consume. Reference → Raindrop. Reading → Burn.

This is the setup a few Burn users have described. Browser bookmark bar stays clean. Work references and tool documentation live in Raindrop collections that stay organized and searchable forever. The day's reading queue — articles from Twitter, newsletters, Hacker News — lives in Burn with a 24-hour timer. Anything from Burn that turns out to be a keeper gets vaulted or cross-posted to Raindrop.

The two tools don't step on each other because they were built for different time horizons. Raindrop is permanent memory. Burn is working memory.

The Bottom Line

Raindrop.io is the best bookmark organizer in 2026. Burn 451 is the best tool for actually reading what you save. They're not competitors — they solve different problems.

If you're unsure which problem is yours, I'd actually recommend Raindrop first. It's $2/month cheaper and has no opinionated deletion. If after a month your saved-but-unread pile still grows, come back and try Burn.

Try Burn 451 free

How to Save Articles to ChatGPT: A Non-Coder's Guide to Routines

Fisher Shen (Fisher) — Thu, 23 Apr 2026 00:32:52 +0000

How to Save Articles to ChatGPT: A Non-Coder's Guide to Routines

Published 2026-04-23 · 10 min read

Open your ChatGPT settings right now and look for "Tasks" or "Schedules" in the sidebar. If you're on Plus, Pro, or Team, the panel is already there. There's a good chance the counter reads 0 active tasks.

You're not alone. ChatGPT shipped Scheduled Tasks in January 2025 and most paying users have never opened the panel once. It's the most underused feature of the most popular AI tool on earth — and for the specific problem of "I save articles I never read," it's a fix hiding in plain sight.

This guide is for non-developers. No terminal. No API keys. No code. I set my first one up while making coffee, and the second while the coffee cooled. If that's the bar, you can clear it.

What ChatGPT Routines Actually Do

Routines (officially called Scheduled Tasks inside ChatGPT) let you write a prompt once and have ChatGPT run it on a schedule. Daily at 7 AM. Every Monday at noon. Once, next Tuesday. It sends the result to you as a push notification or email.

The whole feature is built around natural language. You don't pick a time from a dropdown. You type something like "every morning at 7, summarize the top 3 AI news stories in under 100 words" and ChatGPT creates the task for you.

A few facts that matter:

You need ChatGPT Plus, Pro, or Team ($20/month for Plus, the cheapest tier).
You can have up to 10 active tasks at any time. Not 15, not unlimited — 10.
Tasks can run as often as every 15 minutes, up to 4 per hour.
The feature works in the iOS app, Android app, and macOS desktop app. Web and Windows are still catching up at time of writing.
Results come as push notifications or emails. They don't auto-post anywhere.

That's the whole surface area. It's small on purpose. The power comes from what you ask it to do.

5 Routines You Can Set Up Today (No Code)

Here are five that I actually run or have seen work. Copy the prompt text into ChatGPT, hit send, and it becomes a scheduled task.

1. Morning AI News Digest

"Every weekday at 7:30 AM, search the web for the 3 most important AI tool launches or updates from the last 24 hours. Summarize each in under 40 words with a link. Keep the whole message under 150 words."

Why this one first: it replaces three newsletters and a Twitter doomscroll. You read it with breakfast. Done.

2. "What Should I Read Today?"

"Every weekday at 9 AM, pick one article from the list I'll paste below and tell me why it's worth 10 minutes today. Rotate so I don't see the same piece twice in a week."

You paste your reading list once in the same thread. ChatGPT remembers it within that task. It's a tiny nudge but it breaks the "500 saved articles, zero opened" loop.

3. Weekly Reading Recap

"Every Sunday at 6 PM, ask me what I read this week. Wait for my reply, then write a short summary of the top themes and one question I should think about next week. Send it to my email."

This one is a ritual, not an automation. The point is the Sunday nudge forces you to actually recall the week. Most people skip this step and wonder why nothing sticks.

4. "What Was I Researching Last Week?"

"Every Monday at 8 AM, remind me of the three topics I was researching most last week based on our previous chats, and suggest one concrete next step for each."

ChatGPT's memory has to be turned on for this one. Settings → Personalization → Memory. It pulls from your chat history.

5. Monthly Bookmark Autopsy

"On the 1st of every month, ask me: 'Which three saved articles did you actually read last month? Which 10 did you not open? Want to delete them?' Wait for my reply, then give me a one-line justification for deleting the rest."

Guilt-free way to clear the pile. The wait-for-reply pattern matters — ChatGPT can run a task and then continue the conversation with you when the notification lands.

Where Routines Break: The Saved-Articles Problem

Here's the honest limitation most tutorials skip past.

ChatGPT Routines can search the web. They can remember facts you've told them. They cannot, out of the box, read your Pocket queue, your Chrome bookmarks, your Readwise library, or your Notes app. There's no native "connect my reading list" button.

This matters a lot. The most useful routines would be things like:

"Every morning, summarize yesterday's saved articles."
"Every Friday, list the 5 articles I saved this week that I haven't opened yet."
"Pick the saved article closest to what I'm working on today."

None of these work with Scheduled Tasks alone. The routine has no way to reach into where your articles live.

This is the exact gap Burn 451 was built to close.

How Burn 451 Fills the Gap

Burn 451 is a read-later tool with a 24-hour timer — save something, you have a day to read it or vault it or let it go. The part that matters for this post: Burn ships a public REST API, a command-line tool, and a 26-tool MCP server. All three are free, on the free tier, today.

For non-developers, the way this works with ChatGPT Routines is simpler than it sounds.

Option A: The sharing link trick (zero setup).
Every vault in Burn has a public share URL. You vault articles about, say, "AI agents" into one vault. Inside your ChatGPT routine you paste that vault URL and ask ChatGPT to fetch it. Example prompt:

"Every morning at 8, fetch https://burn451.cloud/vault/ai-agents and summarize the 3 newest articles in under 120 words."

ChatGPT can open public URLs. You don't need an API key. You just need one vault and one link.

Option B: The ChatGPT custom GPT path (still no code).
If you're on Plus, you can build a Custom GPT in about 4 minutes. In the GPT builder, paste the Burn API docs URL and tell the builder "connect to the Burn 451 API, token is ." You get the token from Burn's settings panel — copy one field, paste one field. Then your scheduled task can reference the custom GPT and it'll pull real-time data.

Option C: The MCP route (for the slightly technical).
If you also use Claude Desktop, Claude Code, or Cursor, Burn's MCP server connects your vault to those clients in one line. That's a different workflow from ChatGPT Routines, but worth mentioning because some readers will want it.

For the non-coder path, Option A covers 80% of what most people want.

Step-by-Step: Your First "ChatGPT Reads Burn" Routine

Time estimate: 3 minutes, assuming you already have a Burn account.

Step 1. In Burn, create a vault for your daily reading. Call it whatever you want — I called mine "morning-feed."

Step 2. Vault 3-5 articles into it. Anything you'd want summarized.

Step 3. Click the vault's share button. Copy the public URL. It looks like https://burn451.cloud/vault/morning-feed.

Step 4. Open ChatGPT (iOS, Android, or macOS app). Start a new chat. Paste this, replacing the URL with yours:

"Every morning at 8 AM, fetch this URL: https://burn451.cloud/vault/morning-feed. Take the 3 most recently vaulted articles. Write a 120-word brief covering what each one argues and one sentence on why it matters. Send me a push notification when it's ready."

Step 5. Send it. ChatGPT will confirm: "Task scheduled." You can see it in the Schedules panel.

That's it. Tomorrow at 8 AM your phone buzzes with a 120-word summary of the three articles you vaulted. Over time, as you save more, the brief gets richer. You can edit the task any time — change the word count, change the time, change the vault.

When This Breaks

I said I'd be honest. Here's what actually goes wrong.

ChatGPT skips days. Roughly 1 in 10 runs just... doesn't fire. OpenAI hasn't explained why. Don't build anything mission-critical on it.
Web fetch is finicky. ChatGPT can't always open every URL — some pages 403, some load too slow, some return content it doesn't want to summarize. Public Burn vault URLs are plain HTML and work reliably in my testing, but occasional misses happen.
The 10-task cap is real. If you hit it, you have to delete an old task to make a new one. No pleading your way out.
Non-Plus users are locked out. This feature doesn't exist on free ChatGPT. If you don't want to pay $20/month to OpenAI, skip this entire post — or use Claude's or Gemini's free scheduling features, which work differently.
The output lives in notifications. ChatGPT doesn't save task results into a clean log. If you want a searchable archive of your morning briefs, you have to copy them somewhere yourself.

None of this is a dealbreaker. But "set it and forget it" is aspirational. "Set it and glance at it" is honest.

The Pricing Picture

ChatGPT Plus: $20/month. Assumed if you're reading this.
Burn 451: Free today. The 24-hour timer, vaults, AI summaries on save, public share URLs, REST API, CLI, and 26-tool MCP server are all on the free tier.
Total new spend to do everything in this post: $0.

I built Burn this way on purpose. You shouldn't have to pay two tools to fix a reading habit. ChatGPT Routines + Burn's free tier covers the full workflow.

FAQ

Can I save an article directly to ChatGPT?
Not the way you might hope. ChatGPT has a "save to memory" feature, but it stores short facts about you, not full articles. For article-length content, you save into a read-later tool like Burn and let ChatGPT reference it by URL or via a Custom GPT.

Do ChatGPT Routines work on the free plan?
No. Scheduled Tasks require Plus, Pro, or Team. There is no free trial for this specific feature at time of writing.

How many routines can I have?
Up to 10 active tasks at any time. If you hit the cap, you delete or pause one before creating a new one.

Will this work with Pocket, Instapaper, or Readwise?
Only if those tools expose public vault URLs or a documented API, and only if you're willing to build a Custom GPT to reach them. Pocket shut down in July 2025. Readwise has a REST API but requires a developer-ish setup. Burn 451 ships public share URLs so a ChatGPT routine can fetch without any API glue.

Is my saved content private when ChatGPT fetches it?
If you use a public Burn vault URL, anyone with the URL can view it — same as a shared Google Doc set to "anyone with the link." Don't use public vaults for private research. Use the Burn API with an auth token if you want private access; that path needs a Custom GPT to hold the token.

What's the best first routine to set up?
The morning AI news digest. It takes 60 seconds to create, provides visible value the next morning, and gives you an excuse to open the Schedules panel and see the rest of the surface area. Start small, then add one more routine per week.

Building Burn's MCP Server: 3 Patterns That Actually Work

Fisher Shen (Fisher) — Wed, 22 Apr 2026 00:43:08 +0000

This post was originally published on burn451.cloud. Syndicated here.

Building Burn's MCP Server: 3 Patterns That Actually Work

MCP has been open-source for over a year now. Cursor shipped Bugbot MCP support earlier this month. Anthropic published a 2026 roadmap that explicitly moves spec evolution out of fixed release cadences and into working groups. And my own burn-mcp-server just crossed a thousand installs on npm. Somewhere in the middle of all that, MCP stopped being "the new Anthropic thing" and became the default way I think about exposing any product to an agent.

I build a read-later app called Burn 451. About a month ago I shipped burn-mcp-server on npm — 26 tools that let an agent read, triage, and curate my saved articles. Last 7 days: 349 installs. Last 30 days: 1152. Most of that is self-use plus a small group of early users I can name on two hands. The adoption curve is not the point of this post. The point is that somewhere between the first tool and the twenty-sixth, I made three design calls that kept the thing from collapsing under its own weight, and I want to write those down while the code is still fresh.

I am not a professional engineer. I ship with Claude Code, I read my own diffs, I break things, I fix them. If you are building your first MCP server you will probably make the opposite call on at least one of these, and that is fine — the point is to know why you made it.

How should you expose your data to an MCP client — as tools or as resources?

Tools win for agents that act, resources win for read-only dumps, and in practice almost every MCP client I care about treats tools as first-class and resources as an afterthought. I went tool-first for Burn and I would do it again.

Here is what the code actually looks like. burn-mcp-server registers 26 server.tool() calls and exactly 2 server.resource() entries. The resources expose burn://vault/bookmarks and burn://vault/categories — bulk JSON dumps of the user's permanent knowledge base. They exist because the MCP spec says they should. In 30 days of production use I have not once seen Claude Code, Cursor, or Windsurf actually prefer a resource read over a tool call, even when both are wired up to return the same data.

The reason is simple. A tool has a schema. The agent knows what to pass, what it will get back, and what the side effects are. A resource is a URI you fetch; the agent has to guess whether fetching it helps. Claude Desktop will happily list your resources in the UI, but Claude Code in the terminal — which is where agents actually work — ignores resources most of the time unless you prompt the model explicitly to go look at them.

So I pushed everything that an agent might want to call into tools. search_vault with a query and limit. list_flame for the inbox. get_flame_detail for full article extraction. Even the bulk views got tools (list_vault, list_categories) because a tool call with an explicit filter is cheaper than dumping the whole vault as a resource and asking the model to grep it.

The one place resources still pull their weight is discoverability. When someone plugs burn-mcp-server into Claude Desktop for the first time and opens the MCP inspector, the two resources show up as a hint: "this server has a vault, here is what's in it." They are not the workhorse. They are the welcome mat.

If you are designing an MCP server from scratch, the rule I follow now: every action goes in a tool, every read that needs a filter goes in a tool, and you only reach for resources when you want a stable URI that external tools can reference by name. Everything else is noise.

Where should the filtering and business logic live — in the client or on the server?

On the server, every time, even when the client is perfectly capable of doing it. This is the call I made earliest and the one I am most glad about.

When I first sketched burn-mcp-server I thought about thin server + thick client — expose raw Supabase queries, let the agent figure out filters, let each MCP client (Claude Code, Cursor, Windsurf, future ones I haven't seen yet) build its own opinionated UX on top. That lasted about one afternoon. The problem is that "let the agent figure out filters" is a line item that shows up in every agent prompt, on every client, forever. Each client has a slightly different personality. Each agent has a different definition of "recent." The status flow — Flame (24h inbox) → Spark (read, 30-day lifespan) → Vault (permanent) → Ash (expired) — is load-bearing for how Burn works, and letting a model reinvent it at the edge is how you ship bugs users cannot reproduce.

So burn-mcp-server carries the weight. Every tool has a single, explicit purpose. list_flame only returns status=active bookmarks and computes remainingHours, isBurning (≤ 6h), isCritical (≤ 1h) on the server. The agent does not need to know the countdown expires at countdown_expires_at; the tool tells it "this one burns in 2.3 hours, that one in 47 minutes." Same with search_vault — the client passes a query string, the server handles the title ilike, the tag fallback, and the deduplication. The response is shaped for an agent to reason about, not for a developer to query.

The most useful piece of this pattern is a helper I wrote called verifyBookmark(id, expectedStatus). Any tool that moves a bookmark through the status flow — move_flame_to_spark, move_spark_to_vault, move_flame_to_ash — calls it first. If the agent tries to promote a bookmark that is already in the Vault, the tool returns a readable error: "Bookmark is in Vault (expected Flame)". The agent recovers, the state stays consistent, and I do not spend evenings debugging "why did a Vault entry lose its category." Pushing this into the server means one implementation, one test surface, one place to change.

There is a commit I keep coming back to as a reminder of why this matters. Early on I let the server depend on whatever Supabase project the caller happened to point at. A config drift bug later — commit 03da444, "correct Supabase project ref in MCP server, add zod dependency" — reminded me that the server is the ground truth. Clients should not even have the option of pointing at the wrong database. zod showed up in that same commit because I added runtime validation on every tool input; schema in the SDK is nice but trusting it is not.

Thin client, thick server. If you are writing your own MCP server and you find yourself thinking "I'll let the agent handle this case" — stop, put it in the server.

How do you debug a server whose errors the client never shows you?

You log every tool call on the server, from the first line of every handler, and you keep the logs local-only so users are not shipping their reading history to your analytics pipeline.

This one hit me during the week I shipped MCP 2.0 with write capabilities (commit e21d4f5, "MCP 2.0 write capabilities + free tier + Web Collection + remove Cluster"). Suddenly agents were calling move_spark_to_vault and create_collection and write_bookmark_analysis — real writes, real state changes. Any one of them could fail silently. Claude Code in particular has this habit of quietly retrying a failed tool call with slightly different args, which looks like nothing to the user and panic to me when I check Supabase an hour later and see three half-written collections.

The observability layer is not fancy. It is console.error at the top of every handler, a sliding-window rate limiter that logs every cap hit (RATE_LIMIT_MAX_CALLS = 30 per minute), and a session cache at ~/.burn/mcp-session.json that records when tokens were exchanged and refreshed. console.error because stdio MCP servers use stdout for protocol and stderr for everything else — I tripped over that on day one, wrote a textResult with a leading log line, watched Claude Code crash with a JSON parse error, fixed it, moved on.

What matters is that the server writes its own audit trail. When a user tells me "the agent said it moved 10 Flames to Spark but nothing happened," I do not need them to reproduce. I ask them to check ~/.burn/ for the session cache and pull the last 50 stderr lines from their Claude Code logs. Nine times out of ten the answer is obvious: token expired mid-batch, rate limit hit at bookmark 7, Supabase RLS rejected a move because the user changed accounts between launches. A separate commit — 9519cbb, "fix: MCP auth independent session + rescue quota display" — came directly out of one of those reports, where the session cache and the quota display were stepping on each other.

There is a second half to this that I care about more than the first. I do not send any of this to a server I control. No Sentry, no PostHog, no backend analytics hook. The audit lives on the user's machine, behind 0o600 file permissions, and it deletes itself when the cache rotates. An MCP server runs on the user's local stdio; the agent sees their full reading history; the last thing I want is a phone-home log that records which articles they asked about. If you are building an MCP server that touches any kind of personal data, resist the urge to wire in observability that leaves the machine. Your future self, and your users, will thank you.

FAQ

What is an MCP server?

An MCP (Model Context Protocol) server is a process that exposes tools, resources, and prompts to an AI agent over a standard protocol. The client — Claude Desktop, Claude Code, Cursor, Windsurf — connects to the server and calls tools as if they were local functions. MCP is the equivalent of a REST API for agents, except the schema is self-describing and the agent discovers the tools at connection time. Anthropic open-sourced the protocol in late 2024, and by 2026 it has become the de facto standard across the major agent-facing editors.

How do I install burn-mcp-server?

Run npx burn-mcp-server after setting BURN_MCP_TOKEN in your environment. Get the token from Burn App → Settings → MCP Server. For Claude Desktop, add an entry to mcpServers in your config pointing at burn-mcp-server with the token in env. The package is on npm and works with Claude Code, Cursor, and Windsurf without changes.

Why did you go tool-first instead of resource-first?

Because every MCP client I tested — Claude Code, Cursor, Windsurf, Claude Desktop — prefers tools in practice. Tools carry a schema the agent can reason about; resources are URIs the agent has to decide to fetch. For 26 operations across search, triage, curation, and analysis, tool-first keeps behavior consistent across clients. Resources still earn their keep as welcome-mat hints (burn://vault/bookmarks, burn://vault/categories) but not as the main interface.

How do you keep the server stateless across restarts?

Session caching at ~/.burn/mcp-session.json with 0o600 permissions. On first run the server exchanges the long-lived MCP token for a short-lived Supabase session, then caches both the access token and refresh token. Subsequent launches restore the session from disk with zero network calls. Supabase's onAuthStateChange listener writes fresh tokens back to the cache when they auto-refresh. If the cache is corrupt or the refresh fails, the server falls back to a full exchange.

What happens if an agent hits the rate limit?

The rate limiter is a sliding 60-second window with a 30-call cap per MCP session, in-memory. When an agent trips it, the tool returns a readable message — "Rate limit exceeded (30 calls/min). Retry after 12s." — instead of silently failing. Claude Code and Cursor both handle this gracefully; the agent usually pauses and retries. The limit exists less for abuse than for runaway loops: an agent that loses track of state can burn through 30 list_flame calls in three seconds and the limiter is the circuit breaker.

Is this the right time to build an MCP server?

Yes, if you already have a product with a data model worth exposing. The protocol has been open-source for over a year, Anthropic has moved spec evolution into working groups rather than fixed releases, and the same server I ship on npm runs on Claude Code, Cursor, and Windsurf without per-client forks. Tooling is mature enough that you spend your time on the data model, not on protocol plumbing. No, if you are building the server before the product — the 26 tools in burn-mcp-server are a direct mapping of the app's existing status flow, and trying to design tools without a product underneath is a quick path to an agent surface no one uses.

Best AI Bookmark Manager 2026: 10 Tools Tested by Someone Who Built One

Fisher Shen (Fisher) — Tue, 21 Apr 2026 02:51:03 +0000

Originally published on burn451.cloud — sharing the canonical link so you get the latest version with the comparison table and FAQ schema.

I built Burn 451 because my Chrome had 4,700 bookmarks I never opened. That gives me skin in this game, so take the ranking with that in mind. What I can give you that a generic listicle can't is the honest read on what these tools actually do when you use them for a few weeks.

"AI bookmark manager" is a confusing category in 2026. Readwise calls itself AI reading. Mymind calls itself AI memory. Karakeep calls itself AI tagging. Burn calls itself AI triage. All of them save links, all of them do something with a language model, and almost none of them mean the same thing by "AI." This guide covers ten tools, what their AI actually does, who each is for, and where each one breaks.

What "AI bookmark manager" actually means in 2026

Three different things, in ascending order of ambition.

AI as a summary layer.You save an article, the tool fetches it, an LLM writes a paragraph or three bullets. That's it. Readwise Reader, Matter, and Glasp all sit here. Useful, but the AI is doing work you could do with a browser extension and the OpenAI API in an afternoon. The value is that it's integrated into the save flow.

AI as an organization layer. The tool decides what the article is about and files it for you. Mymind picks a visual space. Karakeep picks tags. Raindrop Pro picks smart collections. The AI is replacing the folder-and-tag UX, which is the first UX most bookmark managers get wrong. This is the tier where power starts mattering.

AI as a query layer. You ask a question, the model answers from the corpus of what you saved. Burn 451 ships this through an MCP server— Claude Desktop and Cursor can run queries like "what did I save about context engineering this month" without leaving the chat. Recall ships it as an internal knowledge graph. Mem ships it as chat-with-your-notes. This is where the ceiling of the category lives, and it's the layer where most bookmark tools still haven't shown up.

The 10 tools, ranked honestly

Ranking below. Price, AI capability, who it's for, and where it breaks. Burn is #1 because I built it and I use it. I'll be specific about where the other nine beat it.

[See comparison table on the original post]

1. Burn 451 — AI triage and an MCP server

Price: Free. AI: per-article summary, 3-bullet digest, vault-level editorial summaries, an MCP server with 26 tools for Claude and Cursor.

The core UX choice is the 24-hour timer. Articles auto-delete unless you finish or tag them, which kills the "save it forever, never read it" failure mode that built my 4,700-bookmark disaster. The vault is where anything you keep lives — curated collections with AI summaries on each article, queryable through the MCP server in real time. Nine live vaults covering Karpathy, Tiago Forte, Paul Graham, Simon Willison, context engineering.

Beats the others on: MCP-first architecture, free tier is actually useful, iOS app, open MCP server on npm. Loses to the others on: no Safari extension yet, no social/sharing layer, the 24h delete is opinionated and some people hate it.

2. Readwise Reader — AI for serious readers

Price: $8 per month. AI: Ghostreader generates summaries, explanations, and outline notes. Chat-with-article pulls context from your highlights. Spaced repetition resurfaces highlights.

Readwise is the best tool in this guide if you actually read deeply and highlight as you go. Ghostreader's AI is thoughtful — it generates outlines and summaries that are genuinely useful, not marketing filler. The highlight review system keeps what you read alive weeks later. I've used Readwise on and off for three years.

Who it's for: the 10% who actually read the long articles they save. Where it loses:the other 90%. If you're a saver and not a reader, Readwise just gives you a nicer inbox for articles you'll never open. Also $8 per month forever.

3. Matter — AI for the iOS crowd

Price: Free with a $8-per-month premium tier. AI: auto-summary on save, AI-generated daily digest, read-aloud with decent voice quality.

Matter nails the mobile read-later experience better than anyone else. The typography is gorgeous, the swipe gestures are natural, the queue model is exactly right for phone reading. The AI summary on save is useful without being in the way. Premium adds AI highlights and personal newsletter digests.

Loses to Burn on: no MCP, no CLI, no free full vault export. Loses to Readwise on:weaker highlight system, no spaced repetition. But for pure "save on phone, read on phone," Matter still wins.

4. Mymind — AI for visual thinkers

Price: $13 per month. AI: auto-tags, auto-categorizes into visual spaces, search by meaning.

Mymind refuses to show you a folder tree. There is no way to manually organize. You save, the AI files it into a space, and you browse the mood board. It is beautiful and it works if your brain works visually. It does not work if you want to run structured queries or share with a team.

Who it's for: designers, art directors, people who save for inspiration rather than reference. Where it loses:the $13 price is the highest in the guide excluding Mem, and the product will not answer queries like "show me everything about Karpathy from March." That's on purpose — but that purpose isn't most people's.

5. Raindrop.io — traditional bookmarking with AI bolted on

Price: Free tier is generous, $3 per month for Pro. AI: smart collections (Pro), AI full-text search (Pro).

Raindrop is the functional survivor from the pre-AI era — 15M+ users, rock-solid sync, every platform covered. The AI features are recent additions and they work, but the product DNA is still folder-and-tag bookmark management. If you liked Delicious in 2009, this is the 2026 answer with optional AI on top.

Who it's for: organizers who want to run the UX themselves and treat AI as a bonus. Read more: Burn 451 vs Raindrop.io.

6. Karakeep (formerly Hoarder) — self-hosted AI

Price: Free if you self-host. AI: auto-tags and summarizes via OpenAI, Anthropic, or local Ollama.

Karakeep is the serious open-source option. Docker Compose to install, point it at your preferred model, done in roughly 30 minutes. Auto-tagging works, full-text search is fast, mobile clients are functional. You pay the API bills yourself, which for a single-user install is usually $1–3 per month on OpenAI's small models, or $0 if you run Ollama locally.

Beats Burn on: full data sovereignty, no external service can ever shut it down. Loses to Burn on:you're the sysadmin, mobile polish is weaker, no managed MCP, you do your own backups.

7. Glasp — social AI highlights

Price: Free with a $8-per-month Pro tier. AI: AI summary on save, ChatGPT plugin, AI copilot.

Glasp is what you want if your reading benefits from a community. Highlights are public by default, you follow other readers, you see what they're thinking. For some people that's the entire point. For others it's a privacy trainwreck. Know which one you are before installing.

Beats the others on: social discovery, the ChatGPT plugin is the only one in this guide. Loses on: privacy defaults, no MCP, the AI summary quality is noticeably weaker than Readwise or Burn.

8. Recall — bookmarks as a knowledge graph

Price: $10 per month. AI: auto-summary, automatic wiki-style links between related saves, spaced repetition review.

Recall treats bookmarks as nodes in a Wikipedia-for-your-brain. Save an article about Karpathy, Recall auto-links it to other Karpathy saves, and the resulting graph is browsable like a mini wiki. When it works it's magical. When it doesn't, the graph is noisy. In my testing across ~200 saves, about 60% of the auto-links were useful, 40% were noise.

Who it's for: researchers who save densely in a few topics. Where it loses: generalist readers, because the graph needs density to be useful.

9. Mem.ai — a notes app with bookmarking

Price: $15 per month. AI: chat-with-notes, auto-connections, AI writing assistance.

Mem is more Notion-replacement than bookmark tool. You can save links and they become notes, and the AI does good work connecting them to other notes. But the center of gravity is writing, not saving. If you already have a notes app you like, Mem is not what you want for bookmarks. If you want one tool to replace both Notion and your bookmark manager, it's the only real candidate here.

10. Instapaper — the AI-free baseline

Price: Free with a $3-per-month premium tier. AI: none natively. Clean typography, text-to-speech, highlights.

Instapaper is included as the reference point. No AI. The same product it was in 2012, still working, still good at what it does. If every tool above added AI as decoration rather than real capability, Instapaper would out-deliver them. That's worth knowing before you pay for AI features you won't use.

How to choose in 60 seconds

Decision tree:

• You want to ask questions of your saved articles via Claude or Cursor:Burn 451. It's the only one with a native MCP server. Free. - • You actually read deeply and highlight: Readwise Reader. Pay the $8 and skip the free-tier dance. - • You save on phone, read on phone: Matter. The mobile experience is still the category leader. - • You want zero manual organization and visual browsing: Mymind. - • You want folders and tags you control, with optional AI: Raindrop.io. - • You want to self-host everything: Karakeep. Plan for 30 minutes of setup. - • You're saving for research on a few dense topics: Recall. - • You want no AI, just a clean read-later: Instapaper. ## Why I built Burn 451

The short version: 4,700 Chrome bookmarks I never opened. I tried Pocket (shut down July 2025), Readwise (worked, but I didn't read enough to justify $8 per month), Raindrop (beautiful, still didn't read anything), Instapaper (same). The pattern was that every tool optimized for saving. None of them fought the core problem — saving without reading.

Burn deletes by default. Saves expire in 24 hours unless you finish them or send them to the vault. That's the whole behavior design. Everything else — MCP server, vault collections, AI summaries — followed from "once you do actually read something, what should happen to it." The answer turned out to be: turn it into a queryable knowledge base that Claude can read.

This is the pattern Karpathy described in his LLM Wiki gist — raw saves become curated markdown become queryable context. I didn't know I was building that when I started. I was just trying not to drown in bookmarks.

If any of that sounds useful, Burn is free. Try it. If the 24-hour delete sounds terrifying, I'd start with Readwise Reader or Raindrop.

I Built a Read-Later App. Karpathy Described My Data Model. (with MCP + Claude Code)

Fisher Shen (Fisher) — Mon, 20 Apr 2026 12:41:49 +0000

I'm not an ML researcher. I don't have a CS degree. I built a read-later app called Burn 451 because my bookmarks pile kept embarrassing me. Yesterday I shipped the ninth vault — 25 essays by Tiago Forte, our in-house PKM canon. The week before that, Andrej Karpathy published a gist describing how he organizes his personal research with an LLM. 16M views in 48 hours. I read it and realized he had just described my database schema.

What Karpathy said

The pattern is three folders. raw/ holds immutable source material — papers, transcripts, articles. The model reads it, never writes to it. wiki/ holds LLM-authored markdown, one file per concept, with backlinks and provenance tracked in git. outputs/ holds synthesized answers the model writes back after a query.

No vector database. No embeddings. No chunking. The LLM reads the markdown directly in its context window. Karpathy frames it as a compiler: raw is source, wiki is the compiled binary, outputs is the runtime. His own wiki on one research topic is around 100 articles and 400K words.

The top Hacker News thread on the gist hit 296 points. The main objection was model collapse — won't LLM-generated notes degrade over iterations? Karpathy's answer in the comments: he uses already-trained models to curate, not to retrain. Curation is a one-way flow. It compounds.

The counter-arguments matter. Epsilla's team pointed out that walking a directory is O(n) — it works at 100 pages, strains at 1,000, breaks at 10,000. Towards AI noted that vector embeddings are still the cheapest way to answer "what's relevant" across arbitrary corpus sizes. Both are right. The pattern only works inside a narrow envelope: small corpus, stable content, one human owner, model with a 200K+ context window. That envelope is the exact shape of a personal read-later archive.

The accidental reference implementation

I read the gist and opened my own codebase. The mapping is one-to-one.

My bookmarks table in Supabase is the raw layer. Every article a user saves lands there with the full fetched text, the canonical URL, and a timestamp. The model never edits these rows. They're append-only by construction.

My collections table is the wiki layer. Each collection is a topic — Karpathy, Simon Willison, Paul Graham, vibe coding, Tiago Forte. Nine live right now. Each collection holds a curated list of bookmark IDs, plus an AI-written summary and three-bullet digest generated per article. The full compiled output lives at website/data/vault-content/<slug>/<id>.md. Today that directory holds 140 markdown files and 263,000 words of source text.

The outputs layer is what the reader sees. Every vault renders as a static page at burn451.cloud/vault, regenerated hourly. Each article has its own public URL with structured data, an AI summary, and a link back to the original. The new one is burn451.cloud/vault/tiago-forte.

The piece Karpathy doesn't talk about in the gist is ingest. In his version, he drops files into raw/ manually. In Burn, ingest is automatic. A user taps save on their phone. The article is fetched through a clean-reader pipeline, deduped, summarized, and filed under a collection. I ship this as burn-mcp-server on npm — 26 tools for Claude and Cursor to query the vault in real time. Tools like search_vault, list_vault, get_article_content. It's the automated pipeline into Karpathy's raw/ folder. I didn't know that when I built it.

Demo: Tiago Forte vault in Claude Project

Here's how to run it yourself. Takes five minutes.

Step 1. Open the Tiago Forte vault. Twenty-five essays covering PARA, the CODE method, Building a Second Brain, and his AI-era writing. The vault exports as a zip of markdown files — frontmatter with title, URL, fetched date, then the full article body. Total size around 40K words, well under Claude's 200K context ceiling.

Step 2. Open Claude, create a new Project, name it something like "Tiago Forte Second Brain". Drag the zip into the Knowledge panel. Claude unpacks the markdown and adds each file to the project index. No embedding step. No chunk configuration.

Step 3. Ask things you actually want to know. Three queries I ran:

"What is Forte's CODE method in one paragraph?" Claude returned a clean synthesis across the CODE introduction essay and the book chapters: Capture what resonates, Organize by actionability with PARA, Distill into the notes you'll actually use, Express by turning the notes into creative output. The answer named the four steps in order and cited which essays each was drawn from.
"How does PARA differ from Zettelkasten?" This is where the no-RAG pattern earned its keep. Claude pulled from three different essays and produced a contrast — PARA organizes by actionability (what will I use this for?), Zettelkasten organizes by atomic idea (what concept does this belong to?). A chunk-based RAG would have returned a top passage from one essay. The full-context read produced the comparison.
"How has Forte's view on AI changed between his 2022 writing and 2026?" Claude walked the timeline. Early caution about AI commoditizing notes. Later reframing around AI as a distillation partner. The answer tracked the shift across essays — something RAG's top-k retrieval struggles with by design.

If you're a developer, skip the export. Install burn-mcp-server in Cursor or Claude Code. The vault is already served as live MCP tools — the model calls search_vault and get_article_content directly. No file drag. New saves appear within seconds. This is the version I use day-to-day.

Where no-RAG breaks

I'm going to be honest about where this falls apart, because the pattern is being oversold on X right now.

Corpus size. Claude's context window is 200K tokens. Roughly 150K words. Past that, Claude Projects silently flips into RAG mode under the hood — there's an open issue documenting this. My Karpathy vault is already at 120K words. Merge all nine of my vaults into one project — 263K words — and you're not running pure no-RAG anymore.

Non-text. Images, audio, video. The pattern assumes markdown. A YouTube transcript works. A diagram doesn't. Forte has great slide decks. They don't make it in.

Live data. Claude Project knowledge is frozen at upload time. New essays need a re-upload. This is why the MCP version matters — it queries live Supabase, so the corpus updates the moment you save something new.

Who this isn't for. Enterprise search. Multi-tenant. Row-level ACL. Regulatory audit. A folder of markdown can't answer "which employees saw this document." If your requirements include any of that, use a real semantic graph.

What this means for you

If you save articles to a read-later app, you're already halfway to an LLM Wiki. You have the raw layer. You probably even have the wiki layer — it's called your tag system. The missing piece is the last mile: an export that an LLM can read, or an MCP server that hands it over in real time. Pocket never shipped either. Readwise ships an API but no MCP. The rest of the category is still optimizing for save count.

That's the whole product thesis behind Burn. Read-later is the natural shape of the pattern. The 24-hour timer handles triage. The vault handles the wiki. The MCP server handles ingest. Try it free. Point it at your bookmarks. See what your own reading looks like when you can ask it questions.

FAQ

What is an LLM Wiki?

An LLM Wiki is a human-curated set of markdown files that a language model reads directly at query time. Instead of chunking documents and retrieving embeddings, the model walks the directory and answers from the raw text. Karpathy proposed the pattern in April 2026 as an alternative to RAG for small, stable corpora owned by one person.

How is this different from RAG?

RAG chunks documents, embeds the chunks, and retrieves top-k matches at query time. An LLM Wiki skips all of that. The model reads the full markdown, uses its own context window as the index, and answers with cross-document synthesis. No vector database, no embedding costs, no chunk boundaries to fight.

Do I need to be technical to use this pattern?

No. If you can drag files into a Claude Project or ChatGPT Project, you have everything you need. The pattern works with any chat tool that accepts a knowledge folder and has a 200K-token context window. The technical version — MCP servers, CLI tools — is optional and only useful if you want live data.

What's Burn 451's role in this?

Burn 451 is a read-later app that accidentally matches the LLM Wiki shape. The bookmarks table is the raw layer. The vault collections and markdown files are the wiki layer. The MCP server automates ingest, so saving an article in Burn is the same as filing a new note in Karpathy's raw folder.

When should I still use RAG?

Use RAG when your corpus is bigger than your context window, when content changes every few minutes, or when you need multi-tenant access control. The LLM Wiki pattern breaks past roughly 200K words, fails on non-text content like images and audio, and has no concept of user permissions.

Can I use this with Claude Code or Cursor?

Yes. Install burn-mcp-server from npm, connect it to Claude Code or Cursor, and your saved articles become live tools the model can call. You skip the export step entirely. New saves in Burn appear as new queryable documents within seconds.

How big can the corpus be before the pattern breaks?

The hard ceiling is the model's context window. Claude handles 200K tokens, roughly 150K words. Past that, Claude Projects silently flip into RAG mode under the hood. In practice, keep a single wiki under 100K words for pure no-RAG behavior. Split larger corpora into topic-specific projects.

Originally published at burn451.cloud. Written by Fisher — @hawking520.

Pocket Alternative 2026: The Complete Guide After Pocket's Shutdown

Fisher Shen (Fisher) — Sat, 18 Apr 2026 08:38:52 +0000

I had 2,847 bookmarks in Pocket when it died.

I'd read maybe 94 of them. And I'm the guy who built a read-later app.

When Mozilla killed Pocket on July 8, 2025, I wasn't sad — I was relieved. My unread pile finally had an excuse to disappear. But then I realized: if I just move 2,847 links to another app, I'll end up in exactly the same place.

That realization is why I built Burn 451. But this post isn't a sales pitch — it's the honest guide I wish I had when I was looking for alternatives. I've tested all of them. Some are better than Burn for certain workflows. I'll tell you which.

No affiliate links. No sponsored placements.

What happened to Pocket?

Pocket was shut down on July 8, 2025 after Mozilla cut investment over two years. 20+ million users got an HTML export file and a "good luck."

Here's the timeline:

2007 — Read It Later (later Pocket) launches as a bookmarklet
2017 — Mozilla acquires Pocket, integrates into Firefox
2023 Q4 — Mozilla layoffs hit the Pocket team hard
2024 Q1 — Pocket Premium killed, free-only
2025 March — Mozilla announces sunset
2025 July 8 — Pocket dies
2025 October — Export tool goes offline. Data gone forever.

If you haven't exported yet and it's before October 2025: do it now at getpocket.com/export.

So what should I use instead?

Short answer: it depends on what you actually do with saved articles. Most people save and never read — which means the tool doesn't matter. What matters is whether the tool changes that behavior.

Here's my honest ranking after testing everything:

App	Price	AI	CLI/MCP	Best For
Burn 451	Free / $4.99/mo	Full AI digest + MCP	Yes	People who hoard and never read
Raindrop.io	Free / $3/mo	Search only (Pro)	API only	Pure bookmark organizing
Readwise Reader	$8/mo	Ghostreader highlights	API	Serious highlighters
Instapaper	Free / $3/mo	None	API	Minimalists
Matter	Free / $8/mo	Basic	No	Apple ecosystem
Wallabag	Free (self-host)	No	API	Privacy-first
Karakeep	Free (self-host)	AI tagging	API	Self-hosters + AI
GoodLinks	$5 once	No	No	Apple-only, no subscription

A few notes:

Omnivore was another promising open-source option. ElevenLabs acquired it in late 2024 and killed it almost immediately. "Open source" doesn't guarantee longevity when the team pivots.

Pocket's real gap wasn't features. It was the largest free read-later app with deep browser integration. Nothing fills that exact hole, but honestly? The alternatives are all more capable.

For developers: CLI + MCP is the real story

If you write code and use AI tools, the MCP integration is the thing that actually matters. I'm biased here — I built it — but hear me out.

Your saved articles can become context for Claude, Cursor, or any MCP-compatible AI. You don't copy-paste links. You ask "what did I save about WebSocket performance?" and get answers from your own reading history.

Burn 451: Full CLI + 22-tool MCP server + REST API
Wallabag: Self-hosted, full API, no AI (build your own)
Raindrop.io: Clean API, no CLI, no MCP

If you live in the terminal and work with AI, Burn's ecosystem is genuinely different. If you want total infra control, Wallabag.

The free tier showdown

Raindrop has the most generous free tier for organizing. Burn has the most generous free tier for actually reading.

	Burn 451 Free	Raindrop Free	Wallabag
Unlimited saves	✓	✓	✓
AI features	✓	✗	✗
Full-text search	✓	✗ (Pro)	✓
CLI/MCP	✓	✗	✗
Mobile	iOS	iOS + Android	Both
Setup	Zero	Zero	Need a server

Burn's free tier has a catch: the 24-hour burn timer. Articles expire if you don't act on them. This is by design — it's a digestion system, not storage. If you want 10,000 articles sitting quietly forever, use Raindrop or Pinboard.

How to export your Pocket data

Go to getpocket.com/export → download HTML → import to your new app. Deadline: October 2025.

For Burn 451:

npm install -g pocket-to-burn
pocket-to-burn import --file pocket_export.html

Tags, timestamps, and read/unread status are preserved. Old articles go straight to Spark (not the 24-hour inbox).

Most other apps (Raindrop, Readwise, Instapaper, Wallabag) also accept Pocket HTML import directly through their settings.

What makes Burn 451 different

Most read-later apps compete on the same axis: better storage, better folders, better reading font. Burn rejects the premise. The problem isn't saving — it's that you save too much and never go back.

24-hour timer: Every article gets a countdown. Read it, vault it, or let it burn.
AI digest: Don't read 15 articles — read a 2-minute synthesis of what matters.
MCP server: Your reading history becomes context for AI tools.

The metaphor: information comes in, gets processed, nutrients absorbed, waste eliminated. Hoarding is constipation.

Is it for everyone? No. If you want a quiet archive, use Raindrop or Pinboard. Burn is for people who are tired of lying to themselves about "reading it later."

Where Burn falls short (yes, I'm listing my own weaknesses)

No Android app — iOS and Web only as of April 2026
Opinionated — The timer stresses some people out
Young product — Launched 2025, less polished than decade-old competitors
Not for archivists — If you want 10K bookmarks searchable in 3 years, that's not us

The bottom line

Pocket's death is a forcing function. Don't just migrate your pile to a new app. Ask yourself: do I want a storage system or a processing system?

Storage: Raindrop.io (free) or Pinboard ($22/year)
Premium reading: Readwise Reader ($8/mo)
Self-hosted: Wallabag or Karakeep (free)
Actually read what you save: Burn 451 (free)

94 out of 2,847. If you see yourself in that number, maybe give it a shot.

Forem: Fisher Shen (Fisher)

Cal Newport's Reading System for Your Read-Later Pile

What is Cal Newport's reading system?

How does Slow Productivity apply to read-later apps?

What is the difference between additive and extractive reading?

How do I apply Cal's "Notebook over Chatbot" rule to bookmarks?

What's a 5-step Cal Newport-inspired reading system?

Should I use Burn 451 for this system?

How do I build a Cal Newport-style reading vault?

The 5 essays from Cal Newport that change how you read

Why Cal Newport doesn't have an X account

The bottom line

Burn 451 vs Raindrop.io: AI Digest vs Bookmark Organizer

What Is Raindrop.io Best At?

What Is Burn 451 Best At?

Feature-by-Feature Comparison

Pricing in Detail

Do Burn 451 and Raindrop.io Solve the Same Problem?

Who Each Tool Is Wrong For

Can I Use Both Raindrop and Burn Together?

The Bottom Line

Related reading

How to Save Articles to ChatGPT: A Non-Coder's Guide to Routines

How to Save Articles to ChatGPT: A Non-Coder's Guide to Routines

What ChatGPT Routines Actually Do

5 Routines You Can Set Up Today (No Code)

1. Morning AI News Digest

2. "What Should I Read Today?"

3. Weekly Reading Recap

4. "What Was I Researching Last Week?"

5. Monthly Bookmark Autopsy

Where Routines Break: The Saved-Articles Problem

How Burn 451 Fills the Gap

Step-by-Step: Your First "ChatGPT Reads Burn" Routine

When This Breaks

The Pricing Picture

FAQ

Related Reading

Building Burn's MCP Server: 3 Patterns That Actually Work

Building Burn's MCP Server: 3 Patterns That Actually Work

How should you expose your data to an MCP client — as tools or as resources?

Where should the filtering and business logic live — in the client or on the server?

How do you debug a server whose errors the client never shows you?

FAQ

What is an MCP server?

How do I install burn-mcp-server?

Why did you go tool-first instead of resource-first?

How do you keep the server stateless across restarts?

What happens if an agent hits the rate limit?

Is this the right time to build an MCP server?

Further reading on Burn

Best AI Bookmark Manager 2026: 10 Tools Tested by Someone Who Built One

What "AI bookmark manager" actually means in 2026

The 10 tools, ranked honestly

1. Burn 451 — AI triage and an MCP server

2. Readwise Reader — AI for serious readers

3. Matter — AI for the iOS crowd

4. Mymind — AI for visual thinkers

5. Raindrop.io — traditional bookmarking with AI bolted on

6. Karakeep (formerly Hoarder) — self-hosted AI

7. Glasp — social AI highlights

8. Recall — bookmarks as a knowledge graph

9. Mem.ai — a notes app with bookmarking

10. Instapaper — the AI-free baseline

How to choose in 60 seconds

Related reading

What makes a bookmark manager an 'AI bookmark manager'?

Is there a free AI bookmark manager that actually works?

What's the difference between Readwise Reader and Burn 451?

Which AI bookmark manager works with ChatGPT or Claude?

Can I export my bookmarks if I want to switch tools later?

Is a self-hosted AI bookmark manager worth the setup?

How does Mymind's AI work compared to the others?

Which tool should a developer pick?

I Built a Read-Later App. Karpathy Described My Data Model. (with MCP + Claude Code)

What Karpathy said

The accidental reference implementation

Demo: Tiago Forte vault in Claude Project

Where no-RAG breaks

What this means for you