Most browser extensions that call an LLM route your text through the developer's backend first. That's how they log usage, rate-limit, upsell. Your highlighted words — the ones you didn't know, the concepts you were embarrassed to Google — pass through a server you don't control before they reach the model.
rabbitholes doesn't do that. When you highlight a word and the tooltip renders, the request goes from your browser directly to api.anthropic.com. There's no intermediary. I don't have a backend. I can't see what you're looking up.
This wasn't a privacy-marketing decision. It was the only architecture that made sense for what the extension actually does: sit on every page you read, all day, and explain things you half-know. The volume and intimacy of that data made a passthrough server feel wrong from the start.
The implementation consequence: you supply your own Anthropic API key, stored in chrome.storage.sync (Chrome's encrypted extension storage, never exposed to page scripts). The Brave Search integration — the globe icon that re-answers your query enriched with live web results — hits api.search.brave.com the same way. Two API keys, two direct connections, zero telemetry.
Manifest V3 enforces some of this by default. Service workers can't maintain long-lived connections the way MV2 background pages could, which pushes the architecture toward stateless per-request calls anyway. The privacy property and the MV3 constraint happened to align.
The tooltip itself renders in a shadow DOM, so it doesn't pollute the host page's styles or scripts. Nothing rabbitholes injects persists after you close the tooltip.
If the direct-API model is a dealbreaker because you don't want to manage API keys, this isn't the right tool. But if you've avoided LLM-powered reading tools because you didn't want a third party indexing your reading habits, the architecture here is different by construction, not by policy.
Top comments (0)