v0.68.0 — ElevenLabs joins the roster
One tool joins the roster, and one dependency specifier that only ever worked by accident.
ElevenLabs joins the roster
moshcode install elevenlabs
moshcode elevenlabs auth login
moshcode elevenlabs agents list
ElevenLabs' CLI manages Eleven Agents — conversational voice agents you define in files and push/pull against their platform, alongside the knowledge bases, tools, tests and phone numbers those agents use. The same binary reaches the rest of the API: voices, text-to-speech, dubbing, transcription, music, and workspace usage.
elevenlabs auth login runs a PKCE OAuth flow and stores the credential in the system keyring, falling back to a file under ~/.config. Nothing works before that. Scripts want --format json — which is already the default when stdout is not a TTY — and --query, a JMESPath expression applied before formatting.
It is a tool, not an engine, and the name is the whole reason that needs saying. ElevenLabs calls these agents, and moshcode has an /agents that means something else: hand the terminal to a live session. Every subcommand here is one API request that exits. There is no session to hand over, so putting it behind /agents would have meant landing the operator in a program that prints help and leaves — exactly the thing engines.mjs already refuses to fake with a one-shot list command. It sits with railway, supabase and alchemy instead, and pipes like they do.
The install spec carries no flags, on purpose. The published package is a small Node shim; the real CLI is a native binary shipped per platform as an optional dependency. An install run with --omit=optional or --no-optional still succeeds and still puts elevenlabs on your PATH — and then every invocation of it dies with "the platform package is not installed". Better to install the way that works than to explain that failure later.
No upgrade key, for the reason mcpjam and alchemy have none: npm install -g is idempotent and the CLI ships no updater of its own, so re-running the install is the upgrade.
A short sha that a clean install could not resolve
The autoblog dependency was pinned by a short sha, #75e54af. pnpm resolves a short ref by matching it against what git ls-remote advertises, and that commit is not the tip of any branch or tag — so a fresh resolution fails with "Could not resolve 75e54af to a commit". Installs worked anyway, because the lockfile already had the answer recorded.
The commit was never missing. pnpm fetches it as a codeload tarball, which serves any commit by sha whether or not it is advertised, and that is what the lockfile pointed at all along. The fix is the same commit written out in full: same tarball, same 0.4.0, no behaviour change, and the lockfile diff is the specifier string and nothing else. What changes is that a clone with no lockfile can now install.