Anthropic released Claude Code — the agentic CLI — into general availability in early 2025.¹ Within weeks I was running it across half a dozen active projects simultaneously: finessume, pegues.io, LGTM, VIKI, LFG. The experience was powerful and opaque in equal measure. Every session ran its own agent process, spent its own token budget, and modified its own files. There was no way to see what all of them were doing from a single vantage point.

The first thing I noticed was that sessions would collide — two instances reading and writing the same .claude/CLAUDE.md, each making decisions based on stale context the other had already changed. Config divergence was silent and cumulative. I needed tooling that didn’t exist yet. That gap became CCEM.

Version 1.0.0 shipped on October 17, 2025 as @ccem/core: a focused TypeScript / Node.js CLI that solved the immediate problem of safely managing Claude Code config files across concurrent sessions. I built it TDD-strict from the first commit — every phase had a full test suite before any implementation code. Seven commands shipped at v1.0.0:

• ccem merge — five strategies (recommended, default, conservative, hybrid, custom) for reconciling divergent .claude/ configs
• ccem backup and ccem restore — compressed archives with SHA-256 checksums
• ccem audit — Zod²-based security scanning of .claude/ configs with severity filtering
• ccem fork-discover — conversation history analysis to identify divergence points between sessions
• ccem validate — schema validation against known Claude Code config formats
• ccem tui — an Ink³ interactive terminal UI with 6 views

v1.0.0 released with 543 tests at 92.37% coverage. By December 2025, a React/Express web UI layer and Chrome DevTools MCP⁴ integration brought the test count to 867 at 96.89% coverage.

When Anthropic shipped the Claude Code hooks system⁵ — SessionStart, PreToolUse, PostToolUse, SubagentStart, SubagentStop, SessionEnd — I had a way to push real-time data out of every running session. I built a Python monitor: a single ~500-line file using stdlib http.server with an embedded HTML/JavaScript dashboard, D3.js dependency graphs, and a Ralph methodology⁶ flowchart.

It worked. It also collapsed the moment three sessions fired heartbeats simultaneously. Python’s GIL⁷ and http.server’s single-threaded request model meant concurrent heartbeats serialized, timestamps drifted, and dashboard state arrived in bursts. Across 10+ active Claude Code sessions, that was unacceptable. The Python monitor wasn’t a failure — it was an exact proof of concept that told me precisely what I needed next: a concurrency model designed for this problem.

The Phoenix APM launched in v2.0.0 (November 2025) as a git submodule, on port 3031. I reimplemented every feature from the Python monitor — agent fleet view, D3.js dependency graph, Ralph methodology flowchart — but now backed by OTP processes instead of a polling loop. Every registered Claude Code session has a dedicated GenServer that owns its state; the D3 graph updates in real time via Phoenix PubSub the moment a hook fires.

In December 2025 I added a second component: CCEMAgent, a native SwiftUI macOS menubar app. I wanted the monitoring layer to be ambient — always present without occupying a browser tab. CCEMAgent polls port 3032, surfaces project count, active sessions, and UPM wave progress in the system menu, and uses LaunchAtLogin (ServiceManagement framework) so it starts with macOS automatically. UNUserNotificationCenter delivers native notifications when session states change.

By February 2026, I had 38 active projects registered in apm_config.json. The single-project assumption baked into v2.0.0 had to go. The v2.2.x refactor introduced subdirectory-namespaced sessions in ETS, a project router, and a port manager for clash detection. Each project has its own namespace in the ETS session index — project A’s sessions are completely isolated from project B’s at the data layer, even though they share a single Phoenix process. session_init.sh upserts the active project into apm_config.json automatically on every new Claude Code session start.

The test suite was the forcing function. After the multi-project refactor, v2.3.3 had 193 test failures. I worked through them systematically using a GenServerHelpers pattern that correctly handles OTP’s async message-passing lifecycle in test contexts. Zero failures on release.

v2.2.1 also shipped an OpenAPI 3.0.3 specification covering 50+ endpoints across REST, SSE, and LiveView routes. The v2 API surface added SLOs, alert rules, audit log, and a full v3-compatibility endpoint layer so existing hook integrations required no changes to continue working.

In early March 2026, the AG-UI (Agent-User Interaction) protocol¹³ emerged as an open standard for streaming structured agent events to frontend UIs. Where CCEM had been using proprietary endpoints (/api/register, /api/heartbeat, /api/notify), AG-UI defined a typed, portable event vocabulary across seven event categories.

I integrated AG-UI in two layers. In v5.0.0, three new GenServers backed an SSE event stream at /api/ag-ui/events: EventRouter (routes and fans out incoming events), HookBridge (translates every legacy hook call into the equivalent AG-UI event automatically — existing integrations got AG-UI emission for free, with zero changes to their hook scripts), and StateManager (maintains canonical agent state using RFC 6902 JSON Patch¹⁴ for efficient state diffs).

In parallel, I extracted a standalone Elixir library: ag_ui. Fifteen core type structs, 30 event structs, SSE and Phoenix Channel transports, a middleware pipeline, and an HTTP agent client — all independently testable and ready for publication to hex.pm. The library shipped with 75 tests and zero failures.

CCEM v5.1.0 is three tightly integrated components built and maintained entirely by me over five months:

• @ccem/core CLI/TUI — TypeScript, Node.js, Ink. 7 commands, 867 tests at 96.89% coverage. Manages config files, merges, backups, security audits, and fork detection.
• APM Server (apm_v5) — Phoenix/Elixir, Bandit, LiveView. 30+ OTP GenServers, 22 LiveView pages, 50+ REST/SSE routes, OpenAPI 3.0.3 spec, ETS session index, PubSub broadcasts. Monitors N concurrent Claude Code sessions across 38 registered projects.
• CCEMAgent — SwiftUI/macOS. Native menubar app, WebKit APM window, UNUserNotificationCenter, LaunchAtLogin, AG-UI chat view and agent management controls (v5.1.0).

Plus a standalone Elixir library (ag_ui) with 75 tests — 15 type structs, 30 event structs, SSE + Phoenix Channel transports — independently publishable to hex.pm.

More than the code, CCEM reflects how I approach engineering: when a new standard or protocol emerges, I don’t wait to see if it gains adoption — I ship an implementation. MCP arrived and I built hook integrations. AG-UI arrived and I extracted a library. Claude Skills emerged and I built a SkillsRegistry GenServer. Each pivot was deliberate, fast, and grounded in the architectural work already done. The bet on Elixir’s actor model paid for itself every time a GenServer crashed and restarted silently while 10 other sessions kept running.

When AG-UI v1 landed in early 2026, there was no Elixir SDK. The protocol is a natural fit for the BEAM — typed event structs map cleanly to Elixir structs, SSE streaming is trivially composable with Plug, and state management over JSON Patch is a GenServer problem. I shipped ag_ui_ex v0.1.0 in one sprint.

Install

def deps do
  [
    {:ag_ui_ex, "~> 0.1.0"}
  ]
end

mix deps.get

Quick Start

alias AgUi.Core.Events

event = %Events.RunStarted{
  run_id:    "run-001",
  thread_id: "thread-001",
  timestamp: DateTime.utc_now() |> DateTime.to_unix(:millisecond)
}

{:ok, sse_data} = AgUi.Encoder.EventEncoder.encode(event)

# Stream events in a Phoenix controller
def stream(conn, _params) do
  AgUi.Transport.SSE.stream_events(conn, fn send ->
    send.(%Events.RunStarted{run_id: "run-001"})
    send.(%Events.RunFinished{run_id: "run-001"})
  end)
end

The library distils the same pattern applied to CCEM APM v5: let the BEAM’s actor model carry the concurrency burden, keep the event schema explicit and typed, and make the transport layer a thin wrapper over Plug. When upstream PR #1293 is accepted, ag_ui_ex joins Go, Rust, Dart, Kotlin, Java, and Ruby as a first-class entry in the AG-UI protocol community SDK registry.