The open-source tool tour: end to end

TL;DR. Chapter 15 is the map from lever to project; this chapter is the test drive. Seven prominent, actively maintained open-source tools, each taken through the same loop: what it is, how it works inside, and a full end-to-end use case that starts at a real terminal, usually with a Claude Code session open, and ends with a measured number. Two of the walkthroughs (ccusage and Repomix) were run for real on this machine and show verified output, including Repomix compressing this book's own code from 37,906 to 23,093 tokens. The others touch tools not installed on the build box and are written as precise follow-along with outputs labeled illustrative.

Contents

How to read the tour
ccusage: the usage ledger, productized
Repomix: pack a repository into one context
LLMLingua: compress a prompt before it ships
Mem0 over MCP: memory that survives /clear
Langfuse: traces and token dashboards
promptfoo: benchmark the prompt itself
LiteLLM: the metering gateway
Choosing from the tour
Further reading
Takeaways

How to read the tour

Each section follows the same shape, because the shape is the lesson:

What it is and where it sits: which lever from this book it implements, and which layer it lives at (inside the session, beside it, or in front of the API).
How it works inside: enough mechanism that the tool is not magic. Every one of these reduces to a technique you already built from scratch in an earlier chapter.
End to end: a concrete session, from install to a number you can compare. The habit this part has drilled applies to tools too: measure before, apply, measure after, keep it only if the realized number moved (Chapter 20 is the cautionary tale).

ccusage: the usage ledger, productized

What it is. A community CLI (github.com/ryoppippi/ccusage) that does exactly what Chapter 25's lab script did, with a product around it: it parses the transcript JSONL under ~/.claude/projects/, prices every usage block against current model rates, and renders daily, weekly, monthly, per-session, and live reports. Entirely local, no API key, no network call for your data.

How it works inside. The same three moves as our usage_ledger.py: walk the JSONL, extract message.usage from assistant lines, multiply by a price table (fetched or cached). The value it adds is upkeep (model prices tracked for you), deduplication across agents (it also reads Codex and other CLI agents' logs), and the live view.

End to end. No install; run it where Node is available:

npx ccusage daily --since 20260627

Real output from this machine (trimmed to the frame; a snapshot from the day this chapter was written):

┌────────────┬───────────────┬─────────────┬───────────┬────────────┬─────────────┐
│ Date       │ Agent         │ Models      │     Input │     Output │  Cost (USD) │
├────────────┼───────────────┼─────────────┼───────────┼────────────┼─────────────┤
│ 2026-06-27 │ All           │             │    95,545 │    125,366 │      $40.73 │
│            │ - Claude      │ - opus-4-8  │    14,807 │    113,448 │      $39.72 │
│            │ - Codex       │ - gpt-5.5   │    80,738 │     11,918 │       $1.01 │
│ 2026-06-28 │ All           │             │    10,241 │    128,899 │      $11.50 │
│ 2026-06-29 │ All           │             │     1,747 │     66,511 │      $15.39 │
│ 2026-06-30 │ All           │             │   421,496 │    787,863 │     $200.44 │
│ 2026-07-01 │ All           │             │    20,988 │     30,717 │      $15.53 │
│            │ - Claude      │ - fable-5   │    20,988 │     30,717 │      $15.53 │
├────────────┼───────────────┼─────────────┼───────────┼────────────┼─────────────┤
│ Total      │               │             │   550,017 │  1,139,356 │     $283.59 │
└────────────┴───────────────┴─────────────┴───────────┴────────────┴─────────────┘

Notice how it confirms the ledger chapter's economics from a different angle: the Input column here is uncached input only (the cache traffic is broken out in the wider table), and output exceeds input on most days, which is Chapter 2's expensive half doing most of the billing. The other two commands worth knowing: npx ccusage session ranks sessions like our top-5 list, and npx ccusage blocks --live is a live burn-rate meter for the current 5-hour window, the closest thing to a fuel gauge while an autopilot run is going.

Repomix: pack a repository into one context

What it is. A packer (github.com/yamadashy/repomix) that flattens a repository into a single AI-friendly file, with per-file token counts, a directory tree, and an optional tree-sitter compression mode. It is the Chapter 5 idea (structure- aware selection) packaged for the "get a whole codebase into a context window" job.

How it works inside. It walks the repo respecting .gitignore, filters with include/exclude globs, strips what you ask (comments, blank lines), counts tokens per file, and emits one XML or Markdown document. --compress parses each file with tree-sitter and keeps signatures and structure while dropping implementation bodies, the same trade Chapter 5 measured.

End to end. The use case: you want a fresh Claude session (or claude.ai, or another model with a big window) to reason about a codebase without an agent crawling it file by file. Pack this book's own lab code:

npx repomix --include "books/context-engineering/code/**" -o pack.xml

Real output from this machine (the summary block):

📈 Top 5 Files by Token Count:
──────────────────────────────
1.  books/context-engineering/code/attention_efficiency.py (3,179 tokens, 12,124 chars, 8.4%)
2.  books/context-engineering/code/temporal_kg.py (2,771 tokens, 10,865 chars, 7.3%)
3.  books/context-engineering/code/semantic_cache.py (2,701 tokens, 10,669 chars, 7.1%)
4.  books/context-engineering/code/kv_cache.py (2,635 tokens, 9,891 chars, 7%)
5.  books/context-engineering/code/agent_memory.py (2,629 tokens, 10,711 chars, 6.9%)

📊 Pack Summary:
────────────────
  Total Files: 18 files
 Total Tokens: 37,906 tokens

Re-run with --compress and the same 18 files pack to 23,093 tokens, 39 percent smaller (also measured on this machine), because bodies went and signatures stayed. Note the free gift in the report: a ranked token census of your codebase, which is Chapter 2's "count before you optimize" done for you. The pack lands in your Claude Code session with a one-liner (claude "Read pack.xml and map the module dependencies"), or in any chat UI by pasting. The trade to respect: a pack is a snapshot that goes stale on the next commit and a cache-unfriendly single blob, so it suits one-shot reviews and cross-repo questions, not a live editing loop where targeted reads win.

LLMLingua: compress a prompt before it ships

What it is. Microsoft's prompt compressor (github.com/microsoft/LLMLingua), the production version of Chapter 3's from-scratch compressor: it deletes low-information tokens from a long context so the same meaning arrives in fewer tokens.

How it works inside. A small language model scores each token's information content (LLMLingua-2 trains a classifier for it); the compressor drops the lowest-value tokens coarse-to-fine (document, then sentence, then token level) toward a target ratio, keeping the question and any sections you protect.

End to end (follow-along; the library is not installed on this box):

pip install llmlingua

# Illustrative: compress a long retrieved document before sending it to Claude.
from llmlingua import PromptCompressor

plc = PromptCompressor(
    model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
    use_llmlingua2=True,
)
result = plc.compress_prompt(long_document, rate=0.4,       # keep ~40%
                             force_tokens=["\n", "?"])
print(result["origin_tokens"], "->", result["compressed_tokens"])

11,342 -> 4,619   (illustrative)

Then verify with the provider's own counter before trusting the ratio (Chapter 2: never budget with a foreign tokenizer), and A/B the answer quality on your own task before adopting it. The honest framing from Chapter 3 stands: compression shines on bulky, redundant reference text (retrieved docs, transcripts, logs) and degrades instructions and code, so aim it at the biggest, dullest block in your prompt and nothing else.

Mem0 over MCP: memory that survives /clear

What it is. Mem0 (github.com/mem0ai/mem0) is the extract-store-retrieve memory layer from Chapter 9; its MCP server (and the hosted OpenMemory variant) plugs that layer into Claude Code as tools, so facts outlive the session instead of dying with the window.

How it works inside. On store, an LLM pass extracts discrete facts from conversation text and upserts them into a vector store with metadata (dedup and conflict resolution included, the part naive implementations get wrong). On retrieve, the current query is embedded and the top-matching facts come back. Exactly the pipeline Chapter 9 built, with persistence and an API.

End to end (follow-along): register the server once, then use it from any session.

claude mcp add mem0 --scope user -- npx -y @mem0/mcp-server   # or the OpenMemory server
claude

Inside the session, the memory tools appear alongside the built-ins, and the workflow is:

> Remember for later: our deploy target is Cloudflare Pages, build is bash
  build.sh into public/, and we never commit runtime artifacts.
  [tool: mem0.add_memory -> stored 3 facts]                    (illustrative)

/clear

> What's our deploy setup?
  [tool: mem0.search_memory("deploy setup") -> 3 facts, ~90 tokens]
  Your site deploys to Cloudflare Pages; bash build.sh writes public/ ...

The measured claim to check with /context: after /clear, the answer costs a ~90-token retrieval instead of re-reading files or re-explaining, and nothing about the deploy setup occupies the window until asked for. The decision to make deliberately: Claude Code already has CLAUDE.md and auto memory (Chapter 18) for project facts, so a memory MCP earns its place for what those do not cover: cross-project facts, per-user preferences at scale, or memory shared by other agents and apps outside Claude Code.

Langfuse: traces and token dashboards

What it is. An open-source LLM observability platform (github.com/langfuse/langfuse, self-hostable): traces, token and cost dashboards, and evaluation tooling. In this book's terms it is Chapter 25's layer 3 with a UI: the place fleet-level usage blocks go to become graphs.

How it works inside. Everything is a trace made of observations; each generation observation carries the model, the prompt, and the same usage fields this part lives on. Ingestion is an OpenTelemetry endpoint or native SDKs; dashboards aggregate tokens and cost by model, user, and tag.

End to end (follow-along): the shortest path from Claude Code to a dashboard is pointing the built-in OTel exporter at Langfuse's OTLP endpoint:

docker compose up -d           # self-host Langfuse, or use the hosted endpoint

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://<your-langfuse-host>/api/public/otel
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic <base64 pk:sk>"
claude

From then on every session streams claude_code.token.usage and claude_code.cost.usage into the dashboard, sliced by model and user, and the questions that took a script in Chapter 25 ("is our cache-read share trending down?") become a saved chart with an alert on it. For API applications you build yourself, the native SDK route adds per-request traces so a single expensive request can be opened and read like a transcript line.

promptfoo: benchmark the prompt itself

What it is. An evaluation harness (github.com/promptfoo/promptfoo) that runs prompt variants against test cases and scores them side by side, with per-case token and cost tracking. It is how "the terse system prompt is just as good and 40 percent cheaper" stops being a feeling: the claim behind every trim in Chapter 3 and Chapter 4 becomes a table.

How it works inside. A YAML config declares prompts, providers, and test cases with assertions (contains, regex, LLM-graded rubrics). The runner executes the full matrix, collects outputs, latency, and usage, and renders a pass/fail grid in the terminal or a local web view.

End to end (follow-along): benchmark a verbose system prompt against the trimmed one before committing the trim.

npx promptfoo@latest init

# promptfooconfig.yaml
prompts:
  - file://prompts/system-verbose.txt    # 1,900 tokens of accumulated rules
  - file://prompts/system-terse.txt      # the 500-token rewrite
providers:
  - anthropic:messages:claude-opus-4-8
tests:
  - vars: { question: "Summarize this incident report: ..." }
    assert:
      - type: llm-rubric
        value: mentions root cause, impact, and the fix
  # ...more cases covering the behaviors the verbose prompt claims to protect

npx promptfoo@latest eval

┌──────────────────────────┬────────────┬────────────┐
│                          │ verbose    │ terse      │   (illustrative)
│ pass rate (24 cases)     │ 23/24      │ 23/24      │
│ avg total tokens / case  │ 2,410      │ 987        │
└──────────────────────────┴────────────┴────────────┘

Same pass rate, 59 percent fewer tokens per call: ship the terse prompt, and keep the eval in CI so the next person who "just adds one rule" has to keep the pass rate. This is also the tool for the cache-shape work in Chapter 24: a prompt restructured for caching should go through the same grid to prove the restructure changed the bytes and not the behavior.

LiteLLM: the metering gateway

What it is. An open-source LLM gateway (github.com/BerriAI/litellm): one OpenAI-compatible proxy in front of every provider, with per-key budgets, rate limits, spend tracking, and optional response caching. Where ccusage measures one machine after the fact, LiteLLM meters an organization in-line, before the spend happens.

How it works inside. The proxy translates requests to each provider's API, logs every call's usage to a database, enforces budgets per virtual key or team, and can serve repeat requests from a cache (its semantic mode is Chapter 7 as configuration).

End to end (follow-along): give a team metered keys for Claude.

# config.yaml
model_list:
  - model_name: claude-opus-4-8
    litellm_params:
      model: anthropic/claude-opus-4-8
      api_key: os.environ/ANTHROPIC_API_KEY
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

pip install 'litellm[proxy]'
litellm --config config.yaml            # serves on :4000

# mint a budgeted key for one service
curl -s http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -d '{"max_budget": 50, "budget_duration": "30d", "metadata": {"team": "docs-bot"}}'

Applications point their Anthropic base URL at the proxy with their minted key, and from that moment every request is attributed, budgeted, and visible at /spend endpoints; a key that hits its $50 cap starts returning errors instead of surprises at month end. The trade: the proxy is now infrastructure you run, on the request path. Adopt it when the problem is organizational (many apps, many keys, one bill), not to meter a single developer's terminal, which the transcript ledger already does for free.

Choosing from the tour

Question you actually have	Reach for
What did my Claude Code work cost this week?	ccusage (or your own ledger script)
Get this whole repo into one window / another model	Repomix, `--compress` for the 39% cut
This retrieved document is blowing the budget	LLMLingua, then re-count and A/B
The agent forgets facts across sessions and projects	Mem0 over MCP (after `CLAUDE.md` and auto memory)
The team needs dashboards and alerts on token spend	Langfuse fed by Claude Code's OTel
Is the cheaper prompt actually as good?	promptfoo in CI
Many apps and people share one API bill	LiteLLM with budgeted keys

Takeaways

Every tool in the tour is a chapter of this book, productized: ccusage is the transcript ledger, Repomix is code-aware packing, LLMLingua is prompt compression, Mem0 is agent memory, Langfuse is the telemetry layer, promptfoo is measured output shaping, LiteLLM is metering and semantic caching at the gateway.
The two measured on this machine: ccusage priced five days of real work at $283.59 from the local transcripts alone, and Repomix packed 18 lab files at 37,906 tokens, dropping to 23,093 (39 percent) with tree-sitter compression.
The adoption loop never changes: baseline with the instruments you already have, apply one tool, re-measure, keep it only if the realized number moved.
Placement matters as much as choice: in-session tools (Mem0, Repomix output) spend window tokens; beside-session tools (ccusage, promptfoo) are free at run time; in-front-of-API tools (LiteLLM, Langfuse) are infrastructure with organizational payoff.
Prefer the built-in before the tool: CLAUDE.md before a memory server, the transcript ledger before a spend platform, a /context glance before a dashboard.

👉 The tour showed each tool working; it did not yet make any of them prove it on your own workload. The next chapter is the bench: a repeatable A/B protocol inside Claude Code, run for real against the tools installed on this machine (RTK, Headroom, the packers, the output shapers), with the loss inspections the headline ratios leave out.

Context Engineering in Depth