Active systems grouped by role. Organization marks preview the labs that build them; symbols and positions imply no rank or periodic law.
Browse every collection
Models, services, runtimes, and other record types keep their own boundaries.
The whole directory in one list: A–Z, or best match first while you search. Scores stay hidden here, since a score only compares like with like. Choose a collection for its own filters, and its scores where it has them.
Choose one family to compare editorial scores. Scores compare systems in this family. All-family browsing is unscored.
Scores compare stable service operations across types. Filter for workload fit before treating overall as a shortlist.
Scores compare documented execution capability on hardware you operate. They exclude throughput, latency, and benchmark rank, so filter for hardware and format fit first.
Packs are documents a host agent installs and reads. They are recorded for what they install, never scored, and never compared. A pack that runs its own code is reviewed as a system instead.
Robots are listed for what their makers document: the models they name or the way they let you run your own, the hardware, how to get one, and the terms. The Atlas does not test robots, so nothing here is scored or compared.
models.dev source catalog and Atlas reviews Artifact licensing describes reviewed release artifacts and mandatory terms, not training code or training data openness. Imported source records have no Atlas score. Reviewed scores compare access and deployability only; they exclude output quality, benchmarks, parameter count, current price, latency, and throughput.
The organizations behind the models A lab is listed once the Atlas has reviewed a model release, a system, or a robot it made, or once it says on its own pages that it is building frontier models. Releases keeps a lab with at least one reviewed release distributed that way; each release keeps its own licence and score in Models.
Interoperability artifacts Protocols, instruction conventions, and package formats, classified by what they connect, with no cross-purpose score.
Explore the data · Models
How can you access a model?
Downloadable weights, developer APIs, and third-party hosts overlap. Explore how access and licensing intersect among releases reviewed in Atlas.
About these counts
Each Atlas-reviewed model release counts once in its license classification and once in every documented distribution mode it carries. A model with several licenses still counts as one release. Distribution columns overlap and must not be added together.
Percentages in the bars use all reviewed releases; percentages in the table use the number of releases in that row. Zero means no matching reviewed record in this catalog, not that a route cannot exist. Counts describe Atlas coverage, not market share or model quality.
These views use Atlas-reviewed classifications, not models.dev reported licenses or open-weight flags. Imported records are excluded. Review dates describe the catalog, not release dates or a fresh check of every model.
Explore documented accelerators, model formats, and API styles. Open a runtime for its hardware requirements, build-specific limits, and evidence.
● Recorded in the review · — Not recorded. Features can depend on the build, backend, and model; a row does not guarantee every combination works together. API compatibility does not imply full endpoint parity.
Scroll the table horizontally to see every column.
Compare recorded deployment options across families, then see how local-first storage intersects with licensing. Select a count to inspect its systems.
How to read these tables
Only active, reviewed systems count. Each system counts once per recorded deployment mode, so deployment columns overlap. Percentages and heat intensity use each row’s total; a zero means no matching catalog record, not an impossible deployment. Missing deployment values remain in the denominator.
Local-first describes where a system keeps its working content by default and whether its vendor retains it. It does not mean all model execution happens locally. “No” includes libraries that keep no content of their own; “Not recorded” is separate from false. License classification does not imply local-first behavior.
These are catalog counts, not market share, quality rankings, or tests of the products. Editorial review dates describe recorded reviews, not release dates or a new verification today.
Every reviewed release names one developer. See each lab's releases, and the developer strings matching no lab or several.
How to read this table
Only reviewed releases count. A release joins the lab its developer string names; developer strings matching no lab or several labs stay visible beside the table instead of being assigned. Select a count to browse the lab's releases. These are catalog counts, not market share or model quality.
Every job carries a count. Choose one to see its three strongest reviewed matches.
A multi-axis model
One family. One primary role. Several orthogonal traits.
A system can be an assistant that uses one provider, connects to work data, and retains service-managed context. Those are different facts—not competing labels or an agent-system score.
External agent memory
A separate library or service persists memory outside the agent runtime. Agents call it through an SDK, API, CLI, or protocol. Replacing the agent does not delete the memory. This improves reuse, but can create an opaque second source of truth.
Ambient capture
Passive collection of digital activity—screenshots, audio, active apps, window titles, or events—without deliberate note taking. It minimizes capture friction but creates severe privacy, noise, retention, and consent obligations.
Agent-system score
Rates reliability, tool use, autonomy, human control, observability and recovery, data sovereignty, interoperability, and maturity. It is not comparable to the memory-system score.
Assistant-system score
Rates product-level reliability, context continuity, tools and integrations, human control, data governance, interoperability, usability, and maturity. It does not rank underlying models.
Inference-service score
Rates operational maturity, governance, regional control, serving flexibility, interoperability, traffic resilience, customization, and documentation. It excludes model quality, current price, and transient performance.
Model-access score
Rates license clarity, artifact availability, deployment portability, serving reach, lifecycle transparency, and documentation provenance. It excludes output quality, benchmarks, parameter count, price, latency, and throughput.
Vector-based
Not a product category. It means embeddings are stored and searched by semantic similarity. PKM tools, RAG apps, memory services, and agents can all use vectors while remaining fundamentally different products.
Published data
Every record here is a JSON file.
This directory publishes its catalog as static data files straight from this domain. No key, no sign-up, no rate limit—fetch them from a browser, a script, or an agent.
Fetching
A plain GET over HTTPS. Each file returns application/json with access-control-allow-origin: *, so a page on another origin can read it without a proxy.
Caching
Responses carry a ten-minute cache-control and an ETag; send If-None-Match to poll cheaply. The ?v= value this page appends is its own content hash for cache busting—leave it off and you still get the current file.
Reuse
Atlas-authored data is licensed CC BY 4.0. The derived models-dev.json snapshot retains models.dev's MIT attribution.
The vocabulary every other file uses: system families, primary roles, orthogonal traits, license identifiers, and score profiles. The other files refer to these by id, so start here.
system_families[] · primary_roles[] · licenses[] · version
Reviewed memory, agent, and assistant systems. Each record carries its family, role, traits, licenses, editorial score, and the strengths and watchouts behind that score.
Reviewed provider-independent model releases, with models.dev discovery metadata once models.dev lists the release, human-reviewed distribution terms, and a dedicated access-and-deployability score.
The complete commit-pinned provider-independent model catalog imported from models.dev. These are attributed source records, not Atlas-reviewed licensing, evidence, or scores.
models[] · source · source_record_count · updated_at · version
Protocols, instruction conventions, metadata schemas, and package formats. These carry no score: they are contracts between systems rather than products to rank.
Agent packs a host agent installs — skills bundles, plugins, process kits, vault bundles, and marketplaces — recorded for what each installs, into which hosts, by which mechanism, and under which licence. Never scored.
The labs that develop the reviewed model releases: type, headquarters, where each publishes, and the exact names the other files use for it, so its models, services, runtimes, specifications, and packs can be joined. Never scored or ranked.
Robots whose maker's own documentation names a learned model or policy, or documents a way to run your own, recorded for hardware, availability, and terms as the maker documents them. Never scored.
The reviewed license and terms evidence behind each record, scoped to the components it covers. Evidence from a Git repository is pinned to the exact file; evidence from a web page records the date it was read.
Projects that were reviewed and deliberately left out, each with its reason. Read it to tell a considered boundary from a gap in coverage.
entries[] · generated_at
What is not published
The system candidate, model-review candidate, and license-review queues stay in the repository. The complete models.dev source snapshot is published separately above, while workflow state and proposed review decisions remain private to the repository.
logos.json is served because this page needs it, but it holds vendored product marks rather than catalog data. Those marks identify their owners' products and are not covered by the catalog license.
The files under /app/ are this page's own payload: the same records, split into what a card needs and what a record dialog needs, so the directory renders without downloading every review first. They are regenerated from the files above and carry no compatibility promise. Build against the endpoints on this page, not against those.
Reading the fields
The data model defines every field, the taxonomy defines every enum, and curation describes the review a record passes before it appears.
An agent landing here can read llms.txt for the same list in one file, or install the Atlas skill to keep the vocabulary between sessions.