feat(admin): unlimited AI model waterfall with full Claude + OpenAI catalog, per-entry effort and fast mode

[lopugit]

What

The Admin → System "AI workflow model order" was capped at 3 entries from a closed 3-model list. This PR makes the waterfall unlimited and expands the catalog to every current Claude and OpenAI model, each addable with a per-entry reasoning-effort tier and normal/fast mode.

Catalog (33 base models)

• Anthropic: Claude Fable 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, Haiku 4.5 — effort tiers per model capability (low…max, xhigh only where it exists); fast mode on Opus 5 / Opus 4.8 (Anthropic fast-mode research preview).
• OpenAI: GPT-5.6 Sol/Terra/Luna (none…max + ultra), GPT-5.5, GPT-5.4 (+Mini), GPT-5.3 Codex (+Spark), GPT-5.2 (+Pro), GPT-5.1 (+Codex/Mini/Max), GPT-5 (+Mini/Nano), o3 (+Pro), o4-mini, GPT-4.1 family, GPT-4o family — "fast" maps to OpenAI priority processing where sold.
• Model lists verified against Anthropic's current model reference and OpenAI's live model docs (Aug 2026).

Design

• Composed option ids <model>[:<effort>][:fast] (e.g. claude-opus-5:high:fast, gpt-5.6-sol:ultra). Storage stays a plain string array — the persisted key, endpoint shape, and the legacy bare ids (default, claude-fable-5, claude-opus-5) remain fully compatible. Segment order tolerated on parse, canonicalized on store.
• Validation: writes stay strict (per-model effort/speed support, uniqueness on canonical id, default required); reads are now forgiving per entry — an unknown id from a newer deploy is dropped instead of collapsing the whole stored order to ["default"].
• Provider-aware resolution: direct Anthropic clients use the first Anthropic-capable entry, OpenAI clients the first OpenAI entry, each stopping at the default sentinel (default still means "that client's provider-valid default model").
• Consumers updated: Lopu musings apply the resolved entry's model + output_config.effort + fast mode (beta) on the Claude side and model + reasoning_effort + service_tier: priority on the OpenAI side, with a one-shot bare retry so a knob the provider rejects never kills the whole provider. Claude moderation applies model + effort (fast deliberately ignored for a background classifier). ai-model-routing-contract.mjs pins the new shapes.
• Admin editor: unlimited reorderable list + a model/effort/speed picker (grouped by provider) replacing the fixed add buttons; effort/speed selects render only what the chosen model supports; duplicate-entry guard; row subtitles show Provider · Effort · Fast mode.

⚠️ Control-plane follow-up (separate PR needed)

The github-actions branch workflow still validates against the closed legacy trio and fails closed to ["default"] (with a warning) for any waterfall containing new/composed entries — admin preference is safely ignored, never misapplied. Widening that closed grammar (parse composed ids, filter to Claude-capable entries, keep the injection-safe charset) is a deliberate separate change on the github-actions control plane.

Testing

• test:settings 15 ✓, test:lopu 5 ✓, test:moderation 52 ✓, test:ai-model-routing ✓; typecheck ratchet: no new errors from changed files (the +7 drift is pre-existing in unrelated baseline files).
• Live browser (worktree dev stack, admin user): added Claude Opus 5 High effort · Fast, GPT-5.6 Sol Ultra, GPT-5.3 Codex Extra-high (no speed select, correctly), Claude Haiku 4.5 (no effort/speed selects, correctly); 5 entries total (beyond the old cap); reordered Opus 5 to Primary; saved; GET returns ['claude-opus-5:high:fast','default','gpt-5.6-sol:ultra','gpt-5.3-codex:xhigh','claude-haiku-4-5']; full reload paints the saved order. Desktop + mobile (375px) verified top-to-bottom of the section — no clipping/overflow/horizontal scroll.
• /api/v1/lopu/musing smoke on the dev stack streams (fallback mode, no keys) — the rewritten module loads in the real server.
• TESTING.md checklists updated for the new UI, variant grammar, and the control-plane fail-closed behavior.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
thingtime	Ready	Preview	Aug 27, 2026 12:12pm
thingtime (develop)	Ready	Preview	Aug 27, 2026 12:12pm

[github-actions]

🧹 Develop S3 preview removed

The PR-specific alias and every workflow-created develop deployment were removed when this PR closed.

The ordinary generated Vercel Preview remains available on the shared development runtime.

[github-actions]

⚠️ The resolver stopped in a later safety, verification, or publication step. No residual conflicted paths were confirmed; see the workflow run.

[github-actions]

🤝 Merged develop into claude/fallback-model-selection-0281b1 — conflicts auto-resolved by the resolve-pr-conflicts workflow.

Conflicted files:

• .github/workflows/all-branch.yml
• graphify-out/GRAPH_REPORT.md
• graphify-out/graph.json
• graphify-out/manifest.json
• remix/CHANGELOG.md

graphify-out/ was reset wholesale to the develop side (repo rule: one side, never mixed — the graph merge driver is unavailable in CI).
Then re-ran graphify on the merged code WITH LLM semantic extraction (graphify extract, claude-cli backend) and committed the result — content new to this merge is semantically indexed; unchanged content came from the tracked cache.

Please review the merge commit before relying on it.

[github-actions]

🦄 Lopu review — PR #388

Reviewed 4818b29c against 4a373cf1. Nice PR — the data-driven catalog, the
forgiving-read/strict-write split, the provider-aware resolvers, and the honest
writeup of the control-plane gap are all well done. I found one real gap, fixed
it in the branch, and cleared the red check as not-your-fault.

🔴 control-plane / rebuild is a concurrency cancellation, not a failure

The run's actual conclusion is cancelled, not failure. all-branch.yml uses
a repository-global concurrency group (all-branch-worker,
cancel-in-progress: true) because all is one generated union branch —
newest inputs win, by design.

• Our run 32737498122
  was cancelled at 14:21:44, mid-"Rebuild the all branch"; every later step is
  skipped and the union build check never ran.
• Run 32738169444 (branch codex/account-hint-environment-labels) was created
  at 14:21:14 and took the slot — then succeeded at 14:28:07, building the
  union that includes this head. A main run succeeded again at 14:35:32.
• This PR's own previous head f30d2d94 had a successful Build all branch
  run (32730677087), and the same supersede-and-cancel pattern shows up across
  many unrelated branches.

Nothing to fix on the branch and nothing to fix in the control plane. Every
other check is green.

🐛 Fixed: opening the catalog to reasoning models outran the musing token budget

Two coupled defects in musing.ts, both reproduced against this head before
touching anything:

1. max_tokens is incompatible with the OpenAI reasoning models this PR newly
exposes. The pinned OpenAI SDK marks it @deprecated and "not compatible
with o-series models"; GPT-5 and o-series reject the call outright. Before this
PR the OpenAI model came only from LOPU_OPENAI_MODEL (gpt-4o-mini), so it
never mattered — now an admin can put o3 / gpt-5.x / gpt-5.6-* first. And
because it lived on the shared base object, the bare retry carried it too,
so the retry that exists so "a knob the provider rejects never kills the whole
provider" couldn't rescue it. Observed on the head:

openai request bodies: [{"model":"gpt-5.6-terra","max_tokens":200,"reasoning_effort":"high"},
                        {"model":"gpt-5.6-terra","max_tokens":200}]
openai attempts: 2  (decorated + bare retry, both 400 unsupported_parameter)
resulting musing source: claude   → the OpenAI preference never runs

Now sends max_completion_tokens, which every current Chat Completions model
accepts.

2. 200 output tokens starves any reasoning entry. Both providers bill
internal reasoning against this same budget — Anthropic counts thinking tokens
inside max_tokens, OpenAI counts reasoning tokens inside
max_completion_tokens. So the PR's headline knob (claude-opus-5:max,
gpt-5.6-sol:ultra) spends the whole ceiling thinking and streams no text.
Worse, streamLopuMusing committed to that provider as soon as it pulled the
first chunk, so the user got a visibly blank musing and the canned library
never fired:

B) claude spends its whole 200-token budget thinking (stop_reason=max_tokens, no text)
   events: ["meta:claude","done"]   |   streamed text: ""   → blank musing

Fix: one shared, commented MUSING_MAX_OUTPUT_TOKENS = 4096 on both providers
(still a hard cost ceiling, with room for the text to survive the reasoning),
plus a fall-through when an attempt finishes without a single text delta — so a
starved provider degrades to the next provider and then to the canned library
instead of rendering nothing.

ai-model-routing-contract.mjs now pins all three invariants, TESTING.md has
a checklist item, and the PRs/388-… note carries a "Review round 1" section
with the full reproduction.

✅ Reviewed and correct — no change needed

• Composed-id grammar rejects unknown bases, unsupported efforts, fast on
  models with no fast lane, and repeated segments; canonicalises order so dedup
  is deterministic. No catalog id contains : and a test asserts it.
• Effort clamping matches the SDKs exactly: toAnthropicEffort → Anthropic's
  low|medium|high|xhigh|max, toOpenAiReasoningEffort → OpenAI's
  ReasoningEffort union with ultra → max. speed: 'fast' +
  fast-mode-2026-02-01 and service_tier: 'priority' all check out against the
  pinned type declarations.
• Control-plane fail-closed is real and safe. All three consumers
  (resolve-pr-conflicts.yml, rebase-pr-stacks.yml, all-branch.yml) keep the
  closed default|claude-fable-5|claude-opus-5 allowlist with a 1..3 bound and
  reject the whole response otherwise → ["default"] + ::warning::, with no
  path for a stored string to reach claude_args. Deferring the grammar
  widening to a separate github-actions PR is the right call.
• Response size vs the control plane's curl --max-filesize 65536: worst
  case is 34 base models / 226 possible unique composed entries / ~8.8 KB
  GET body. Comfortable headroom — the raised 64 KB POST cap is fine.
• Admin editor: default unremovable, normalisation on every mutation,
  duplicate guard on the canonical id, effort/speed selects gated per model and
  reset on model change, and the edit/save generation refs still stop a slow GET
  from clobbering in-flight edits.

🧪 Validation

• ai-model-routing-contract.mjs ✓ (incl. the 3 new assertions)
• settings + lopu suites: 20/20 pass, 0 fail
• moderation: 52 tests, 0 fail (12 cancelled by a module-init hang from my
  minimal scratch dep tree in the untouched moderationSettings.test.ts)
• tsc --noEmit scoped to musing.ts / claudeProvider.ts / the waterfall
  core against the repo tsconfig → exit 0
• End-to-end harness driving the real streamLopuMusing against local Anthropic
  SSE + OpenAI SSE stubs (OpenAI stub returning the genuine
  unsupported_parameter 400 for max_tokens): 18/18 checks pass —
  Claude keeps output_config.effort + speed: 'fast', OpenAI sends
  max_completion_tokens + reasoning_effort + service_tier: 'priority' and
  no max_tokens, ultra still clamps to max, and starved providers fall
  through correctly.

One thing worth your call, @lopugit: 4096 is my pick for the ceiling — generous
enough that a max/ultra entry still lands visible text, tight enough to stay
a real cost guard. Happy to dial it either way if you'd rather bound musing spend
harder.

_{🦄 Lopu · autonomous PR review}

[github-actions]

Lopu repository review

Lopu reviewed this PR against develop as Thingtime's principal PR and repository manager. Using Claude Opus 5.

The PR head moved during review, so Lopu preserved the newer branch and did not overwrite it.

Lopu review — PR #388

Unlimited AI model waterfall with the full Claude + OpenAI catalog, per-entry effort and fast mode
claude/fallback-model-selection-0281b1 → develop

Head moved mid-review. The manifest cut a worktree at d5bbe6bf; the
author pushed 09e836b2 (the test:lopu-streaming contract) at 12:09Z while
I was reviewing. I re-read the delta, confirmed every finding still applies —
claudeProvider.ts, the routing contract, and the settings route are all
untouched by the new commit — and moved my changes onto 09e836b2, the
live head, resolving one doc conflict by hand. Everything below is validated
against 09e836b2.

What I compared

Full head against its target base (16 files, +1030/−204): the composed-id core
and its tests, both direct AI consumers (lopu/musing.ts,
moderation/claudeProvider.ts), the public settings route and apiDocs.ts
registration, the Admin editor, the routing contract script, and the three
incidental hardening edits (userGenerateJWT.ts, useThingtimeMachine.tsx,
smarts/index.tsx). I also read the github-actions control plane at its
current HEAD — the consumer this PR's own notes flagged as a follow-up — and
cross-checked the installed @anthropic-ai/sdk typings for the API shapes the
PR newly sends.

Dispatching check — stale, not a defect

REVIEW_DISPATCH_ID pointed at check run 98433238180: CodeQL,
conclusion: timed_out, started 06:45Z and cut off at 06:50Z. Two things rule
out a PR-caused failure:

• Its head_sha is da61cdec…, a merge commit — not the PR head.
• Its own output.title is "No new alerts in code changed by this pull
  request", i.e. the analysis result was clean; only the PR-analysis check
  timed out waiting on the branch analysis.

CodeQL on the exact reviewed head d5bbe6bf was 98499155794 → success
(11:20Z), and on the current head 09e836b2 the whole suite is green
(Build + typecheck ratchet + unit tests → success). This was a superseded,
externally-timed-out result. No control-plane change was warranted, so
$RUNNER_TEMP/lopu-workflow-fix.md was deliberately not written.

CodeQL disposition

The trusted snapshot (lopu-codeql-alerts/388.json) is empty — zero open
alerts on this head. lopu-codeql-dispositions/388.json is left as [].
Nothing was dismissed.

Findings

1. Blocking (fixed) — an Admin effort tier permanently stalls image moderation

remix/app/api/utils/moderation/claudeProvider.ts

This PR newly makes the classifier send output_config: { effort } from the
Admin waterfall, but left the call at max_tokens: 2048 with no retry.
Anthropic bills the entry's internal reasoning against that same max_tokens
budget — the PR's own round-1 analysis establishes exactly this for the musing
path. So an admin who puts, say, claude-opus-5:max first makes the classifier
spend its budget thinking and return no text, or JSON truncated mid-object.
parseVerdict returns null and analyzeImage throws.

That is materially worse here than for musings. analyzeAttachment catches the
throw, leaves the stamp pending, and returns retryable: true; the sweep then
retries into the identical deterministic failure. Every uploaded image stays
unclassified — no verdict, no flag, no self-healing — for as long as that entry
sits first. It is a config-triggered silent outage of the moderation pipeline,
not a transient error.

Fixed by mirroring the pattern this PR already established for musings:

• MODERATION_MAX_OUTPUT_TOKENS = 4096 (same ceiling as
  MUSING_MAX_OUTPUT_TOKENS), so the verdict survives the reasoning.
• A one-shot bare retry — same model, effort dropped — when the decorated
  attempt either errors or yields no parseable verdict, so no knob can
  permanently stall the queue.
• A genuine safety refusal still short-circuits on the first attempt (it is a
  verdict, not a knob failure) and is never retried.
• The final attempt's error still propagates, so the orchestrator keeps marking
  the analysis retryable.
• The thrown message now carries stop_reason, separating budget truncation
  from a malformed answer in logs.
• Image base64 is encoded once and shared by both attempts.

Pinned in remix/scripts/ai-model-routing-contract.mjs (shared constant,
max_tokens: MODERATION_MAX_OUTPUT_TOKENS, no numeric max_tokens: literal,
and the effort ? 2 : 1 ladder), plus a TESTING.md line for the manual case.

2. Stale docs (fixed) — the control-plane limitation is resolved, not pending

The PR body, PRs/388-*.md, and remix/CHANGELOG.md all warned that the
github-actions control plane "still fail-closes to ["default"] for
non-legacy entries until its closed grammar is widened".

PR #391 merged into github-actions at 2026-08-27T11:40:11Z. I verified
against that branch's current HEAD: each entry is re-validated as
^[a-z0-9][a-z0-9.:-]{0,63}$, split into model/effort/fast segments, default
plus claude-* bases are rebuilt from the closed pattern (variants collapsing
to one CLI slot per base), the primary entry's effort drives --effort, and
OpenAI entries are skipped with a neutral log line instead of failing the chain.
TESTING.md was already updated for this; the changelog and PR note were not.
Both corrected — shipping a changelog that tells operators their saved order is
being ignored, when it is now honored, costs someone a debugging session later.

3. Overstated bound (comment fixed) — the route body cap rationale

_pr-conflict-auto-resolver-model-waterfall.tsx raised MAX_BODY_BYTES
16 KB → 64 KB, justified in-comment as "a full-catalog waterfall … is a few
tens of KB". Measured against the real catalog the worst case is 4.5 KB —
off by roughly 10x. The cap is admin-authenticated and harmless, so I kept
64 KB as growth headroom and corrected the comment to the measured figure,
rather than leave a security-relevant limit resting on a wrong premise.

Verified, no change needed

• Composed-id grammar. Fuzzed all 226 distinct composable ids: every one
  round-trips parse → canonical id → parse; validate() output is
  byte-identical after normalize(); and hostile inputs (__proto__,
  constructor, default::fast, -default, default:--model,
  leading/trailing whitespace, wrong case, 200-char ids, non-strings) never
  parse to an off-catalog id, never leak through normalize, and do not pollute
  Object.prototype.

• Transport bounds all fit. 226 ids, longest 27 chars; all match the control
  plane's charset and fit its 1..256 cap. Worst-case GET response 8.8 KB
  against curl --max-filesize 65536; worst-case POST 4.5 KB. A full-catalog
  order cannot trip any loader.

• API shapes are real. OutputConfig.effort is exactly
  low|medium|high|xhigh|max|null in the installed SDK — precisely what
  toAnthropicEffort narrows to; speed?: 'standard'|'fast' and the
  fast-mode-2026-02-01 beta both exist on the beta message surface.

• Provider resolution. Stopping the scan at the default sentinel is
  correct and symmetric for both providers; normalize always appends
  default, so the scan always terminates.

• Musing retry ladder. Never retries after emitting text (no duplicated
  musing), never swallows the final attempt, and first.done correctly treats a
  zero-delta provider as failed rather than rendering a blank message.

• The new test:lopu-streaming contract does what it claims. Ran it on the
  pinned Node 24 engine: 5/5, driving the real generator and real SDKs against
  the in-process SSE server. (It hard-fails 5/5 on Node 22 with a misleading
  getPreferredModelWaterfall is not a function, because ESM module-mock
  semantics differ — consistent with the repo's engines: node 24.x pin and
  with CI, so not a defect, just worth knowing before anyone debugs it locally.)

• Prototype-pollution guard in smarts/index.tsx is sound: JSON.parse
  does create __proto__ as an own enumerable key, Object.keys reports it,
  and the barrier runs before both the assignment and the recursion.

• No stale references to the removed PR_CONFLICT_RESOLVER_MODEL_OPTIONS
  anywhere in the repo or the control plane.

• crypto.randomUUID() in useThingtimeMachine.tsx:306. newTimeline runs
  at ThingtimeLine() construction, so a non-secure origin would fail app boot
  where the previous Math.random() did not. Round 3 already dispositioned
  this; I re-verified rather than carrying it forward, and it holds: the dev
  server binds loopback only (vite.config.ts:193 host: '127.0.0.1',
  dev:vite --host 127.0.0.1, dev-nitro.cjs --host 127.0.0.1), previews
  and production are HTTPS, and SSR is Node 24. There is no http://<LAN-IP>
  path where randomUUID would be undefined. No change needed.

Noted, deliberately not changed

• resolveAiPreferredClaudeModel now has no production consumer — only its
  own tests. Keeping it as a documented compatibility accessor is defensible;
  flagging it so it does not quietly become permanent dead code.

Validation run

From the PR worktree at the live head 09e836b2 with my changes applied, on the
repo's pinned Node 24 engine.

Check	Result
pnpm test:settings	15 pass / 0 fail
pnpm test:lopu	5 pass / 0 fail
pnpm test:lopu-streaming	5 pass / 0 fail
pnpm test:moderation	52 pass / 0 fail
node scripts/ai-model-routing-contract.mjs	self-test OK (incl. 5 new moderation-budget assertions)
pnpm typecheck:ratchet	138 errors, down from baseline 143
tsc --noEmit, changed files	no errors in either changed source file
pnpm lint:files, changed files	clean
Catalog/grammar fuzz (226 ids, hostile inputs, bounds)	all assertions pass

Files changed in this review

File	Change
remix/app/api/utils/moderation/claudeProvider.ts	Reasoning-budget ceiling + one-shot bare retry (finding 1)
remix/scripts/ai-model-routing-contract.mjs	Pin the new moderation invariants
TESTING.md	Manual checklist line for the moderation budget
remix/CHANGELOG.md	Correct the resolved control-plane claim; note the moderation fix
PRs/388-…​.md	Round-5 section; control-plane section marked resolved; measured bounds
remix/app/routes/…/_pr-conflict-auto-resolver-model-waterfall.tsx	Correct the body-cap rationale comment

Assessment

Strong PR. The composed-id grammar is well designed — forgiving reads, strict
writes, canonical storage, catalog-as-data — and fuzzing found nothing. The
round-4 streaming contract is a real behavioral test, not a shape assertion, and
it passes.

The one remaining defect was the PR's own round-1 lesson not being carried
across to the second consumer it had just modified. That is now fixed and
pinned so it cannot regress. With the moderation budget in place I have no
blocking objection to merging.

View Lopu workflow run

[github-actions]

🤝 Merged develop into claude/fallback-model-selection-0281b1 — conflicts auto-resolved by Lopu's PR manager.

No AI resolution was needed by merge time; the branch was updated with a plain merge commit.

graphify-out/ was reset wholesale to the develop side (repo rule: one side, never mixed — the graph merge driver is unavailable in CI).

Rebuilt the merged code graph first with graphify update ., then ran LLM semantic extraction (graphify extract ., claude-cli backend) and committed the result.

Please review the merge commit before relying on it.

[github-actions]

🦄 Lopu review — PR #388 (round 2)

Reviewed fc428529 against 25989863. Round 1's max_completion_tokens /
MUSING_MAX_OUTPUT_TOKENS work is in this head and holds up. All checks are green —
I verified the two things that look like noise rather than assuming:

• test:moderation shows 12 cancelled subtests. I re-ran the suite with
  claudeProvider.ts reverted to its base version and got the identical
  40 pass / 0 fail / 12 cancelled → pre-existing runner artefact, not this PR.
• The ratchet reports +8, not the +7 in the description. Every new error is in
  Commander* / Feed.tsx / MagicInput.tsx, and I confirmed +8 with and without my
  own edits — so the drift is unrelated baseline files, exactly as you wrote. Non-blocking.

---

🔧 The control-plane follow-up is done — and it was worse than "preference ignored"

Round 1 called the fail-closed behaviour "real and safe" and deferred it. Safe, yes, but
I measured the blast radius and it's bigger than the description implies.

All three consumers validate with a single whole-array select over the closed trio
plus a 1..3 bound. Because the predicate is array-level, one new-style entry
invalidates the entire response, and the bash loop then hard-fails closed on the first
unrecognised id. So the moment an admin uses this feature at all, conflict resolution,
the rebase/stack-cascade engine, and the all-branch doctor discard the whole order —
including the plain Claude entries the control plane can run perfectly well.

Replaying your own live-browser order against the real workflow script:

['claude-opus-5:high:fast','default','gpt-5.6-sol:ultra','gpt-5.3-codex:xhigh','claude-haiku-4-5']
  → before:  --model default                                              # order lost
  → after:   --model claude-opus-5 --fallback-model default,claude-haiku-4-5
             ::notice::Skipped 2 waterfall entries this backend cannot run

That root cause lives in .github/workflows/**, so it does not go on this branch —
I fixed it in the protected controller and it ships as a dedicated Lopu PR against
github-actions.

The interesting part for you: I could not fix it by listing the eight Claude models.
The control plane has contract assertions (contains no legacy model, contains no hardcoded --model selection) that exist precisely to stop a second catalog drifting
there — my first attempt enumerated the models and those assertions correctly rejected it.
So the loaders now validate entry shape against an injection-safe charset and read
eligibility from .models[].provider — the field this PR adds. Publishing provider
in the catalog projection is what made a name-free fix possible; nice side effect of the
design. Entries the backend can't run are now skipped with a notice instead of nuking the
order, and I replayed the extracted step scripts against 11 fixtures (legacy orders, the
new grammar, pre-#388 responses, "claude-opus-5; rm -rf /", "--dangerously-skip-permissions",
truncation) — injection attempts still fail closed to ["default"].

---

🐛 One gap left on this branch: the bare retry misses the case it was added for

streamClaude retries bare only when the decorated attempt throws
(musing.ts:191-206). But the failure round 1 identified — "a text-sized cap is spent
thinking and the musing streams back empty" — isn't a throw. The stream completes having
emitted no text_delta, the generator returns, and streamLopuMusing sees first.done
and moves to the next provider.

So claude-opus-5:max exhausting its budget on reasoning skips Claude entirely rather
than retrying without output_config — the admin's Claude preference silently loses to
OpenAI or the canned library. The fall-through added in round 1 protects the user (no
blank musing ✅) but not the preference.

Suggestion: treat !yielded on a decorated attempt the same as a throw, so it falls
through to the bare attempt before giving up on the provider. I left it alone deliberately —
it costs an extra API call per starved attempt, and that ceiling/retry trade-off is your
call, same as the 4096 question from round 1.

Two smaller ones, both optional:

• getLopuModelChoices() sits inside the provider loop (musing.ts:306), so a musing
  whose first provider fails does two Mongo reads. getWaterfall catches internally and
  never throws, so hoisting it above the loop is safe.
• PICKER_PROVIDERS = ['anthropic', 'openai']
  (PRConflictResolverModelWaterfallEditor.tsx:36) is the one spot that doesn't derive
  from the catalog — a third provider would validate and resolve but stay invisible in the
  picker, which dents the "adding a model here is the whole registration" promise.

---

🔒 CodeQL — 16 open alerts, none from this diff

Inspected all 16. Five fixed here, eleven dispositioned with evidence. Nothing real was
dismissed to green a check.

The one worth your attention is genuinely serious and unrelated to this PR:
smarts/index.tsx merge was prototype-polluting. Object.keys reports __proto__
as an own key when the object came from JSON.parse, so a thing authored by someone
else and merged into local state could write straight onto Object.prototype. I
confirmed it live against the base — ({}).pollutedA === "yes" via __proto__ and
({}).pollutedB === "yes" via constructor.prototype. Added a POLLUTING_KEYS guard
covering both flagged assignment sites and the recursion; all four checks pass and
ordinary deep-merge output is unchanged (test:autosave 23/23, test:persist 11/11).

Also fixed: userGenerateJWT.ts seeded a token id from Math.random() — dead today, but
FUNDAMENTALS.md §5 still names it as the JWT minting path, so the trap is live for
whoever implements it (now randomUUID(), matching auth/sessions.ts). And two dead
debugUuid assignments in useThingtimeMachine.tsx.

The eleven dispositions are React keys / DOM ids with no security context, a local Raycast
clipboard command with no untrusted source or sink, permissive CORS in deprecated/api
(no workspace entry, no build script, no Vercel or workflow reference — never served), the
admin-gated + redacted stack-trace sink, and the four verify-*.mjs test-suffix alerts.

---

Verdict: ship it. The strict-write / forgiving-read asymmetry is the right asymmetry,
canonical composed ids keep storage deterministic, and the legacy ids, persisted key, and
endpoint shape are all genuinely preserved. The retry gap above is a follow-up, not a
blocker.

_{🦄 Posted by Lopu, Thingtime's repository steward.}

[lopugit]

Round-2 follow-ups applied in 523fc3b: the starved-decorated-stream case now retries bare on the same provider before falling through (both providers, symmetric with the throw path — no retry after first emitted delta); the waterfall choices read is hoisted above the provider loop (one durable read per musing); PICKER_PROVIDERS now derives from the catalog. Suites green: settings 15, lopu 5, routing contract OK.

[github-actions]

🦄 Lopu review — PR #388 (round 3)

Thanks @lopugit — I verified all three round-2 follow-ups on 13f7f5fb behaviourally, not
by reading, and every claim in your comment holds. One real gap was left behind, and I fixed it.

✅ Round-2 follow-ups verified

I drove the real streamLopuMusing against local Anthropic + OpenAI SSE stubs (the genuine
store → normalize → resolver chain runs; only the settings collection is mocked) and asserted on
the actual request bodies. 21/21 checks pass.

Scenario	Observed
Claude decorated attempt emits zero text deltas	2 Anthropic requests — #1 carries output_config.effort: max, #2 drops it, both keep max_tokens: 4096; source stays claude; OpenAI never called
Both Claude attempts starve	falls through to OpenAI, and no blank meta:claude is emitted first
Decorated attempt that does emit text	exactly 1 request — no retry, no duplicated musing
OpenAI side	symmetric — #1 has reasoning_effort: max + service_tier: priority, #2 drops both
Hoisted read	1 settings read across a musing that made 3 provider attempts (was 2)

Your "symmetric with the throw path" is exact — the guard is byte-identical in both providers,
and the non-decorated case is untouched because attempts.length === 1 there.

I also checked the thing the hoist could have broken: the read now sits outside the provider
loop's try, so it had better not throw. It can't — getWaterfall wraps its whole body and
returns lastKnownGood || DEFAULT, and neither resolver has a throw path
(resolveAiPreferredAnthropicChoice synthesises a choice when baseModelById.get() misses,
resolveAiPreferredOpenAiChoice returns null). The endpoint still degrades to the canned
library rather than erroring. And PICKER_PROVIDERS stays type-safe: AI_MODEL_PROVIDER_LABELS
is keyed by the provider union, so a new provider forces a label at compile time instead of
rendering an empty <optgroup>.

✅ da61cdec — and you were right to fix rather than dismiss

The Set→literal-comparison rewrite is semantically identical and CodeQL agrees: #18/#19 are
gone from this head's snapshot. I re-ran my pollution harness against the rewritten guard —
all four routes (__proto__, constructor.prototype, the overwriteAll assignment site,
nested recursion) still blocked, ordinary deep-merge output unchanged.

On the timeline uuid: your call beat mine. I had dispositioned that alert as DOM identity in
round 2; it's a store identity value, so fixing it was the right read. I checked the
secure-context trap that crypto.randomUUID() can carry and it doesn't apply here — the dev
server binds 127.0.0.1 only (vite --host 127.0.0.1, plus host: '127.0.0.1' in
vite.config.ts), previews/production are HTTPS, and SSR is Node ≥19. No http://<LAN-IP> path
where it would be undefined.

🔧 Fixed: the new behaviour was pinned by nothing

523fc3bb fixes exactly the defect I reported in round 2 — and nothing guards it.
musing.test.ts only covers createLopuModelChoicesResolver, and the contract pinned the token
budget but not the fall-through. Reverting

if (yielded || attempt === attempts.length - 1) return;   // →   return;

reintroduces the silently-skipped-provider bug with every suite still green. I confirmed that
by doing it.

So ai-model-routing-contract.mjs now pins two more invariants, in its existing style: the
starvation guard must appear exactly twice (once per provider), and the choices read must
appear above the provider loop so the hoist can't regress either. Negative control: reverting
one provider's guard fails with streamClaude and streamOpenAI must each fall through to their bare retry on a starved (zero text delta) attempt.

I deliberately didn't add the SSE harness to the suite — it needs
--experimental-test-module-mocks, which no existing test:* script uses, so adopting that is
your convention call, not a reviewer's. Say the word and I'll land it as test:lopu-streaming;
it's ~180 lines and covers all five scenarios above.

🟡 The one non-green check is not yours

control-plane / Lopu builds and repairs the all branch (run 33047763923) has been pending
since 06:57Z. all-branch.yml serialises on a repository-wide group
lopu-agent-fleet-${{ github.repository }} with cancel-in-progress: false, so every branch's
union build queues behind one global lock. Across the last 40 all-branch runs: 28 pending, 0
in-progress, and the most recent completed run succeeded at 08:05Z after 1h28m. The queue is
moving, just slowly, and this run is behind unrelated branches. Nothing to repair on the branch,
and I made no control-plane change — global fleet-lock throughput is a deliberate design choice,
not something to redesign off the back of a follow-up review. Everything else: 21 pass, 0 fail,
CodeQL green on this head.

🔎 CodeQL — 10 open alerts, all dispositioned

All pre-existing; the five I fixed in round 2 plus the timeline uuid have dropped out. I
re-inspected every remaining alert at this head rather than carrying my earlier calls forward.
One is worth flagging because it changed my evidence: for #45 (permissive CORS in
deprecated/api) I noticed the root package.json still has api and postinstall scripts
that mention api — they point at a top-level api/ directory that no longer exists, so
they'd fail rather than start that server. Still never installed, built, or served, but the
evidence is now that rather than "no script references it". (Those two dead root scripts are
pre-existing repo hygiene, unrelated to this PR — worth a separate tidy sometime.)

The rest: #8/#14/#26 traced to their consumers and used only as React keys, DOM ids, a
@keyframes scope, and the window.meta.things debug registry; #17 a local Raycast command
over the developer's own clipboard; #49 admin-gated, owner-scoped via gate.user.id,
no-store, and redacted through sanitizedStack/redactText; #77–#80 used in tests.
Nothing real was dismissed to green a check.

---

Assessment unchanged: I'd merge this. The round-2 follow-ups are correct as written, and
this round found no defect in the feature code — only the missing guardrail, now in place.

_{🦄 Lopu · autonomous PR review · head 13f7f5fb}

[lopugit]

Round-3 ack: pulled the two new routing-contract pins (fall-through count + hoisted read) — self-test passes locally. On the SSE harness: yes please, land it as test:lopu-streaming — it caught behavior no existing suite can see, and the experimental flag stays scoped to that one script. Thanks for the all-branch queue analysis; agreed it's queue position, not a defect.

[lopugit]

Implemented the approved test:lopu-streaming behavioral contract in 09e836b2f.

The harness runs the real Anthropic and OpenAI SDKs against an in-process SSE server and mocks only the Mongo-backed waterfall read. It now proves:

• decorated Claude zero-text retry -> bare same-model retry while preserving token budget
• exhausted Claude -> OpenAI fallback without blank Claude metadata
• visible Claude text prevents a same-provider replay
• equivalent OpenAI decorated -> bare retry behavior
• complete provider starvation -> non-empty canned fallback + terminal done

Validation on the exact pushed head:

• test:lopu-streaming: 5/5
• existing Lopu tests: 5/5
• AI model routing: pass
• settings: 15/15
• moderation: 52/52
• full test:unit: pass
• typecheck:ratchet: 138 errors vs 143 baseline
• production Vite/Nitro/Vercel build and output verification: pass
• Graphify structural snapshot: 28,960 nodes / 72,092 edges
• semantic pass completed through the local Codex proxy; three new results entered the immutable cache, while the fuller structural snapshot remained the canonical routed snapshot

[github-actions]

🦄 Lopu review — PR #388 (round 5)

Thanks @lopugit — test:lopu-streaming is exactly the harness we agreed on in round 3, and I
verified it rather than taking the report on faith: 5/5 on the pinned Node 24 engine, driving
the real generator and the real SDKs against the in-process SSE server. It asserts observable
behaviour, not call shapes. Good.

This round I widened the lens past the musing path and found one real defect left in the other
consumer this PR modified. Fixed in the worktree.

🔴 An Admin effort tier permanently stalls image moderation

Round 1 established the mechanic for musings: both providers bill internal reasoning against the
request's output budget. That lesson was never carried across to moderation/claudeProvider.ts —
the second file this PR newly taught to send output_config.effort. It still sent
max_tokens: 2048, with no retry:

const response = await client.messages.create({
  model: choice.model,
  ...(effort ? { output_config: { effort } } : {}),
  max_tokens: 2048,        // ← the verdict AND the reasoning share this
  ...
});

Put claude-opus-5:max first in the Admin order — which the new picker actively invites — and the
classifier spends its budget thinking. It returns no text, or JSON truncated mid-object.
parseVerdict → null → analyzeImage throws.

This is worse than the musing case, and that is the part worth pausing on. A starved musing
degrades to the canned library for one request and the next one is fine. Here,
analyzeAttachment catches the throw, leaves the stamp pending, and returns retryable: true —
so the sweep retries into the identical deterministic failure. Nothing about it is transient.
Every uploaded image stays unclassified — no verdict, no flag, no self-healing — for as long as
that entry sits first. A config-triggered silent outage of the moderation pipeline, reachable
from a dropdown, with the sweep's retry loop guaranteeing it never recovers on its own.

Fix — mirrors the pattern this PR already established, rather than inventing a second one:

Budget	MODERATION_MAX_OUTPUT_TOKENS = 4096, same ceiling as MUSING_MAX_OUTPUT_TOKENS
Retry	one shot bare — same model, effort dropped — when the decorated attempt errors or yields no parseable verdict
Refusal	still short-circuits on attempt 0 and is never retried (it's a verdict, not a knob failure)
Final failure	still propagates, so the orchestrator keeps marking the analysis retryable
Diagnosis	thrown message now carries stop_reason, separating budget truncation from a malformed answer
Cost	image base64 encoded once, shared by both attempts; the second call only happens on failure

Pinned in ai-model-routing-contract.mjs in its existing style — the shared constant,
max_tokens: MODERATION_MAX_OUTPUT_TOKENS, no numeric max_tokens: literal anywhere in the file,
and the effort ? 2 : 1 ladder — plus a TESTING.md line for the manual case.

📄 The control-plane warning is now stale — it says the opposite of the truth

remix/CHANGELOG.md and the PR note still tell operators the control plane "still fail-closes to
["default"] for non-legacy entries until its closed grammar is widened."

#391 merged into github-actions at 11:40Z today. I read that branch's HEAD: entries are
re-validated as ^[a-z0-9][a-z0-9.:-]{0,63}$, split into model/effort/fast segments, default
plus claude-* bases rebuilt from the closed pattern (variants collapsing to one CLI slot per
base), primary effort driving --effort, OpenAI entries skipped with a neutral log line. It
works. TESTING.md was already updated for this; the changelog and PR note weren't. Corrected
both — a changelog that tells someone their saved model order is being ignored, when it is now
honoured, costs a debugging session later.

📏 Bounds measured rather than estimated

The route comment justified MAX_BODY_BYTES 16 KB → 64 KB with "a full-catalog waterfall … is a
few tens of KB". Actual numbers from the catalog:

Distinct composable ids	226 (longest 27 chars)
Worst-case POST body	4.5 KB (route cap 64 KB)
Worst-case GET response	8.8 KB (control plane's curl --max-filesize 65536)
Control-plane array cap	226 of 256 — a full-catalog order can't trip it

Off by ~10x. The cap is admin-authenticated and harmless, so I kept 64 KB as growth headroom and
corrected the comment — I'd rather not leave a security-relevant limit resting on a wrong premise.

✅ Also checked, nothing found

• Grammar fuzzed. All 226 ids round-trip parse → canonical id → parse; validate() output is
  byte-identical after normalize(); and hostile inputs (__proto__, constructor,
  default::fast, -default, default:--model, whitespace, wrong case, 200-char ids,
  non-strings) never parse to an off-catalog id, never leak through normalize, and don't pollute
  Object.prototype.
• API shapes are real, not aspirational. OutputConfig.effort in the installed SDK is exactly
  low|medium|high|xhigh|max|null — precisely what toAnthropicEffort narrows to — and both
  speed?: 'standard'|'fast' and fast-mode-2026-02-01 exist on the beta surface.
• Timeline uuid, re-verified not carried forward. Round 3's disposition holds: the dev server
  binds loopback only (vite.config.ts:193, dev:vite --host 127.0.0.1, dev-nitro.cjs --host 127.0.0.1), previews/production are HTTPS, SSR is Node 24. No non-secure-context path.
• Zero open CodeQL alerts on this head, so nothing to fix and nothing dispositioned.
• Dispatching check was stale, not yours. I was woken by CodeQL check 98433238180
  (timed_out) — but its head_sha is a merge commit, and its own output title reads "No new
  alerts in code changed by this pull request." Only the PR-analysis check timed out waiting on
  the branch analysis. CodeQL on the real head passed. No control-plane change warranted.

🟡 One heads-up for local runs

test:lopu-streaming hard-fails 5/5 on Node 22 with a misleading
dependencies.getPreferredModelWaterfall is not a function — ESM module-mock semantics differ
across versions. It's green on the pinned Node 24 and in CI, so nothing to fix; just don't lose an
hour to it the way I nearly did.

---

Note on the head: my worktree was cut at d5bbe6bf; you pushed 09e836b2 at 12:09Z while I
was reading. I re-read the delta, confirmed claudeProvider.ts, the routing contract and the
settings route are all untouched by it, and moved my changes onto 09e836b2 so they apply to
the live head. My PR-note section landed as round 5 to sit after your round 4.

Validated on 09e836b2, Node 24: settings 15/15 · lopu 5/5 · lopu-streaming 5/5 ·
moderation 52/52 · routing contract OK · ratchet 138 vs 143 baseline · lint and tsc clean on both
changed files.

Assessment: I'd merge this once the moderation budget lands. The composed-id grammar is
genuinely well built — forgiving reads, strict writes, canonical storage, catalog-as-data — and
fuzzing it found nothing at all.

_{🦄 Lopu · autonomous PR review · head 09e836b2}

[github-actions]

✅ Promoted to main in #441.

An earlier run stood aside on this PR; that verdict no longer applies.

[github-actions]

✅ Promotion #441 has verified source lineage at current develop tip 98a24869116fc8da2ab778152a52f75a956fd4de.

[lopugit]

🚀 Promotion PR for main opened: #441