llm-db

name	llm-db
description	Builder-oriented guidance for the upstream `llm_db` package. Use when Codex needs to model provider and model catalogs, select models by capability or price, wire catalog lookups into Elixir code, or review `llm_db` boundaries versus `req_llm`, `jido`, and `jido_ai`.

LLM DB

llm_db is the upstream Hex package name.

Start Here

Use this skill when the task is about model metadata, capability catalogs, or provider/model selection logic.

Good triggers:

• "Add model selection based on context window or pricing."
• "Normalize OpenAI, Anthropic, or OpenRouter model ids in Elixir."
• "Turn the LLM DB docs into a runnable catalog lookup example."
• "Review whether this code belongs in llm_db or in the provider client."

Read references/builder-notes.md before editing when the task touches capability filters, pricing metadata, or cross-provider normalization.

Primary Workflows

Build catalog-backed selection

• Model the caller's selection criteria first: provider allowlist, modality, tool support, context window, price ceiling, or local-vs-hosted constraint.
• Keep catalog lookup pure and deterministic. Return model metadata or a narrowed candidate list before making any network call.
• Push actual inference requests into req_llm or another provider client. llm_db should decide, not execute.

Add or refine provider metadata

• Start from the package's existing schema and naming conventions instead of inventing a parallel shape.
• Preserve upstream provider ids exactly, then add a local mapping layer only if the app needs aliases.
• Prefer additive metadata updates over app-specific branching in the core catalog.

Turn docs into runnable examples

• Build examples around lookup, filtering, ranking, or capability checks.
• Show how the chosen model metadata feeds a later req_llm or Jido workflow.
• Keep examples small enough to run in iex or a focused test.

Review package boundaries

• Keep catalog concerns in llm_db.
• Keep request transport, retries, and streaming in req_llm.
• Keep agent orchestration, directives, and tool use in jido or jido_ai.

Build Checklist

• Confirm which providers and model families the app actually needs.
• Verify whether the task needs static metadata, live pricing refresh, or both.
• Keep the API shape obvious: input criteria in, ranked models or metadata out.
• Add tests for provider aliases, missing models, and fallback behavior.

Boundaries

• Do not use this skill for prompt design or message shaping.
• Do not hide provider-specific HTTP logic inside catalog helpers.
• Do not promise pricing freshness beyond what the package sources actually support.