Back to all projects Project

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.

2026 Creator and developer
  • TypeScript
  • JavaScript
  • Next.js
  • Prisma
  • Vercel
  • AI
Model Discovery Feed project cover

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.