Milestone 2.5.G1.M2 — Model Capability Registry

Status: Completed
Goal: Track A — Multi-Provider Adapters
Phase: 2.5 — Provider Generalization & Foundation
Estimated effort: 1–2 days
ADR: ADR-0041 — Model capability registry

Why This Milestone Exists

Today, supported models are effectively a hardcoded list, and Registry.For(model) only reports which provider handles a model, not what that model can do. With Anthropic and later self-hosted vLLM models that differ in context windows, tool-calling support, and vision support, provider identity alone is not enough for the proxy or future context-assembly engine (for example token-budget sizing, or whether a tool-call request is even valid).

Non-Goals

Dynamic capability negotiation at runtime (static table is correct for now)
Pricing/cost data per model (separate concern)
Per-request model selection logic (Phase 4 routing)

What shipped

provider.ModelCapability + CapabilityCatalog with curated BuiltInCapabilityCatalog
Registry.Capability(model) beside Registry.For(model)
Fail-closed NewRegistry(catalog, …) (ErrMissingCapability)
IBEX_MODEL_CAPABILITY_OVERLAYS for ExtraModels
Maintainer diff tool: go run ./packages/provider/scripts/diff_capabilities -fetch

Success signals

A capability record exists per registered model (context window, tools/vision/streaming, tokenizer family)
Lookup by model ID is available alongside provider lookup
OpenAI and Anthropic models used in Phase 2.5 have capability entries
Missing capability is a startup/configuration error, not a silent nil at request time
Optional: a sync/diff path against an upstream table if the curated table is kept small
Tests cover lookup, missing-model failure, and tokenizer-family presence
Repo guards / CI checks still pass (verified on PR)

Prerequisites

2.5.G1.M1 (Anthropic provider adapter) — establishes which Anthropic models are registered