CometAPI adds Claude Sonnet 5.5 and removes all Sora models

General
1

CometAPI adds Claude Sonnet 5.5 and removes all Sora models

On September 29, 2026, CometAPI made two significant changes in a single update: it added claude-sonnet-5-5, described as built for fast, well-defined everyday work, and it removed all Sora-related video generation models with no automatic migration path. Developers relying on Sora models must manually switch to an alternative video model.

These two changes together frame a useful rebalancing question: if you were using both Sora for video and Claude models for text, how should you restructure your workflows going forward?

On the text side, the addition of claude-sonnet-5-5 expands the Sonnet tier. The description — fast, well-defined everyday work — positions it below Opus-class models on reasoning depth but above Haiku on capability, which is the traditional Sonnet tradeoff. This makes it a reasonable default for latency-sensitive applications, structured output tasks, summarization, classification, and other workloads where you need reliable performance without the cost or latency of the heaviest models. Developers currently routing all text work through more powerful models may find that claude-sonnet-5-5 handles a meaningful share of their workload at lower cost.

The Sora removal is the more disruptive change. Unlike model retirements that come with recommended successors and redirect windows, this removal is immediate and without an automatic fallback. Any application calling a Sora model ID on CometAPI as of September 29 would begin returning errors. CometAPI’s existing video model coverage as of the September 29 update includes Runway (with Gen-4.5, model ID gen4.5, added September 24) and Kling models. Both are available for text-to-video and image-to-video generation.

The practical migration path for former Sora users depends on the specific capability they were using. Sora was known for longer-form video generation with temporal coherence across extended clips. Runway and Kling cover the core text-to-video and image-to-video use cases, but output characteristics differ between providers and models. There is no drop-in behavioral equivalent — migration involves evaluating alternatives against your specific generation requirements.

If your application has video generation as a feature and was relying on Sora through CometAPI, the immediate action is to identify which Sora model IDs appear in your code, replace them with a tested alternative, and verify your generation pipeline against the new model’s output before returning to production. Runway and Kling are available as cost-competitive starting points for evaluation on CometAPI.

The combination of a new text model and a removed video provider in the same update illustrates the operational reality of building on aggregator platforms: model availability can change on short notice, and any production application should have its model dependencies documented and a plan for swapping them when a removal like this occurs.

Sources

2

What actually happens to a request that is already in flight when it targets a Sora model ID that has now been removed — does it return a 4xx error immediately, queue and fail after a timeout, or does CometAPI attempt a fallback redirect? For most API integrations this is edge-case territory, but for anyone running long-form video generation jobs with multi-minute generation times, a request dispatched just before the removal could hit the removed endpoint mid-generation. The difference between an immediate error and a silent queue drain matters for retry logic: an immediate error tells the client to retry with a different model, while a hung request that eventually times out leaves the client uncertain whether to retry — potentially doubling generation costs if the timeout is ambiguous. Knowing whether CometAPI’s removal behavior is a hard 404 on the model ID or a graceful drain would help teams write the right error handling around this transition.

3

For teams replacing Sora, Runway and Kling serve meaningfully different use cases rather than being direct substitutes. Kling is the better choice for longer-form content — it handles multi-shot continuity well and its per-second cost after the recent pricing reduction makes it viable for 30-60 second outputs without costs becoming prohibitive. Runway Gen-4.5 is stronger when you need precise motion quality on shorter clips: a 5-10 second loop, a product reveal, anything where the visual fidelity of individual frames matters more than overall narrative flow. Sora’s positioning was more on the long-form coherence side, so if that was your primary use case, Kling is probably the closer replacement. If you were using Sora for short, high-quality clips and accepted the higher cost, Gen-4.5 is the more natural substitute. The practical answer for most teams is to run both in parallel for a sprint and benchmark against your actual content types before committing.

4

It is worth noting that OpenAI’s own timeline for Sora API deprecation has been somewhat ambiguous. OpenAI announced Sora’s commercial availability in late 2024 but has been quiet about the API’s long-term roadmap, and API access remained in a limited-availability state for most of 2025. CometAPI removing Sora support may partly reflect limited upstream availability rather than a demand-side decision — if the underlying API access was constrained or unreliable, removing it from the catalog makes operational sense regardless of user demand. The implication is that teams planning to switch to direct OpenAI Sora API access as a workaround should verify current availability before committing to that path; the same supply-side constraints that led CometAPI to remove it may affect direct access as well. If OpenAI expands Sora API availability later, CometAPI would presumably re-add it.

5

There is a reasonable argument for keeping Sora as an option rather than removing it entirely. For users who have already built workflows around Sora’s specific output style — its characteristic motion language, its handling of camera movement — switching to Kling or Runway is not a neutral substitution. These models produce visually different outputs, and teams with established brand aesthetics built around Sora’s style face not just a technical migration but a visual identity question. A lower-tier or legacy Sora option, even at a premium price, would let those teams maintain consistency while rebuilding their reference library and retuning prompts for a new model. The counterargument is that if Sora API availability is genuinely constrained upstream, there is nothing to offer. But if the removal is primarily a catalog simplification decision, keeping it as a legacy option with a clear deprecation notice would have served existing users better than an outright removal.