My Loop overview

The command center

My Loop is the window where work is filed, run, reviewed and paid for. It is not a separate app — it is a section of the terminal desktop, and everything in it is backed by SQLite files under ~/.tde/ that the desktop, the Runtime and Web Share all read from. The My Loop product page covers what it is for; this section covers how it works.

tde

Open the desktop and My Loop is the default surface. The left rail carries the sections you use daily; the rest are reached from the Control Center or the command palette.

The left rail

The rail shows eight entries, grouped under a Workspace header, with an AI Chat button pinned to the bottom. Each conversation streams on its own — you can send in chat B while chat A is still thinking; Stop affects only the open chat; closing the window leaves runs alive until you stop them or quit TDE. Personas, attachments and Pass behavior are covered under Agents and personas.

Alt+1 … Alt+8 jump straight to those eight in that order. Ctrl+↑ and Ctrl+↓ cycle them. With the rail focused, ↑/↓ change section, Enter, → or Space dives into the content, and Tab or Esc steps back out.

Below 72 columns the rail collapses to icons only; below 50 it becomes a ☰ drawer in an app bar.

Clicking Control in the rail opens the standalone Control Center window rather than an embedded panel.

Tasks

The board is the center of gravity. Columns are the stages of the selected pipeline. Project and Pipeline remain independent selects; assignee, tag and search compose with the fixed All | Attention | Review | Failed control. Its counts apply every other filter and ignore only the selected operational condition.

Each card combines the tracker id and title with the current operational condition, agent/run state, stage, changes, tests and pending decision. These signals come from one read model over the Task, latest Run, Agent Control, Changes, Tests, human decisions and Runtime evidence — never from terminal parsing, a timeout or the name of a pipeline stage. A newer human decision resolves older review evidence, and a failed latest Run remains visible even when no Agent is attached.

Task Mission Control

Opening a card always starts at a responsive grid with eight signals: Task, Current Run, Changes, Tests, Runtime, Deliverables, Dependencies and Activity. Empty signals stay compact and explicit; cards contain no hidden action toolbar.

Activate a signal to open its complete section. On a wide terminal, the right rail combines direct Sections navigation with Linear-style Properties whose selects open next to the field. On a narrow terminal, the rail becomes a bounded index above the content. Activity entries are individually focusable and open their own structured detail.

Esc returns from a section to the same grid card, then to the same Board position. Mouse and arrows + Enter/Space expose the same controls. Review, attention and failure actions are typed, idempotent and append an immutable human-operation event.

The saved view contains only effective filters. It pulls once when My Loop opens, publishes once when it closes, and never changes an open window because another device moved. Search and filter text pass Secret Guard and absolute path rejection before local persistence or Sync.

Read Projects and tasks for the card model and Pipeline and stages for how a card moves.

Sprints

A sprint is a dated window — Weekly (7-day blocks inside a month), Biweekly (days 1–15, then 16 to month end) or Monthly — named like Sprint Jun 1 - 2026. It carries a status (Active or Closed), a markdown summary and a set of tasks.

The screen is a month calendar: days inside an active sprint use the accent fill, days inside a closed sprint use the selection swatch, today is prefixed with *. Below it sits one card per sprint in that month; opening one shows the date range, the task count, the summary and a grid of task cards.

Rollover is an Bot, not a timer in the UI. Once a sprint's end date has passed, the Sprint rollover bot has an agent write the markdown summary, closes the stale window and opens the next one. Without an agent it falls back to a generated summary listing tasks, completed, in progress, blocked and highlights.

Reports

One report exists: a monthly view of the currently filtered board. It carries five tiles — ACTIVE, CREATED, COMPLETED, AGENTIC AVG, LOOP AVG — then a per-developer table (DEVELOPER / ACTIVE / DONE), generated Insights lines and the top tags.

←/→ change month (you cannot page into the future), t cycles the tag filter, P cycles the project filter and f clears both.

Usage & Costs

Every run — from the board, from AI Chat, from a bot — writes one row to the ledger at ~/.tde/usage.db with the project, task, stage, agent, persona, provider, model, session and four token counters (input, output, cache-read, cache-write).

Cost is stored twice. reported is what the CLI itself said it billed; estimated is the API list-price equivalent for the measured tokens, computed from the pricing table. The billable figure is the larger of the two, tracked in millionths of a dollar so sub-cent turns aggregate before rounding.

Sessions run outside TDE are folded in too: the ledger ingests each CLI's own on-disk session logs — ~/.claude/projects, ~/.codex/sessions and OpenCode's database — skipping anything whose working directory sits under ~/.tde/worktrees or ~/.tde/repos, because the scheduler already recorded those.

The screen offers 24h, 7d, 30d and All ranges, three tiles (TOTAL SPEND, RUNS, TOKENS), a correlated-session list, a token breakdown, a daily heatmap and share-of-spend bars for Projects, Models, Agents, Stages and Daily. Aggregates are computed in SQLite instead of loading the whole ledger into the UI. Use CSV to export the active range and filters. It refreshes on entry and every five minutes while you stay there.

Quotas & Limits

This section reads the agent CLIs' own quota state rather than inferring it from TDE's ledger. Claude windows come from the same OAuth usage endpoint the CLI's /usage panel uses (5h, 7d (weekly), 7d (<model>), plus extra usage and an informational plan row); Codex windows come from its persisted rate_limits.primary/secondary and its live endpoint, including 7d (code review) and a credits note.

Each row draws a meter and a percentage — danger at 90%, warning at 70% — plus a pace glyph (↑ ahead, → on track, ↓ under) and the reset time. Below, a Sessions — context window list shows recent CLI sessions and how full their context windows are.

Quotas are not cosmetic. Crossing 80% latches an alert into Activities, raises a toast and mirrors to Telegram when configured, and the worst percentage per CLI is pushed into the scheduler — which throttles earlier when the burn rate runs well ahead of the window clock. A task whose agent is rate-limited is parked rather than run.

Everything else

• Projects — repos, worktrees, integrations.
• Bot — cron and webhook automations.
• Agents — personas over your installed CLIs.
• LLM — connect Claude Code, OpenAI Codex, Cursor and OpenCode, plus a local Ollama runtime. See Agents and personas.
• Skills — playbooks synced to all four CLIs.
• Processes — a live process table (PID, CPU%, MEM, S, NAME) with Enter to send SIGTERM and n to renice by +5.
• Control — the Control Center.