Why Claudeye

​

Uncover what your agents did

• Projects and sessions browser - filter by date range or keyword, paginated and sorted newest-first
• Full execution trace viewer - every message, tool call, thinking block, and system event
• Nested subagent logs - expand to see subagent executions inline, pre-loaded with the session
• Virtual scrolling - handles sessions with thousands of entries without performance issues

​

Understand where they struggle

• Session stats bar - turns, tool calls, subagents, duration, and models at a glance
• Custom evals - grade sessions with pass/fail results and 0-1 scores
• Per-eval recompute - re-run a single eval without reprocessing all others
• Conditional evals - gate evals globally or per-item, with session and subagent scope control
• Cache invalidation hook - register a custom function to invalidate stale cached results based on age, score, or any custom logic

​

Utilize insights to improve

• Custom enrichments - compute metadata (token counts, quality signals, labels) as key-value pairs
• Custom actions - on-demand tasks triggered from the dashboard with full access to eval and enrichment results
• Alerts - callbacks that fire after all evals complete for a session (Slack webhooks, CI notifications, logging)
• Dashboard views and filters - organize filters into named views with boolean toggles, range sliders, and multi-select dropdowns
• Dashboard aggregates - cross-session summary tables with full control over collect and reduce logic
• Unified queue - all evals and enrichments go through a single priority queue with bounded concurrency, live tracking at /queue
• JSONL export - download raw session logs
• Auto-refresh - monitor live sessions at 5s, 10s, or 30s intervals

​

How Claudeye compares

​

How it works

1. createApp() and app.eval() / app.enrich() / app.action() / app.alert() / app.condition() / app.dashboard.* register functions in global registries
2. When you run claudeye --evals ./my-file.js, the server dynamically imports your file, populating those registries
3. All eval and enrichment execution routes through a unified priority queue - each individual eval and enrichment is a separate queue item. UI requests use HIGH priority; background scanning uses LOW priority
4. Each item runs through: cache check - execute if uncached - cache result - check if session complete - fire alerts if complete
5. The global condition is checked first. If it fails, everything is skipped
6. Per-item conditions are checked individually. Skipped items don’t block others
7. Each function is individually error-isolated. If one throws, the others still run
8. After all evals and enrichments complete for a session, registered alerts fire with the full eval and enrichment summary
9. Results are serialized and displayed in separate panels in the dashboard UI
10. Named dashboard views compute filter values incrementally - only new or changed sessions are processed - then filter and paginate server-side
11. Dashboard aggregates run a separate server action that collects per-session values and reduces them via user-defined reduce functions into sortable summary tables
12. When --queue-interval is set, a background processor scans for uncached items on a timer. Track queue state at /queue or via the navbar dropdown

​

Distribution