ElevenLabs CLI v1 Moves Its Entire Voice Agent Platform Into the Terminal
ElevenLabs ships a terminal-first CLI that treats voice agents as version-controlled config files, with structured JSON and skills for coding agents.
- ElevenLabs launched CLI v1, exposing the full API as terminal subcommands with structured JSON output.
- Agents-as-code: pull, edit, dry-run diff, and push voice agent configs like source code.
- Dual-mode errors: humans get readable hints, coding agents get parseable JSON with fix instructions.
- Every command exposes
--schema, a machine-readable contract of inputs and response shape. elevenlabs generate-skillswrites workflow instructions into your project for coding agents to follow.- Install via
brew install elevenlabs/tap/elevenlabs, Scoop, or curl. Source on GitHub.
ElevenLabs just moved its entire platform into the terminal. The new ElevenLabs CLI v1 exposes every API endpoint as a subcommand, and it treats voice agents like source code while treating coding agents like first-class users.
Every endpoint published in the OpenAPI spec is available as a subcommand, from listing agents to generating music to converting text to speech. Installation is a single line through Homebrew, Scoop, or curl:
brew install elevenlabs/tap/elevenlabs
Agents you can diff
The headline feature is agents-as-code. Pull every agent in your workspace into local config files, edit them like any other part of your codebase, preview the exact diff, and push to production by hand or through your coding assistant. The workflow collapses to three commands:
elevenlabs agents pull # every agent becomes a local config file
elevenlabs agents push --dry-run # preview exactly what would change
elevenlabs agents push # apply
Branches keep environments separated. A dev branch can use a test phone number and a cheaper LLM while production runs the real number and a frontier model. For teams running one or two bots, the dashboard is fine. When you're managing a fleet spread across hundreds of customer orgs or bulk-migrating from another platform, files and version control become the only workflow that scales.
Built for coding agents that fail differently
The team acknowledges that an agent using a CLI fails differently than a person does. It cannot answer an interactive prompt, it retries constantly, and it learns from whatever the error message gives it. So the CLI dual-modes itself based on whether a human or a bot is at the keyboard.
- Detection: the CLI checks TTY to decide who is running the command.
- Humans get a readable error with a hint pointing at
--help. - Agents get the same failure as parseable JSON with an error code, message, and reason.
- Schemas over help pages:
--helpis for people,--schemais for bots. Every API command prints a machine-readable contract: typed inputs, where each one goes, what's required, and the exact shape of the response.
Calling elevenlabs text-to-speech convert --schema returns a JSON object listing every parameter, its location in the request, its type, and which fields are required. The agent can construct a valid call without guessing, and when it inevitably guesses wrong, it gets a structured error it can loop on.
Skills that ship workflows, not just docs
Running elevenlabs generate-skills writes instructions into your project for every product group. Skills teach your coding assistant complete workflows: how to build an agent, generate speech, or transcribe a call. Think of it as scaffolding that turns Claude Code or a similar assistant into a competent operator for the ElevenLabs surface area, without you writing the prompts.
The CLI also complements the hosted MCP server rather than replacing it. Reach for the CLI when you want agents in version control, and use the hosted MCP server for conversational management. With MCP, Claude can pull recent conversations, find where callers drop off, and rewrite the greeting. With the CLI, a coding assistant can script that same fix across every voice agent in your fleet.
Practical use cases
- Bulk migration: pull hundreds of agents, transform their configs with a script, push back.
- Multi-tenant SaaS: keep per-customer configs in the same repo as the app, with PR review.
- CI/CD for voice: gate changes to production on dry runs and diffs.
- Agentic ops: hand Claude Code the skills and let it iterate on greetings, prompts, and voices while you review the resulting commits.
Why this matters
Voice agent platforms have mostly lived in dashboards, which is fine for prototypes and painful at scale. Treating agents as config files puts them under the same review, rollback, and audit workflow as everything else in a codebase. The more interesting bet is the agent-first interface: designing errors, schemas, and help output specifically for a non-human caller. If coding agents are going to operate infrastructure on our behalf, tools that talk back in JSON, not ANSI colors, will win. The documentation and open-source repo are already live.