I let the LLM answer with UI components instead of text: building Siftlume

Most AI summarizers answer with the same thing: another wall of text. You started with a long page and you end up with a shorter long page.

I wanted something I could scan in seconds, so I built Siftlume, a free, open-source (MIT) Chrome extension where the model answers with UI components instead of paragraphs: a one-line TL;DR, key figures, takeaways, charts, timelines, diagrams and checklists, chosen to fit what you are reading.

There is no Siftlume server. You bring your own LLM key (or run a small model in the browser), and requests go straight from your browser to the provider you pick.

Install it from the Chrome Web Store or read the source on GitHub.

The idea: the model picks components, not markup

Instead of asking the model to write prose or raw HTML, I give it a fixed library of UI components and let it compose a small program from them. The pipeline has five steps:

1. Extract. Readability and Turndown for HTML, pdf.js for PDFs, Papa Parse for CSV, schema.org JSON-LD for recipes, products, jobs and events, captions for YouTube, the GitHub API for pull requests, and Google's own export for Docs, Sheets and Slides.
2. Prompt. The system prompt is generated from a library of OpenUI components, so the model knows exactly which blocks exist: charts, timelines, verdicts, argument maps, SWOT, code review findings and more.
3. Stream. Output streams through the AI SDK, straight from the browser to the provider.
4. Validate and repair. The output is parsed as OpenUI Lang. If it does not parse, or a diagram will not render, the errors go back to the model once.
5. Render. React components render the result in the side panel of the tab you are reading, or in a full-page tab.

Why a fixed component list helps

Letting the model write HTML is flexible, but it is hard to trust and hard to style. A closed set of components gives you three things:

• Predictable output. Every block has a known shape, so a bad response fails validation instead of breaking the page.
• Consistent design. The components carry the look, so the model cannot invent a layout that clashes with the rest of the UI.
• A cheap repair loop. Because the output is parsed, you can hand the parser's errors back to the model and usually get a valid answer on the second try.

The catch is that the component list and the prompt that describes it have to ship together. If you change one without the other, the model starts emitting blocks that no longer exist.

Pages are read their own way

A generic "summarize this page" prompt gives generic results, so the extraction step depends on the source:

• YouTube is summarized from the captions, and quotes jump the video to that moment.
• GitHub pull requests are read through the API: what changed and why, grouped by area, with review state and CI checks. A Critique mode produces review findings by severity with links into the diff.
• Recipes, products, jobs and events come from schema.org data, so you get ingredients with a servings stepper, a price and rating breakdown, or an "Add to calendar" card.

There are four ways to read the same source: Summary for the gist, Explain to understand it, Critique to judge it, and Action for what to do next. Follow-up questions are answered only from the source, and quotes scroll to the exact passage on the page.

Privacy and cost

API keys stay in the browser. Page content goes only to the provider you configured, and only when you ask for a summary. For no key at all, you can download a small model once and run it on your own graphics chip. It supports OpenAI, Anthropic, Gemini, OpenRouter, Groq, DeepSeek, Mistral, xAI, Together, Ollama, LM Studio and any OpenAI-compatible endpoint.

What I am still learning

The part I am least sure about is how well the model chooses blocks on unusual pages. I would love to hear which blocks you find useful and which feel like noise, and what kinds of pages break it.

If you try it, the repo is here: github.com/tamnt1707/siftlume. Issues and PRs are welcome.