fix: separate reasoning metadata from provider config

[Soulter]

Model capability metadata can include reasoning: true. The dashboard was copying that descriptive flag into per-model provider configuration, which caused the generic configuration editor to expose it as an editable request setting. Capability metadata and request configuration need to remain separate.

Modifications / 改动点

• Derive the reasoning capability badge directly from model metadata instead of persisted provider configuration.
• Stop writing reasoning into newly created model providers and remove legacy copies from source-backed provider records at dashboard API boundaries.
• Preserve arbitrary fields on standalone providers that are not source-backed.
• Add a reasoning_effort string preset to custom request body parameters with high as its default value.
• Add regression coverage for schema serialization, provider creation, provider updates, and standalone-provider compatibility.
• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

• uv run ruff format . — 501 files unchanged
• uv run ruff check . — passed
• uv run pytest tests/test_fastapi_v1_dashboard.py -q — 89 passed
• cd dashboard && pnpm typecheck — passed
• Dashboard locale JSON validation — passed

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
• 👀 My changes have been well-tested, and verification results are provided above.
• 🤓 No new dependencies are introduced.
• 😮 These changes do not introduce malicious code.

Summary by Sourcery

Separate reasoning capability metadata from provider configuration across dashboard and API flows.

New Features:

• Add a reasoning_effort string preset with default high to custom request body parameters for providers.

Bug Fixes:

• Prevent reasoning metadata from being persisted in source-backed provider configurations and exposed as editable request settings.
• Ensure provider capability badges and model panels derive reasoning support from model metadata instead of provider configuration.

Enhancements:

• Sanitize provider configurations at dashboard API boundaries to strip legacy reasoning fields while preserving arbitrary fields on standalone providers.
• Hide reasoning from the provider edit dialog payload so updates do not reintroduce metadata into configuration.

Tests:

• Add regression tests covering provider schema serialization, provider creation and update behavior, standalone-provider compatibility, and the reasoning_effort preset in the provider config schema.

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The frontend dialog unconditionally strips the reasoning field when editing/saving providers; if standalone providers also use this dialog, their preserved reasoning metadata will be lost—consider restricting this to source-backed providers or otherwise ensuring standalone provider metadata is not removed.
• The _strip_legacy_reasoning_metadata helper currently only keys off provider_source_id; if there are other forms of source-backed providers or future metadata fields that should be stripped, you may want a more robust criteria or central documentation of which fields are considered capability metadata vs. configuration.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The frontend dialog unconditionally strips the `reasoning` field when editing/saving providers; if standalone providers also use this dialog, their preserved reasoning metadata will be lost—consider restricting this to source-backed providers or otherwise ensuring standalone provider metadata is not removed.
- The `_strip_legacy_reasoning_metadata` helper currently only keys off `provider_source_id`; if there are other forms of source-backed providers or future metadata fields that should be stripped, you may want a more robust criteria or central documentation of which fields are considered capability metadata vs. configuration.

## Individual Comments

### Comment 1
<location path="dashboard/src/composables/useProviderModelConfigDialog.ts" line_range="89-93" />
<code_context>

   function openProviderEdit(provider: any) {
     const editableProvider = JSON.parse(JSON.stringify(provider))
+    delete editableProvider.reasoning
     providerEditData.value = editableProvider
     providerEditOriginalId.value = provider.id
</code_context>
<issue_to_address>
**suggestion:** Reasoning is deleted twice in the edit flow; consider centralizing this cleanup.

`openProviderEdit` deletes `editableProvider.reasoning`, and `saveEditedProvider` deletes `providerEditData.value.reasoning` again, even though `providerEditData.value` comes from `editableProvider`. The second deletion is therefore redundant. Centralize this cleanup in one place to keep the edit flow simpler and make it clear where transient fields are removed.

```suggestion
  async function saveEditedProvider() {
    if (!providerEditData.value) return

    savingProviders.value.push(providerEditData.value.id)
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	astrbot-docs	c009ca3	Commit Preview URL Branch Preview URL	Aug 15 2026, 08:32 AM