Eight model releases published between February 12 and 19, 2026 gave deployment teams more ways to run an AI workload. A team could use a hosted general model, operate published model weights in infrastructure it controls, or use a specialized media service. Teams now had to compare who runs the model, where data moves, what actions the model can take, and who supports it.
This article uses those February releases as a dated record. It helps an owner, operator, or technical lead choose a deployment path and a bounded test. It does not rank current models. Before a purchase or production change, check the provider's current catalog, price, model ID, terms, region, and lifecycle notice.
Example
Update, August 10, 2026: The original article said eight models launched from February 15 through 22, but it named six models and one separate product preview. Primary sources place the eight model releases covered here from February 12 through 19. This revision adds Step 3.5 Flash and MiniMax M2.5. It uses ByteDance's official Seed 2.0 name and corrects GLM-5 from 44 billion to 40 billion active parameters. It also removes launch rankings, price comparisons, free-access advice, and data-privacy promises. Google's current Gemini API catalog still lists Gemini 3.1 Pro as a preview. Anthropic's current model overview lists a later Sonnet generation among its latest models.
The eight releases expanded three deployment paths
The release record includes four models with published weights, several hosted general-model options, and one hosted video model. Some products crossed those boundaries. Qwen, for example, paired published weights with a hosted model. The useful distinction is who operates the model and what kind of workload it serves.
Scroll sideways to see all 4 columns.
| Release date | Release | Source-bounded launch fact | Deployment path added or expanded |
|---|---|---|---|
| February 12 | Step 3.5 Flash | StepFun published model weights under Apache 2.0. Its model card describes 196 billion total parameters and 11 billion active parameters. | Self-managed general model |
| February 12 | GLM-5 | Z.ai released model weights under the MIT License and also offered hosted access. It reported 744 billion total parameters and 40 billion active parameters. | Self-managed or hosted general model |
| February 12 | Seedance 2.0 | ByteDance released a video model that accepts text, image, audio, and video inputs and generates audio with video. | Hosted specialized media model |
| February 13 | MiniMax M2.5 | MiniMax published model weights under its modified MIT model license. | Self-managed general model |
| February 14 | Seed 2.0 | ByteDance announced Pro, Lite, Mini, and Code models. At launch, it offered the full series through Volcano Engine and put Pro and Code in the Doubao app and TRAE. | Hosted general-model family |
| February 15 | Qwen3.5 | Qwen released Qwen3.5-397B-A17B weights and a hosted Qwen3.5-Plus model. The published model has 397 billion total parameters and 17 billion active parameters. | Self-managed or hosted multimodal model |
| February 17 | Claude Sonnet 4.6 | Anthropic made Sonnet 4.6 the default for Free and Pro users at launch and released it through its API and major cloud platforms. | Hosted general model with computer use and tool access |
| February 19 | Gemini 3.1 Pro | Google released Gemini 3.1 Pro in preview through its developer, enterprise, and consumer products. | Hosted general model |
These sources establish dates, model names, model formats, licenses, and launch access. They do not establish one winner. Each vendor also published benchmark results under its own settings. Google reported ARC-AGI-2 results, Z.ai reported coding and agent evaluations, Qwen published a wide benchmark table, and Anthropic published computer-use and preference evaluations. Those results can help a team choose test cases, but they do not form a common business score.
The same limit applies to price. A token rate or a vendor's comparison with another product cannot predict the cost of a local workflow. The full cost can include input preparation, retrieval, cache and batch behavior, retries, human review, integration, hosting, monitoring, support, and model updates. The old article converted launch price claims into savings advice without that record, so this revision removes the claims.
Choose who will run the model before comparing scores
A hosted model lets the provider run the model-serving infrastructure. Your team still decides what data can go to the provider and which tools the model can use. It also decides what a person must review and how the workflow responds to a failed or retired model. Hosted access can reduce infrastructure work, but it does not remove the local data and workflow decisions.
Published weights create another option. They let a team or its implementation partner operate the model on selected infrastructure. They do not establish that the full application is open source, that the system has no outbound network path, or that the deployment is private, supported, or economical. The licenses also differ. Step 3.5 Flash and Qwen3.5 use Apache 2.0, GLM-5 uses MIT, and MiniMax M2.5 uses a modified MIT model license. A team must review the exact license and the complete system design before it treats published weights as a deployment answer.
Seedance 2.0 added a different decision. A video workflow needs evaluation criteria for source assets, motion, audio, editing, approval, and rights. A text-model benchmark cannot select a media model for that work. Keep the workload type fixed before comparing products.
The following constraints decide whether a path fits:
Scroll sideways to see all 3 columns.
| Decision | Evidence to collect | What the release cannot decide |
|---|---|---|
| Workload fit | Representative inputs, expected outputs, difficult cases, and the current human baseline | Whether a general benchmark predicts local quality |
| Data boundary | Source systems, data class, which provider can receive the data, storage, logs, regions, and deletion rules | Whether hosted access or published weights are private by default |
| Tool and action permissions | Read, draft, change, send, approve, retry, and rollback rights | Whether model tool use is safe for a specific workflow |
| Total operating cost | Provider charges or infrastructure, setup work, review time, retries, monitoring, and maintenance | Whether a lower token rate produces a lower total cost |
| Model lifecycle | Pinned model ID, update owner, retest trigger, deprecation notice, and fallback | Whether launch access will remain current |
| Owner capacity | The person or team that can test, operate, review, support, and stop the system | Whether a technically possible deployment can be maintained |
For a workflow that can see sensitive data or take actions, map the boundary before expanding the test. The AI workflow security review worksheet covers source systems, credentials, outbound access, approvals, logs, and rollback. It applies to hosted and self-managed systems because either path can be configured badly.
Tool access changes the cost of a failure
Several February announcements emphasized tool use, computer use, or long-running tasks. Those features can let a model search, call an API, edit a file, or operate a screen. They also change a quality error into a system action. The test must separate an allowed draft from an allowed change.
Start with the least authority that can prove the workflow. A model can prepare a reply, proposed record update, or list of missing fields while a person reviews the source and approves the next step. If the team later permits a write, send, or access change, the workflow needs duplicate-action protection, an approval rule, a log, and a rollback path. The model release does not supply those controls for the local system.
Long context needs the same discipline. Capacity to accept a large input does not establish that the model will retrieve the right detail, preserve every constraint, or handle the data safely. Test the exact document set and the failure cases that matter. Do not use a context limit as permission to send a contract library or customer database in one request.
Run one bounded workload test
A useful comparison keeps the workload, source set, tools, and review criteria stable. Change the model or deployment path, then measure the effect. This prevents a stronger prompt, cleaner source set, or more permissive tool policy from being mistaken for a model difference.
- Record the baseline. Measure how the workflow runs now. Include the current owner, time, review steps, error or rework cases, and direct cost.
- Build the test set. Use representative inputs, difficult cases, known exceptions, and at least one case that should stay manual. Protect sensitive data until the data boundary is approved.
- Name the review owner. One person must accept, edit, reject, or stop each result. Add a security, legal, or domain reviewer when the consequence requires it.
- Keep a full cost record. Record provider charges or infrastructure use, setup time, review time, retries, failures, monitoring work, and expected maintenance.
- Define failure before the run. Include unsupported claims, missed source details, wrong tool choices, repeated actions, sensitive-data exposure, and outputs that a reviewer cannot verify.
- Set the stop condition. End the test when the planned cases are complete, a predefined stop-level failure occurs, or the option cannot meet the minimum quality, cost, or review threshold. Do not keep tuning an option after it has failed the condition unless the team approves a new test.
The test should produce a decision. The evidence may support a hosted model, a self-managed model, a specialized service, a narrower workflow, or no deployment. It should also show which work remains local: data preparation, integration, review, exception handling, support, and model lifecycle management.
Choose the implementation path after the evidence is complete
The February releases expanded the available paths. They did not remove the need to define one workload, constrain its data and actions, measure full cost, and assign an owner. A deployment team can make the next decision when the same test has produced comparable evidence for each serious option.