Skip to content

v0.7.1 — nothing offered that was not declared

Choose a tag to compare

@anfreire anfreire released this 12 Oct 16:34
· 7 commits to main since this release

A custom model that declares low, medium and high was still offered xhigh and max in /effort, and a pick above the ladder silently fell back at request time. The README promised that nothing is offered that was not declared; the pickers were not keeping that promise. This release makes them.

The fix

Claude's /effort slider, its usage line and the non-interactive usage stop at a model's cap — the per-model maxEffortLevel setting, which arrived in 2.1.267 together with the capability override — and never ask the capabilities. Only the /model picker asks both, which is why effort-limits had already trimmed xhigh and max there; nothing could take its ladder below high.

The cap reader folds every settings layer it can see into the lowest per-model cap. A new effort-cap step bakes each model's declared top as one more layer in that list, so every surface that folds those layers follows, and the semantics come from upstream's own fold rather than from the patch: a lower cap in your settings still wins, max exempts, a model declaring no level keeps the control off rather than a cap, and a pick above the top gets upstream's own message — "exceeds the cap … set by your settings" — which is then true. One identity owed to the bundle, at the point where that path is fed, instead of a cut per surface.

The step is required when a model declares a top below max and the settings schema caps effort per model; builds before 2.1.267 report it absent, with a note. Its locator reads the two names upstream wrote (maxEffortLevel, modelSettings) and the list the reader walks, so 2.1.289 adding a third layer source cost nothing.

Compatibility

Transparent. Upgrade and re-apply (patch-cc apply, or the menu) to get the cap; the saved selection replays unchanged. Effort resolution itself is untouched: a session's /effort pick still applies to every model for that session, saved per-model levels are read at session start, and /effort status answers identically on the pristine binary. One visible consequence: a saved effort above a model's declared top now prints upstream's cap warning at launch where the clamp used to be silent — set that model's effort once, or lower it in modelSettings, and it goes.

Validated

  • GitHub CI passes on Python 3.11, 3.12, 3.13 and 3.14 for the release commit.
  • patch-cc doctor over all 70 held builds, 2.1.216 → 2.1.296: every patch matches and every baked binary boots. Diffed against the previous sweep, exactly one number moves — custom-models gains one candidate and one application on each of the 29 builds from 2.1.267 — and the 41 builds before it gain the note. No other build's count, note or runtime line moved.
  • The locator binds the same list on every dumped build from 2.1.267 to 2.1.296, two spread sources or three; 2.1.257 is absent with its witness false. The per-model cap schema and CLAUDE_CODE_MODEL_CAPABILITIES both first appear in 2.1.267 — none of 2.1.258–2.1.266 has either.
  • On the patched 2.1.296, non-interactive /effort for a three-level model prints <low|medium|high|auto> where it printed all five; /effort status matches the pristine binary for every model, with and without --effort.
  • The 0.7.1 wheel and sdist build and pass Twine metadata checks.
uvx --no-cache patch-cc        # or: uv tool install patch-cc && patch-cc