pbi-cli: a Power BI command layer for Claude Code, split into a connected model half and an offline report half

The gap pbi-cli fills: an agent that can only read files cannot fix a measure

Power BI work splits into two artifact types that normally need two different tools. The semantic model is a live Analysis Services tabular database; the report is a folder of JSON. An AI agent handed only a filesystem can read TMDL or PBIR text but cannot evaluate a DAX expression, check whether a relationship is active, or confirm that a measure returns what its author intended. That is the gap pbi-cli targets. Its README frames the pitch as giving Claude Code "the Power BI skills it needs", and the mechanism is a CLI that the agent shells out to rather than a plugin that runs inside the agent. The audience is narrow and explicit: Windows users with Python 3.10+, Power BI Desktop already open, and Claude Code as the interface. If you model in Tabular Editor and review in the Desktop UI, most of what pbi-cli offers is already covered by tools you have.

Two layers that share a name and almost nothing else

The architecture diagram in the README is the most useful part of the documentation because it makes the split explicit. The semantic model layer uses in-process .NET interop from Python to Power BI Desktop through TOM and ADOMD, with bundled DLLs shipped inside the package at `pbi_cli/dlls/`. The README states there is no MCP server and no external binaries, and that execution is sub-second. The report layer does something entirely different: it reads and writes PBIR JSON files directly, needs no connection, and works against `.pbip` projects. That difference has practical consequences. Model commands fail without a running Desktop instance. Report commands work on a checked-out repository with no Power BI installed at all. A workflow that mixes both, say editing a measure and then binding a visual to it, crosses a boundary where one half can silently be operating on a stale in-memory model while the other edits files on disk. The README does not describe how conflicts between the two are resolved, and that is a real gap rather than a detail.

Getting it running: three commands and a PATH trap

The README gives a three-step install. `pipx install pbi-cli-tool` handles PATH automatically, then `pbi-cli skills install` registers the Claude Code skills as a one-time setup, then `pbi connect` attaches to Power BI Desktop. The package name on PyPI is `pbi-cli-tool` while the executable is `pbi-cli` and `pbi`, which is worth noting because a `pip install pbi-cli` will not get you this project. The README also documents the pip path and the failure it produces: on Windows, `pip install` often places the `pbi` command in a directory that is not on PATH. The suggested fix is to print the Scripts directory with `python -c "import site; print(site.getusersitepackages().replace('site-packages','Scripts'))"`, add it to PATH, and restart the terminal. That is an honest piece of documentation, and the recommendation to use pipx instead is the right one. Configuration lives in `~/.pbi-cli/`, with `config.json` holding the default connection preference, `connections.json` holding named connections, and `repl_history` storing command history. There is also a REPL, implied by that history file, though the README does not document its commands in the material available.

What the 13 skills actually change about using it

The README says that after `pbi-cli skills install`, Claude Code discovers 13 Power BI skills, each teaching the agent a different area, and that you do not need to memorize commands. This is the part of the design that distinguishes pbi-cli from a plain CLI wrapper. A bare CLI requires the agent to know the subcommand surface; skills move that knowledge into the agent's context. The trade-off is that skill quality now determines output quality, and the README does not enumerate the 13 skills or describe their boundaries in the supplied material. It also means the install step is load-bearing: skip `pbi-cli skills install` and you have a CLI the agent has to guess at. The examples the README shows are task-shaped rather than command-shaped: create measures in bulk, debug broken DAX, snapshot and restore the model, audit for issues, test row-level security. Those are the operations where a live connection earns its keep, because each one needs the engine to evaluate something.

The report layer is the half you can use without Power BI installed

Report authoring in pbi-cli works on PBIR files, which the README expands as Enhanced Report Format, and on `.pbip` projects. No connection is needed, which makes this layer usable in CI or on a machine that has never had Desktop installed, provided you are on a platform where the package installs. The README advertises a six-step report workflow and names the surface: visuals, pages, themes, filters, across 32 visual types. Release v3.11.0 added custom visual authoring for `.pbiviz`, and v3.11.1 fixed custom visual metadata, so that path is recent and has already needed one correction. The obvious limitation is format lock-in. A `.pbix` file is a binary container; the report layer edits JSON. If your reports are still `.pbix`, this half of the tool has nothing to open, and the README does not describe a conversion step. Teams that have not moved to PBIR or `.pbip` should treat the report layer as unavailable until they do.

Windows, Desktop, and the cost of a live connection

The README states the requirements plainly: Windows with Python 3.10+ and Power BI Desktop running. That is the hardest constraint in the project. The semantic model layer depends on in-process .NET interop with a Desktop process, so there is no headless server path described, no Linux container story, and no macOS story. For a team that wants model checks in a Linux CI runner, pbi-cli is the wrong tool; the report layer alone might fit, but the package still has to install and the DLLs are Windows-oriented. There is a second cost that the README does not discuss: a live connection means the model you are editing is the one open in Desktop. Bulk measure creation and model health checks run against that state, and the snapshot and restore features exist precisely because edits are consequential. Anyone adopting this should treat the Desktop file as the source of truth and keep the snapshot habit, not because the README warns about it but because the operations it advertises are bulk mutations with no described undo beyond restore.

Tabular Editor is the comparison that matters

Tabular Editor is the established alternative for the semantic model half, and the difference is not features but who is driving. Tabular Editor is a GUI and a scripting host: a human clicks through a tree of measures, or writes C# scripts that run against the TOM object model. pbi-cli exposes a similar TOM surface but expects an AI agent to compose the calls, and it adds a report layer that Tabular Editor does not cover in the same package. So the choice is roughly this. If you want a person reviewing each model change in a visual tree, with scripting for the repetitive parts, Tabular Editor is the more mature and better-documented path. If you want an agent to make twenty measure edits from a chat prompt and you accept that you will verify the result afterwards, pbi-cli is aimed at exactly that. The report layer has no direct equivalent in Tabular Editor, which is the strongest argument for pbi-cli as a single tool. Note that the README does not benchmark the two against each other, and this comparison rests on what each tool is, not on measured speed.

Licence, releases, and what you are signing up to maintain

pbi-cli is MIT licensed, which permits commercial use, modification and redistribution with the licence text retained. That is permissive and low-friction, and it is the same licence Tabular Editor's CLI carries, so licence is not a differentiator here. This is not legal advice; check the LICENSE file and your own obligations. On maintenance, the release history in the supplied material shows v3.10.10 in April 2026, v3.11.0 and v3.11.1 on the same day in May 2026, and the last push in September 2026. The cadence is active, and the fact that v3.11.1 shipped hours after v3.11.0 to fix custom visual metadata suggests the custom visual path is newer and less settled than the core model commands. The upgrade cost is mostly environmental: bundled DLLs ship inside the package, so a Power BI Desktop update that changes the TOM or ADOMD surface is a compatibility event you cannot patch yourself. Pin the version in your environment and re-run `pbi connect` after Desktop updates rather than upgrading pbi-cli blindly.

Editorial conclusion

Adopt pbi-cli if you are on Windows, already drive Power BI Desktop from Claude Code, and want bulk measure edits, DAX debugging, snapshots and RLS testing without leaving the chat. Do not adopt it if you are on macOS or Linux, if your reports live in the legacy .pbix binary rather than PBIR, or if you want a GUI where a human reviews each model change. Before committing, verify three things: that `pbi connect` attaches to your running Desktop instance, that your report is in PBIR or .pbip form so the offline layer has files to edit, and that `pbi-cli skills install` actually registers the 13 skills in your Claude Code setup, since the model layer is useless without that handshake.

Official sources

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