podwise-cli: a Go client that turns podcasts into agent-readable data

The gap podwise-cli fills: podcast content that a script can consume

Podwise.ai produces transcripts, summaries, outlines, Q&A and mind maps from podcast episodes. Those artefacts normally live behind a web dashboard, which is fine for a person and useless for an automation pipeline. The CLI exists to move that same content into a form a program can call: the README describes it as a tool for AI agents, letting LLMs, skills runtimes and automation pipelines fetch structured podcast insights without a browser or a human in the loop. That framing is narrower than "a podcast player for the terminal" and it should shape how you evaluate the project. The intended user is someone building agent workflows, not someone who wants to listen to podcasts in a shell. The repository is written in Go, which means the distributed artefact is a single static binary rather than a runtime-dependent script, and it is published under the MIT licence. The README also points to two adjacent surfaces beyond the plain command line: a set of prebuilt agent skills and an MCP server. Those two are the reason the project is worth a look even if you never type podwise by hand.

How the CLI, the skills layer and the MCP server divide the work

There are three entry points over one backend. The first is the CLI itself: subcommands such as popular, ask, search, process and get. The second is the MCP server, started with podwise mcp, which the README says communicates over stdin/stdout and exposes the same capabilities as tools. The tool list is explicit: search_episode, search_podcast, popular, process, get_transcript, get_summary, get_qa, get_chapters, get_mindmap, get_highlights, get_keywords, ask, drill, follow, unfollow and list_episodes. That is a one-to-one mapping onto the CLI surface, which is a sensible design because it means an MCP client and a shell script reach the same data through the same account. The third entry point is the skills layer, installed with npx skills add hardhackerlabs/podwise-cli. Skills are not a separate API; they are documented workflows that sit on top of the CLI. The README lists catch-up, weekly-recap, episode-notes, topic-research, episode-debate, language-learning, discover and refine-taste. The stated routing is: the agent loads the Podwise CLI reference docs, matches the user's intent to a workflow, then either loads and executes that workflow or runs a CLI command directly. So the data flow is agent to skill or tool, skill or tool to CLI, CLI to the Podwise service, and content back up the same path. Nothing in the material suggests the CLI does transcription locally. It submits work and retrieves results.

Installing and authenticating without guessing at flags

Four installation routes are documented. On macOS, brew install hardhackerlabs/podwise-tap/podwise. Otherwise the install script: curl -sL https://raw.githubusercontent.com/hardhackerlabs/podwise-cli/main/install.sh | sh. There are prebuilt archives on the releases page, unpacked with something like tar -xzf podwise_linux_amd64.tar.gz and moved onto the PATH with mv podwise /usr/local/bin/ followed by chmod +x. And from source, for anyone with Go installed: git clone the repository, cd podwise-cli, go build -o podwise ., then move the binary. Configuration is the part that decides whether the tool is usable at all. The documented path is podwise auth, which opens a browser authorisation flow and saves the API key automatically, followed by podwise config show to verify the connection. If you already hold a key, podwise config set api_key your-sk-xxxx sets it directly. Configuration lives at ~/.config/podwise/config.toml, so the credential is a plain file on disk and any process running as that user can read it. That is the normal shape for a developer CLI and also the thing to think about before wiring it into a shared CI runner. The README does not describe key scoping, rotation or revocation, so treat the file as a secret and manage it the way you manage any other long-lived token.

What the commands actually take and return

The input surface is broader than Podwise's own catalogue. podwise process accepts a Podwise episode URL, a 小宇宙 episode URL, a YouTube video URL, or a local file such as ./episode.mp3. The README marks the Podwise URL as recommended, which is a quiet admission that the other three paths are convenience routes into a service that is happiest with its own identifiers. Retrieval is split by artefact rather than by episode: podwise get summary <url> and podwise get transcript <url>, with the MCP tool list adding Q&A, chapters, mind map, highlights and keywords as separate fetches. That granularity matters for agents, because an agent that needs chapter timestamps should not have to pull a full transcript to get them. Search is similarly split: podwise search episode "machine learning" --limit 20 for episodes by title keyword, and podwise search podcast "Lex Fridman" for shows by name. Discovery has its own command, podwise popular, and question answering has podwise ask "the future of AI Agents", which the README describes as answering from podcast transcripts. Follow and unfollow are documented as idempotent, which is the right property for an agent that may retry a step. The README truncates partway through list_episodes, so the exact behaviour of that tool is not fully described in the material available.

The hosted dependency is the whole ballgame

Every content command is a network call to podwise.ai behind an API key. There is no documented offline mode, no local transcription engine, and no way to point the CLI at a different backend. If the service is unreachable, or the key expires, or the account lapses, the CLI returns nothing useful. That is a deliberate trade: you get transcription, summarisation and mind-map generation without operating any of it, and you accept that the capability is rented. The practical consequence is that podwise-cli is the wrong tool for anyone whose requirement is data residency, air-gapped operation, or a per-episode cost they control. It is also a poor fit if your source material is not already well served by the upstream pipeline; the README gives no detail about supported languages, audio quality thresholds, or how long processing takes, so anyone with unusual inputs should test before designing around it. A second limitation is thinner and easier to miss: the skills installed by npx skills add are documented workflows, and the README says the agent matches intent to a workflow before executing it. Intent matching is probabilistic. For a repeatable pipeline, calling the CLI or the MCP tool directly removes that ambiguity and is the more defensible choice.

Where podwise-cli sits next to a self-hosted transcription stack

The obvious alternative for the same job is a self-hosted pipeline built from an open speech-to-text model plus a summarisation step, orchestrated by something like whisper.cpp or a similar local transcriber. The difference in approach is not a matter of polish; it is where the work happens. A local stack runs inference on your own hardware, so marginal cost per episode is electricity and time, transcripts never leave the machine, and the pipeline keeps working when a vendor does. In exchange you own model selection, diarisation, chunking, prompt design for summaries, and the storage layer for results. podwise-cli inverts every one of those: zero infrastructure, a hosted account, and output shapes that are already decided for you. The CLI's own differentiator is not transcription quality, which the README makes no claims about, but the packaging around it. One binary, a config.toml, an MCP server on stdin/stdout, and a set of named workflows that a skills runtime can pick up. If you already pay for Podwise, the CLI is close to free to adopt. If you do not, the honest comparison is between a subscription and the engineering time to stand up local inference, and that calculation has nothing to do with this repository.

Upgrades, licence and what maintenance looks like from outside

The release cadence visible in the material is roughly one version every two to three weeks: v0.4.0 on 2026-05-05, v0.4.1 on 2026-05-19, v0.4.2 on 2026-05-31, with the last push to main on the same day as v0.4.2. That is an actively developed pre-1.0 project, and pre-1.0 is the operative fact. Command names, flags and MCP tool schemas can change between minor versions, and any agent skill you write against them inherits that instability. Pinning a version is the sane default: Homebrew gives you the tap, the install script pulls the latest, and manual installation from the releases page lets you choose. If you build skills on top of the CLI, note that the README points agents at reference docs that ship separately, so a skill and a CLI version can drift apart. The licence is MIT, which permits commercial and closed-source use and modification provided the copyright notice and permission notice are preserved. That is a permissive licence and it does not impose copyleft obligations on your own code, but it also means the project offers no warranty. The MIT grant covers the CLI source. It does not cover the podwise.ai service, which is governed by separate terms that are not reproduced in the material here, so read those before assuming the same permissions extend to the content you fetch.

Editorial conclusion

Adopt podwise-cli if your pipeline already depends on podwise.ai for transcription and summarisation, and you want that content reachable from shell scripts, skill runtimes or an MCP client without a browser. Do not adopt it if you need self-hosted transcription or a tool that works without a Podwise subscription, because every content command is a call to a hosted service. Before committing, run podwise auth, confirm podwise config show returns a key, then process one episode you already know and compare the returned transcript against the source audio.

Official sources

1. hardhackerlabs/podwise-cli on GitHub
2. License: MIT
3. Project website
4. README
5. Releases