Model Discovery Feed
A provider-agnostic specification and reference implementation for publishing a model discovery feed, with validated fixtures, an HTTP contract, and named delegation profiles for picking a model.
The problem
Choosing which model to send a task to is a moving target. Prices, context windows, scores, and free-tier availability change week to week and differ by provider. The Model Discovery Feed defines a single provider-agnostic contract for publishing that data, so a tool can query it rather than hard-coding a stale model list.
What it defines
The feed is a contract, not a router. It is deliberately not an proxy, a , or a credential store. It exposes a small set of read endpoints over HTTP for the schema, the feed, its status, the models, and the providers. The models endpoint supports additive filters plus named delegation profiles such as best-coder, best-value-coder, and best-free-coder.
The reference implementation
This repository is a Next.js and example that shows how to publish a conforming feed, validate fixtures, and serve the contract. It also ships an explorer with an export drawer, which renders whatever the current filters select through a small row-and-wrapper template. Markdown delegation tables, CSV, and come as presets, one per delegation profile.
Exporting straight into a tool's config
One of those presets is deliberately not a report. It writes a ready-to-commit config file for the Cline plugin for Claude Code and Codex: a set of named delegation targets, each one a provider-and-model pair the feed currently ranks highest for that kind of work, with a line of guidance on when to use it. Drop it into the project and the plugin's own delegation commands resolve against live rankings rather than a model list somebody typed once.
That is what the export drawer is for. The template is generic, so a new consumer needs a preset rather than a change to the feed.
What else consumes it
A contract only earns its keep when something downstream reads it. The most involved consumer is the LiteLLM Model Config Maintainer, which fetches the feed, applies the rules its wrote, checks that each candidate model actually answers, and configures a local proxy accordingly. Two useful things follow from that.
The first is for the person: a proxy that stays current on its own. New free models appear when a provider adds them, retired ones drop out, and an exhausted subscription steps aside until it refills. Because the result is an ordinary -compatible endpoint, any tool that takes an address and a model name can use it directly.
The second is for the tools. Claude Lane Orchestrator gets a delegation route whose model list is maintained for it. It never reads the feed and never sees the rules; it asks which model fits the job at hand and dispatches to whatever is reachable at that moment. So a model published upstream becomes one an orchestrating can route real work to, two hops later, with a small contract at each step.
Current state
Active. It ships public documentation for the feed contract, a client integration guide, fixture examples, and a deployment guide.