Overview
How might we design running meters so people can trust and act on AI output?
When this pattern fits
- Essential for AI coding agents, research tools, and any long-running automation where users benefit from ambient visibility into token spend and progress while execution is in flight.
When to skip or lighten it
- Free unlimited tiers where cost is irrelevant.
- Sub-second completions where meters never readable.
- Audiences that only need a final receipt, not live noise.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Meters that update too late to cancel.
No stop control beside the meter.
Showing cost without currency or plan context.
Hiding that tool calls are multiplying spend.
How products use it
| Product | Implementation |
|---|---|
| Cursor | Live usage cues during agent runs. |
| Claude Code | Session usage panels while working. |
| OpenAI Playground | Live token counting on generations. |
| Vercel | Usage dashboards for AI resource spend. |
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Running Meters" AI interface design pattern.
Pattern Definition:Frequently asked questions
What belongs on a running meter?
Live tokens or dollars, elapsed time, and a stop/pause control. Optional breakdown by tool calls.
How does this differ from pre-task cost estimate?
Estimate is the forecast before start. Running meters are the live actuals during execution.
Should meters survive after the run?
Collapse into a receipt on completion. Keep detail available in history.
What if the meter contradicts the estimate?
Explain drivers (retries, extra tools) and let users tighten scope next time.