APIs keep moving after a model stops reading. lurq reads the exports your installed version actually ships and hands them to your agent before it writes a line.
What kind of builder are you? Public GitHub only, no sign-in.
When a request touches packages, lurq resolves the versions from the registry, analyzing compatibility, and reports the clashes. We do this before anything is written to your project.
Upgrade me to TypeScript 7.
I'll bump typescript to 7 and leave the lint setup as it is.
@typescript-eslint/eslint-plugin needs peer typescript@>=4.8.4 <6.1.0, but the stack uses typescript@7.0.2
Left alone, npm refuses the install.
Holding typescript at >=4.8.4 <6.1.0 until the plugin supports 7.0.2.
Upgrading the compiler should be an obvious move for models. The problem is nothing in the editor knows if the other tools have caught up.
One call resolves the versions each package currently supports, with retrieved info refreshed on published upgrades.
@typescript-eslint/eslint-plugin still declares support for >=4.8.4 <6.1.0, so npm refuses to put it next to 7.0.2. You get the version compatible with your stack instead of wasting thirty minutes figuring out why.
A new major is where the old API breaks. We record the day each model stopped reading and count what the registry shipped after it. The code comes back confident, and written for a version that has moved on.
Claude Opus 5 stopped learning in may 2026.
Anthropic’s published figure7%
of the packages it knew have broken since may 2026
2,892
shipped a new major upgrade after may 2026
40,223
packages the index already tracked by then
| Rank | Model believes | Actually on | ||||
|---|---|---|---|---|---|---|
| 01 | ansi-styles | 6.2.3 | 7.0.0 | +1 | 2 moshipped jul 2026, wrong for 2 months | 685M |
| 02 | supports-color | 10.2.2 | 11.0.0 | +1 | 2 moshipped jul 2026, wrong for 2 months | 501M |
| 03 | chalk | 5.6.2 | 6.0.0 | +1 | 2 moshipped jul 2026, wrong for 2 months | 385M |
| 04 | commander | 14.0.3 | 15.0.0 | +1 | 4 moshipped may 2026, wrong for 4 months | 371M |
| 05 | @types/node | 25.6.0 | 26.6.1 | +1 | 3 moshipped jun 2026, wrong for 3 months | 317M |
| 06 | js-yaml | 4.1.1 | 5.4.1 | +1 | 3 moshipped jun 2026, wrong for 3 months | 298M |
| 07 | @babel/code-frame | 7.29.0 | 8.0.0 | +1 | 3 moshipped jun 2026, wrong for 3 months | 252M |
| 08 | which | 6.0.1 | 7.0.0 | +1 | 5 moshipped may 2026, wrong for 5 months | 243M |
Read from lurq's own index on 22 Sept 2026. The may 2026 cutoff is Anthropic's published figure for Claude Opus 5. Totals count only packages the index already tracked by that date, and every number here is measured against it.
usage · resolve_surface · diff_surface
Exported symbols and signatures, read out of the version's own shipped .d.ts. We hand the delta to your model: what moved, what went, what is new.
diff_surface
{
"package": "zod",
"fromVersion": "3.23.8",
"toVersion": "4.1.12"
}Symbols removed, added and changed between the two, read from shipped JavaScript.
verify · evaluate
Downloads, release cadence, open advisories, deprecation flags. We catch the package that does not exist: a name the model produced fluently, spelled the way a real one would be spelled.
verify
{
"package": "reqeusts"
}Comes back with exists: false, and the real name it is one edit away from.
compat
Every pair in the set, graded against declared peer ranges and co-installs already in the compatibility matrix.
compat
{
"packages": ["next", "react", "react-dom"],
"versions": { "react": "19.2.0" }
}Every pair graded against declared peer ranges and co-installs already seen.
compat · usage
We check against the runtime you deploy on. Declared engines can range, so stacks can resolve perfectly and still die in production because one node doesn't support the Node you ship.
usage
{
"package": "sharp",
"version": "0.34.4"
}Returns the version's declared engines, so its Node floor is read rather than assumed.
Existence and version ranges come straight off the registry. Maintenance is a composite: downloads, release cadence, open issues, the OpenSSF Scorecard. Risk is OSV advisories plus the deprecation flags. The API surface is the odd one out, parsed from each package's shipped types.
Install once, and it finds what you already have.
lurq setup
signed in · key received from the browser
key validated · saved to ~/.lurq/config.json
detected Claude Code, Cursor, VS Code
wrote 3 keyed MCP entries + 2 skill files
no database credentials written
restart your agent to finish
Setup opens a browser, and signing in is the whole interaction: the key is handed back to the terminal on its own, with nothing to copy. Then it works out which assistants are installed and writes both a keyed MCP entry and a skill file for each. Your key is stored for the CLI too, so there is no second command and nothing to export.
The tools your editor gets.
lurq setup --agent claude-code
connected · https://api.lurq.run/mcp
tools: recommend evaluate compare verify compat
usage resolve_surface diff_surface
plan diagram capabilities report_outcome
every response carries a dataAsOf timestamp
MCP is the standard way an editor hands a model a new tool. Register lurq once and everything in that editor can reach it. Setup also drops a skill file, so the model reaches for it without being asked.
For nerds, run in your terminal.
lurq verify jsonwebtoken
lurq compare date-fns dayjs moment
lurq compat next react react-dom
lurq usage zod --known 3.22.4
--json on any of them, for a script to read
Every capability is a subcommand, reading the same hosted index as your editor. No database, no API key to pass: setup stored it once.
Run the server behind your personal key.
lurq serve-http --port 8080
listening on :8080
POST /mcp api key required
GET /healthz
per-ip and per-key rate limits on by default
The same MCP server over HTTP, with API-key auth and rate limits. For a platform that needs the endpoint inside its own perimeter.
Pricing
The command line and the installable skill cost nothing and always will. What the paid plans buy is the hosted index: the compatibility graph, the version surfaces, and the crawl that keeps both current.
$0/mo
1,000 hosted calls a month
Past the limit: 20 calls a day until the month turns
Enough to find out whether the index is telling the truth.
$15/mo
10,000 hosted calls a month
Past the limit: 20 calls a day until the month turns
For one developer who runs it on every install.
Everything in Free, plus
$25/seat/mo
15,000 calls a month per seat, pooled · 3-seat minimum
Past the pool: $8 per 1,000 calls, up to 2x the pool
For a team whose agents answer to one policy.
Everything in Pro, plus
from$1,000/mo
Uncapped hosted calls
For a company that needs the graph under its own controls.
Everything in Team, plus
A call is one tool request against the hosted index. The CLI run locally against your own database is unmetered. When a plan's monthly calls run out, it keeps 20 calls a day instead of stopping, until the month turns (UTC). Monthly Team is the exception: calls past the pool are billed at $8 per 1,000, up to 2x the pool, and the daily grace applies after that. Yearly Team has no overage. Business is uncapped. The free plan never asks for a card.
Something not covered here? Talk to us.
lurq is a dynamic index of JS/TS packages that your coding agent checks before install. We score packages from public signals and verify in sandboxes where necessary. Your agent asks lurq, then writes the code.
A model remembers an API as it was on the day training stopped. lurq reads the version in your project: its exports, its peer ranges and its advisories, each with the date it was read. The model still writes the code. It writes it against the right version.
Claude Code, Cursor, Windsurf, VS Code / Copilot, Codex, Gemini CLI, Antigravity, Kiro, and anything else that can use a CLI or MCP connection. One install step writes the config file each of those already reads.
Three things, honestly. The API surface index covers 39944 package versions so far, so for most packages the exact-signature answer is not there yet. Sandbox verification runs on a queue rather than on demand, which means a brand new pair may not have been executed when you ask. And the whole index is JS/TS only, with no plans for other ecosystems until this one is solid.
lurq reads metadata: downloads, release dates, advisories. But, lurq also returns info from sandboxed trials. Did the install succeed? Does it import? Do these two versions coexist? We outrace the changelog and the training data.
Because six individually healthy packages can still refuse to install together. Peer ranges conflict, engines disagree, transitive versions collide. lurq mines compatibility from co-installs, so a stack can hold together rather than break later from a simple upgrade.
Every answer carries a dataAsOf timestamp, so you can see exactly how old the reading is.
Yes, free to get started. Create an account, generate an API key, and you get the CLI, the agent connection, and the installable skill with a monthly allowance of hosted calls.
A bug, a package we have scored wrong, a stack you want a second opinion on. There is no ticket queue. It lands in an inbox one of us reads.