How to Use Xmax X2.0: Developer Setup and No-Code Options

There are two real paths to using Xmax's X2.0 model, depending on whether you're building something or just want to try it. This page covers both: the official developer integration path through platform.xmax.ai, and the no-code alternative for people who don't want to write or maintain integration code.

Path 1: Integrating X2.0 as a developer

If you're building a product feature on X2.0, the official route is Xmax's developer platform. At a high level, the setup looks like this:

1. Get platform access and API keys. Xmax issues two kinds of keys: a permanent key (prefixed uk-) meant to stay on your backend server and never be shipped to a browser, and temporary keys (prefixed tk-) that your backend generates and hands to the frontend. Temporary keys carry a TTL (time-to-live) and a usage allowance, so a leaked frontend key has a limited blast radius.

2. Install the SDK. X2.0's official SDK is the JavaScript browser package @xmaxai/sdk-global, installed with npm, pnpm, or yarn. It's currently the only supported SDK — Xmax lists Python and native mobile SDKs as in development, so server-side and native app integrations aren't yet officially supported.

3. Choose a mode. Decide which of the six X2.0 modes fits your use case: CharX (face swap), ClothX (outfit swap), VibeX (style transfer), MoX (motion/drag-to-animate), DimX (AR character summon), or Free (fully custom prompt and reference image).

4. Set up input and transport. X2.0 takes input from either a browser camera stream or an uploaded video file. The SDK handles file uploads by sending them directly to Tencent COS storage and returning a usable URL you pass back as a reference image. The live session itself runs over WebRTC, and output renders into a <video> element in the page.

5. Handle billing in your session logic. Usage is metered per second of generation (1 credit per second). New accounts get a free credit allowance to test with; beyond that, consult Xmax's official pricing page, since specific rates are set there and can change.

This is a legitimate, well-documented integration path — but it is an integration path. You're writing frontend code, managing a key-issuing backend, and handling WebRTC session state.

The core realtime session, step by step

Once your keys and SDK are in place, a live X2.0 session follows the same short pipeline every time. In plain terms:

That five-call rhythm — client, stream, connect(), set(), disconnect() — is the whole realtime loop. Everything else (modes, uploads, trajectory control) layers on top of it.

The six X2.0 modes

X2.0 is a single all-in-one model that exposes several published modes. Each mode is really just a preset prompt plus a rule for the reference image you pass into set():

You can also ignore the presets entirely and supply your own prompt and reference image, which is exactly what Free mode is for.

Camera input vs. video-file input

X2.0 accepts two kinds of input and treats them almost identically. For live camera work you publish a getUserMedia stream. To transform a pre-recorded clip instead, convert the file into a publishable stream with createVideoFileStream(), build the model from that file's width, height, and frame rate, and mark the input as a file when you connect(). Both paths render into the same <video> element and use the same set() call — only the input preparation differs.

Directing motion with trajectory control

X2.0's interactive side is what separates it from render-and-wait video tools. When you bind an output element, the SDK adds a drag surface so users can steer generated motion by dragging directly on the video — MoX is the obvious fit. For custom control you can send coordinates yourself with sendTracks(), passing points in the content resolution you set on connect(), not the displayed size of the element. This is how "playable," interactive video actually works under the hood; see real-time interactive video for the concept behind it.

Uploading reference images

Modes like CharX, ClothX, VibeX, and DimX need a reference image, and the SDK handles that for you. Call the upload helper (for example client.files.uploadAndCheckImage(file)) and the file goes directly to Tencent COS; you get back a public url to pass straight into set() as the reference. The SDK fetches the temporary storage credentials automatically, so you never manage cloud-storage keys yourself. Type checks are strict — handing a video to the image uploader fails immediately.

Authentication and billing

Authentication is the part most likely to trip up a first integration. X2.0 uses two key types: a permanent key (uk-) that must stay on your backend, and short-lived tk- temporary keys your backend mints and hands to the browser. Your server calls the temporary-key endpoint with two parameters — expireSeconds (how long the key lives) and pointsLimit (how much it can spend) — and returns the resulting tk- and its expiry to your frontend. Because a tk- carries a TTL, a capped quota, and cannot mint further tk- keys, a leaked browser token has a limited blast radius. The permanent key never leaves your server.

Billing is metered per second of generation — 1 credit equals 1 second — so your per-session pointsLimit is effectively a seconds budget for that browser token. New accounts get free credits to evaluate with. For current rates, check Xmax's official pricing or our Xmax pricing breakdown; specific prices are set by Xmax and can change. For a deeper walkthrough of the endpoints and request shapes, see the Xmax X2.0 API guide.

Path 2: Using X2.0's capabilities without writing code

You don't have to build any of the above to get X2.0's output. A no-code app runs the model for you and exposes the modes through a normal interface, so you skip the SDK, the key-minting backend, and the WebRTC session handling entirely.

LiveGen: the no-code way to use X2.0

LiveGen (livegen.ai) is a consumer web app built on Xmax's X2.0 model, designed for exactly the audience that doesn't want to do the steps above. There's no SDK to install, no API keys to mint or rotate, no backend to stand up, and no WebRTC plumbing to write.

Using LiveGen looks like this instead: open livegen.ai in a browser, allow camera access (or upload a video), pick a mode, and the transformation runs live in the page. That's the entire setup. The same X2.0 modes are surfaced under plain-English names — Face Swap, Outfit Swap, Style Morph, Bring to Life, and Summon — so you get X2.0's output without touching an SDK. When the presets don't fit, Freestyle gives you a custom prompt and reference image, the same idea as Free mode.

This matters for two groups in particular: non-developers who want to try real-time video transformation for content, streaming, or personal use, and developers who want to evaluate what X2.0 actually produces before investing time in a full SDK integration. If you were exploring the model through Xmax's own playground, LiveGen also works as an Xmax playground alternative — the same underlying model, no account or code required.

Which path is right for you?

The decision comes down to whether you're shipping X2.0 inside your own software or just using it.