patent: prior-art search for dev tool ideas across 19 sources
A prior-art search for your code ideas — has this dev tool already been shipped?
At a glance
- What is it?
- patent is a Rust CLI that takes a plain-English dev tool idea, searches package registries plus GitHub and Hacker News, ranks matches by semantic similarity, and returns an Open, Crowded or Saturated verdict. Its value is in what it refuses to claim.
- Who is it for?
- Adopt patent if you are about to start a dev tool and want a fast, local, reproducible first pass over registries you would otherwise grep by hand, and if you are comfortable reading a verdict as scoped evidence rather than a novelty check. Do not adopt it if you need coverage of academic literature, patents proper, or closed-source internal tools, and do not treat exit code 0 as permission to build.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The question patent answers, and the one it refuses to
Before writing a dev tool, most people do a handful of ad hoc searches: a crates.io query, an npm query, a GitHub search, maybe a Hacker News search. The queries are keyword-shaped, so a tool described in different words than yours stays invisible. patent replaces that loop with one command that fans out across 19 sources at once and ranks the results by semantic similarity rather than substring match.
The audience is narrow and specific: developers deciding whether to start a CLI, a library, or a small service, and maintainers doing a sanity check before announcing something as new. It is not a legal tool. The README draws the boundary itself: "Like a patent search, but for code. It finds prior art, yet, never certifies absence." That sentence is the whole design philosophy. patent can show that something exists. It cannot show that nothing does, because it only searched the sources it searched.
That distinction matters more than it first appears. A tool that returns a confident "novel" is worse than useless, because it invites you to skip the manual check. patent instead scopes every verdict to what was actually found, always prints the list of sources checked, and surfaces any selected source that failed as "not reached." A clean Open result is framed as "keep looking before you commit," not as a green light.
How the search pipeline ranks matches
The pipeline has four visible stages. First, source selection: patent picks the registries relevant to the idea, while GitHub and Hacker News are always searched. That selection step is the least documented part of the tool; the README states that it happens but does not describe the rules, so do not assume it will include Homebrew for a library idea or Packagist for something that is obviously not PHP.
Second, semantic ranking. Every match is embedded locally with fastembed and ranked by cosine similarity to your idea. This is the mechanism that makes differently-worded prior art surface, and it is also why the tool needs a bundled ONNX Runtime, which is where the glibc requirement comes from.
Third, a maintenance signal. Where a source publishes a last-updated date, matches untouched for two years or more are flagged. The README is explicit that stale matches are flagged, never demoted, on the reasoning that an abandoned tool is still proof the idea has been built. It also draws a careful line: a match with no date is one no source published a date for, not a stale one. If two sources return the same URL, the surviving row borrows whichever date was found.
Fourth, the verdict. An LLM summarises the results into Open, Crowded or Saturated, and the README states this summary is floored against the similarity data so it can never under-rate a populated space. That floor is the interesting engineering choice: the LLM can raise the severity of a verdict but not lower it below what the embeddings found. It is a guard against a chatty model talking you out of a crowded result.
Installing patent and running a first search
The primary install path is crates.io. On Linux you need build dependencies first. Fedora and RHEL users install openssl-devel and gcc-c++; Ubuntu and Debian users install libssl-dev and g++.
sudo apt install libssl-dev g++
cargo install patentPre-built binaries also exist on the releases page. Either way, the README states that both the prebuilt binaries and a from-source cargo install require glibc 2.38 or newer, which means Ubuntu 22.10+, Debian 13+ or Fedora 38+. The bundled ONNX Runtime that powers local semantic search depends on it. On older distributions such as Ubuntu 22.04 with glibc 2.35, the README's guidance is to build inside a newer toolchain such as a debian:13 or ubuntu:24.04 container rather than on the host.
With the binary installed, the shortest useful invocation is a quoted idea:
patent "interactive cli to kill whatever's on a port"The TUI opens with ranked matches. Arrow keys or j and k scroll, / filters, s cycles the sort between similarity, popularity and name, Enter shows match details including description, popularity, last updated and URL, and o opens the selected URL in a browser. Running patent with no argument launches the same search prompt inside the TUI.
If you do not want to wait on a model, --fast skips the LLM entirely and derives the verdict from similarity scores:
patent "kubernetes log viewer" --fastFor scripting, --json writes to stdout instead of the TUI, and the exit code carries the verdict, which makes it usable as a gate:
patent "react component for infinite scroll" --json | jq .The Ollama dependency and the --fast escape hatch
The default verdict backend is local Ollama, which the README treats as optional because --fast removes the need for it. If you want the LLM verdict, install Ollama from ollama.com and pull the default model:
ollama pull qwen3.5The model name is configurable with --model or the PATENT_MODEL environment variable, and the default is qwen3.5. You can also point patent at any OpenAI-compatible endpoint with --api-base, which the README states must end in /v1, plus --api-key or the PATENT_API_KEY or OPENAI_API_KEY environment variables.
patent "kubernetes log viewer" --api-base https://api.openai.com/v1 --model gpt-4o-miniThe privacy consequence is stated plainly: with --api-base, your search query is sent to that remote server to generate the verdict. The default local Ollama backend and --fast keep everything on your machine. For anyone evaluating an unannounced product idea, that distinction is the difference between a private check and a disclosure, and it is worth deciding deliberately rather than by which command you happen to type.
Settings can also live in a config.toml in the platform config directory: ~/.config/patent/config.toml on Linux, ~/Library/Application Support/patent/config.toml on macOS, and %APPDATA%\patent\config.toml on Windows.
model = "gpt-4o-mini"
api_base = "https://api.openai.com/v1"
api_key = "sk-..."Precedence runs CLI flag, then environment variable, then config file, then built-in default.
Where patent gives you a misleading answer
The most obvious failure mode is coverage. Nineteen sources sounds like a lot until you list what is missing: academic papers, actual patent filings, private repositories, internal company tooling, and anything that only ever shipped as a blog post. A tool that exists solely as a well-known internal script at three large companies will not appear, and patent will report Open. The README's own framing anticipates this, which is why the verdict is scoped to the sources checked rather than to the world.
The second failure mode is the LLM verdict itself. The floor against similarity data prevents under-rating, but nothing in the README describes a corresponding ceiling, so a model that over-reads a sparse result set could push Crowded when the matches are only loosely related. If you want the verdict to be a pure function of the embeddings, --fast is the honest choice, and it is also the fastest.
The third is environmental. The glibc 2.38 requirement rules out a real population of machines, including Ubuntu 22.04 LTS, which was still widely deployed at the time of writing. The README points at issue #37 for this and recommends containerising the build, which is workable but not free.
Finally, rate limits. GitHub search without a token allows 10 requests per minute; setting GITHUB_TOKEN raises that to 30. A run that touches many sources on a slow connection will feel it.
patent as a library versus running it as a CLI
The engine is published as a library crate, which changes what you can build with it. The README names three entry points: sources::search_all fans out to the registries, rank::rank_async ranks matches by semantic similarity, and verdict::assess produces the integrity-scoped verdict over any LLM backend. Documentation is at docs.rs/patent.
That is a different proposition from the CLI. If you are building a tool that needs prior-art checks as a step inside a larger workflow, embedding the crate avoids shelling out and parsing JSON. The trade-off is that you inherit the same source coverage and the same glibc-linked ONNX Runtime dependency, so the environmental constraint does not go away. For most people the CLI plus --json is the simpler integration, and the exit code gives you the verdict without parsing anything at all.
Compared with hand-searching each registry, the difference is not just speed. A manual pass is keyword-driven, so it misses the differently-worded match that semantic ranking is designed to catch. Compared with a general web search, patent is narrower and more structured: it returns registry entries with dates and popularity rather than a page of results you have to triage.
Licence, maintenance and what upgrading costs
The crate is dual-licensed MIT OR Apache-2.0, matching the LICENSE-MIT and LICENSE-APACHE files at the repository root and the license field in Cargo.toml. For most Rust consumers this is the standard permissive pairing and requires nothing beyond attribution; if your organisation has a policy on dual-licensed crates, that is a question for your own legal review rather than something the README settles.
On maintenance: the repository is not archived, and the last push was on 2026-09-14. Releases have been frequent, with v0.14.0 on 2026-09-08, v0.13.1 on 2026-09-05 and v0.13.0 on 2026-08-31. The version numbers are still in the 0.x range, which means the library API named in the README (sources::search_all, rank::rank_async, verdict::assess) carries no stability promise across minor versions. If you depend on the crate rather than the binary, read the CHANGELOG before each bump.
The MSRV is 1.88, declared in both the README badge and Cargo.toml. Two repository files, roadmap-0.5.0.md and roadmap-0.6.0.md, sit at the top level alongside a CHANGELOG.md and CONTRIBUTING.md, so the project keeps its planning in the open even though those roadmaps are excluded from the published crate tarball.
The ongoing cost of using patent is mostly environmental: you keep a Rust toolchain at 1.88 or newer, a glibc 2.38 or newer host or container, and optionally a local Ollama instance with the model pulled. The --fast flag removes the last of those, and the --api-base path replaces it with a network dependency and a privacy trade-off.
Editorial conclusion
Adopt patent if you are about to start a dev tool and want a fast, local, reproducible first pass over registries you would otherwise grep by hand, and if you are comfortable reading a verdict as scoped evidence rather than a novelty check. Do not adopt it if you need coverage of academic literature, patents proper, or closed-source internal tools, and do not treat exit code 0 as permission to build. Before you rely on it, confirm three things on your own machine: that your distribution ships glibc 2.38 or newer, that Ollama is running with the model you intend to use or that you are passing --fast, and that the sources listed in the output are the ones you actually care about. The exit code is the contract: 0 Open, 1 Crowded, 2 Saturated.
Frequently asked questions
How do you use patent to check whether a dev tool idea already exists?
Install it with cargo install patent, then pass the idea as a quoted string, for example patent "interactive cli to kill whatever's on a port". The TUI opens with matches ranked by semantic similarity, and the verdict is Open, Crowded or Saturated. Running patent with no argument launches a search prompt inside the TUI instead.
What does patent mean by a Saturated verdict?
Saturated is the highest of the three verdict levels and means the space is densely populated according to the sources checked. The verdict is floored against the similarity data so it cannot under-rate a populated space. The CLI exits with status 2 for Saturated, 1 for Crowded and 0 for Open.
Does patent search actual patents?
No. It searches 19 package registries plus GitHub and Hacker News, and the README describes it as "like a patent search, but for code." Patent filings and academic literature are not among the sources it queries, so a clean result says nothing about them.
Can patent tell me that my idea is completely new?
No, and the README is explicit about this: patent can prove something exists but can never prove something doesn't, because it only searched some sources. A clean Open result means keep looking before you commit, not that the idea is novel.
Does using patent send my idea to a third party?
Only if you configure a remote backend. With --api-base your search query is sent to that server to generate the verdict. The default local Ollama backend and the --fast flag, which skips the LLM entirely, keep everything on your machine.
Community notes