Find what’s driving the size
of your Go binary
bonsai compiles your binary, measures which dependencies drive its size and
its minimum Go version, and reports how much each one would save if removed.
What it does
Reports retained size
Each dependency is measured by the bytes that would leave the binary if it were removed, not its source or download size. Weight shared with dependencies you keep is not double counted.
Reads the linker, not go.mod
bonsai compiles the target and uses the linker’s post-DCE reachability, so code that dead-code elimination already stripped is not counted. Nothing is inferred from the module graph.
Ranks candidates by size and effort
Candidates are ordered by bytes at stake and by how hard they are to remove. Cuts are sequenced so that weight shared between dependencies is attributed and freed in the right order.
Sees inside transitive dependencies
Mark the code you control and bonsai reports savings from cutting imports inside dependencies-of-dependencies, which tools that only read direct dependencies cannot account for.
Reports the Go version floor
The minimum Go version your dependencies require, per target platform. Shows which dependency sets the floor and how removing it changes the minimum.
CLI, TUI, JSON, and MCP
Tables in the terminal, an interactive explorer, JSON output for CI, and an MCP server for agents.
How bonsai sees your dependencies
Every module lands in one class, and the class decides whether a cut is even possible. The --controlled boundary is the one thing you move, and moving it is how you reach the weight buried deeper in the graph.
--controlled matches. Never pruned; bonsai looks for imports to cut out of it.--controlled to push this boundary deeperWidening --controlled promotes a whole layer of 3rd-class deps into 2nd-class candidates. That is the lever: it exposes the cuttable surface further down and lets bonsai wring out weight that tools reading only your go.mod never see.