Saving LLM Default Model Fails When Existing Specialized Model Preferences Reference Inactive Models

Developers
1

I am trying to update the default model under More → Advanced → LLM, and it fails with a Failed to save settings. response.

Steps to Reproduce

  1. Use an account whose saved LLM preferences include a specialized model that is no longer present in the active model catalog.
  2. Open More → Advanced → LLM.
  3. Change the default model (for example, the Code model).
  4. Click Save.
    Then you are expected to see a failed message.

Detailed Information

The save request fails with HTTP 400, and the updated default model is not saved.

Example frontend console error:

PUT https://staging.anna.partners/api/v1/user-settings/settings 400 (Bad Request)

Error saving settings: Error: Model 'fun-asr-realtime-2026-02-28' for 'stt' not found or is inactive

Another observed API response:

{
  "detail": "Model 'qwen3-tts-instruct-flash-realtime' for 'tts' not found or is inactive"
}

The request payload contains the complete model_preferences object, including specialized models that the user did not modify. For example:

{
  "model_preferences": {
    "code": "google/gemini-3-flash-preview",
    "vision": "google/gemini-3.1-flash-image-preview",
    "image_edit": "fal-ai/nano-banana-2",
    "image_gen": "doubao-seedream-5-0-260128",
    "stt": "fun-asr-realtime-2026-02-28",
    "tts": "qwen3-tts-instruct-flash-realtime"
  }
}

Suspected Root Cause

This appears to be a synchronization issue between the active model catalog and persisted user preferences:

  1. The account has historical stt and/or tts preferences pointing to models that have been removed or deactivated.
  2. The frontend loads and resubmits these values as part of the full model_preferences payload.
  3. The backend validates every model preference for existence and active status.
  4. Validation of one stale specialized model fails, so the backend rejects the entire request atomically.

Therefore, the failure is not necessarily caused by the default model being changed. It is triggered by unrelated inactive specialized model values included in the same save request.

Suggested Fixes

I suggest that the platform should take at least one of the following measures to prevent users from encountering this situation again.

  1. Changing a default model should succeed when the newly selected model is valid, even if unrelated historical specialized preferences reference models that have since become inactive;

  2. Clearly identify invalid specialized preferences and require the user to select valid replacements before saving.

2

Hi @Yinghuo_Mars! :waving_hand:

Thank you so much for this wonderfully detailed report — the repro steps, payload examples, and root-cause analysis made this a joy to investigate. Your suspicion was spot on! :bullseye:

:white_check_mark: Fixed in v1.1.0-beta.182 — shipping this Friday

Saving your settings no longer fails when previously saved specialized model preferences reference models that are no longer in the active catalog. The backend now only validates the preferences you actually changed in a save request — untouched historical entries can never block an unrelated update again. :hammer_and_wrench:

The fix is expected to roll out this Friday. Once it’s live, you’ll be able to update your default and specialized models normally, with no manual cleanup needed on your side.

:telescope: What’s next

Your report also highlighted some rough edges in the Specialized Models module as a whole, and we really appreciate that. We’re planning a broader upgrade of this feature in an upcoming update — smarter handling of model catalog changes and a smoother configuration experience. Stay tuned! :sparkles:

Thanks again for helping us make Anna better — feedback like yours is exactly what keeps the platform improving. Happy building! :yellow_heart: