best-of-ai/best-of-ai: a 1,318-entry curated AI tool directory and what it does not do

What problem a 143-category AI directory actually solves

The README states the intent directly: it is a directory that filters out noise so you can find tools that deliver. The stated differentiator is that every tool is reviewed and ranked rather than scraped. The scale is given in badges at the top of the file: 1,318 tools and 143 categories, with the tool count also repeated in the body text as 1318+. Coverage runs from Code Assistant (39 entries) and DevTools (108) to narrow verticals such as Weather (4), Pets (3), and Space Tech (3). That range is the point. A developer looking for an AI agent framework and a clinician looking for medical imaging tools are both served by the same index, which is unusual for a curated list. The audience implied by the README is broad and non-technical as much as technical: it links to a professionals page with stacks for designers, developers, and marketers. If you are the kind of reader who already tracks AI releases week by week, most of this list will be familiar. The value is concentrated in the long tail of categories that a generalist would never think to search for.

How the list is built and where the ranking criteria stop

The README describes a review-and-rank process but does not define it. We get the claim that tools are hand-picked for quality, innovation, and real-world impact, and that each is reviewed and ranked. What we do not get is a scoring rubric, a reviewer identity, a date per entry, or a changelog for entries that were removed. That matters because the word ranked implies an ordering, and an ordering implies criteria that a reader can audit. None are supplied. The repository's primary language is HTML, which suggests the list itself is rendered as markup rather than stored in a structured data file, but the README does not describe the build pipeline or the source of truth. The category counts in the Contents section (DevTools 108, Writing Assistants 43, Code Assistant 39, Video Generator 34, AI Agents 30) read like generated output, yet nothing in the supplied material confirms how they are produced or how often. Treat the counts as a snapshot, not a maintained contract.

Getting the list and submitting to it

There is no install step, because this is not software you run. The README offers two entry points. The first is the website at bestofai.io, described as the full interactive directory with search, filters, and detailed reviews. The second is the repository itself, which you clone if you want the raw list. The contribution path is a GitHub issue form, and the README gives the exact URL: https://github.com/best-of-ai/best-of-ai/issues/new?template=submit-tool.md&title=Submit+Tool%3A+ followed by the tool name. The README also links to a CONTRIBUTING.md for the fuller process, though its contents are not included in the supplied material. There are no releases retrieved for this repository, so there is no versioned artifact to pin and no changelog to read. If you want to know what changed between two points in time, you are reading commit history, not release notes. That is a normal shape for a curated list, but it means the only stable interface you have is the rendered page and the Markdown in the default branch.

The ranking claim is the weakest documented part

This is the section where the README promises more than it shows. It says every tool is reviewed and ranked, and that the list avoids mediocre apps. Both are quality assertions. Neither is backed in the supplied material by a method, a reviewer, or a criterion that a reader could apply independently. Compare that to a list that simply says it collects tools and lets you filter. The modest claim is easier to trust because it is easier to falsify. Here, a tool appearing in a category could mean it passed a review, or it could mean it was submitted and accepted. The README does not distinguish. There is also a structural tension in the breadth: 143 categories with counts as low as 2 (Others) and 3 (many verticals) suggests that some categories exist to hold a handful of entries, which is a different editorial posture from a list that only includes categories with real depth. Neither approach is wrong, but the README presents both as if they were the same kind of curation.

What this repository is not: no data file, no API, no versioning

If your goal is to programmatically consume a list of AI tools, the supplied material gives you nothing to work with. There is no described JSON or YAML schema, no CSV export, no API endpoint, and no documented build step that turns source data into the HTML the repository is written in. The primary language field says HTML, and the README's Contents section is a Markdown table of contents with anchor links, not a data structure. There are no releases retrieved, so there is no tagged snapshot to depend on. A team that wants to embed a tool directory into an internal portal would be reading the rendered site or parsing Markdown, both of which are brittle against a moving default branch. The README does not claim any of these capabilities, so this is not a broken promise. It is a boundary you should know before you plan around it. For a human browsing for tool ideas, the boundary is irrelevant. For an automated pipeline, it is disqualifying.

Where a wiki-style directory beats this, and where it loses

The obvious alternative is a community-edited directory such as an awesome-list on GitHub, where anyone can open a pull request to add or remove an entry. The difference in approach is editorial control. An open wiki optimizes for coverage and freshness: if a tool exists and someone cares, it gets a line. This repository optimizes for selection, and the README states that explicitly with the phrase no fluff, no mediocre apps. The trade-off is that an open list will surface a tool the day it launches, while a curated list will surface it only after someone decides it belongs. The other difference is structure. A typical awesome-list is one long Markdown file grouped by headings, which is easy to diff and easy to parse. This project splits the same content across a README table of contents and a website, which is friendlier to read and less friendly to consume. If you want the widest possible net, the open list wins. If you want a shorter list where the omission of a tool is itself a signal, the curated approach is the one you want, provided you trust the curator.

Maintenance, licensing, and what to check before you cite it

The repository is not archived and the last push recorded is 2026-09-07, which is consistent with the README's claim that new tools are added regularly. That also means the list moves under you. Any citation of a category count should carry the date you read it. On licensing, the README displays an MIT badge that links to a LICENSE file, but the repository metadata supplied here lists the license as unknown. Those two facts conflict. The badge is a claim in the README; the metadata is what the hosting platform reports. Before you reuse the list content in your own product, open the LICENSE file at the path the badge points to and confirm what it actually says. This is not legal advice, and the MIT badge in a README is not a substitute for reading the file. The maintenance cost to you is low if you are a reader and higher if you are a contributor: submissions go through the issue template, and the README does not describe a review turnaround time or acceptance criteria.

Editorial conclusion

Adopt this if you need a starting shortlist of AI tools and you can afford to verify each entry yourself; skip it if you need a machine-readable dataset, an API, or a ranked list with published scoring criteria, because none of those are described in the supplied material. Before relying on it, open the LICENSE file the README badge points to, since the repository metadata returned an unknown license, and check whether the category counts in the README still match the live list at bestofai.io.

Official sources

1. best-of-ai/best-of-ai on GitHub
2. Issues
3. Project website
4. README