The task
Correct or extend the model catalogue in chimera/providers/catalog.py.
It is a table of dataclasses that says itself: DATA ONLY — extend/correct freely. Slugs get renamed, prices get cut, context windows grow. A stale catalogue quietly routes work to a model that no longer exists, at a price that is no longer real, and chimera models shows the wrong thing to everyone.
This is a two-line pull request that is genuinely useful, and one of the very few places you can improve a core behaviour without touching core logic.
Where
chimera/providers/catalog.py — the CATALOG tuple- The invariants are checked by
tests/test_catalog_invariants.py, so obvious mistakes (a negative price, output cheaper than input, a duplicate slug, an empty tier) fail before review
Done when
Good candidates
Anything in the table you know to be wrong. A newer model in a tier that is thin. A price that dropped. A tools: False that is now reliable — though that one is a claim about behaviour, so say how you tested it.
Scope guard (keep it small)
Data only. Deliberately out of scope: changing CatalogEntry's shape, touching resolve_tiers or the cost-mode presets, or moving the catalogue to YAML. If a tier's defaults look wrong to you, that is a real discussion and a separate one.
The task
Correct or extend the model catalogue in
chimera/providers/catalog.py.It is a table of dataclasses that says itself: DATA ONLY — extend/correct freely. Slugs get renamed, prices get cut, context windows grow. A stale catalogue quietly routes work to a model that no longer exists, at a price that is no longer real, and
chimera modelsshows the wrong thing to everyone.This is a two-line pull request that is genuinely useful, and one of the very few places you can improve a core behaviour without touching core logic.
Where
chimera/providers/catalog.py— theCATALOGtupletests/test_catalog_invariants.py, so obvious mistakes (a negative price, output cheaper than input, a duplicate slug, an empty tier) fail before reviewDone when
uv run pytest tests/test_catalog_invariants.pyis greeninput_per_m/output_per_mareNoneif you do not know, never a guess (the field's docstring is explicit: a price is never invented)Good candidates
Anything in the table you know to be wrong. A newer model in a tier that is thin. A price that dropped. A
tools: Falsethat is now reliable — though that one is a claim about behaviour, so say how you tested it.Scope guard (keep it small)
Data only. Deliberately out of scope: changing
CatalogEntry's shape, touchingresolve_tiersor the cost-mode presets, or moving the catalogue to YAML. If a tier's defaults look wrong to you, that is a real discussion and a separate one.