The bookmark graveyard is a content strategy problem, not a productivity one
Every social media operator I know runs the same quiet scam on themselves: they save far more than they ever read. A tactical Reel goes into a “Hooks” collection. A competitor’s LinkedIn teardown gets bookmarked. A paper on recommendation systems gets starred. Six weeks later, none of it has touched a single post, and the creator is back to scrolling for inspiration from scratch. That gap — between what we collect and what we actually publish — is the real bottleneck in modern content operations, and it’s why I paid attention to Opyt, a new tool from maker David Maimon that turns the sources you already trust into a queryable knowledge base inside the AI clients you already use. It’s free, MIT licensed, and it says something uncomfortable about how most of us run research: we treat saving as a substitute for thinking. It isn’t.
Opyt isn’t a social media scheduler, and it isn’t trying to be. But the problem it’s attacking — turning a firehose of followed sources into usable, cited answers — is the same problem every serious creator faces when they sit down to plan a month of content. So let’s look at what it actually does, where it fits against the tools already on your stack, and where I think it falls short.
What Opyt actually solves (and what it doesn’t)
The maker’s own framing is refreshingly honest and worth quoting directly: he kept bookmarking posts on X, subscribing to Substacks, and saving papers he meant to read, and most of them stayed unread. He wanted that material available where he actually works — in Claude. So Opyt ingests the sources you already follow and trust, builds a knowledge base from them, and keeps adding to it as those sources publish. You then query that base from Claude, Cursor, Codex, or any MCP-compatible client.
The key architectural detail is MCP — the Model Context Protocol. If you’ve been living inside ChatGPT and haven’t touched MCP yet, the short version is that it’s an open standard for connecting AI assistants to external data and tools. Opyt rides that standard instead of building its own chat interface, which is a deliberate and, I think, correct bet: creators don’t want another tab. They want their existing assistant to know more.
The maker lists four concrete use cases: catching up on AI news drawn from people you follow plus research and repos Opyt found in the background; checking before you build by searching repos, papers, and posts together; thinking through career decisions using what your sources see growing or slowing; and sharing knowledge bases with a friend so you can search both at once and see whose collection each result came from, with revocable access. Pricing is straightforward — the tool is free and MIT licensed, you can keep your knowledge base local, and you pay only for the AI tools you use plus any OpenRouter usage. There’s no disclosed user count, funding, or team size, and I’m not going to invent one.
Why “hybrid search plus top-k” matters more than it sounds
In the comments, a user named Justin Rockmore asked the sharpest question on the page: what decides the ranking on a query? The maker’s answer — result recall is top-k with hybrid search, then each post in the top-k is opened by the model and injected into the model’s context — is the whole ballgame for anyone who’s been burned by a “smart” retrieval tool.
Here’s why I care. Hybrid search means combining keyword matching with semantic (vector) matching. Pure semantic search is great at finding conceptually related material and terrible at finding the exact phrase a competitor used. Pure keyword search is the reverse. Most creator-facing “AI search your notes” tools quietly pick one and hope you don’t notice. The top-k-then-inject pattern is also a known tradeoff: you get precision because a model reads the retrieved posts, but you burn context window and latency, and recall is capped at whatever k is. If your knowledge base is 400 saved posts and k is 10, you’re seeing 2.5% of your archive per query. That’s fine for “what’s new this week” and potentially frustrating for “find the one contrarian take I saved in March.” The maker didn’t disclose the value of k or how hybrid weighting is tuned, so I’d treat recall as an open question rather than a solved one.
How this differs from the tools already on your stack
Let me be blunt about the comparison set, because “AI knowledge base” is a crowded aisle and most of it is aimed at a different buyer than you.
Notion has AI, and plenty of creators run their entire content calendar there. But Notion’s model is manual curation — you decide what goes in, and the AI answers over what you’ve already organized. Opyt’s pitch is the opposite: ingest continuously from sources you follow, then answer. That’s a real philosophical difference. Notion is a library you build. Opyt wants to be a librarian who keeps shelving.
Readwise and its Reader product are the closest functional cousin — save highlights from articles, newsletters, and books, then resurface them. Readwise’s daily review is genuinely good at spaced repetition. What it doesn’t do is continuously pull from the people you follow on X and blend that with repos and papers into one queryable layer. If your research diet is mostly long-form reading, Readwise is more mature. If it’s mostly timeline-shaped, Opyt’s model fits better.
Then there’s the whole category of AI social tools — Buffer with its AI assistant, Metricool for analytics and scheduling, Later for visual planning. These live downstream of research. They help you publish and measure. Opyt lives upstream: it’s supposed to help you decide what’s worth saying. That’s a cleaner division of labor than most “all-in-one” creator suites pretend, and I’d rather see a tool do one stage of the pipeline well than five stages adequately.
Why short-form creators should care more than B2B ones
If you publish on TikTok or Instagram Reels, your content is fundamentally trend-reactive. The window between a format emerging and it being saturated is measured in days. The operators who win are the ones who notice a pattern across five creators before it becomes obvious — and that’s a synthesis task, not a saving task. A knowledge base that ingests the accounts you follow and lets you ask “what format is showing up repeatedly across these people this week” is directly useful.
LinkedIn and X creators writing longer-form analysis have a slower clock. Their research is often primary — original data, interviews, first-hand experience — which no ingestion tool can manufacture. For them, Opyt is a convenience, not a lever. My take: the closer your content is to commentary on other people’s output, the more this class of tool changes your output. The closer it is to original reporting, the less it matters.
The sharing feature is the sleeper
The most under-discussed item in the launch post is knowledge base sharing — give a collaborator access, search both collections with one question, see which collection each result came from, revoke whenever. For solo creators this is a curiosity. For anyone running a content team or a two-person newsletter, it’s a genuine workflow. Research silos are one of the most expensive invisible costs in small content operations: the person who reads the industry newsletters and the person who writes the posts are often different people, and the handoff is a Slack message with three links. A shared, queryable, attributed knowledge base is a better handoff. I’d bet the maker undersold this.
What social media operators can steal from this, regardless of whether they adopt it
Even if you never install Opyt, the design choices here are worth copying into your own workflow. Three of them stand out.
Separate collection from synthesis. The reason bookmark graveyards exist is that saving feels productive and reading feels like work. Any workflow that puts a synthesis step between the two — even a weekly 20-minute “ask my archive a question” ritual — beats a bigger pile. The maker’s own framing that the hard part is “what comes back, not what goes in” is the correct diagnosis, and it applies whether your archive is in Opyt, Notion, or a folder of screenshots.
Cite your sources in the output, not just the input. The sharing feature’s attribution — seeing which collection a result came from — is a small UX decision with a big trust implication. When you use AI to draft a post, you should be able to trace every claim back to the source that produced it. If your current AI writing workflow can’t do that, you’re one hallucinated statistic away from a credibility problem in your comments section.
Keep the data portable and local where you can. Free, MIT licensed, local-first, no new app to open — that combination is rare and worth rewarding. A lot of creator tools lock your research into a proprietary format specifically so you can’t leave. Open source and MCP compatibility mean the knowledge base is yours and the interface is swappable. I’d weight that heavily when choosing any tool that sits between you and your own research.
Where the math breaks
Here’s the honest limitation. Retrieval quality is capped by ingestion quality. If you follow 200 accounts and half of them post engagement bait, your knowledge base is half engagement bait, and the model will confidently synthesize garbage. Opyt doesn’t fix your information diet; it just makes the consequences of a bad one more visible and faster. There’s also a real risk of homogenization: if every creator ingests the same 50 thought leaders and asks the same questions, the outputs converge. The tool that helps you find “what’s new” can just as easily help you produce “what everyone already said.” Your differentiation has to come from somewhere the ingestion can’t reach — your own experience, your own data, your own weird taste.
Where I think it falls short
The launch page is thin on specifics, and I’d rather flag the gaps than paper over them.
There’s no disclosed detail on which platforms are supported for ingestion, how often sources refresh, or how the tool handles the X API — which, as anyone who’s built on it knows, has rate limits and access tiers that break naive ingestion pipelines. If Opyt is pulling from X reliably, that’s a meaningful engineering achievement and the maker should say so. If it’s relying on manual export, that changes the value proposition entirely. Not disclosed.
There’s no published evaluation of retrieval accuracy, no benchmark, no failure-mode documentation. “Hybrid search plus top-k” is a reasonable architecture, but reasonable architectures fail in predictable ways — duplicate near-identical posts crowding out diverse results, recency bias, source-authority bias. I’d want to see how it handles a query where the right answer is an old post from a small account.
Privacy deserves scrutiny too. “You can keep your knowledge base local” is a strong claim, but the AI tools you query it with are not local, and MCP means your retrieved context flows to whichever model you’ve configured. That’s fine — it’s how the whole stack works — but it should be stated plainly rather than implied. If you’re ingesting paid newsletters or private Slack content, read the actual data flow before you point a tool at it.
And the obvious one: this is an early-stage product with a single maker, no disclosed funding, and no visible roadmap. Free and MIT licensed means you’re not risking money, but you are risking time. Treat it as a workflow experiment, not infrastructure.
What I’d watch / test next
Concretely, here’s what I’d do this week if I were evaluating this for a content operation.
First, run a controlled test: pick ten sources you actually follow, ingest them, and ask three questions you already know the answers to. If it surfaces the right posts and cites them correctly, the retrieval works. If it surfaces plausible-sounding posts that aren’t the ones you had in mind, the ranking is off and you’ve learned that in twenty minutes instead of two months.
Second, test the failure mode that matters most for creators — recency versus relevance. Ask “what did these sources say about short-form video in the last 30 days” and then ask “what did they say about it a year ago.” If the answers blur together, you’ve found the boundary of the tool’s usefulness for trend work.
Third, watch the repo. MIT licensed means you can read the code, see the commit cadence, and judge whether this is a weekend project or something with legs. Fourth, check the MCP client support list against whichever assistant you actually pay for — the whole value proposition collapses if your client isn’t compatible.
And fifth, decide in advance what you’ll do with the answers. The failure mode of every research tool is that it becomes another place to save things. The only metric that matters is whether it changes what you publish. If it doesn’t, it’s a nicer graveyard.
