steipete/summarize: a CLI and browser side panel that turns links, files and media into clean text

The gap summarize fills: extraction, not just summarization

Most tools called summarizers assume you already have text. The hard part is usually upstream of that: pulling readable content out of a page full of navigation and scripts, getting a transcript out of a YouTube URL, or reading a PDF without a separate conversion step. Summarize bundles those paths behind one command so the input can be a URL, a file, a video or a podcast episode rather than a string you pasted yourself.

The audience is narrow and specific. It is aimed at people who live in a terminal and already have a model provider or an authenticated coding CLI available on the same machine. The README's quick start makes that explicit: extraction works with no API key at all, while a model-generated summary requires configuring a supported provider or pointing at a coding CLI. If you have neither, the tool still does something useful, just not the thing its name promises.

How the routing works across pages, files, YouTube and slides

The README presents the design as a routing table rather than a pipeline diagram, and the ordering matters. Web pages go through Readability extraction, with optional Markdown and Firecrawl fallbacks. Files are handled by file-aware extraction, with model attachments where the provider supports them. YouTube and podcasts are the interesting case: the tool prefers published transcripts first, and only falls back to configured transcription when none exist. That ordering is the right default, because a published transcript is free and fast, and transcription is neither.

Audio and video route to local or cloud transcription, with optional speaker labels. Video slides take a different path again: scene-based frames, optional OCR, and timestamped output. The repository layout backs this up. There is a packages/core directory built separately from the CLI, and the published package.json exposes three entry points: the root, ./content and ./prompts. That split is deliberate. Content extraction and prompt construction are usable without the CLI dependency surface, which is why the README points at @steipete/summarize-core for programmatic work.

The practical consequence is that a single command can silently take several different paths, and which one it takes depends on what you have installed. The README states that native ffmpeg, yt-dlp and tesseract extend codec, YouTube slide and OCR support, and that a bundled WebAssembly FFmpeg path covers common media without a native install. So the tool degrades rather than fails, but it degrades quietly, and the fallback path is not documented as producing identical output.

Installing summarize and getting a first extraction

The fastest way to confirm the tool runs is the one-off invocation from the README, which does not install anything permanently:

npx -y @steipete/summarize --version

For regular use, npm or Homebrew both work. The npm package requires Node.js 24 or newer, and Homebrew/core plus the macOS archives on GitHub Releases provide standalone builds that avoid the Node requirement:

npm install --global @steipete/summarize

The first genuinely useful command needs no API key. Point it at a page and ask for extraction only:

summarize "https://example.com" --extract --plain

With --extract and --plain you should get readable body text with no model involvement. The README's own example output for that URL is the IANA documentation blurb and a link to iana.org, which is a good sanity check: if you see navigation chrome or script fragments, the extraction path is not working as intended.

To get an actual summary, add a provider. The README shows the coding-CLI route, which reuses credentials you already have rather than asking for an API key:

summarize "https://example.com" --cli codex

The default auto model chooses among configured providers. Before troubleshooting anything, run the status command, which the README says inspects the effective setup without exposing keys:

summarize status

That output is the first thing to read when a summary fails, because it tells you which providers were actually detected rather than which ones you intended to configure.

Configuration lives in one JSON file, and flags win

Configuration sits at ~/.summarize/config.json, and the README states plainly that command-line flags take precedence. Model IDs use provider/model names, and the supported set is wider than a single vendor: configured API providers, OpenAI-compatible endpoints, Ollama, OpenRouter free models, and authenticated coding CLIs including Codex, Claude, Gemini, OpenClaw and GitHub Copilot.

That breadth is the main reason to consider this over a single-provider wrapper, but it also means the auto selection rules are doing real work. The README links a separate document for automatic selection, which is a signal that the logic is nontrivial enough to need its own page. If you care which model handles a given input, do not assume auto will pick the one you would have picked. Set it explicitly.

The browser extension follows the same pattern with one extra step. Direct mode runs without a companion service, using Chrome capabilities for local transcription and slide extraction. The optional daemon adds CLI model backends, native media tools, OCR, shared caches and Firefox media support. Pairing is done by copying the token the extension displays and running:

summarize daemon install --token <TOKEN>

So the extension is not a separate product with its own configuration. It is a second surface over the same config file and the same provider list.

Where summarize is the wrong tool

The clearest limitation is the Node.js 24 floor on the npm package. That is a current-generation requirement, and on a machine pinned to an older LTS release the npm install path is closed. The Homebrew and macOS archive builds exist precisely because of this, but they are described as macOS archives, so the escape hatch is not universal.

Media quality is conditional in a way that is easy to miss. The README lists ffmpeg, yt-dlp and tesseract as the tools that extend codec support, YouTube slide extraction and OCR. Without them, the bundled WebAssembly FFmpeg path covers common media, but the README does not claim it covers everything the native tools do. If your work depends on slide OCR or unusual codecs, the WebAssembly fallback is not a substitute, and nothing in the documentation tells you in advance which inputs will fall through.

The third limitation is about what a summary is. Summarize produces text from a model; it does not verify that text against the source. For a podcast episode or a long video, the transcript may itself be machine-generated when no published transcript exists, so errors can compound: transcription mistakes feed into summarization mistakes. For anything where accuracy matters, use --extract and read the text rather than trusting the summary layer.

Finally, the Chrome extension in direct mode is deliberately less capable than the daemon-backed setup. If you install the extension expecting CLI-grade model backends and native media support without the daemon, you will not get them.

How it differs from calling an LLM API directly

The honest alternative is a script that fetches a URL, runs a readability library, and posts the text to a model API. That approach is not much code, and it gives you full control over chunking, prompt and provider.

The difference is the input surface. A hand-rolled script handles one input type well, usually HTML. Summarize's routing table covers pages, PDFs, images, text files, YouTube, podcasts, audio, video and video slides, and it encodes a preference order for transcripts that you would otherwise have to discover yourself. If your inputs are always web pages, the script is simpler and has fewer moving parts. If your inputs are mixed, the routing is the product.

The second difference is credential reuse. The --cli path lets an authenticated coding CLI supply the model, so you do not need to provision a separate API key or manage one more secret. For individual developers that is a real convenience; for a team with centralized key management it is the opposite, because model access becomes tied to whoever is logged in on that machine.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-10. The release history in that window is dense: v0.21.9 on 2026-08-09, v0.21.10 on 2026-08-10, and v0.21.11 later the same day. That is a fast release cadence, and while the package.json version reads 0.22.0, the pre-1.0 numbering is the relevant fact. Anything below 1.0 signals that flags and config keys can move between releases, so pinning a version is reasonable if you script against it.

Upgrade cost concentrates in three places. The config schema at ~/.summarize/config.json, the model ID format of provider/model, and the flags documented in the command reference. Because flags override config, a flag rename breaks automation silently in the sense that the command still runs, just not with the behaviour you expected. The --json output is described as a stable automation envelope, which is the surface to build against if you need something more durable than stdout text.

The licence is MIT, which permits commercial and closed-source use and requires preserving the copyright notice and licence text. That is the extent of what can be said here; the actual obligations depend on how you redistribute it, and that is a question for your own legal review rather than something to settle from a README.

Editorial conclusion

Adopt it if you already have a model provider configured or an authenticated coding CLI on the machine, and you want one command that handles a URL, a PDF and a YouTube link without writing extraction code. Skip it if you need a hosted service with no local setup, or if your environment cannot run Node.js 24. Before committing, run summarize status to see which providers and media tools it actually resolved, and check whether ffmpeg, yt-dlp and tesseract are present, because the quality of YouTube and slide output depends on them.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes