- Show complete user messages with every image immediately after sending
- Analyze up to four bounded images without adding pixels to Design context
- Organize image handling under the extensible attachment domain
- Route bounded selection renders through the optional Vision model
- Return compact text findings without retaining image data in Design chat history
- Bound MCP and AI image exports by their longest pixel edge
- Redact and bound provider error details in copied logs
- Avoid repeat toasts after locale changes
- Show reasoning effort only for supported providers
- Report credit and output-limit failures through localized toasts and debug logs
- Persist optional provider-specific reasoning effort on model profiles
- Classify insufficient-credit connection tests and cover failure diagnostics
- Separate model, connection, and advanced settings
- Resolve capabilities and output limits from provider catalogs
- Keep custom model compatibility declarations explicit
- Centralize design-profile eligibility for the selector, role assignment, fallback, and tests
- Keep built-in provider model selection intact while switching saved custom profiles
- Add localized accessible labeling and constrain long profile names
The chat model chip is a dropdown for built-in providers but a static label
for OpenAI-compatible and custom-model setups, so anyone using a custom
endpoint had to open Settings to change models -- even with several models
already configured.
Add a profile switcher that reassigns the design role from the chat panel.
It lists saved profiles that can use tools, shows the profile name rather
than the raw model ID, and badges the vision-capable ones. It writes the
same assignments.design field the Settings dropdown does, so the two stay in
sync.
Only renders when more than one tools-capable profile exists; a single
profile keeps the existing label. Built-in providers keep ProviderModelSelect
unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Make MiniMax-M3 the default MiniMax model
- Verify the existing OpenAI-compatible adapter sends M3 requests correctly
- Update AI documentation and release notes for #431
Anthropic omits Access-Control-Allow-Origin unless the caller sends
anthropic-dangerous-direct-browser-access, so the web build failed with an
opaque "Could not reach this endpoint from the browser" for the anthropic
provider. @ai-sdk/anthropic does not send the header and neither did our
adapter.
Send it from the browser only. The desktop build routes through tauriFetch
and is not subject to CORS, so it does not need to advertise browser access.
Fixes#436
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Resume persisted outbox jobs at startup without dropping writes when credentials are unavailable
- Serialize IndexedDB revisions and guard sync completion against concurrent saves
- Reconcile tombstones without reviving deleted documents and bound S3 metadata requests
- Require explicit CORS configuration instead of overwriting bucket rules during connection tests
- Keep ACP agents exclusive to the Design role and normalize invalid model limits
- Separate provider connections, model profiles, capabilities, and role assignments
- Replace role-specific forms with a reusable model library and assignment table
- Resolve credentials lazily per connection and preserve existing Design settings
- Route Design chat through the assigned profile while exposing Review, Fast, and Vision runtimes
- Move provider-specific model construction behind typed adapters
- Keep OpenAI- and Anthropic-compatible configuration reusable
- Verify every direct provider is registered while ACP agents stay separate
