Proposal: support Alibaba Cloud Model Studio video generation in the standard Hypit workflow

[Flandern1211]

Summary

Would the maintainers be interested in supporting Alibaba Cloud Model Studio video-generation models in Hypit's official Distribution?

The core requirement is that ordinary users and Agents can use their Alibaba accounts through Hypit's existing Quickstart workflow. Adding this Provider should not introduce a separate DashScope-specific workflow or require users to understand vendor API details.

I would also like to confirm whether related support is already planned and which package boundaries the maintainers prefer before preparing a formal PR.

Problem

Alibaba Cloud Model Studio provides Wan and other hosted video models for:

• text-to-video;
• first-frame and first/last-frame generation;
• reference-video generation;
• video editing and extension;
• motion transfer and person replacement.

Hypit currently does not ship a corresponding Model package and Provider. Users with an Alibaba account must create and maintain a project-specific integration, including request mapping, media upload, asynchronous polling, and result collection.

I explored a local wan2.2-i2v-flash proof of concept, but it supports only one image-to-video model and is not suitable as the final architecture.

Expected user experience

Alibaba Cloud Model Studio should appear as another service choice within Hypit's existing workflow:

1. The user installs and works through the existing Hypit Skill.
2. The user provides a reference or describes the desired video.
3. The Agent offers Alibaba Cloud Model Studio as a service option and connects the selected account through the standard Runtime and credential mechanisms.
4. The Agent explains the planned paid work and obtains authorization before generation.
5. Generated video is delivered through normal Hypit Build Results, export, and Studio workflows.

Author Sources should remain independent of the selected Provider. Users should not need to handle DashScope request bodies, media hosting, task polling, or result URLs.

Proposed direction

• Add provider-neutral Model definitions for the supported video models.
• Add an @hypit/provider-dashscope Provider using Hypit's existing Endpoint, Runtime, credential, pricing, and Build contracts.
• Keep shared DashScope transport and asynchronous task handling separate from model-specific protocol adapters.
• Automatically stage local reference media through the Provider.
• Return generated media as standard Hypit video Outputs.
• Start with Wan 3 text, frame, reference, editing, and extension capabilities.
• Extend additional Wan and Model Studio-hosted video models by protocol family after the common Provider boundary is established.
• Keep non-Wan models under their correct Model ownership rather than representing every Model Studio model as Wan.

The intended result is an extensible Model Studio integration, not a Provider hardcoded to a single Wan model.

Questions for maintainers

1. Is Alibaba Cloud Model Studio video support a shared production need suitable for Hypit's official Distribution, or should it remain an external/project-owned extension?
2. Is related Alibaba/Wan support already planned or being developed?
3. Is a provider-neutral Model package plus @hypit/provider-dashscope the appropriate boundary?
4. Should the initial contribution be limited to Wan 3 before adding other video protocol families?
5. If this direction is useful, would you like me to take responsibility for the initial implementation?

I will wait for explicit maintainer confirmation of the need and direction before developing the proof of concept into a formal PR.

[sakurahello1]

I'd be glad to implement this if maintainers are open to it — I have an Alibaba Cloud Model Studio (DashScope / Bailian) account to test against, and I'm in the same situation as the original poster: users here need it to work through the standard Quickstart, not a vendor-specific path.

Rough shape, per CONTRIBUTING's "describe the approach first": a Provider package alongside the existing generation providers implementing the same Provider contract (submit → poll → fetch), auth via a single env/config key, model ids exposed the way current providers expose theirs, DashScope's async task states and its content-moderation rejections normalised into the contract's existing failure kinds so nothing upstream learns vendor codes. No new workflow, no new CLI flags.

@Flandern1211 if you were planning to build this yourself, say so and I'll stay out of the way — otherwise I'm happy to take it. Maintainers: is this the direction you want, and is there a reference Provider you'd like it modelled on?