One SQLite file. Inspectable from anywhere.

Status vocabulary

• queued— Just created; the scheduler hasn't picked a window yet (rare race window — usually fills within 1s).
• scheduled— Window picked. Will dispatch at the chosen UTC hour inside the deadline. Sits here until the tick daemon fires.
• running— The provider call is in-flight. For Batch-API tasks this can be hours; for sync tasks it's seconds.
• completed— Provider returned. A carbon receipt is written: actual intensity, tokens in/out, dispatched_at timestamp.
• failed— Provider returned an error. The reason is persisted; `ebb retry <id>` re-dispatches.
• cancelled— Manually cancelled. Idempotent — already-completed tasks return their existing status if you cancel them.

Inspect from the CLI

# All tasks (any status)
ebb queue list

# Filter
ebb queue list --status scheduled
ebb queue list --region US-CAL-CISO --since 2026-05-01

# One task in detail (prompt, region, schedule, receipt if completed)
ebb queue show <task_id>

# JSON for piping
ebb queue list --json | jq '.[] | select(.status == "failed")'

# Receipts only (completed tasks)
ebb receipts list
ebb receipts show <task_id>

From the agent (any MCP host)

The same queue is reachable through the MCP check_queue_status tool. Your agent can answer "what's queued?" or "did that task run?" inline:

> /ebb-ai:check
Total tasks: 3
  scheduled: 1 · completed: 2

> /ebb-ai:check 7f3a2b9e
status     completed
region     US-CAL-CISO
scheduled  22:15 UTC (4h ago)
completed  22:15:08 UTC
estimated  0.34 g CO2e
actual     0.31 g CO2e   (-9 %)
result     <the LLM response>

Why not show a live queue here?

The site is read-only and doesn't have a back-channel to your machine. Surfacing a "live" queue on a public dashboard means either centralizing the queue server-side (privacy-bad) or fabricating a demo (honesty-bad). A later release will add an opt-in HTTP control plane the dashboard can talk to; until then the queue is local-first by design.