audible-cli: driving your own Audible library from a terminal

The app directory decides where your login data is written

Everything audible-cli knows about your accounts lives in an app directory, and the README spells out three per-platform paths: `C:\Users\<user>\AppData\Local\audible` on Windows, `~/.audible` on Linux, and `~/.audible` on macOS. Inside that directory the config file is named `config.toml` and written in TOML format, with the repository topics listing `toml` among its tags. The directory also holds the profile and auth files created during setup, which means the whole thing can be relocated with a single environment variable. That is the escape hatch for anyone running the tool on a shared machine, inside a container, or on a removable volume.

export AUDIBLE_CONFIG_DIR=/path/to/dir

The point worth noting is that this is not a per-invocation flag. It is read from the environment when the process starts, so a shell profile is the natural place for it. Anyone auditing an install should look first at whether `AUDIBLE_CONFIG_DIR` is set, because otherwise the default on macOS and Linux is a hidden folder directly in the home directory. The README does not document what happens if the directory already contains a partially written config, so a fresh directory per account is the safer habit if you switch profiles often.

Quickstart creates config, profile and auth in one interactive step

The entry point is deliberately small. The documentation gives three commands as the whole getting-started path, and the first one is interactive rather than flag driven.

audible quickstart

The documentation states that this creates config, profile and auth file, so the three artifacts that later commands depend on are produced together. Because it is interactive, it asks rather than guesses, which suits a tool that has to hold region specific login state for one or more Audible accounts. After that, listing and downloading are non-interactive:

audible library list
audible download --all --aax

A separate console script named `audible-quickstart` also appears in the packaging metadata, so the setup step is reachable without the subcommand form. The `audible` entry point itself maps to `audible_cli:main`, and the project is published on PyPI as `audible-cli`. Nothing in the documentation describes a headless or non-interactive setup mode, so a provisioning script that cannot answer prompts has no documented path today.

Library, wishlist and profile switching run through the same command tree

The CLI is organised around a small set of verbs, and the README gives a table of goals mapped to commands. Listing and exporting the library are separate subcommands, so you can pull a machine readable copy without touching the audio files:

audible library export --output library.json

Wishlist handling is a sibling of library, and profiles are selected with a global flag rather than a subcommand:

audible wishlist add --asin B004V00AEG
audible -P germany library list

That `-P` flag is what makes the multi account claim workable. One installation can hold several regional profiles, and a single command targets the one named. The `profiles` and `subcommands` topics on the repository match that shape. Downloads accept a date filter and a format switch, which is the combination most useful for incremental syncing:

audible download --start-date "2023-01-01" --aaxc --all

The documentation does not explain how a download decides between AAX and AAXC when both are valid for a title, so treat the format flag as the decision point rather than assuming a default.

The audio path runs on the audible library package, not on hand written HTTP

audible-cli is a front end. The heavy lifting, including region specific API calls and the AAX and AAXC handling, comes from a separate package named `audible`, pinned in the dependency list as `audible>=0.11.0`. The CLI adds the parts an end user actually touches: argument parsing through `click`, an interactive prompt layer built on `questionary` and `prompt_toolkit`, progress bars from `tqdm`, tabular output from `tabulate`, and asynchronous file writing with `aiofiles`. Network requests use `httpx`, which the documentation credits for speed, and `Pillow` is present for image handling, which fits the cover artwork the project advertises.

Two details in the packaging metadata reveal how carefully the boundary is managed. The `httpx` dependency is capped at `httpx>=0.27.2,<0.29`, and `prompt_toolkit` is capped at `<4` with a comment explaining that the code imports `create_output` directly rather than through `questionary`, so the cap guards against a major release moving that symbol. That kind of pinning says the maintainer expects breakage from the ecosystem and plans around it. The consequence for you is that upgrades are a moving dependency surface, not a stable contract, and the version of the underlying `audible` package matters as much as the CLI version.

Crypto speed is decided by which optional extra you install

Downloading DRM protected audiobooks means fetching activation bytes and decrypting files, which is where the CPU cost lands. audible-cli offers an optional extra named `cryptography` that pulls in `audible[cryptography]>=0.11.0`, giving the Rust accelerated backend. The documentation states that without it the tool still works using a pure-Python fallback, only slower.

pip install "audible-cli[cryptography]"
# or, when installed as a tool:
uv tool install "audible-cli[cryptography]"

A second extra named `pycryptodome` exists for platforms where `cryptography` publishes no wheel, which the packaging metadata identifies as currently Windows on arm64. The bundled standalone binaries already ship an accelerated backend, so the plain `pip install audible-cli` route is the case where the fallback is most likely to be felt on a large library.

Install paths also vary. `uv tool install audible-cli` is the recommended route, `uvx --from audible-cli audible` runs it without installing, and plain `pip install audible-cli` works for a normal environment. A source install clones the repository and runs `pip install .` in the clone. The declared Python floor is `>=3.11,<3.15`, with classifiers listing 3.11 through 3.14, so a Python 3.10 workstation is out of scope.

Prebuilt binaries carry a glibc floor that Linux users must check

The releases page offers standalone executables for Windows, macOS and Linux, so no Python install is required. The macOS builds are Apple silicon only, and the README explicitly routes Intel Mac users to `pipx install audible-cli` instead. On Windows the onedir archive is recommended for faster startup.

Linux is where the constraint bites. The standard builds are compiled on Ubuntu 22.04 and need glibc 2.35, which covers Ubuntu 22.04, Debian 12, RHEL 9 and anything newer. A second set built on a 24.04 base needs glibc 2.38 and reaches fewer systems. If you are on an older enterprise distribution, the binary will not start, and the choice is between building from source and running an older Linux build.

One more operational detail: the archive names now carry the architecture, for example `audible_mac_arm64.zip` rather than `audible_mac.zip`. The old unsuffixed names are still published but the README states they will be dropped after 15 November 2026, so any automation that downloads a fixed legacy URL has a deadline.

Plugins live in a top level plugin_cmds directory, and a Rust rewrite is queued behind it

The repository layout lists a `plugin_cmds` directory alongside `src`, `tests`, `docs` and `utils`, and the feature list describes a plugin system for custom commands and extensions. How a plugin is registered is not documented anywhere, so the extension point is real but its contract is not written down. Documentation is hosted at `audible-cli.readthedocs.io` and a `CHANGELOG.md` sits at the repository root, which is where changes between versions are recorded.

The bigger structural fact is the note at the top of the README: a Rust reimplementation called audible-rs is in development, offering a single static binary, a reworked command set, an encrypted auth format, a local SQLite library database with FTS5 search, and a capability based plugin system. It is described as pre-alpha and seeking testers. The same note states that audible-cli stays fully supported, that audible-rs is not an immediate replacement, and that the two use separate config directories so they can run side by side. That separation is the useful part for planning: you can test the new tool without migrating credentials.

On maintenance, the last push was on 2026-10-16, and the recent releases are v0.6.0 on 2026-09-01, v0.5.1 on 2026-08-15 and v0.5.0 on 2026-08-05, a run of three tagged versions inside two months. The packaging metadata still labels the project as Beta.

Editorial conclusion

audible-cli fits people who already own Audible books and want them as files on disk, especially across several regional accounts, and it is not a tool for anyone wanting titles they have not bought. Before adopting it, check that the Python version in your environment falls inside the 3.11 to 3.15 range, confirm that the crypto extra you need installs on your platform, and verify that the prebuilt binary glibc floor matches your Linux distribution.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. mkb79/audible-cli on GitHub
4. README
5. Releases