DATASTAND

The latest npm security advisories, normalized for machines: severity, CVSS 3.x and 4.0 (score and vector, each null when upstream has not scored that version), EPSS (`epss_score`, the probability of exploitation in the next 30 days, and `epss_percentile`, both null where the advisory has no CVE or no score) so you can rank by how likely an attack is and not only how bad, affected packages, vulnerable ranges, patched versions, a per-row `packages` list — the distinct package names the advisory touches, so matching a build against your lockfile is one set lookup per row instead of walking every vulnerable range — and a per-row `fix_status` (patched, partial or unpatched) so the advisories no upgrade can fix stand out without walking every affected package, and a per-row `source_repo` — the advisory's upstream repository as a plain http(s) URL, null where GitHub has none recorded — so you can join advisories to a repo without cleaning git+/.git spellings. Merged from two upstream orderings — the 100 most recently published advisories and the 100 most recently REVISED — so a CVSS score finally assigned, or a vulnerable range widened to include the version you run, reaches you instead of being invisible because the advisory was published weeks ago. Derived from the GitHub Advisory Database (CC-BY 4.0, attributed). Add ?since= to get only the advisories published or revised since your last fetch; if nothing has changed you are not charged, so polling for new vulnerabilities costs nothing until there are some. Every build carries a `coverage` block stating what it can and cannot answer: `delta_complete_since` is the point back to which a ?since= delta is complete — ask for one earlier and it is refused for free rather than served short — and `upstream_unchanged_since` says how long upstream has been serving the same newest advisory, because generated_at is the age of our fetch and not the age of the content. That block is on this free listing (info.output.example.coverage) at the current build's own figures, so you can check the bound against your polling interval before you pay for anything. The same block's `mix` counts what the build holds — rows per severity and per fix_status, how many carry an EPSS score, and `unpatched_critical` — so you can see whether a build has anything you would act on before buying it.

A ranked, tagged digest of the last 24h of high-signal Hacker News stories, scored by engagement, with links, the source domain and discussion volume. Each row also carries points_per_hour — points gained per hour since posting, as of the build — so you can sort for what is rising now rather than what has simply had longest to collect votes. Each row also says what kind of post it is — show_hn, ask_hn, launch_hn, tell_hn or story — with a kind_counts tally, so the day's Show HN tool launches are one filter away instead of a title regex. Each row carries hn_id, Hacker News' integer item id, so builds and ?since= deltas merge and dedupe on one key. Each row names its author, the submitter's Hacker News username, so you can follow the accounts that launch tools or pick out a company's own posts. Every row is classified across eleven topics — ai, devtools, data, infra, security, web, hardware, plus policy, business, science, culture — and carries a developer_relevant flag, so you can keep the engineering stories and drop the front page's politics, science and obituaries, which are about half of a typical day. Built from public Hacker News data. Add ?since= to get only the stories that appeared since your last fetch, with the tag counts recomputed over that slice; an empty delta is not charged. Every build carries a `coverage` block stating the window it actually swept, the points threshold it was built with, and whether upstream's page came back full — and `delta_complete_since` is the point back to which a ?since= delta is complete. This is a 24h SKU, so ask for anything older and it is refused for free rather than answered short. The block also says outright what a created_at delta cannot see: the threshold is applied at fetch time, so a story that crosses it days after it was posted arrives with its original timestamp and a delta skips it. That block is on this free listing (info.output.example.coverage) at the current build's own figures, so you can check the bound against your polling interval before you pay for anything.

Daily market intelligence on the x402 Bazaar: index size and composition by network/scheme, USDC price distribution percentiles, real usage stats (share of resources with 30-day calls, top-20 by calls), new-listing rate, churn-risk aging, and domain concentration. Every build also carries a `changes` block saying what MOVED since the build before it — resources, unique domains, 30-day calls, each price percentile and bucket, every network that gained or lost, and which domains entered, left or shifted within the top 20 — each figure as from/to/delta and stamped with `window_hours`, the actual time between the two builds, because a delta without its window is not a fact. Every number there is recomputable from the two published builds, and a null means the diff was not computed and says why; it never means nothing moved. Aggregated from the public CDP discovery API. `sweep.truncated` says whether the read reached the end of the index (alongside `index_reported_total` when the API states one), so the resource count is either the whole Bazaar or explicitly flagged as a floor. Rebuilt daily by an autonomous agent. The free catalog (metadata.data.preview) lists every field this report contains with its type, so you can see the exact shape before paying. HOW MUCH moved is free too: `info.output.example.changes` carries this build's own `window_hours` and the count of movements in each section — headline metrics, networks, price buckets, and domains that entered, left or shifted the top 20 — so you can tell a busy build from a quiet one before you pay. What moved is the report.

A verified, machine-readable table of current LLM API pricing (input/output per MTok, cached-input where published) and context windows across Anthropic, OpenAI, Google, xAI and Together. `providers` on this listing carries that coverage as this build counts it — provider and row count, derived from the shipped table rather than from this sentence — so a provider that joins or leaves is visible here before you pay. `fields` on this listing answers the other half of that question — how much of the schema this build actually fills in, counting for every column how many of the shipped rows carry a value, derived off those rows rather than from this sentence. Read it against `count`, and read the free sample row against it: the sample is always the file's first row, so `fields` is what tells you how typical that row is. If you came for one column in particular, check it there first — `context_window_tokens` is the sparse one, because several of the providers named above publish no window on any page we can fetch. Every row is read off the provider's own page on its stated verification date and carries that page's URL; a row the provider stops publishing is dropped, not carried forward, and a context window we could not verify is null rather than guessed — a null means we did not verify it, never that the model lacks one. `sources_fetched_at` records when those pages were actually fetched, so the gap between the fetch and the verification date is auditable rather than asserted. Each curation carries a `changes` block diffing it against the previous published one: rows added, rows dropped (with their last known figures, plus `replaced_by` naming the successor row when the provider renamed the model rather than delisting it), and every movement in price, context window or source URL as from/to — so a returning buyer sees what moved instead of re-reading every unchanged row (`count` on this listing says how many that is on this build). A null there means the diff was not computed and says why; it never means nothing changed. A `sources` block names the whole sweep behind those rows: every provider page CI fetched this week, its HTTP status, whether it could be read, and how many published rows cite that exact URL — counted off the shipped table, not asserted. Read it before reading a dropped row as a delisting: a page that goes unreadable drops its rows for the same reason a delisted model does, and only this block tells the two apart. A readable page that produced no rows says why in its own words, so a provider we cover but cannot parse is distinguishable from one we never looked at. Standard pay-as-you-go rates, with batch/flex/fast-mode tiers noted per row. Where a provider charges more once a prompt passes a stated length, the dearer tier is a machine-readable `long_context` object on that row (`threshold_tokens`, input, output and cached-input rates) rather than prose, so a router can price a long prompt without reading notes. Where a provider has already announced a dated price change (an introductory rate ending, a scheduled doubling), the row carries a `scheduled_price` object (`effective_date` and the rates from that date), so a budget can be priced past the change without reading notes. Re-verified weekly by the operator agent. This table is curated weekly, so the question worth answering before you pay is whether it moved at all — and that answer is free: `info.output.example.changes` carries this build's own `added_count`, `removed_count`, `repriced_count` and the `since` they are measured from. A week of three zeroes means you already have this file; do not buy it. Which models moved, and to what, is what the $0.05 buys.

Every model listed on the OpenRouter marketplace with per-MTok input/output pricing, cached-input rates where published, the cache-write rate beside them where the marketplace bills one (`cache_write_per_mtok_usd`, so an agent can tell whether caching a prefix pays before it caches it), and context windows — several hundred rows, refreshed daily. Every row carries a `vendor` (the model maker as the marketplace spells it, e.g. `anthropic`, `x-ai`, `meta-llama`), so you can filter by maker without parsing model ids. Every row also says whether the model takes tool calls (`supports_tools`, read off the marketplace's own supported parameters; null when it does not say), so an agent can rule out the cheap models it cannot use before comparing price, whether its response can be held to a JSON schema (`supports_structured_outputs`, likewise; plain JSON mode does not count), so an agent that parses the answer as data can filter to models that will keep to its shape, whether it is a thinking model (`supports_reasoning`, likewise), so an agent can price reasoning tokens, which bill as output, or rule them out, and lists what the model accepts as input (`input_modalities`: text, image, file, audio, video, as the marketplace states them; null when it does not say), so an agent holding a screenshot or a PDF can filter to models that will read it, and carries the most tokens one response can return (`max_output_tokens`, the marketplace's own cap; null when it states none, never the context window), so an agent planning a long generation can rule out models that would cut it off. Where the marketplace has scheduled a model's retirement, the row says when (`expiration_date`, YYYY-MM-DD; null when none is scheduled), so a pipeline pinned to a model id hears about it before the route goes dark. Each build carries a `changes` block diffing it against the previous published build: models added, models the marketplace dropped (with their last known figures), and every price, context-window or scheduled-retirement-date movement as from/to — so a daily buyer can see what actually moved instead of re-reading 400 unchanged rows. A null there means the diff was not computed and says why; it never means nothing changed. How much moved is on this free listing: `info.output.example.changes` carries this build's own `added_count`, `removed_count` and `repriced_count` against the `since` they are measured from, so a daily poller can skip a build that did not move without paying to discover it. Which models moved is what you are buying. The breadth companion to our hand-verified llm-pricing table: use this to enumerate what exists and what it costs, use llm-pricing when you need vendor-verified provenance.

Keyword search over the x402 Bazaar discovery index (the ~8,000 most-used resources of the full daily sweep, refreshed daily — `info.output.example.corpus` on this listing carries this build's own `indexed` and `of_total`, so the size of what you are searching is read off the build, not this sentence): find services by text query with price and usage filters, ranked by unique payers. The discovery endpoint itself has no search — this is it. Every match is reachable: `count` is the full number of hits and `offset`/`limit` page through all of them, up to 100 rows per call. A page past the end of the results is refused with a 400 and settles no payment. Priced per row: $0.005 covers the default 20 rows, each further row adds $0.0002, and a full 100-row page costs $0.021. The 402 always quotes the exact price for the `limit` you asked for, before you pay, so a small query is never charged for a large one.

Cost-optimised endpoint selection: name a capability (web search, token safety, enrichment) and get the x402 endpoints that provide it ranked cheapest-first in USDC per call, with 30-day adoption stats alongside each price. Refreshed daily from the Bazaar discovery index. `offset`/`limit` page through the full ranked list (up to 100 rows per call); `cheapest` always names the globally cheapest listing, whichever page you asked for. Read `price_floor_complete` before you read `cheapest`: this endpoint searches the most-used slice of the Bazaar, not all of it, and the slice is cut by adoption — so the listings most likely to undercut the price you are shown are exactly the ones the cut removes. False means a lower price may exist below our line, and `corpus.cutoff.payers_30d` says where that line is; `min_payers` cannot reach under it, and `filters.min_payers_effective` tells you when your value was raised to it. Ask for `min_payers` strictly above the cutoff and the answer is complete for its own bar. The flag, the cutoff and the corpus size are all on the free catalog listing (`info.output.example`) at the current build's own figures, so you can tell what you are buying before you pay for it.

What just launched in the x402 economy: the most recently listed or reindexed Bazaar resources, newest first, with price and adoption stats. Track new competitors, spot fresh capabilities to consume, or watch a category fill up. `offset`/`limit` page through the matches, up to 100 rows per call. Read `window_complete` before you read `count`: this feed draws from a bounded pool of the newest listings, and `listed_at` is the Bazaar's re-index stamp rather than a first-published date, so on a busy index that pool spans minutes rather than days (`corpus.covers_hours` is this build's exact figure). Ask for `days=7` and you will usually get `window_complete: false` and `corpus.covers_since` — the oldest stamp the pool holds, which is the real window your answer covers. That distinction is the difference between "the market was quiet this week" and "this feed only reaches back to `covers_since`", and both the flag and the bound are on the free catalog listing (`info.output.example`) at the current build's own figures, so you can check whether your window is answerable before you pay for it.

Vet an x402 seller before integrating: how many resources the domain lists, its total 30-day call volume, its best-adopted endpoint, and its price range (min/median/max USDC per call), plus its most-used endpoints. Answers 'is this provider real and what do they charge' in one paid call. THE TWO HALVES OF THE ANSWER HAVE DIFFERENT SCOPES AND THE RESPONSE SAYS SO. The aggregates are computed over the whole daily Bazaar sweep, which is why `listed: false` is a real due-diligence result — it means the domain offered nothing anywhere in the sweep, not merely that we declined to index it. The endpoint list is served from the searchable slice (the most-used part of that sweep), so `resources_servable` and `resources_complete` state how much of the domain `top_resources` can reach before you read it, and a seller whose endpoints are all lightly used returns an empty list beside real aggregates rather than a silently short one. `offset`/`limit` page through what is servable (up to 100 rows per call).

Cheapest-model router: send your token workload and get every current LLM ranked by estimated USD cost, with per-MTok prices, cached-input rates, and context windows. Merges the weekly hand-verified llm-pricing table (every figure carrying its official source URL and verification date) with the daily OpenRouter marketplace catalog — 400+ models — and marks each row `operator-verified` or `marketplace-listed`; `verified_only=1` keeps just the first kind. Every ranked model is reachable: `count` is the full number of candidates and `offset`/`limit` page through all of them, up to 100 rows per call, while `cheapest` and `cheapest_verified` always name the global best whichever page you asked for. `min_context` reports how many models it excluded for an unverified (null) context window rather than dropping them silently, and `include_unknown_context=1` ranks them anyway. A page past the end, and a `provider` that names no model, are both refused with a 400 and settle no payment.

curl -i https://datastand.dev/api/data/npm-vuln-digest   # returns 402 + payment requirements
# then retry with an X-PAYMENT header — see x402-fetch (JS) or x402/httpx (Python)

curl -i "https://datastand.dev/api/data/dev-signals?since=2026-08-31T10:12:22Z"

curl -i "https://datastand.dev/api/search/bazaar?q=weather&offset=20&limit=50"

curl -i "https://datastand.dev/api/llm/route?input_tokens=20000&output_tokens=1500&min_context=200000"

0x470a1b647d668d3820add26d70c8371557ff4c6b