How to Build a “Read with AI” Sidebar for Any Blog Article

A selection sidebar, inline highlight annotations, and a full-page chatbot all answer "help we understand this content," but they scope context differently and cost differently per question. A selection sidebar triggers on a text highlight and sends only that highlight plus its enclosing section — small, cheap, and precise, but it only answers questions about text the reader already selected. Inline annotations (margin notes generated ahead of time for known-tricky passages) cost nothing per reader because they're precomputed once and served as static content, but they can't answer a question nobody anticipated. A full-page chatbot can answer anything about the whole article, at the cost of sending much more context per turn and a UI that competes with the article for attention.

For a blog where the goal is "clarify the paragraph I'm stuck on," the selection sidebar is the right default: it matches the reader's actual mental state (I don't understand this, not the whole page) and keeps the context small enough to answer fast and cheaply. The build below targets that pattern, with a callout on how to extend it toward the other two.

The request path has four hops. The reader selects text inside a section with id="atomic-acquire" (any existing article section anchor works — see Preventing cache stampede with Redis locks for a real section built this way). A selectionchange listener on the client captures the selected string and walks up the DOM to find the nearest ancestor with a data-section-id, giving you a section id, not just raw text — that id is what lets the API route pull the actual section body server-side instead of trusting whatever the client sends.

The client posts { sectionId, selectedText, question } to an API route. The route looks up the section's canonical body from the same BlogPost data the page rendered from — never the client's copy of the DOM — builds a prompt of (section body, selected text, question), and calls the model with streaming enabled. The response streams back over the same HTTP connection as Server-Sent Events, and the sidebar renders tokens as they arrive rather than waiting for the full answer.

The client side needs two pieces: a listener that turns a browser selection into { sectionId, selectedText }, and a fetch that reads a streamed response body incrementally instead of awaiting response.json(). The API route needs to reject any sectionId it doesn't recognize and cap the section body length before it ever reaches the model call.

The naive first version of this feature often skips section scoping entirely and sends the full rendered article — every section's body concatenated — as context on every question, on the theory that "more context can only help." On a 2,000-word article this adds thousands of prompt tokens per question, most of them irrelevant to what the reader selected. Cost scales with article length instead of question complexity, latency grows because the model has to attend across a much larger context, and answer quality often gets worse — the model has to figure out which of ten unrelated sections the question is actually about, and sometimes answers the wrong one.

The fix is exactly the section-scoping from the previous step, but the failure is worth reproducing once so the fix isn't cargo-culted: remove the sectionId filter, concatenate every section's body into one context string, and ask a question that only makes sense for one specific section. Watch the answer quality and latency both degrade as article length grows, then restore scoping and confirm both recover.

Add precomputed inline annotations alongside the sidebar once you notice the same three or four questions repeating in sidebar logs for a given article — those are worth answering once at publish time instead of re-generating per reader. Add a full-page chatbot only when readers are asking questions that span multiple sections or reference material outside the current article ("how does this compare to the Kafka article?") — a selection sidebar's scoped context can't answer that class of question well, because the answer legitimately needs more than one section.

For most technical blogs, ship the selection sidebar first: it is the cheapest to operate, the easiest to reason about for trust boundaries, and matches the actual reader intent ("explain this") most of the time. Treat annotations and a chatbot as additive features once usage data shows the sidebar's scope is the limiting factor, not the starting point.