The full ElevenLabs API comes to the terminal with agents-as-code

ElevenLabs CLI v1 brings audio generation and agent management into a command-line interface with structured outputs, version-controlled files, and CI/CD deployment.

Generating speech, transcribing a recording, composing music, or modifying an ElevenLabs agent can now be done from the terminal without manually writing HTTP requests or installing a separate SDK for each operation. ElevenLabs CLI v1 turns the functions published in the platform’s OpenAPI specification into commands that can be used by a person, script, or coding agent.

The tool covers all public endpoints described by ElevenLabs. A command can convert text to speech and save the result to a file, launch a transcription, produce music, manage sound effects, list available voices, or interact with ElevenAgents features. Text responses can be returned as JSON, tables, YAML, or CSV, while binary content is written directly to a specified path.

This coverage does not introduce new audio capabilities. The CLI provides another interface for calling existing services. Generations, transcriptions, and other processing still run on ElevenLabs infrastructure under the permissions, quotas, and costs associated with the account. Installing the tool does not allow the company’s voice models to run locally.

The code is available on GitHub under the MIT license. Most commands are generated from the OpenAPI specification using Fern. ElevenLabs adds custom workflows for locally managing agents, tools, and tests. This structure should allow the command surface to follow API changes without requiring every command to be rebuilt manually.

Installation is available through Homebrew on macOS and Linux, Scoop on Windows, or shell scripts for Unix-style terminals and PowerShell. The project is written in Rust and can also be compiled from source. Once installed, the `elevenlabs` binary is available globally.

For local use, `elevenlabs auth login` opens a browser window and starts an OAuth authentication flow. The documentation states that credentials are then stored in a local file protected by restricted permissions. The repository also supports the `ELEVENLABSAPIKEY` environment variable, a project-level `.env` file, or a key supplied for a single command.

The environment-variable approach is better suited to automated pipelines. In GitHub Actions, for example, a key can be stored as a secret, injected during deployment, and used to preview, apply, and verify a configuration. A `.env` file placed inside a project requires more caution and should be excluded from the repository to prevent credentials from being published with the code.

The CLI is designed around the differences between a person and a coding agent. The `--help` command produces human-readable documentation, while `--schema` returns a structured contract describing the available parameters, their locations, types, required fields, and expected response shape.

A coding agent can therefore inspect the schema before constructing a command instead of guessing its syntax. When an error occurs, the program detects whether the output is being viewed in an interactive terminal. A person receives a formatted message with a suggested correction, while a program or agent receives a JSON error that is easier to parse before retrying.

Commands can also receive parameters directly as JSON. Results can be sent to `jq`, integrated into a script, or chained with other terminal tools. Automatic pagination can retrieve multiple result pages and stream them progressively as NDJSON.

The `--dry-run` mode plays an important role in this automation. It validates a request locally and displays the HTTP call that would be sent without executing it. For agent synchronization, it also shows the expected differences between the local files and the remote configuration.

This preview reduces the risk of accidental changes but does not provide a complete test. It does not necessarily verify final account permissions, quotas, service availability, or an agent’s actual behavior after deployment. A valid command can still be rejected by the API or produce a configuration that performs poorly in conversation.

The main organizational change involves agents-as-code. Running `elevenlabs agents init` creates a structure containing registries for agents, tools, and tests, along with separate folders for their configuration files. Each agent becomes a JSON file that can be committed to Git, reviewed in a pull request, and tied to a product version.

The `elevenlabs agents pull` command imports agents from a workspace into the local project. The received files preserve the raw JSON representation supplied by the API so they can be sent back without transformation. A team can then modify a prompt, change the voice, select another language model, adjust the maximum call duration, or replace a tool.

`elevenlabs agents push --dry-run` compares the local configuration with the workspace version. Once reviewed, `elevenlabs agents push` applies the changes. This workflow is particularly relevant to companies managing many agents or deploying similar configurations across hundreds of customer organizations, where repeated edits in a dashboard become difficult to track.

Synchronization still requires a clear working method. By default, `agents pull` skips agents that already exist locally. The `--update` option is required to replace those files with changes made through the browser or API. Conversely, the repository states that `agents push` force-overrides the configuration of the main branch or registered branches. An outdated local copy could therefore erase a newer change if the team does not synchronize first and review the difference.

Branch management can separate development from production. A test version might use a different phone number, another voice, or a less expensive language model, while the main branch retains the configuration intended for users. Commands can target a branch by name or ID.

This feature relies on the ElevenAgents versioning system. Versioning must be enabled for the relevant agent and cannot be disabled afterward. Each committed change creates a version, with options to roll