Agent interface

Start with /openapi.json (the contract), then /api/v1/recipes.json (the index). Errors are RFC 9457 application/problem+json; validation errors carry JSON Pointers you can fix programmatically. An expired-key 401 is machine-readable: its problem body carries type: https://localairecipes.com/problems/key-expired, code: key_expired and a renew_by hint your human can act on — re-login at /keys via the magic link. Keys come from the magic-link flow: POST /api/v1/keys {"email":"..."}.

• /openapi.json — OpenAPI 3.1 contract
• /llms.txt — llms.txt v2 guide
• /api/v1/recipes.json — recipe index, filterable: ?q= ?tier=curated|community ?engine= ?model= ?hardware= ?generation= ?tags= ?sort= ?page= (meta.applied echoes what took effect)
• /api/v1/leaderboard.json — one leaderboard per hardware configuration; whole-rig decode/prefill by concurrency, ranked across models, with each model's AA Intelligence
• /api/v1/benchmarks.json — boards (tier on every row)
• GET /healthz — dependency probe (Postgres + corpus ref); 200 ok, 503 degraded
• POST /api/v1/benchmarks — import a benchmark run file (llm-inference-bench JSON; gzip accepted; benchmark runs must reference an existing recipe via recipe_slug to appear on boards)
• /benchmarks/api — envelope spec + curl for the benchmark-ingest lane (201/replay idempotent by content_hash; 422 RFC 9457 pointers; 429 500 writes/day; tier: only an admin key sets verified)
• GET /api/v1/benchmarks/{sha}.json — the committed run file itself, byte-for-byte (sha is the content hash; immutable, ETag = sha)
• PATCH /api/v1/recipes/{slug} — update a live recipe (commits a new revision). Update recipes your key created; maintainers update anything. Patch paths: title summary license config model performance — unknown paths are rejected, never dropped.
• PATCH /api/v1/families/{slug} — promote a pending model family ({"pending": false}; admin key, one-way). PATCH /api/v1/recipes/{slug} with {"tier":"curated"|"community"} (tier change) and DELETE /api/v1/recipes/{slug} (retire, optional {"reason":…}) — admin-only.
• POST /api/v1/recipes/{slug}/fork — fork any live recipe into a NEW community-tier recipe your key owns (revision 1 copies the source live revision byte-for-byte; title "Fork of …"; credits carried + fork provenance; facets copied; lineage in forked_from_recipe_id). Tier rules: submissions and forks are ALWAYS community — curation to curated is an owner/admin action; your fork is yours, only you (or an admin) can update it.
• /robots.txt — crawl policy (AIPREF-style, agents welcome) + soft page-lane fair-use rate limit (see /llms.txt, "Website lane rate limits")
• /sitemap.xml — URL index

Every recipe twin at /api/v1/recipes/{slug}.json includes an agent block with a paste-ready prompt and fetch command. If a twin's engine_source carries a non-empty install_note, the recipe is not installable as written (e.g. the engine needs a source build — no image is published yet); follow the note instead of the plain launch command. A twin's revision.notes carries the revision provenance wording (attribution and any deviation notes) — the same text the HTML page shows under Revision notes.

Image-based twins additionally carry a requirements block - Docker + NVIDIA Container Toolkit, and an NVIDIA driver floor derived from the image tag's CUDA level, cited to the NVIDIA CUDA Toolkit Release Notes (unknown - check the image tag when the tag carries no CUDA level, never a guessed number) - plus artifacts download pointers. Hardware-bound values (GPU UUID, model directory paths, host port) are placeholders that describe the author's rig: map them to your own machine before launching (GPU UUID via nvidia-smi -L).