Public catalogs & IDs

The ready-made building blocks OpenEng offers come from public catalogs. Each catalog is a small website of its own at <kind>.openeng.app, where you can browse and search it, and each publishes the same data as JSON for the Console and the engine to read. Everything on this page is public: no sign-in and no key.

You don't need any of these files to use OpenEng. The Console shows every catalog on its own pages and lets you adopt or import entries from there (The Console). This page is for anyone who wants to script against the catalogs, check what a config refers to, or pin a version.

The catalogs

Each catalog's name links to its site. Entry counts are from each catalog.json on September 25, 2026; the catalogs grow, so read count (or the length of the entry list) for the current number.

Two catalogs share the connectors site but are different things: the connectors are for the engineering apps, and the integrations are what the Console's Connect → Connectors page lists (Glossary).

Each entry also has a page on its catalog site, such as models.openeng.app/m/codegemma-7b. The part of that URL after the path prefix is a URL-friendly name, and it isn't always the same as the end of the entry's id: that model's id is mdl_def_codegemma_7b.

IDs

Every item's id says where it came from.

Prefixes you'll see on your own items include mdl (models), agt (agents), tpl (templates), sch (schedulers), cell (cells), mcp (MCP servers), stp (storage points), skill, loop and connector.

Version pins: <id>@<version>

Once something is published it never changes, and <id>@<version> names exactly one published version:

• Configs. Every publish freezes a new version of the config. The Console's version timeline offers the pinned id <id>@<version> for copying (The version timeline), and the engine's log names the config version it serves the same way, for example warm-up: config <id>@<version> READY.
• Templates. Publishing a template you wrote freezes an unchangeable copy of it at <id>@<version> (Templates).
• Catalogs. Each catalog version is frozen in its own file, catalog/v<version>.json (below).

The catalog.json contract

Every catalog site serves the same files:

The integrations catalog is the exception: it's at connectors.openeng.app/integrations/catalog.json and has no index or versioned copies.

The catalogs don't all use the same envelope. Each one is a JSON object with the entries in a list named after the catalog, plus version fields:

An entry's id is in its id field, its publicId field, or both, depending on the catalog.

curl -s https://skills.openeng.app/catalog.json | jq '.count'     # 885 on September 25, 2026
curl -s https://agents.openeng.app/catalog/index.json             # {"latest":"1.0.0","versions":["1.0.0"]}
curl -s https://templates.openeng.app/ab-experiment-plan.md       # one template's full prompt

A few catalog sites publish more than the catalog:

• models.openeng.app also serves runtimes.json (13 runtimes and the model formats each one runs) and providers.json (12 providers) (Models).
• loops.openeng.app also serves catalog/strategies.json and a /reference page: the iteration strategies the engine uses inside a single turn, published as reference data. They aren't loops you run (Loop strategies).
• connectors.openeng.app also serves each connector's source as a zip under /packages/, and the write-key generator at connectors.openeng.app/write-key (Connectors).
• roles.openeng.app is for browsing. The AI engine doesn't read it: it uses the signed roles pack from releases.openeng.app (Release integrity).

The public release feed

releases.openeng.app shows the engineering apps' releases with their release notes; releases.openeng.app/app/<product> shows one product. The feeds behind it, and those of the AI engine's packs, are public JSON:

https://releases.openeng.app/v1/<product>/<channel>/latest      # the newest release
https://releases.openeng.app/v1/<product>/<channel>/versions    # {"versions": [ … ]}, newest first

Products with a feed on September 25, 2026:

The engineering-app releases are filed on the beta channel, and the stable URLs serve the same releases, because that's what the engines check. So a record you fetch from a stable URL can say "channel": "beta". The AI engine checks the engine product on its own channel (stable unless you set OPENENG_UPDATE_CHANNEL); on September 25, 2026 that feed has no release yet (The engine).

A release record, shortened:

{
  "product": "terminal",
  "channel": "beta",
  "version": "0.0.4",
  "releaseDate": "2026-09-19",
  "notes": "OpenEng Terminal Engine 0.0.4 — every endpoint moves to openeng.app.",
  "changelog": ["…"],
  "critical": false,
  "minSupportedVersion": "0.0.1",
  "artifacts": [
    {
      "platform": "linux",
      "arch": "x86_64",
      "url": "https://openeng.app/engine/terminal/bin/openeng-terminal-linux-x86_64",
      "checksum": "sha256:6e07aa7f…"
    }
  ]
}

• artifacts has one entry per platform and CPU: where the binary is and its sha256: checksum. Release records hold only these pointers; the binaries are served from openeng.app. Every engine checks the checksum before it installs an update (Release integrity).
• critical and minSupportedVersion: a critical release, or any newer release when the running AI engine is older than minSupportedVersion, is swapped in on disk right away instead of at the engine's next start, and the engine asks you to restart it (The engine). App engines always move to the newest release when they start.
• Each version is its own record, so versions is the full history.