[HouMinXi]

openai-gpt-sol pins codex/gpt-6-astra-high. Live 2026-09-13 the Codex leg returned HTTP 200 and combo quality validation marked the stream streaming upstream error, so the combo step failed 502. Family fallback never ran: quality 502 returned from executeTargetAttempt without calling getNextFamilyFallback, and FAMILY_FALLBACK_TEMPLATES had no Astra rows.

onmi-gemini3.6 pins agy/gemini-3.8-flash-high. Empty-content already hops in nonStreamingProviderLeg, but the family table had no 3.8 rows. parseModel("agy/...") canonicalizes provider to antigravity, whose static catalog listed 3.7 only, so hop candidates were filtered out.

What

• Add GPT-6 Astra effort-alias family (high -> max -> ultra).
• On quality-invalid 200, hop the same connection to the next sibling instead of failing the combo step. Do not consume combo maxRetries. Guard hop when provider is missing.
• Add Gemini 3.8 Flash family (high -> medium -> low). Prefer combo alias / providerHint for registry lookup so agy/ hops against the catalog the combo named.

Not subsumed by later merges

• fix(sse): classify a 2xx body as a disguised upstream failure (#13461) #13910 classifies a 2xx body whose assistant text is the provider's own error prose (credits exhausted, and similar). This hop is for quality-empty 200: the stream is structurally a completion, combo validateQuality rejects it, and we want the next effort alias on the same connection. Tip executeTargetAttempt still returns qualityValidationFailure() immediately after handlePreContentStreamRetry; there is still no family hop.
• fix(combo): retry pre-content streaming failures #13630 retries pre-content streaming failures. The hop here is after that helper returns false. Same function, different branch.

Catalog files were rebased onto buildSurfaceCatalog / ANTIGRAVITY_SHARED_MODELS. Unique vs current release/v3.8.51: family templates, the hop in executeTargetAttempt, providerHint lookup, tests.

Test

tests/unit/combo/execute-target-attempt.test.ts and tests/unit/model-family-fallback-notation.test.ts: 21/21. Inject: drop the Astra high template -> 3 fail; drop the hop continue -> 1 fail; drop Gemini 3.8 high template -> 1 fail. Restore: 21/21.

This is submitted for review and merge. The earlier hold wording was a mistake, not a request to defer.

⚠️ base-red inherited: #13866

[diegosouzapw]

Solid root-cause work on both the Astra quality-empty-200 case and the Gemini 3.8
family-table gap — ran your two test files at head, 21/21 pass. I noticed the PR body
ends with "Contributor only. Do not merge." — flagging that I'm respecting that and
holding this as defer rather than routing it toward merge. Whenever you're ready to
have it merged, just let us know and we'll also need to reconcile it with #13630, which
touches the exact same return branch in executeTargetAttempt.ts (different mechanism,
same hunk) — happy to help coordinate the rebase order at that point.

[diegosouzapw]

Leaving this one as you asked — the title still carries [defer] and the body says contributor-only, do not merge. Noting for whenever you pick it up again:

• open-sse/config/agyModels.ts and open-sse/config/antigravityModelAliases.ts now conflict with the tip: the catalog there was refactored to buildSurfaceCatalog / ANTIGRAVITY_SHARED_MODELS, while this branch still carries the literal AGY_PUBLIC_MODELS array shape. A rebase will need the new builder.
• The idea itself (hopping a quality-invalid 200 to the next family sibling without consuming combo maxRetries) is sound and we would review it properly once you lift the defer.

Nothing to do on your side right now; just keeping the record straight.

[HouMinXi]

@diegosouzapw I do want this contribution merged. The earlier "Contributor only / Do not merge" wording was my mistake; it described who would perform the merge, not a request to hold the PR. Sorry for the confusion. I have removed that wording and the [defer] title prefix.

Your technical concerns still stand: the catalog changes need to use the current buildSurfaceCatalog / ANTIGRAVITY_SHARED_MODELS structure, and the quality-invalid return path must be reconciled with #13630. Removing the accidental hold is not a claim that those conflicts or checks are already resolved.

[diegosouzapw]

Segurando conforme o veredito defer do plan-file, e o conflito com a base reforça.

A PR está conflitante com release/v3.8.51 e o plan-file já a marcava como defer (⭐4) — ou seja, o adiamento não é pela qualidade, é de sequenciamento.

Ela mexe na mesma área que várias PRs mergeadas hoje (o caminho de combo/fallback recebeu #12956, #12957, #13630 e outras), então o conflito tende a crescer, não encolher, enquanto ela espera.

Sugestão: rebase sobre o tip atual antes de retomar a avaliação — o veredito ⭐4 foi medido contra uma base bem anterior e precisa ser reconfirmado contra o que existe hoje. Vale especialmente verificar se o hop de quality-empty 200 do Astra ainda é necessário depois da #13910 (classify a 2xx body as a disguised upstream failure), que ataca uma classe parecida de problema.

[HouMinXi]

Rebased onto current release/v3.8.51.

The quality-empty hop is still needed. #13910 (classifyFakeSuccessBody) is allowlisted to pollinations / perplexity-web and looks for error prose in a 200 body. Astra quality-empty and Gemini 3.8 empty-content are a different class: HTTP 200 with no usable assistant text, not a disguised failure sentence.

Conflict resolution kept the tip's pre-content streaming retry (handlePreContentStreamRetry) and runs the family hop after it. Unknown providers do not hop.

Tests: 21/21 on the hop + family tables. Injection: forcing familyNext = null turns the Astra hop red; restoring it is green.

Head 38516bf198.

[HouMinXi]

Rebased onto current release/v3.8.51 (1603c86e06). GitHub now reports MERGEABLE / 0 behind.

Checked #13910 against this hop: it classifies a 2xx body whose assistant text is the provider's own error prose. The Astra case is a quality-empty 200 (validateQuality → streaming upstream error) on a structurally normal completion. Tip executeTargetAttempt still returns qualityValidationFailure() right after handlePreContentStreamRetry; there is no family hop on that path. #13630 covers the pre-content retry helper above this branch.

Family templates for Astra and Gemini 3.8, plus the hop, are still unique vs tip. Tests 21/21 on this tree.

Please re-evaluate when you have a slot. The earlier defer / contributor-only wording is withdrawn.

[HouMinXi]

Rebased onto current release/v3.8.51 (36493a6270). Unique commits unchanged.

[HouMinXi]

Live combos this hop is for were not Gemini failing over to Claude.

onmi-gemini3.6 has 10 steps. Every step is agy/gemini-3.8-flash-high on a different Antigravity account. Quality-empty 200 fails that account and tries the next Gemini account, or returns 502.

openai-gpt-sol has two steps, both codex/gpt-6-astra-high (live is -xhigh) on two Codex accounts. Quality-empty 200 does the same thing: next account, or 502.

On 2026-09-13 Codex returned HTTP 200 with no visible text. validateQuality marked streaming upstream error. executeTargetAttempt returned 502 without calling getNextFamilyFallback, and the family table had no Astra rows. Gemini 3.8 already hops empty content in nonStreamingProviderLeg, but agy/ canonicalizes to antigravity and that catalog only listed 3.7, so the hop candidates were filtered out.

This PR hops the same connection to the next effort alias: Astra high -> max -> ultra, Gemini 3.8 high -> medium -> low. It does not spend combo maxRetries. After the family is exhausted, the existing step failover still runs.

A combo that pins *-high can still return medium/low (Gemini) or max/ultra (Astra) after a quality-empty 200. If that is unacceptable, keep those ids out of FAMILY_FALLBACK_TEMPLATES.

[diegosouzapw]

Re-homed to release/v3.8.52: v3.8.51 entered its release freeze, so the branch now belongs to the release captain and development continues on the next cycle. Nothing is wrong with this PR — it just needed a live base. No action needed from you; CI will re-run against the new base.