The two CLIs that ship with the coming release - spider and spider-mon - already make Spider accessible from a terminal.

Pointing an LLM at either of them and asking it to figure out the right invocation works, in the same way that pointing an LLM at any CLI works: well enough on simple questions, fragile on real workflows.

The two Claude Code plugins that ship alongside the CLIs solve the fragility.
They teach Claude the data model, the verbs, the conventions, and a set of investigation patterns purpose-built for Spider.

The same questions that takes five hand-prompted CLI calls in plain Claude Code become one skill invocation with a structured report.

Spider has a full self-monitoring GUI: parsing pipeline metrics, agent states, Redis and Elasticsearch internals, service CPU and latency, log search. It is great for browsing and for opening on a screen during an incident.

It is less great when the question is "diff the last hour against last week, on this specific metric".
Or "give me a new performance metrics".
Or "did the upgrade I just rolled out actually move any metric?".
These are queries, not dashboards.

spider-mon is the CLI for those questions.

Spider's UI is great when you want to see what has been captured.

But there is a long tail of moments where the UI is not the right tool:

• a 3 a.m. incident where the goal is "did the call to the payments service actually go out?",
• a CI job that needs to confirm a deployment generated the expected traffic,
• an AI agent that needs to investigate a slow endpoint before suggesting a fix.

Those use cases want a CLI command. spider.

The Controller rewrite in Go last February was a single agent.
The lessons learned there - that Claude could carry a Node service across to Go with feature parity over a handful of evenings, and that the runtime gains were real - made one thing obvious: the parsing pipeline was next.

This release ships the result:

• Seven services migrated.
• Three serialization formats swapped from JSON to Protobuf.
• Three hot paths swapped from REST to gRPC.

The Network-View UI is the largest single codebase in Spider: about 1,800 files of React, with ~35 collection modules, a handful of D3 visualisations, a Cytoscape-based network map, and the grids, filters, dashboards, and timeline that make it the analyst-facing surface.

Until April 2026 it was also six years behind on its dependencies.

This release ships the modernisation.

• React 16 → 18. (React 19 dependencies bring performance issue)
• MUI v4 → v7.
• Classic Redux connect() → Redux Toolkit.
• Webpack → Rspack.
• Moment → Luxon.

~1,800 files touched, hundreds of imports rewritten, hundreds of *Container.js files deleted.

A handful of independent improvements landed over the past few days, all aimed at the same thing: less friction between you and the data.

Every few seconds, the Spider UI polls for the status of all whisperers.
For each one, the backend was returning the complete instances[] array - up to a week of per-instance snapshots. Most of that data was never used during polling.
Fixing it required changes to a backend service, a config service, a Helm chart, and the frontend.

Claude did all of it. Alone.

Spider already offers a grid for browsing communications one by one and a sequence diagram for reading call flows.
Neither of them answers the question at a glance: when exactly did this request happen, how long did it take, and what else was running at the same time?

The waterfall view is the answer.
It places every communication on a shared timeline as a horizontal bar.
The bar's left edge is the start time; its width is the duration. Slow requests are instantly visible as wide bars; gaps between bars reveal idle time; overlapping bars reveal parallel activity.

The centrepiece feature is lane grouping, which groups communications by endpoint pair and stacks concurrent ones vertically - turning the waterfall into a concurrency map.

Spider captures and parses several Layer 7 protocols at once: HTTP and PostgreSQL, both TLS encrypted or not.

Until now, each protocol lived in its own dedicated view.
That worked well for focused investigation - but it made it harder to reason about what a service was actually doing at a given moment, because you had to flip between tabs and correlate manually.

The Unified view (labelled "All" in the view selector) solves this.
It is a unified view that shows HTTP and PostgreSQL communications together in a single grid, sequence diagram, waterfall, and stats panel.

The Spider Controller is the Kubernetes-native agent that watches your cluster in real time: it tracks pods, services, deployments, and ownership chains, attaches capture agents to pods, answers DNS queries, and maintains a live WebSocket connection to the Spider backend. For the past few years it has been written in Node.js. That changes now.