Xmax bills its X2.0 API on a simple metered model: 1 credit per second of generation. Rather than charging per image or per request, cost scales directly with how long a session actually runs, since X2.0 is a real-time streaming model, not a one-shot generator.
This page explains the billing mechanics as documented by Xmax. For actual credit prices and any plan tiers, check the official pricing page directly — rates are set and updated there, and we're not going to guess or reproduce numbers that could go stale. This is an independent explainer and is not affiliated with Xmax.
Most image and text-to-video APIs charge per generation: you send one prompt, you get one output, you pay one unit. X2.0 doesn't work that way. It takes a continuous stream — a browser camera feed or an uploaded video — and transforms it frame by frame in real time, returning generated video for as long as the session stays open. There's no single "output" to charge for, so Xmax pricing meters the one thing that actually varies: time on the model.
That design keeps the cost model honest. A five-second test and a ten-minute live session run through exactly the same pipeline; the only difference is how long the meter runs. It also means there's no per-request overhead to optimize around — you're not penalized for reconnecting or for switching modes mid-session, because billing tracks generated seconds, not the number of calls you make. If you're new to the model itself, what Xmax X2.0 is covers the real-time streaming architecture that this billing model follows.
Because X2.0 processes a continuous video stream — from a browser camera or an uploaded file — rather than producing a single output from a single prompt, Xmax meters usage by time: every second of generated output consumes 1 credit, regardless of which of the six modes (CharX, ClothX, VibeX, MoX, DimX, or Free) you're running. The mode you choose changes what the output looks like, not how it's billed.
This means cost is predictable in one sense (you can estimate cost from expected session length) and variable in another (a longer live session costs proportionally more than a short one — there's no flat per-generation fee).
Xmax credits show up again at the point where you actually authorize a browser or mobile session, and understanding that link makes the pricing far easier to control. Your permanent key (uk-) stays on your backend and is never sent to a client. When a user starts a session, your server calls the temporary-key endpoint and mints a short-lived tk- key for the frontend. That request takes two parameters that map straight onto pricing:
expireSeconds — the time-to-live for the key, after which it stops working automatically.pointsLimit — the total credit quota the key is allowed to spend before it's cut off.Because 1 credit equals 1 second of generation, pointsLimit is effectively a hard cap on billable seconds for that one session. Set it to the maximum length a user should be able to run, and you can't be surprised by runaway usage. A tk- key can never mint another tk- key, so a leaked client credential can only ever spend up to the quota you already set. This is the practical lever for keeping Xmax cost bounded per user, and the full request/response shape is documented in the Xmax X2.0 API guide.
New Xmax accounts receive a free credit allowance, intended for testing the API and evaluating output quality before committing to paid usage. This is standard practice for metered developer APIs and gives you room to run real sessions — not just look at documentation — before deciding whether to integrate.
Because the free allowance is denominated in the same credits you'll pay for later, it doubles as a realistic cost preview: run a handful of representative sessions, watch how many credits they consume, and you'll have a grounded per-session number long before you set a budget. Treat the free tier as a measurement tool, not just a trial.
No — billing is flat across the model's capabilities. CharX (character swap), ClothX (outfit swap), VibeX (style transfer), MoX (bring-to-life with trajectory control), DimX (summon a virtual character), and Free (custom prompt plus reference image) all run on the same X2.0 model and all meter at 1 credit per second. Adding a reference image, dragging a motion trajectory, or switching modes mid-stream doesn't change the rate. If the official pricing page ever introduces mode-specific rates or volume tiers, verify current pricing there — but the documented default is a single per-second rate for every mode. Seeing how the six modes are used in practice makes it clear why a flat time-based rate fits all of them equally well.
Since we're not reproducing specific figures here, the reliable way to forecast Xmax x2.0 pricing for a project is to work in seconds, then apply the current rate:
Because X2.0 is billed by generation second rather than by output file, the official pricing page is still the only source of truth for the numbers. Before you commit, confirm:
Per-second, quota-capped billing fits teams building their own real-time video features on top of X2.0 — you hold a uk- key on the server, mint tk- keys with a pointsLimit per user, and pay only for seconds generated. It's a developer-facing model that assumes you'll manage account setup, backend key issuance, metering, and moderation yourself. If you don't want to run that infrastructure just to see whether the output quality justifies it, the no-code route below is faster.
If you want to see what X2.0 actually produces before setting up an account, backend key management, and billing on platform.xmax.ai, LiveGen (livegen.ai) is a consumer web app built on X2.0 that lets you try the real-time transformation modes directly in your browser — camera in, transformed video out — without writing integration code or configuring your own metering. It's a fast way to evaluate output quality and decide whether a full API integration (and its associated per-second billing) is worth it for your use case.
LiveGen wraps the same modes in plain-English product names — you can try real-time face swap or AI video style transfer without touching the API. LiveGen uses credits too (1 credit = 1 second, free to start, watermarked exports on the free tier), so a few sessions there give you an intuitive feel for how per-second billing plays out before you commit to your own integration. If you're specifically weighing the hosted playground against building direct, the Xmax playground alternative breakdown is a useful next read.
Metered at 1 credit per second of generation, across all six modes.
Yes, new accounts receive a free credit allowance for testing before paid usage begins.
On Xmax's official pricing page — specific rates aren't reproduced here since they're subject to change.
Billing is per second of generation regardless of mode; check the official pricing page to confirm whether rates vary by mode.
When your backend mints a temporary tk- key, set pointsLimit to the maximum credits (seconds) that session may use and expireSeconds for its lifetime. The key stops working once either limit is reached.
Per second of generated output, not per request. Reconnecting or switching modes mid-session doesn't add a per-call fee — only generated seconds are metered.
Work in seconds: average session length times expected sessions equals total credits (since 1 credit = 1 second), then apply the current per-credit rate from the official pricing page.
LiveGen (livegen.ai), built on X2.0, offers a no-code browser experience for trying the transformation modes directly.
Open your camera and become anyone — free to start, no sign-up for your first try.
Start generating free