AI InfrastructureCase study

LLM Flightdeck — Mission Control for LLM Operations

Delivered scope

Four KPI pages; every figure recomputed from real run artifacts of three upstream repos

Conceptual artwork. Not a photograph or screenshot of the client's system.
Client
Open-source project
Category
AI Infrastructure
Location
Indonesia
Completed
August 16, 2026

⚠ This is an open-source project, not client work. Every number quoted below comes from offline runs on the three upstream repos’ deterministic mock providers — not measurements of any production system — and the project README publishes the command that reproduces each one.

The problem

Once a business starts running LLMs, four operational questions arrive at once: how much are we spending, did the last prompt change break anything, which provider is unhealthy right now, and how resistant is this system to prompt injection. The answers are scattered across different tools, or do not exist yet. Flightdeck is a mission-control layer over three of our other engineering repos — llm-eval-harness, llm-cost-gateway, and prompt-injection-bench: it ingests their real run artifacts and renders one dashboard for all four questions.

What was built

Four pages over artifacts validated by Zod schemas:

  • Overview — cross-tool KPIs: spend, worst budget headroom, latest eval pass rate, regression count, ASR, and currently open circuits.
  • Cost — spend and token burn-down per workload phase, cache hit rate, per-tenant budget meters, and the routing policy panel.
  • Evals — run history and a case-level diff: which cases flipped pass → fail, which scorers carried the drop, and which case improved.
  • Security — ASR per defense preset (127-attack corpus × 9 presets × 5 repetitions) at three simulated target susceptibilities, with a category × preset matrix and per-repetition spread.

Engineering decisions

Two producers (the eval harness and the injection bench) serialize raw records but not their aggregates, so Flightdeck recomputes mean, pass rate, and ASR from those records. The recomputation formulas are unit-tested against the fixtures, so a formula that drifts from the producers’ definitions fails the test suite. No number on any page is hardcoded.

The dashboard deliberately reads static artifact snapshots rather than scraping anything live: no polling, no websocket, no connection to a running gateway. It is a read-only viewer over files, and the README states that limitation plainly.

The numbers behind the screens

The bundled fixtures deliberately contain stories, not clean data: a planted prompt regression (mean drops 0.917 → 0.860; three cases regress beyond the 0.02 tolerance, one improves), a demo-capped tenant driven into its 1,500-token daily cap, and mid-primary’s outage history (4 failures, 2 rejections, the circuit closed again after recovery). On the security page, at susceptibility 0.8 even the full defense stack lets 22.2% of attacks through; at 0.3 the same stack measured 0.0% — both reported as mock-run results, and every chart carries the label.

Run it yourself

Requires Node ≥ 20, no API keys, no database:

npm install
npm run demo   # open http://localhost:3000

Public repo: github.com/ridwanspace/llm-flightdeck. The three upstream repos are needed only to regenerate the fixtures, not to run the demo.

From this study to your project

Does your team face a similar problem?

Tell us about the workflow and its constraints. We start with a scope we can describe and verify.

Next case study

MCP Guarded Tools — Large Tool Surface Governance