Questions & Answers

Skim is a pay-per-call clean reader API for AI agents. Your agent POSTs a URL to /api/v1/read and gets back agent-ready markdown plus structured metadata, typically in about a second. The agent pays $0.002 per call in USDC on Base using the x402 protocol. No signup, no API keys, no monthly bills.

Autonomous AI agents — research agents, coding agents, RAG pipelines, summarization tools, citation checkers, competitive monitors — anything that needs to read the web without a human managing the billing relationship. Humans can use it too, but the ergonomics are tuned for machines.

Clean markdown of the article body (the same Readability extraction you get from Firefox's reader mode), the raw text version, and structured metadata: title, byline, site name, excerpt, language, published time when available. The full response shape is in the docs.

Yes. Register 1-20 URLs with POST /api/v2/watch ($0.01 once) and you get back a private watch id. Each poll of GET /api/v2/watch/diff?id=... ($0.005) re-reads every page and returns exactly what changed since your last check: lines added and removed, samples of each, and a numericOnly flag that tells you when the only difference is numbers — timestamps, view counters, prices — so a content monitor can skip the noise while a price tracker keeps it.

Nothing runs in the background: pages are only fetched inside a paid poll, so your agent controls the cadence and the cost. Full details in the docs.

Article and content pages — blog posts, news, documentation, wikis, GitHub READMEs, research papers. Skim is built on the same Mozilla Readability core as Firefox's reader mode, so any page with a real main article body extracts cleanly: navigation, ads, sidebars, and boilerplate are stripped and you get tidy markdown plus structured metadata. The public benchmark spans Wikipedia, Paul Graham essays, MDN, the Python docs, arXiv, and Hacker News — not just one kind of site.

For client-rendered or JS-heavy pages, basic /api/v1/read now auto-detects when a page comes back empty because it needs JavaScript and transparently re-renders it in a real browser — at no extra charge. When a page does load but a specific section is JavaScript-injected (most often pricing or spec tables), reach for /api/v1/read/js to force a browser, or /api/v1/extract to pull the exact fields you ask for. PDFs are supported too. Where Skim isn't a good fit: pages that are really interactive apps — dashboards and web apps. If a URL extracts poorly, send it to hello@skim402.com — failing URLs are the most useful feedback we get.

Typical extraction is 5–20ms of jsdom + Readability + turndown after the outbound fetch returns. End-to-end latency is dominated by the target site's response time plus one x402 facilitator verification round trip (usually under 200ms on Base).

For a lot of agents, yes — and for some it's the whole game. A trading or markets agent is only as good as what it just read and how fast it read it; in markets a few milliseconds can be the difference between acting on a headline or an SEC filing first and acting on it late. The same holds for anything time-sensitive: live monitoring, breaking-news summarization, price or availability checks.

Skim does the extraction itself in about 5–20ms and hands back clean, model-ready markdown instead of raw HTML your agent has to wade through. Feeding an LLM tidy markdown rather than a full HTML page also means fewer tokens and less time spent parsing — so the speed advantage compounds downstream, not just at the fetch.

Three differences that matter:

1. Payment model. Skim is pay-per-call over x402, no signup or API key. Jina and Firecrawl both require an account and a subscription.
2. Target customer. Skim is built for autonomous agents calling APIs without a human managing billing. Other readers can be used by agents but assume a human owns the account.
3. Distribution. Skim ships as an MCP server, so Claude / Cursor / any MCP-aware agent can use it natively.

Extraction quality is roughly comparable — most clean readers use the same Readability core. The differentiation is payments and agent-nativeness, not extraction.

If you're happy maintaining your own SSRF defense, redirect handling, content-type sniffing, charset detection, Readability tuning, retry logic, and infrastructure — go for it. Skim packages all of that as a single HTTP call. The point of paying $0.002 is that you don't have to think about any of it.

Stripe requires an account, a card, and a billing relationship. An autonomous agent in 2026 doesn't have a card — it has a wallet. x402 lets the agent pay programmatically with USDC in a single HTTP roundtrip, no signup, no recurring charge to track. If you're a human integrating Skim, x402 looks like extra complexity. If you're an agent, it's the simplest possible model — just call and pay.

Because API keys are friction Skim doesn't need. To use a key-based API, a human first has to sign up, generate the key, and paste it somewhere safe — a step an autonomous agent can't do on its own. Then the key becomes an operational liability: a long-lived secret sitting in a config file or .env, waiting to leak.

Keys that expire are no better. Many providers cap keys at around 90 days for security, so the key silently lapses and your running agent starts getting 401s mid-task — often with no human around to rotate it. Keys that never expire just trade that problem for a permanent secret you can leak. It's a lose-lose.

x402 sidesteps the whole category. There's no key to issue, store, rotate, expire, or leak. Each call carries its own one-time payment authorization signed by the agent's wallet — the wallet is the identity, and the signature is good for exactly one request. Nothing persists between calls.

Honestly — it's early. x402 launched as a Coinbase proposal and has a small but real ecosystem: facilitators on Base, scanners like x402scan, the MCP Registry indexes x402 servers. The bet isn't "x402 has won." The bet is: autonomous agents need pay-per-call infra, x402 is the cleanest open standard in the space, and being the canonical reader on that standard is a defensible early position. If x402 doesn't take off, Skim is a comfortable indie business. If it does, Skim is the plumbing.

Base mainnet by default, using Coinbase's CDP facilitator. The service can also be configured to run on Base Sepolia (testnet) using the public x402.org facilitator for development.

You don't get charged in the first place. The x402-express middleware verifies your signed payment authorization upfront but only settles it on-chain if Skim returns a 2xx response. If extraction fails — bad URL, paywall, JS-only page, PDF parse error — Skim returns 4xx and the facilitator skips settlement entirely. Your USDC stays in your wallet; no refund flow needed.

If settlement itself fails (facilitator unreachable, network blip), the middleware swaps Skim's success response for a 402 and your wallet is still untouched — you can retry. The reverse — settling without a successful response — is prevented by the middleware ordering.

Every successful paid call comes back with an X-Payment-Response response header. That header is your receipt — it's a base64-encoded JSON blob containing the on-chain Base transaction hash for the USDC settlement, the network, the amount, and the payer/payee addresses. Decode it and you can paste the transaction hash into basescan.org for an independent, permanent record of the payment.

Your wallet's transaction history is the parallel record. Every call to Skim shows up as a USDC transfer from your wallet to Skim's receive address on Base. For accounting, exporting your wallet's USDC transfers to that address gives you a complete log of what you spent on Skim across any period — no need to query us at all.

We do not email per-call receipts. There's no email on file because there's no account — your wallet is your identity, and the chain is the receipt.

It's the design of x402 — settlement is on Base and the receive address is necessarily public. The Skim receive address is dedicated to revenue, not personal, swept periodically. If on-chain visibility of revenue is a deal-breaker for your use case, let's talk.

The payment record and the usage record are the same thing, so there's nothing to reconcile. Every successful call is one USDC transfer from your wallet to Skim's receive address on Base, stamped with an amount, a timestamp, and a transaction hash. There is no separate invoice to match against usage — the on-chain ledger is the itemized bill.

To pull a report, export your wallet's USDC transfer history (most wallets do this in a click) or your address's transactions from basescan.org, which offers a CSV download for any address and date range. Filter to Skim's receive address and you have a complete, line-by-line record of what you spent and when — ready to drop into a spreadsheet or hand to an accountant.

Compared with a key-based SaaS, it removes whole steps: no monthly statement to chase down, no estimating overages, no usage-to-bill reconciliation, no subscription you forget to cancel. You only ever paid for calls that returned a 2xx, at $0.002 each, so the numbers always tie out exactly. The savings show up as bookkeeping time you get back and billing surprises you don't get.

Yes — sum the USDC transfers from your wallet to Skim's receive address over the period. A Basescan CSV export or any wallet export gives you the line items; total the amount column and you have your spend for the month, quarter, or year. Because every line is a real settled transaction, the total is audit-ready without anything from us — no statement to request, no account to log into.

Compute on a typical call is ~5–20ms of jsdom + Readability + turndown plus the outbound fetch — cents per thousand at scale. The $0.002 covers that, plus x402 facilitator fees, plus a margin that makes the business viable solo. The protocol supports dynamic pricing so we can revisit as volume grows.

The percentage rate isn't the problem — the average card fee is around 2.35%, and 2.35% of $0.002 is a rounding error. The killer is the fixed per-transaction fee that rides alongside the percentage, typically about $0.30 per charge. On a $0.002 sale that fixed fee is roughly 150x the price of the thing you're selling — you'd lose about $0.30 on every call. That fixed floor is why true micropayments never existed on card rails: the cost to move the money dwarfs the amount being moved.

x402 over USDC on Base has no fixed floor. Settlement costs a fraction of a cent, so a $0.002 charge can actually net $0.002. That's not a discount Skim chooses to offer — it's a different rail that makes the price possible at all.

Only if you run enough volume to clear the break-even. A flat plan bills you for the capacity you might use, not the work you actually do. Say a reader charges $49/month: you don't come out ahead until you're past roughly 24,500 reads that month (at Skim's $0.002 each). Do 2,000 reads and you effectively paid about 2.5 cents per read — more than ten times Skim's price — and in a quiet month you pay the full $49 for almost nothing.

Agent workloads are bursty and unpredictable, which is the worst possible fit for a fixed monthly fee. Usage-based pricing means you pay $0.002 when your agent reads and nothing when it doesn't — no minimum, no idle months, no subscription to remember to cancel. You only ever pay for calls that returned a 2xx.

Yes, because reading and reasoning are two different jobs on two different price curves. Turning raw HTML into clean text is mechanical work — stripping nav bars, ads, and footers. When you fetch a page and pipe it through your own model to clean it, you're paying frontier reasoning rates to do a janitor's job.

Skim is a flat $0.002 per read no matter which model you run. So when you upgrade to the next, pricier frontier model, your reading bill doesn't move — you only pay premium rates for actual thinking, not for cleaning up markup. Cheaper base models lower everyone's costs, but the structural waste of running a general-purpose model over a fixed mechanical task stays. Across millions of reads and every model upgrade, delegating the reading is a saving that compounds.

Yes — automatically. Above 50,000 reads per month, your per-call price scales down on its own: no contract, no signup, no sales call. The discount is applied to the wallet doing the reading, so there is nothing to configure.

Running at a scale beyond that (millions of reads per month)? Email hello@skim402.com and we will make sure the curve fits your volume.

The first call returns 402 with the price — that's your free "preview." There's no free request allowance because there's no account to attach one to. If you want to test without spending, point the MCP client at Base Sepolia and use testnet USDC.

Yes. Skim returns data, not instructions. It is never in the agent's reasoning loop — it's an HTTP endpoint the agent fetches from, like any other API. Nothing Skim returns is interpreted as tool calls or prompts by the agent runtime; the markdown is treated as document content.

The MCP wrapper that bridges Skim into Claude, Cursor, and other agent tools is open source on npm — roughly 200 lines, auditable in five minutes. It does one thing: forwards your URL to /v1/read, pays the 402 challenge with your wallet, returns the markdown. No embedded prompts, no tool instructions, no hidden behavior.

Per request: timestamp, URL fetched, response size, payment transaction id. No request bodies stored, no extracted markdown stored, no user identifiers (there are no users). Operational logs are retained 30 days.

Every fetch resolves DNS first and rejects private, loopback, link-local, multicast, CGNAT, and cloud-metadata address ranges (including 169.254.169.254). Redirects are followed manually with the same checks applied at each hop. See the architecture page for the full reader pipeline.

Skim fetches the URL you send. It does not bypass paywalls, login walls, or anti-bot challenges — if the target server returns an error or a thin landing page, that's what gets extracted. Respect for robots.txt and terms of service is the responsibility of the caller; Skim is infrastructure, not a circumvention tool.

Install the Coinbase Wallet browser extension (Base network is built in), create a new wallet dedicated to agent infrastructure, fund it with a few dollars of USDC on the Base network (not Ethereum — this is the #1 newbie mistake), and paste the private key into your code samples or your agent's MCP config. The same wallet works for both your own testing and your agent's autonomous calls.

You don't need an exchange account to fund it, either — the Coinbase Wallet extension has a built-in "Buy" button that takes a credit card (or debit); just make sure you pick USDC (a stablecoin pegged to the US dollar) on Base. There's no buying and selling cryptocoins on the spot market and no confusing cryptocoin trading pairs — your card converts to USDC automatically, and topping up later works the same way.

Full step-by-step walkthrough — including the "why a dedicated wallet" reasoning and the MCP config snippet — is on the wallet setup page.

For one agent, use one wallet for your whole deterministic-infra stack — not a separate wallet per service. Think of it like a corporate card: you don't issue a new card for every subscription, you keep one with a sensible limit and let the statement show where the money went.

It's simpler to run (one balance to fund and watch), and you don't lose cost visibility — every service has its own receiving address, so the blockchain already tags each payment by who received it, even from a shared wallet. Funding a deliberate runway is also your best runaway protection: load roughly a month of expected volume (for Skim, $0.002/call — so 10 million calls is $20,000) plus a buffer, and that balance caps your worst case across every service at once.

The exception: isolate by risk, not by vendor. Give a dedicated wallet to anything expensive, experimental, or not yet trusted — and give each agent its own wallet if one machine runs several for different customers. Full reasoning is in How to set up your agent's wallet.

Install the MCP server with npx -y skim-mcp, set your Base wallet private key in the MCP config, and the read_url tool will appear in your agent. Full setup is on the For Agents page.

Yes. The docs have curl, JavaScript (x402-fetch), and Python (x402-requests) samples. The MCP server is just a convenience wrapper around the same endpoint.

Point a wallet funded with a dollar or two of USDC on Base at POST /api/v1/read and do a single read of any public URL. One clean response confirms everything at once: your client library installed, it picked up the wallet key from your environment, it signed the payment locally, and the payment settled.

A successful response includes the cleaned markdown plus a base64 X-PAYMENT-RESPONSE header — decode it for the on-chain settlement transaction, which is your proof the read was paid. The docs have copy-paste curl, JavaScript, and Python test scripts. You don't need ETH for gas; x402 settles USDC gaslessly.

The endpoint is fully open at the network level — no origin allowlist — and it answers CORS preflight for standard methods, so a browser fetch succeeds for the request itself.

The real caveat isn't CORS, it's key safety: x402 payments are signed with your wallet's private key, and that key must never ship to front-end code. So in practice you call Skim from a server, worker, or backend function where the key stays private — not directly from the browser.

By design, one call reads one page — that's what keeps the price knowable upfront ($0.002, every time) and the response instant. Skim doesn't currently follow links to other pages for you.

There's a workaround today: if your agent wants more of a site, it just makes more calls — one per URL. What a crawl endpoint would add is Skim discovering the links itself. So when it feels like "I only got the first page," the honest answer is: call the other pages too, which for an agent is trivial. POST /api/v2/read/batch even accepts several URLs in a single request.

One caveat: some sites (live dashboards, data tables) load their "next page" into the same URL with JavaScript rather than linking to a new one. For those, a crawl wouldn't help either — use mode: "js" to read what the page shows after its scripts run.

The MCP wrapper (skim-mcp) is open source on npm. The API server is closed for now — it's a v1 and the protocol is the interesting part, not the implementation. May open-source the server later once it's cleaner.

Karilyn — an ex-creative-director, Berkeley grad, non-engineer. Skim was built solo with a coding agent doing the code and Karilyn doing product, design, distribution, and the shape of the product. It's a genuinely new way to build a company and we're happy to talk about what does and doesn't work.

Real business. The receive wallet, MCP listing, trademark, and roadmap are set up for the long haul. Whether it stays indie-scale or grows depends on x402 adoption — either outcome is fine.

/v1/extract ships at launch — pass a URL plus a JSON Schema, get back typed JSON guaranteed to match. $0.015 per call. Beyond that: a /v1/search endpoint, PDF support on /v1/read, and a streaming variant for large documents. Each will ship behind its own price. Subscribe to the changelog (coming soon) or follow @skim402 on X for updates.

The extractor runs over the cleaned page content, not over the model's training data. If a field isn't on the page, the model leaves it out (or null) instead of filling in what it "knows." So the JSON is a faithful read of the URL you pointed at — verifiable against the source — not a guess from memory. That's the trust contract: agents using /v1/extract can rely on the JSON having come from the page they specified.

Caveat: the model can still misread or misclassify what's on the page (e.g. picking up a sidebar product list as the main product list). That's a normal LLM limitation. If accuracy matters, narrow the schema with description hints on each field — they're respected by the model.

Best: try it from a real agent and tell us what broke. Second best: tell one other builder. Third best: send a URL that Skim fails on — that's the gift that keeps giving.