Vidu Pricing: Web Plans, API Credits and Upgrade Triggers

Buying path

Vidu has two practical buying paths: the consumer web app for creators and the developer API for programmatic generation. The web app is the default starting point because it lets a user test text, image, reference, and start-end workflows before committing engineering time or API budget.

The official pricing surface presents Vidu as a free-to-paid product, but the public page is dynamic and can require live account or checkout context for the complete plan view. That makes the structured plan data useful as a buying snapshot, not a replacement for checking the active purchase screen before paying.

For most individual creators, the sensible first paid step is the entry subscription route after the free allowance proves output quality. That route keeps experimentation in the visual workspace and avoids treating API credits as a general-purpose creator subscription.

Upgrade triggers

Upgrade when the free allowance no longer supports the number of iterations needed for a campaign, client concept, or repeatable social-video workflow. Vidu's value improves when a user is producing batches of shots, refining references, or testing multiple cuts rather than making a one-off clip.

Higher tiers become easier to justify when the workflow depends on consistent access, larger monthly credit pools, or features and scheduling rules that may only appear in the live paid environment. The key trigger is not just wanting better clips; it is needing enough predictable generation capacity to finish work without constant quota friction.

Teams should also upgrade when review cycles require several variants from the same prompt, image, or reference set. In that scenario, a lower allowance can distort creative judgment because users stop iterating before they have actually tested the shot direction.

API and team boundaries

The API boundary is separate from the app subscription boundary. Vidu's developer docs price generation with credits, and video cost can change by model, duration, resolution, and workflow type. That makes API usage appropriate for products, internal tools, and automated pipelines, not simply a hidden version of the app plan.

API buyers should model cost from the intended generation mode. A short Q3 or Q1 test at one resolution does not prove the economics of a production workflow with longer clips, higher resolution, or many retries. Usage estimates should include failed experiments and quality-review passes, not only final exports.

Team and enterprise decisions should focus on permissions, governance, procurement, and support expectations. When multiple people need shared access or when generated video becomes part of a business-critical process, the checkout price is only one part of the decision.

Final pricing check

Before paying, confirm the active web subscription terms in the live Vidu purchase flow, including billing cadence, credit allowance, cancellation rules, and any off-peak or no-peak eligibility shown in the account. The public pricing page is not enough by itself when the plan table is rendered dynamically.

Before funding API usage, confirm credit recharge rules, eligible models, per-second pricing, resolution choices, duration limits, and whether off-peak pricing applies to the workflow you will actually run. App credits and API credits should be budgeted separately unless Vidu's account screen explicitly joins them.

The clean purchase path is to prove creative fit in the web app, choose the lowest paid subscription that supports routine iteration, and move to API credits only when generation is embedded in software or automation. That keeps the buying decision aligned with how Vidu will actually be used.