Use case · Drift investigation
Behavior feels different. Where did it drift?
Drift is the change no code review catches — same code, different outputs. Ask your coding agent to read traces you have already exported, turn them into checks, and compare against your expected behavior. EvalGlass makes drift a delta you can read.
Inspect recent traces and tell me where behavior drifted from our expected checks.
What it checks
trace-derived cases vs. your expected behavior · tone · grounding · tool-call patterns. It uses traces you have already exported (OpenTelemetry / OpenInference / local JSON) — no SDK on the evaluation path (a live pull is a separate, experimental opt-in lane). It is a comparison you run, not continuous monitoring — and evalglass watch next lets you schedule it: one run against a baseline, a typed drift.json, then exit (built for cron or CI, not a resident daemon). It flags a regression only when the runs are comparable and the paired interval clears zero — otherwise the delta is within_noise; not_comparable or a missing baseline is reported as exactly that. The watcher adds no exit class and never promotes the baseline.
The scorecard
Verdict informational — a comparison on exported traces, not a live monitor. Illustrative example, not a measured result.
What it will not claim
EvalGlass does not watch your traffic. It reads traces you export and compares them to your checks — a deliberate run, not an always-on monitor. evalglass watch next can schedule that comparison as a one-shot on cron or CI, but it never watches live traffic — and a no-comparable-regression result never means quality is fine. No false green →
Ask your coding agent.
Evaluate my agentic app using EvalGlass.
Related