webref/docs

Research a question

webref delegates your question across multiple sources — docs, forums, blog posts, and technical articles — and returns one cited article. The same information that other tools dump as 16k+ tokens of noise, webref delivers as prose with every fact sourced, verbatim quotes checked against their pages, and an explicit list of what the web did not establish. Nothing useful gets cut, it's just expressed more clearly.

You can ask questions, pass URLs, or mix both. The planner figures out what to search and what to read.

Usage

bash
webref "your question here"

Pass a URL to read and synthesize a specific page:

bash
webref "summarize https://example.com/article"

Mix questions with URLs to combine web search and targeted page reads:

bash
webref "compare https://lib-a.dev/docs and https://lib-b.dev/docs for auth support"

By default, webref shows a minimal live progress view in a real terminal: generated searches, source progress, then the final answer.

bash
webref "Docker networking explained"

When piped, webref switches to one additive plain-text transcript:

bash
# Save to file
webref "GraphQL best practices" > notes.md

# Copy to clipboard (macOS)
webref "JWT token structure" | pbcopy

Result anatomy

Every research result has the same parts.

The witness line under the title says in one sentence what the sources agree on and where they part ways.

The as-of line dates the research and counts the sources: how many were read in full, how many were seen only as search snippets, and what kinds of pages they were.

The article is prose that names its source in the sentence that states each fact. It is the same information reorganized to remove redundancy across sources, not a summary that loses detail.

Quote cards sit under the prose they support: a verbatim quote, a link to its page, and a label that opens with a seal word saying how much weight the source carries (Official, Study, Evaluator, Independent, or a caveat: Sells this, Forum post, Unclear source, Outdated), then the source type (Official docs, Expert, News, Vendor, Forum), the page's date with its age ("Apr 2026, 5 months old", or "likely outdated" when the cataloger judged it stale for the question), the cataloger's note, and "Snippet only" when the page was never retrieved. Every quote is checked mechanically against the page it cites. One that could not be found there ends with N words not on page, on the page and in the markdown alike.

Not established lists what the web did not answer. Each entry is concrete enough to write a follow-up from. When the sources covered the question, the article says so in one line.

Tips for better queries

Write queries with clear intent, not keyword lists. The synthesizer needs to understand what you want to know, not just which terms to match.

bash
# Good - clear intent
webref "how to handle file uploads in Next.js 14 app router"

# Less good - keyword soup
webref "next.js file upload handler api route multipart"

Be specific about what you're trying to learn. Include version numbers, frameworks, or specific use cases when relevant.

bash
webref "how to set up TypeScript path aliases in Vite"
webref "Drizzle vs Prisma performance and DX tradeoffs"

Ask natural questions for comparison or evaluation.

bash
webref "What's the difference between useMemo and useCallback?"
webref "better-auth pricing and license model"

Split multi-topic queries into separate research calls. If you need both pricing info and setup instructions, run two research calls. Each call should have a single clear intent.

Credits

A research costs one credit, and so does each follow-up. Credits are only deducted for successful results — if something goes wrong, you're not charged.

Check your balance anytime on your dashboard.