zero_inspector_kit ships a debug console inside your Flutter app, and the 1.14.0 changelog says what leaked

One line of code, except for the route tracker

The headline integration claim is explicit: one line of code, no changes to existing project code, with the panel auto-disabled in release builds. Most of the tool honours that, because logging capture hooks print and debugPrint rather than asking you to route your logger anywhere, and network capture covers both the http package and Dio. One feature does not. Route tracking is wired through a navigator observer, and the configuration it requires reads navigatorObservers: [InspectorRouteObserver()], which means adding an entry to your MaterialApp. That is a one-line edit to a file you already own, and it is the only one the integration story asks for, but it contradicts the absolute phrasing of the claim. There is also an overlay to think about: a floating button with a breathing animation that auto-docks to the screen edges, positioned specifically to stay clear of the back gesture. Whether that overlay sits over your UI during a demo depends on configuration the readme does not spell out.

The 1.14.0 upgrade note is a list of things that leaked

The most informative paragraph in the readme is the upgrade banner at the top, and it is worth reading as a changelog in prose rather than as marketing. It names eight categories of problem fixed in 1.14.0: unreleased UI controllers and scroll positions, a duplicated WebSocket connection, double-closed WebSocket sessions, a broken alert throttle, persistence double-initialisation, memory-leak tracking that mis-keyed its records, Dio failure and stream edge cases, and gaps in sensitive-data masking. Three of those are resource leaks in the inspector itself rather than in your app, which means the tool was consuming memory and holding sockets on your behalf while you were trying to find the leak. Sensitive-data masking appearing in the same list is the item to sit with, because a network inspector that logs request bodies is only useful if the redaction is right, and the note admits the gaps without saying what closed them.

Session data lands in a database the inspector also shows you

Persistence arrived with version 1.9.0 and it is not an export-only feature. Logs, network records, errors and alerts are flushed asynchronously into a database the plugin creates for itself, named zero_inspector_kit.db, described as a disk ring buffer. The neat consequence is that this file is itself visible in the Database tab, so the tool that inspects your databases also inspects its own, and you can watch the buffer fill while you work. On launch, logs, errors and alerts replay back into their tabs, which turns a debug session into something you can reconstruct after the fact rather than something you had to be watching for. Alerts are part of that: they are persisted to disk and survive app restarts, and the panel header exports and shares the full session archive including them. The trade is that a diagnostic artefact is now written into your app's storage on every debug run, which is worth a thought if your build has data-retention rules attached to it.

The replay editor only lets you change query params

Replay is asymmetric by design, and the readme is clear about which half you get. The in-app replay editor lets you edit query parameters and preview the response, while the URL, the headers and the request body stay read-only. That is a reasonable boundary for retrying a request you have already seen, since the query string is where the variable part of most GET requests lives, and it deliberately keeps you from reconstructing a POST body by hand and accidentally replaying a mutation. Alongside it you get batch copy of requests as cURL, filtering by method, status and whether the request was intercepted, and interceptor rules that can modify bodies and headers on the way out. Those interceptor rules and the replay editor are different mechanisms with different permissions: one rewrites traffic live, the other edits only the query string of a captured request, and the readme keeps them in separate sections because they are.

WebSocket and gRPC capture start switched off

Streaming protocols are opt-in, and the reason given is that runtime toggles like the memory and FPS monitors exist to avoid overhead. WebSocket frames and gRPC calls do appear in the same Network list as HTTP traffic rather than in a separate view, so a single filter spans all three once capture is enabled. The cost of that default is visible in the 1.14.0 notes, which include a duplicated WebSocket connection and double-closed WebSocket sessions, and neither of those would be found by a project that never turned the capture on. Given that the fix shipped in the version the readme tells every user to upgrade to, the practical reading is that the feature was off by default while it was still being debugged. Turning it on costs nothing in configuration terms, and it is the only way the WebSocket path in this plugin gets exercised at all.

The jank threshold is computed from your refresh rate

The frame monitor does two things that a fixed threshold cannot. Frame records carry phased build and raster timing, so a dropped frame is attributed to the build phase or the raster phase rather than counted as an undifferentiated jank. And the jank threshold itself is adaptive, derived from the display refresh rate, explicitly so that 120Hz screens stay strict instead of inheriting a 60Hz budget and passing frames that a user would see as stutter. That is a small design decision with real consequences: on a high-refresh panel the monitor will report jank that a naive threshold would hide, so a rising jank count after a display change is not necessarily a regression in your rendering code. The monitor carries a master switch for the same reason the memory monitor does, to keep the sampling cost off builds that do not need it, and the readme treats that as a feature rather than an admission.

Leak detection borrows Flutter's own allocation list

Since 1.9.0 the leak detector bridges Flutter's official FlutterMemoryAllocations rather than running only its own tracking. The stated purpose is cutting false positives, which is the correct problem to solve: a leak detector that reports retained objects that the framework is holding on purpose trains you to ignore it. The rest of the memory monitor is broader than the word leak suggests. It shows a trend chart, the Dart heap, a native memory breakdown, image cache statistics and storage statistics, so the panel covers both sides of the process rather than only the managed side. The companion correction in 1.14.0 is that leak tracking was mis-keying its records, which means a leak list from an earlier version could attribute retention to the wrong object. For anyone who acted on those reports, the upgrade changes what the historical numbers mean as well as fixing them.

Two install paths, and one of them points at a branch

The recommended install is the pub.dev dependency, pinned to the current release line. The alternative is a git dependency, and its shape is worth reading closely because it is not a tag reference. The ref is a branch named for the version it was cut from, and the line above it carries a comment telling you to replace 1.14.0 with the version you need, which means every upgrade is a manual edit to the ref in your pubspec rather than a resolved version bump. That is the trade the git path offers: you get the source at exactly the revision the maintainers cut, at the cost of managing the pointer yourself. Both paths install the same package, and the version in the pubspec should agree with the release you are actually chasing, since the readme tells every user to move to 1.14.0 and the git branch name carries that same number.

dependencies:
  zero_inspector_kit: ^1.14.0

The git variant is equally short, but note that the ref line is a branch rather than a tag, so it tracks whatever the maintainers push to that branch rather than a fixed commit.

Editorial conclusion

Adopt it when you are shipping a Flutter app to Android or iOS and need to diagnose a problem on a real device rather than on your desk, since it captures print and debugPrint output, HTTP and Dio traffic, and crash signatures without you rewiring your network layer. Skip it if you need web or desktop targets, because the supported platforms are named as Android and iOS only and the repository carries no other platform directories. Before you trust it, check the single-line integration claim against the one feature that is not single-line, the route tracker, which needs an observer added to your navigator. And read the 1.14.0 upgrade note before upgrading, because it enumerates the exact failure modes that earlier versions had.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes