Changelog

What's new in Multimodel Chat.

Release v1.1.0

New Feature

May 21, 2026

Added

  • Feature Requests: Users can now submit and suggest new features directly through the app.
  • Changelog: Introduced this changelog to keep you updated on the latest improvements and bug fixes.
  • User Feedback: Added a dedicated feedback system for users to share their thoughts and report issues.

Fixed

  • Anthropic Provider Integration: Resolved an issue where file uploads were causing errors due to message role restrictions.
    • Technical Change: File text content is now sent within the user message instead of the assistant message to comply with provider requirements and ensure system messages are handled correctly.

How to use this release log

Published entries above are the release record. They describe specific changes and their publication dates; this reading guide is not an additional release announcement. If the list is empty or unavailable, do not interpret that state as evidence that nothing has ever changed. Return to the published entries when available and use the relevant setup or product guide for current instructions. A marketing article about a provider launch is also not automatically a statement that the model was deployed in this workspace.

Start with the entry relevant to the feature you use rather than assuming every change applies to every account. A model catalog update, a conversation-interface change and a billing change solve different problems. Note the affected workflow and any action explicitly requested by the release. When a note only describes a visual improvement, it should not be read as a new entitlement or a change in third-party API pricing. Follow the product's current pricing and provider documentation for those separate questions.

Before you rely on a model-catalog change

Record the provider and exact API identifier used in your important workflow. Similar display names can refer to different generations or endpoints, and a preview name should not be treated as a permanent promise of availability. Check the provider guide for the app's bundled configuration, then verify availability in your intended account with a small non-sensitive request. A catalog entry is useful discovery information; it is not a completed test of your key, quota, input format or task quality.

For a replacement model, keep a reference task whose result you can independently verify. Compare factual preservation, format compliance and billed usage before moving a recurring process. If your request includes a long file, check the new entry's context setting rather than assuming a newer generation is always larger. Preserve the old input and expected result so you can explain a behavior change without sharing a real customer document. Do not infer a retirement date from the absence of an exact model in a public rate card.

Protect local conversations when changing browsers

This app stores chat history and attachments in per-user browser storage. Account settings and local history are not the same thing. Before resetting site data, replacing a device or troubleshooting by clearing storage, make a supported backup and verify that the file was saved. An update notice should not be interpreted as a promise that local conversations have been copied to a server. Keep the original browser profile available until you have checked any migration you intend to make.

Saved provider keys are also held in a per-user browser vault. A new browser may require you to connect those accounts again, even when sign-in succeeds. Deleting a local connection and revoking a key at the provider are different actions. Use the provider's account controls when you need to stop a credential from working everywhere. Avoid including keys, unredacted exports or private conversation text when you ask for help interpreting a change.

Report a regression with a reproducible example

A useful report names the public feature, browser, expected behavior and observed behavior. Include a short sequence that someone else can follow with non-sensitive sample data. If the problem concerns a model request, identify the provider and model without exposing the credential. Note whether the request failed before output, stopped partway through, or completed with an incorrect result. Those cases may have different causes, and a screenshot of the final error alone can omit the important distinction.

Check saved partial output before retrying an interrupted generation. A repeat can create another provider request, so avoid using repeated paid generations as an uncontrolled troubleshooting loop. If the behavior depends on a particular uploaded file, create a safe minimal example rather than distributing the original confidential attachment. Keep your own record of when the issue started, but do not invent a release association solely because two events happened on the same day. The published log and a reproducible test should establish the connection.