feat(catalog): add claude-fable-5-1 to model metadata - #3293
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Team Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughThe change adds Claude Fable 5.1 model metadata and updates Anthropic pricing tests to confirm jawcode precedence for both ChangesClaude Fable 5.1 support
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This adds Claude Fable 5.1 metadata and aligns Anthropic pricing resolution coverage. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2 files. (1 skipped: 1 unsupported.) Full details: Title checkExplanation The title clearly and concisely describes the primary change: adding claude-fable-5-1 to the model metadata catalog. It matches the changes in scripts/model-metadata.source.json and the related generated metadata and pricing updates. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
✅ Deterministic PR hygiene checks passed. |
✅ READY
Review readiness checklist
✅ 4/4 boxes ticked. This pull request is already Ready for Review. Hygiene✅ Deterministic PR hygiene checks passed. |
리뷰 · 우선순위 46 / 80이 PR은 #3203이 Anthropic 레지스트리· PR이 하는 일은 짧고 분명합니다. 소스 JSON에 Fable 5.1 객체를 넣고
다만 이 브랜치는 작은 정확도 이슈도 있습니다. 본문은 thinking 블록을 라인 메인테이너의 판단이 필요한 지점
너의 추천 이 댓글은 grok-bot이 작성했습니다 |
|
The branch is now rebased onto latest dev, so the two commits you were concerned might be reverted are no longer at risk. |
8c168a7 to
4d78ee9
Compare
4d78ee9 to
4de6d1a
Compare
lidge-jun#3203 added the registry and pricing rows but not the model metadata; this fills that gap. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4de6d1a to
a52ccb9
Compare
…credit, Ultra Fast opt-in) (#3478) * docs(devlog): roadmap the 260904 triage gap closure Three gaps the triage verified as NOT done: the half-shipped fable-5-1 metadata, the missing CREDITS row for #3284, and Ultra Fast. The Ultra Fast doc carries the finding that shapes the whole phase: upstream-models.json advertises only priority, so there is no ultrafast tier to forward and re-adding the catalog row would reproduce exactly what #2994 was closed for. What is separately true is that a forced ultrafast request is classified not-requested and gets no speed label — an observability lie fixable without advertising anything. * feat(catalog): add claude-fable-5-1 to model metadata Carries PR #3293 by @Veritas-7, whose metadata half never landed while its pricing half did. On dev, src/usage/expected-prices.ts asserts an expected price for claude-fable-5-1 on four surfaces, but neither scripts/model-metadata.source.json nor the anthropic array of src/generated/model-metadata.ts knew the model existed. The pricing rows arrived through unrelated commits that happened to touch expected-prices.ts; #3293 is the only source of the metadata, and it is still open. Pricing without metadata is the wrong half to have. The generated file is regenerated from the source entry rather than hand-edited, which is what keeps the two consistent: ["claude-fable-5-1",1000000,128000,"text,image",1,null,10,50,0.25,12.5] Note cacheRead 0.25, not the 1 that claude-fable-5 carries: Fable 5.1's published cache-hit rate is 0.025x base input, which the existing expected-prices rows already encode. The PR's own test update comes with it. Adding the jawcode row changes where the price resolves from — src/usage/cost.ts prefers an exact jawcode provider-bundle row over the expected-price overlay — so the assertion moves from source: "expected" to source: "jawcode" with jawcodeProvider: "anthropic", and the overlay is asserted directly instead of through sourceRef. The resolved cost4 is identical either way; only the provenance label changes. Verification: bun run typecheck, bun test ./tests/usage-cost.test.ts (82 pass), bun run test:changed (10752 pass / 0 fail across 569 files). Repository-wide suite not run. Co-authored-by: wj <wj@nas-backup> * docs(credits): record #3284 as carried work Closes the gap issue #3431 opened at @Ingwannu's request. The Gemini 3.8 Flash Antigravity work first submitted by @mdwsk88 in #3284 landed on dev via #3286 (3d3c4fe), and #3284 was closed as superseded rather than merged — so the contributor graph shows nothing. CREDITS.md exists for exactly that case. The file sets two bars and both are met. It says "If you find a landing that belongs on this page, open an issue"; #3431 is that issue. It also says entries cite the maintainer's own words and are never inferred from diff similarity; the quoted text is verbatim from @Ingwannu's closing comment on #3284. Verified independently rather than taken from the issue body: 3d3c4fe is an ancestor of origin/dev and is the #3286 merge, #3284 is CLOSED and not merged, and src/providers/antigravity-models.ts on dev names gemini-3.8-flash 16 times, so the suffix ladder that PR argued for is what shipped. Verification: bun run privacy:scan passed (it reads CREDITS.md); table renders with the existing column alignment. * feat(codex): name the Ultra Fast tier, and move the account actions out of the page head Two halves of issue #3429, plus the page-head relief the same surface needed. PR #2994 added an ultrafast row to the pinned catalog and was closed unmerged: the picker gained a choice the wire could not honor. That verdict stands and is why nothing here synthesizes a catalog row. src/codex/data/upstream-models.json advertises exactly one tier — priority — on every row that has any, so an ultrafast entry would still be fabricated metadata. What is separately true is the half #3429 actually reports. A caller who supplies service_tier: "ultrafast" themselves gets the request forwarded, and then canonicalFastTierMarker folds it to undefined, fastIntent goes false, and the attempt is recorded as fastOutcome "not-requested" — the log asserting the user asked for nothing. requestLogSpeedLabel returns undefined for the same value, so the Logs speed column stays empty. The proxy was carrying a tier it refused to name. canonicalFastTierMarker now folds ultrafast to its own canonical rather than onto priority, which would have been the opposite lie: claiming a 1.5x Fast tier when the caller named a different one. There is deliberately no canonicalToWire entry, so an ultrafast attempt lands on "unknown" instead of a false "applied" — the truth is that it was requested and we cannot confirm it was honored. The ultraFastTier flag follows the fastRows precedent exactly: optional, catch(false) so a malformed hand edit degrades to off, read with === true, and off deletes the key rather than persisting a false nobody chose. Its dashboard toggle gets the boolean guard in config-routes.ts that fastRows never needed. The page head carried a title, a status line, the Spark toggle and two buttons on one row, with the account actions sitting above the cards they act on. Pause and Refresh move to their own row below the account-mode banner. The embedded Providers surface keeps them inline: it renders a bare .row with no title, so there is nothing to crowd there. Verification: bun run typecheck, bun run lint:gui, 408 focused backend tests including the byte-golden default-path guard in fastwire-characterization-routing, and the GUI head-wrap, toast-tone, controller and locale-parity suites. Live on a scratch instance: the head shows only the title and Spark toggle, the two actions render below, the toggle reads OFF by default, and enabling it writes ultraFastTier: true to config.json. Repository-wide suite not run. * fix(codex): make the Ultra Fast flag actually do something Self-review caught the flag stored but never read: `grep ultraFastTier src/` outside config/types/routes returned nothing, so the toggle persisted a preference and changed no behavior. Shipping a switch whose description promises the tier survives regeneration, while nothing consumes it, would be the #2994 failure in a new place — a control that implies an effect it does not have. normalizeRoutedCatalogEntry now consults the flag. With it OFF the four deletes run exactly as before. With it ON the row keeps an ultrafast the OPERATOR put in their own catalog, which is the reported symptom: #3429's reporter hand-edited opencodex-catalog.json and watched every regeneration delete it. Preserving is narrowed, not blanket. retainOnlyUltraFastTier keeps the ultrafast entry and drops everything else, because routed rows are stripped precisely so a clone of a native template cannot inherit OpenAI's priority tier — reopening that under an unrelated flag would be a worse bug than the one being fixed. A service_tier or default_service_tier naming a tier the row no longer carries is dropped for the same reason. And a row carrying only upstream's Fast is still stripped with the flag ON: there is no ultrafast to preserve, and inventing one is the line #2994 was closed for. The flag is read through ultraFastTierEnabled(loadConfig()) inside parsing.ts rather than threaded through deriveEntry. That function and its five call sites are pure RawEntry -> RawEntry transforms with no config parameter; plumbing one boolean through all of them would be a far larger change than the behavior it gates. Callers holding a config can still pass opts.ultraFastTier explicitly, which is what the new tests do, and a read failure degrades to OFF. Four new tests cover both states, including the two refusals: the flag never smuggles Fast onto a routed row, and it invents nothing when the operator supplied nothing. Verification: bun run typecheck, bun run lint:gui, 340 focused catalog/fastwire tests including the byte golden, 10 in ultrafast-tier-honesty, and bun run test:changed at 14419 pass / 0 fail across 785 files. * fix(fastwire): forward an unmapped canonical tier instead of dropping it Adversarial review found that the previous commit made the reported problem worse, and that every suite still passed while it did. Recognising ultrafast as a canonical marker routed it into the canonical-wire lookup in decideTier. That lookup is keyed by canonicalToWire, which maps only priority, so an unmapped canonical fell straight through to { kind: "drop" }. Measured before and after: before ultrafast -> forward-caller wire service_tier=ultrafast after ultrafast -> drop wire service_tier=(absent) So recognition was strictly worse than leaving the tier unrecognised: it used to be a foreign tier, and foreignCallerTiers "verbatim" forwarded it untouched. The operator's hand-configured tier stopped reaching the provider entirely, and the new "ultrafast" speed label became unreachable on the Responses path because tierValueAfterDecision had already cleared the value. That is the exact symptom #3429 reported, reintroduced by the fix for it. An unmapped canonical now falls through to the foreign-tier rules rather than dropping. Second finding, same root cause: callerCanonicalFast was widened to "any marker", which made a fastMode:false request from an ultrafast caller record callerFastSuppressedByConfig. The Fast toggle did not suppress a 1.5x Fast request; it turned away a differently-named one. The predicate is back to === "priority" for the drop/suppression facts, and only fastIntent carries the wider fast-family question. Third: ultraFastTierOptIn called loadConfig() per catalog row, and normalizeRoutedCatalogEntry runs in a per-entry sync loop — that is a chmod, three secret hardenings, a file read and a full Zod parse per row. It is memoized with a 5s TTL plus a reset seam; callers holding a config still pass opts.ultraFastTier and bypass it entirely. Fourth: the expected-prices comment claiming claude-fable-5-1 has no jawcode row was made stale by 21cb149, which added exactly that row. Five new tests cover what the previous suite could not see: the wire decision itself, and the suppression-vs-dropped distinction. The old tests all passed against the broken behavior because none of them asserted decideTier. Verification: bun run typecheck, bun run lint:gui, 720 focused fastwire/catalog/ request-log/usage tests, and bun run test:changed at 14466 pass / 0 fail across 787 files. --------- Co-authored-by: jun <jun@lidge.dev> Co-authored-by: wj <wj@nas-backup>
|
Landed on Why it was carried rather than merged: the branch had been open long enough that only half of it was still missing. The pricing rows for Your Verification on the exact head: Thanks — this was a real gap, not a stale duplicate. |
Closes out devlog/_plan/260904_triage_gap_closure with what actually shipped and the landing SHAs: PR #3478 (3a9c4d2) carried all three gaps, and #3293, #3431 and #3429 are closed citing it. The part worth keeping is the review round. The first Ultra Fast implementation passed every suite and was wrong: recognising ultrafast as a canonical marker routed it into decideTier's canonicalToWire lookup, which maps only priority, so an unmapped canonical fell through to drop and the tier stopped reaching the provider — where previously, as a foreign tier, it was forwarded verbatim. Recognition made the reported problem worse. Every listed suite stayed green because they unit-tested the two edited functions in isolation and never asserted the wire decision, and the byte golden pins catalog bytes rather than the caller routing path. Two lessons recorded: a test of the functions you edited is not a test of the behavior you changed, and widening a predicate that serves three questions silently changes the other two. Also records what was deliberately NOT done — Ultra Fast is still absent from the model picker, because upstream advertises only priority and a catalog row would offer a speed the wire cannot deliver, which is what PR #2994 was closed for. This document describes carried work whose code already landed in #3478 with the trailer. Repeating it here keeps the contributor graph correct for a body that names #3293 as carried. Co-authored-by: wj <wj@nas-backup>
Closes out devlog/_plan/260904_triage_gap_closure with what actually shipped and the landing SHAs: PR #3478 (3a9c4d2) carried all three gaps, and #3293, #3431 and #3429 are closed citing it. The part worth keeping is the review round. The first Ultra Fast implementation passed every suite and was wrong: recognising ultrafast as a canonical marker routed it into decideTier's canonicalToWire lookup, which maps only priority, so an unmapped canonical fell through to drop and the tier stopped reaching the provider — where previously, as a foreign tier, it was forwarded verbatim. Recognition made the reported problem worse. Every listed suite stayed green because they unit-tested the two edited functions in isolation and never asserted the wire decision, and the byte golden pins catalog bytes rather than the caller routing path. Two lessons recorded: a test of the functions you edited is not a test of the behavior you changed, and widening a predicate that serves three questions silently changes the other two. Also records what was deliberately NOT done — Ultra Fast is still absent from the model picker, because upstream advertises only priority and a catalog row would offer a speed the wire cannot deliver, which is what PR #2994 was closed for. This document describes carried work whose code already landed in #3478 with the trailer. Repeating it here keeps the contributor graph correct for a body that names #3293 as carried. Co-authored-by: jun <jun@lidge.dev> Co-authored-by: wj <wj@nas-backup>
Summary
This PR fills the generated-metadata gap for
claude-fable-5-1: the Anthropic registry, expected-prices overlay, and tests already knew the model, but the generated-metadata path did not.scripts/model-metadata.source.json.src/generated/model-metadata.tsfrom the source; the generated output was never hand-edited.thinkingblock usesanthropic-adaptive, matching the current-generation Anthropic entries. An earlier revision of this description wrongly called it a mirror of the older sibling; that wording was incorrect, not the value.Verification
Base commit:
664d80c76(upstream/dev); branch heada52ccb96c; not behind dev.bun run typecheck— exit0.OCX_TEST_NO_QUEUE=1 bun test tests/model-metadata-sync.test.ts tests/usage-cost.test.ts—83 pass,0 fail,456 expect() calls; exit0.OCX_TEST_NO_QUEUE=1 bun scripts/test.ts --changed=upstream/dev --path-ignore-patterns '**/tests/management-integration-routes.test.ts'—14018 pass,11 skip,1 fail,Ran 14030 tests across 759 files. [150.35s]; exit1. The single failure istests/muse-passive-quota-cache.test.ts→a defaulted read is memoized, and invalidation is what clears it, which hits the 5 s per-test timeout under parallel load. It behaves the same way on a second gate run and passes twice when its file is run alone (13 pass, under a second each), on a machine whose load average was between 6 and 9 during the gate. This change adds a model row and its regenerated output, so it has no path to that cache test.tests/management-integration-routes.test.ts, which builds the GUI bundle. It cannot run on this machine: the bundler's CSS minifier reportsCannot find module '../lightningcss.darwin-arm64.node'. That is a local toolchain problem unrelated to this change.10, output50, cacheRead0.25, cacheWrite12.5with thinking modeanthropic-adaptive, and the generated entry carries the same four cost values.Checklist
Review readiness checklist
This PR stays in draft until every box below is ticked. Tick all four boxes once the requirements are met:
All CI tests are green on my local testing.
I pushed my PR to the latest dev commit.
I resolved all correct Codex and CodeRabbit findings.
My PR is ready for review.
Summary by CodeRabbit
New Features
Bug Fixes
Tests