Crux
GuidesObservability

Devtools

Inspect production runs, Evals, Eval runs, Baselines, Review work, and source definitions locally.

Crux Devtools is the browser UI embedded in the native crux local runtime. It reads backend-owned services and projections; React components do not run Evals or reconstruct evidence.

Start Devtools

crux dev
crux dev --tui

The server listens on port 4400 by default and opens the web UI. Application observability can connect through normal Crux config:

crux.config.ts
import { config } from "@use-crux/core";

export default config({
  devtools: {
    serverUrl: "http://localhost:4400",
  },
});

Keep remote observability tokens in environment or platform secrets. Local loopback development does not require Eval-specific config.

Runs

Runs show the canonical observability graph: model calls, context resolution, retrieval, tools, safety decisions, cost, errors, and artifacts. Run detail links source definitions when the exact deployment manifest is available and labels historical or unresolved joins honestly.

When declarative observability patterns actually change captured telemetry, Runs shows a Redacted badge at the run and affected node, detail, and artifact levels. The inspector names only the affected broad surfaces: Artifact preview, Artifact URI, Attributes, and Error message. A badge proves that a configured pattern changed the named telemetry surface; it does not prove that the record contains no other sensitive data.

Runs render each bounded media stream, image or speech, as one logical operation with a separate physical-attempt timeline. The card shows safe route, progress, byte-count, MIME, timing, cancellation, timeout, and Safety provenance only; it never renders media payloads, prompts, URLs, filenames, hashes, refs, or raw provider events. Runs links back to Catalog only when the runtime graph carries one exact media.operation DefinitionRef with role: "invoked-media-operation"; missing, conflicting, or differently scoped references stay unavailable instead of guessing.

For ordinary captured generations built from PromptText, Run Detail keeps the exact resolved user-prompt text and highlights authored/static regions versus interpolated/dynamic regions. Provenance labels are shown when the segment supplied one, alongside static, dynamic, and total token attribution. This is still the normal captured input artifact, not a second telemetry channel. Ordinary string prompts use the existing plain-text card. Missing, malformed, disabled, truncated, or redacted provenance also fails closed to plain text when captured prompt text remains available.

Evals

The Evals page lists the single default Eval export discovered from every *.eval.ts file, its source, Cases, Variants, and latest status. Discovery is separate from execution:

crux eval list
crux eval support --plan
crux eval support

The CLI remains the V1 execution surface. Devtools does not start remote Eval work.

Eval runs

Eval runs show blocking status, completeness, selected Cases and Variants, reuse reasons, latency, cost, scores, checks, and authored Gates. A reused task can link to historical production evidence; that provenance does not imply the evidence was created in the current Eval run.

Use the CLI for saved-run inspection and comparison:

crux eval show <run-id>
crux eval diff <run-a> <run-b>

Baselines

A Baseline is one complete, unfiltered Eval run arm explicitly accepted by a user. Devtools enables Set as Baseline only when the backend reports the run eligible. Core performs the authoritative compatibility and atomic-write checks.

crux eval baseline set <run-id> [--variant <name>]

The view explains source, Case, scorer, Gate, Variant, schema, and parameter compatibility per comparison rather than showing a misleading global match.

Review

Production feedback() creates durable Review work linked to its canonical run. Reviewers can inspect bounded run context, resolve, dismiss, or choose Add to Eval.

The editor prefills production input and call context, never model output as expected truth. Saving delegates to the repository writer and reports one of added, linked, conflict, or pending-sync; it never overwrites an existing Case id.

Inspect

Inspect presents source-discovered prompts, contexts, tools, routing, agents, flows, Evals, relations, safe schemas, and diagnostics from the Project Index. Runtime evidence enriches this authored view without becoming source truth. Historical manifest joins are resolved only against the exact project and manifest identity.

For canonical md sources, Catalog definition detail presents the compiler-owned Markdown classification, owner/named-fragment/anonymous-fragment identity, static/direct or dynamic/callback lifecycle, named-fragment joins, available string-to-md refactors, and hard PromptText diagnostics. Diagnostic cards retain their code, severity, location, and structured cause. These hard compiler diagnostics remain separate from lint findings.

Force a source rebuild only when needed:

crux index reindex

Observability privacy

Catalog and Runs answer different privacy questions:

  • The project-level Observability privacy card in Catalog reports whether the effective Local config has declarative pattern redaction configured. It is project policy, not a Safety guardrail, definition, or Catalog relation.
  • Runs reports whether declarative patterns actually changed captured telemetry for one operation family.

Catalog reflects the effective config loaded by Local on this machine. A differently configured deployed environment may not have the same policy. If Local could not load a config-aware result, Catalog shows Status unavailable instead of treating the policy as disabled.

Crux intentionally withholds pattern rules, matches, values, replacements, nested paths, and counts from both views. Runtime evidence reveals only that some rule matched a broad surface, never which rule or value. The policy changes observability telemetry only; reversible model-boundary pseudonymization remains separate work.

See Privacy and redaction for capture scope, ordering, and fail-closed behavior.

PromptText evidence modes

PromptText has three deliberately different inspection modes:

  • Static preview analyzes the current editor buffer without executing application code. Runtime-only values remain ⟪unknown⟫.
  • Exact preview explicitly invokes observational preview() for a selected connected application runtime. Devtools presents assembled system parts, user-prompt provenance, token totals and budget, dropped/excluded contexts, and validation issues. Opening the page does not dispatch inspection.
  • Captured Run evidence is historical observability from an ordinary generation. It exists only when input capture policy retained the messages artifact and may be truncated, redacted, or absent.

Exact preview creates neither an ordinary Run nor an observability record, so it cannot substitute for captured production evidence. Conversely, a captured Run is not recomputed against the current application runtime.

Local files and privacy

Private Eval runs and evidence live under .crux/evals/ and should remain gitignored. Source-controlled project truth consists of Eval source, hand-authored Case files (including sibling .cases.jsonl), and explicit .baseline.json pointers. Review comments, corrections, raw inputs, outputs, tokens, and credentials do not belong in Baseline files.

The local service uses SQLite WAL, busy timeouts, and bounded read models for concurrent observability and Review traffic. The browser consumes those services over the local HTTP/event API.

On this page