Ludo in your terminal

ludo login shows a short code and opens Ludo in your browser. Check that the code matches and click Authorize. No account yet? You can create one on the same page.

The CLI gets its own key, listed under API Keys in the web app, where you can revoke it; ludo logout revokes it too. Your existing API key and MCP setup keep working. On a CI runner or a machine without a browser, set LUDO_API_KEY or use ludo login --with-key.

The CLI waits for each job and saves every result to ./ludo-output (or wherever --out points). Files stay on your disk after the result links expire, and WebP results get a PNG copy too.

In iTerm2, Kitty, Ghostty and WezTerm the result shows up right under your command. Elsewhere, and inside tmux, the preview is skipped and --open shows the result instead. Each result also says what it cost, how many credits you have left and a good next step.

ludo image create --image-type sprite --art-style Chibi --prompt "a tiny knight with an oversized helmet and a wooden sword"

Animate a sprite and the spritesheet plays as a loop in the terminal; ludo preview <file> plays it again later. Making a Godot game? --engine godot also writes a Godot 4 SpriteFrames resource, ready for an AnimatedSprite2D.

(The CLI names files after the job; we renamed our sprite to knight.webp.)

ludo sprite animate --initial-image ludo-output/knight.webp --motion-prompt "walk cycle" --engine godot

Pass a path to any image, audio, video or model flag and the CLI uploads it: no hosting, no base64. That makes the tools easy to chain: a sprite, then its animation, then a 3D model with ludo model create, rigged with ludo model rig, and a sound with ludo audio sound-effect. --open opens a result, --play plays generated audio and --copy copies the saved paths.

ludo model create --image ludo-output/knight.webp

ludo init sets a folder up as a Ludo project: a .ludo.json with the output folder, your game engine, a style image and default settings per command. Every generated file is recorded in ludo-assets.json with the command that made it. ludo assets lists them, and ludo assets redo remakes one with changes.

ludo init
ludo assets redo ludo-output/knight.webp --prompt "...in blue"

--n 4 makes four variations of the same request, and at a terminal you pick the ones to keep. ludo batch runs a list of different generations side by side; a failed item does not stop the others. A batch or a set of variations that would spend more than 50 credits asks you to confirm first.

ludo batch jobs.json

--dry-run shows what a command would cost without running it, and --max-credits refuses one that would cost more than you set. Give a project or a machine a spending budget (max_credits in .ludo.json, or LUDO_MAX_CREDITS) and ludo spend shows the tally. There is no limit unless you set one.

ludo model create --image ludo-output/knight.webp --dry-run

ludo skill install teaches Claude Code the CLI (add --project to share it through the repo), so you can ask for assets in plain words while it builds your game. ludo init adds the same instructions for other agents, and ludo agent-help prints a one-page guide.

When an agent runs it, ludo prints plain JSON with the saved file paths and no previews or colour. The agent looks up only the commands it needs through --help, so it spends far fewer tokens than with MCP, which loads the schema of every Ludo tool before the first request. That is why the CLI is the recommended way to give agents access to Ludo. ludo feedback lets you, or your agent, tell us about a bug, a limitation or a feature you want.

ludo skill install --project

Commands, flags and prices come from the live Ludo API, so new models and features show up without an update. When a new version of the CLI itself is out, it tells you, and ludo update installs it.