fix(provider): drop removed custom models from the model picker by StiensWout · Pull Request #9075 · pingdotgg/t3code

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

StiensWout · 2026-09-01T18:26:12Z

Removing a custom model in Settings did not remove it from the model picker. The row stayed in the composer picker and in every settings picker, and it survived server restarts.

The server's provider aggregator merges each refreshed snapshot with the previous one and, for every driver except OpenCode, keeps any model that the new snapshot no longer reports. Custom models are built from settings on every probe, so the removed slug was missing from the new snapshot and got re-added from the old one on every refresh, then persisted to the boot cache. The web option builder also took custom rows straight from the server snapshot instead of settings.

Custom rows are owned by settings and every snapshot already carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows. The web option builders only take built-ins from the snapshot and rebuild custom rows from settings, so a removal disappears immediately instead of waiting for the next probe. Mobile reads the server list directly and is fixed by the server change.

Focused tests cover the aggregator merge, the boot-cache hydrate, and the web option list.

Made with Claude Fable 5.1 in T3 Code.

Note

Medium Risk
Changes provider snapshot merging and model-picker assembly, which could affect model lists at runtime, but scope is limited to custom-model retention with targeted tests.

Overview
Fixes removed custom models sticking around in the composer and settings pickers (and across restarts) by treating custom model rows as settings-owned instead of mergeable snapshot history.

On the server, mergeProviderSnapshot and boot cache hydration no longer carry forward previous or cached isCustom models when the current settings-derived snapshot omits them; built-in models still get the existing “retain on empty/partial refresh” behavior. On web, getAppModelOptions / getAppModelOptionsForInstance take built-ins only from the provider snapshot and rebuild custom options from settings, so a deletion shows up immediately even if the server list is stale.

Adds regression tests for registry merge, cache hydrate, and web option lists.

^{Reviewed by Cursor Bugbot for commit 6f05db6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Drop removed custom models from provider snapshots, status cache, and model picker

Filters custom models out of the retained set in mergeProviderModels so a refreshed provider snapshot no longer resurrects custom models that were removed from settings
Excludes custom cached models during hydrateCachedProvider hydration so the status cache does not bring back custom models absent from the settings-derived fallback snapshot
Ignores server-reported custom models in getAppModelOptions and getAppModelOptionsForInstance, rebuilding custom rows solely from user settings so removals take effect immediately
Risk: any code path that relied on server-reported or cached custom models surviving a refresh will no longer see them; check mergeProviderModels in ProviderRegistry.ts and hydrateCachedProvider in providerStatusCache.ts for downstream consumers

^{Macroscope summarized 6f05db6.}

Removing a custom model in Settings left it in the model picker. The server aggregator merged each refreshed snapshot with the previous one and retained every model missing from the new snapshot, so the removed custom row came back on every probe and was persisted to the boot cache. The web picker also took custom rows straight from the server snapshot. Custom rows are settings-owned and every snapshot carries the full current list, so the aggregator and boot-cache merges now never retain previous custom rows, and the web option builders only take built-ins from the snapshot and rebuild custom rows from settings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

macroscopeapp · 2026-09-01T18:43:02Z

Approvability

Verdict: Approved at 6f05db6

Macroscope's review found this PR approvable — This is a focused provider model-picker bug fix that removes stale custom entries from snapshot merging, cache hydration, and UI option construction while preserving current settings and built-in models. The changes are limited, covered by targeted tests, and introduce no schema, deployment, security, billing, or static-analysis risk.

^{You can add or adjust custom eligibility rules. Learn more.}

MatthewFeroz · 2026-09-02T04:03:30Z

just verified looks good to me

github-actionsBot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:M 30-99 changed lines (additions + deletions). labels Sep 1, 2026

macroscopeappBot approved these changes Sep 1, 2026
View reviewed changes

maria-rcks merged commit 941acb4 into pingdotgg:mainSep 2, 2026
23 checks passed

berghtho mentioned this pull request Sep 2, 2026
chore(upstream): sync 2026-09-02 berghtho/t3code#20
Draft