history

Pre-Alpha. This page describes behavior that may change.

Where Ze came from, and how it got to where it is now. Short version: it is the successor to ExaBGP, written from scratch in Go by the same author, with heavy help from AI coding assistants, and it is still pre-alpha.

ExaBGP, the long tail

ExaBGP started in 2009 or so, in Python, as a tool for letting scripts inject and observe BGP routes. It was never meant to be a router. It was a BGP speaker with a JSON event stream on stdout and a text command protocol on stdin, and the programmable model was the whole point. People built DDoS mitigation systems on it, traffic-engineering controllers, looking glasses, monitoring collectors, and long-tail research tools. It is still in production at networks all over the world.

The codebase aged. Python single-threaded performance became the bottleneck. Address-family support lagged behind what modern peers expect. The internal architecture was the one you would expect from a codebase written gradually over fifteen years: a lot of it worked, some of it was quietly broken, and a ground-up rewrite was the honest answer.

A full rewrite is not something a solo developer takes on lightly. The reason Ze exists is that the maintenance landscape changed in 2024 and 2025.

The AI-assisted angle

Ze exists because AI coding assistants (Claude Code in particular) made a ground-up BGP rewrite feasible for one person. That is the honest reason. The author focused on architecture, design decisions, and the BGP knowledge accumulated from a decade of ExaBGP. The assistant handled the volume of protocol encoding, boilerplate, test generation, and fuzz harness plumbing that would otherwise have eaten months.

This shows up in the project in three places. The test suite is larger than a solo project would usually ship with. The plugin count is higher than a solo project would usually ship with. And the in-tree documentation is unusually thorough because documentation is cheap when the tool that writes it can also read the code.

It also shows up in the decisions that were made. A ground-up rewrite lets you pick the architecture. Ze's architecture (a content-agnostic event bus, BGP as a subsystem of plugins on top, YANG-modeled config end to end, five operator surfaces over one tree) is what a decade of ExaBGP taught the author he would do differently if he could start over. That is what Ze is.

Contributors using Claude Code in the Ze repo have access to project-specific slash commands for specs, implementation, review, and testing. The Claude Code cheat sheet lists them all.

What changed from ExaBGP

ExaBGP and Ze share a model (programmable BGP through events and commands) and an intent (be the daemon automation teams reach for). Everything under the hood is different.

	ExaBGP	Ze
Language	Python	Go
Threading	Single-threaded	Goroutines, one per peer plus worker pools
Wire parsing	Eager	Lazy (WireUpdate holds byte-slice references into the read buffer)
Plugin model	External processes only, line protocol	Internal Go plugins and external processes, same APIs
Config	Custom syntax, bespoke parser	YANG-modelled, atomic commits, rollback, hot reload
Operator surfaces	CLI and API	CLI, Web UI, Looking Glass, MCP, REST
Address-family coverage	Narrow	Wide (EVPN, FlowSpec, BGP-LS, VPNv4/6, labeled unicast, VPLS, MVPN, RTC, MUP)
Best-path selection	None (by design)	In the bgp-rib plugin, when acting as a route server
Chaos testing	None	Built in, deterministic, with dashboard
RPKI	None built in	bgp-rpki plugin with RTR client

Some of those differences are intentional divergences rather than fixes. ExaBGP's attribute ordering in UPDATE messages sorted by type code. Ze's ordering follows RFC 4271 Section 5 plus optional attributes, because a fixed order is simpler to implement and RFC-compliant. The neighbor-qualifier syntax ExaBGP uses to target one of several sessions to the same peer is not in Ze. Commands apply to all sessions matching the peer IP. The in-tree exabgp-differences page has the full list.

Where Ze is now

Ze is pre-alpha. No releases, no production deployments, and the APIs and config syntax are explicitly not stable. The version number is YY.MM.DD based on the build date, which is the most honest thing a pre-release project can do.

The things that work today: BGP session establishment, capability negotiation, route reception and forwarding across the full ExaBGP feature set, the plugin model, the YANG config tree, the atomic commit workflow, the five operator surfaces, the chaos testing framework, and the ExaBGP migration path. The status page is the honest current list of what works and what does not.

See also

• What is Ze for the five-minute introduction.
• Why Ze for the long-form "when to use it, when not to".
• Status for the honest current state.
• In-tree README for the authoritative project statement.
• ExaBGP if you want to see where Ze started.

Adapted from main/README.md and main/docs/exabgp/exabgp-differences.md.