LiteLLM Model Config Maintainer
A that keeps a local 's model list current. It reads a model discovery feed, applies the rules you wrote about which models you want, checks that each one answers, and then writes the config.
The problem
One proxy can front a dozen providers at once: a large mirror, a couple of fast hosts, two or three subscription plans, plus direct vendor . Each one names its models differently and answers at a different address.
That setup decays quietly. Providers add free models and withdraw them. Vendors retire model names. Plans exhaust their quota and refill on a schedule nobody remembers. The alternative to a tool here is re-testing eighty models by hand, which nobody does, so the list drifts until a call fails in the middle of real work.
What it does
It keeps that list current without anyone editing YAML. It reads a model discovery feed for what exists across providers, applies the rules you wrote about which ones you actually want, and then checks that each candidate answers before letting it through. A model that fails is withheld and restored when it recovers. A plan that publishes its own reset time comes back on the clock, without spending calls to find out.
That last part is where most of the value is. A listed model is not a working model, and selection alone gets you a config full of plausible entries, some of which fail on first contact.
The rule that keeps it trustworthy
Every file in the system has exactly one writer. Your rules are yours and the tool never edits them. The health record belongs to the tool. The record of what failed in live traffic belongs to the proxy that saw it.
That sounds pedantic, and it is doing most of the work. A run on a schedule can never overwrite a decision you made by hand, and a failure seen in real traffic can never be lost to a regeneration happening at the same moment. The tool also refuses to write a result that looks implausible, on the principle that one bad download should not be allowed to empty a working config.
Answering the routing question
Two commands make the state readable by an rather than a person. One answers which model to use for a kind of work, what it costs, and how wide its window is. The other answers what is exhausted right now and when it comes back.
That matters because the obvious alternative is a table of model names written into an agent's instructions. Such a table is wrong within a week, and it goes wrong silently: the agent keeps confidently routing work to a model that no longer exists or no longer answers.
Where it sits
It is the middle of three projects. Upstream, the Model Discovery Feed publishes which models exist across providers. Downstream, Claude Lane Orchestrator asks which model fits a job and dispatches the work. This project is the only one that knows about a specific proxy, and one answer is the entire contract between it and anything that consumes it.
Current state
Active, and the thing the delegation tooling on this site actually runs against. It ships an installable agent skill that teaches a coding agent the habit the project exists for: ask what is reachable now, rather than trusting a list from last month.