@lingo.dev/cli ships your source content to a localization engine, waits while the engine produces translations, and writes the outputs back to disk. It's the replacement for the legacy npx lingo.dev flow — same project, fundamentally different architecture.
What changed vs. the legacy CLI#
The legacy CLI (npx lingo.dev run) extracted strings, called an LLM directly from your machine, and wrote files in one synchronous pass. The new CLI is async-by-design:
lingo pushuploads sources to your engine, kicks off a server-side workflow, and either waits for completion or returns immediately with a run IDlingo pullfetches outputs from the most recent push — works even if you closed the terminal mid-translation, or are pulling from a different machine- A lockfile (
.lingo/lock.json) tracks the last-known-server version of every target so conflict detection can flag local edits before they get overwritten
This unlocks two things the legacy CLI couldn't do: long-running translations without a hanging terminal, and pulling results on a different machine than the one that ran push (or in CI).
What's in this section#
Quickstart
Install, authenticate, link to an engine, run your first push and pull.
Configuration
`.lingo/config.json`, `.lingo/lock.json`, and per-machine run state at `~/.lingo/runs/<hash>.json`.
lingo push
Send sources, wait for translation, write outputs. Scoped patterns, `--force`, retry semantics.
lingo pull
Fetch the last push's outputs — across machines, across terminal sessions. Conflict detection.
Other commands
login, logout, link, unlink, whoami — the setup and identity commands.