The Go and Protobuf migration cut the parsing pipeline's CPU and memory bills in half. But it left the back office with a different kind of cost: the same plumbing copied across two parsers, a handful of small services doing one job each, and more deployments to operate than the work actually required.

This round of work is about that - not raw performance, but shape. Three changes, all aimed at the same goal: fewer moving parts, less duplicated code, and a foundation that makes the next parsers cheap to build.

Spider has been parsing HTTP/1.1 traffic for years - request lines, headers, status codes, response bodies - and let operators write tag and template rules that pull values out of those parts.

This works perfectly when the body is text.
JSON and XML carry their field names in plain sight, so a rule looking for a client id finds the string clientId sitting right there in the bytes.

Protobuf and MessagePack do not work that way: the body is a compact binary blob, and the field names live in a separate schema, not in the payload. The information is there - it just is not readable as text, so the text rules have nothing to grab onto.

The new HTTP body transcoding feature closes that gap.

• The operator uploads the schema once and declares which requests it applies to.
• From then on, Spider quietly converts each matching binary body into the equivalent JSON before the existing tag and template rules run.
• The same rules that already worked for JSON now also work for protobuf and MessagePack - with no change to the rules themselves.

This version introduces:

• a redesigned UI with new visualizations (multi-protocol view, waterfall),
• a parsing pipeline migrated to Go with Protobuf serialization and gRPC for the hot paths,
• and a new tooling layer for humans and AI agents: the spider and spider-mon CLIs plus two Claude Code plugins that wrap them.
• a vulnerability upgrade agent to lands the release with all known CVEs patched across all 44 active components.

Spider is 40+ Node.js services, 10 Go services, 3 Go clients, and 3 GUIs.
Each one has its own package.json or go.mod with its own dependency tree, its own vulnerable transitive packages, and its own breaking-change risk on every upgrade.

To manage technical debt, I wrote a Claude Code agent that does the entire run on its own.
Result:

• Total elapsed time: about 3h30 for 43 active components.
• Output: 43 fully fixed, 0 failed, 0 CVEs left where a fix existed.

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.