Private betaClaude Code today

Get a handle on what
all your agents are doing.

A session registry, command line tool and desktop app for anyone running lots of coding agents. Every session reports in, however it was started, so you can see what each one is working on, where it's running and which ones need you.

Join the waitlistInstall the pluginHave an invite? Install the plugin.
works with
  • Claude Code CLI
  • Claude desktop app
  • Claude cloud sessions
in flight
  • Cursor
not yet
  • Codex CLI
  • Gemini CLI
  • OpenCode
  • Copilot agent

What each harness gets

tide/api · Thursday
needs you 1active 3idle 2ended 1
Webhook delivery retriesENG-409blocked on human: retry policy, 3 attempts or 5?mbp-16 · 12m
Rate limiter for the public APIENG-412progress: token bucket store merged, middleware nextmbp-16 · 2m
Append-only audit logENG-413claimed: schema and write pathmbp-16 · 6m
CSV export for ordersENG-414progress: streaming writer, 2 of 3 formatscloud · now
Retry jitter for webhooksENG-415paused: picks up after ENG-409mini · 1h
Flaky test in the orders suiteENG-402PR open, waiting on reviewmini · 3h
Fix pagination on /ordersENG-401released done: PR 81 mergedmbp-16 · 5h
active idle waiting on you endedstatus comes from what sessions do, never typed in

An example board. Every row is a session, reported by hooks the session fires anyway.

I kept losing track of my own agents, so I built this

I'm Stef. Most of the code I've shipped this year was written by coding agents, and lots of them at once: Claude Code in a terminal and in the desktop app, sessions in the cloud, Cursor, one Claude account for client work and another for my own. Somewhere in July I realised I'd lost the thread. Which agent was doing the dropdown? Where did the feedback I gave go? Why are there 750 worktrees on this laptop?

So I built something to answer those questions for me. It doesn't run my agents (I like running them my own way), it just keeps track of what they're doing and tells me when one needs me. I've used it for all of my own work since the summer, and I think other people running lots of agents might want it too.

It's in private beta. If you're running lots of agents too, join the waitlist and tell me how you run yours.

Stef Lewandowski

How it works

Claude Code runs hooks at fixed moments in a session. The plugin adds a hook at each one that calls the fibers command line tool, which reports one small fact to the registry and exits. You don't write any of this yourself. The plugin installs nine hooks, run through a small wrapper that always exits cleanly; below are five of them, simplified.

A simplified excerpt, in Claude Code settings form
{
  "hooks": {
    "SessionStart": [{ "hooks": [{ "type": "command", "command": "fibers hook session-start" }] }],
    "Notification": [{ "hooks": [{ "type": "command", "command": "fibers hook notification" }] }],
    "PostToolUse":  [{ "hooks": [{ "type": "command", "command": "fibers hook post-tool-use" }] }],
    "Stop":         [{ "hooks": [{ "type": "command", "command": "fibers hook stop" }] }],
    "SessionEnd":   [{ "hooks": [{ "type": "command", "command": "fibers hook session-end" }] }]
  }
}

Session start

This session started, on this machine, in this worktree, on this branch.

Tool use

Still working. Sent at most once every five minutes, so a long turn doesn't look idle.

Notification or question

Waiting on a person: a permission prompt, a question, or an idle prompt. Only the kind is sent, never the text.

Stop and session end

The turn finished, or the session ended.

Subagent start and stop

A subagent started or finished, recorded under the session that started it.

There are no extra model calls and nothing is summarised. Each hook sends a fact and exits, and if the registry can't be reached the fact waits on disk, so a hook can never break a session. What you get is a row per session:

One session's row
  ENG-412 active  feat/eng-412-rate-limit   progress 2m ago
      mbp-16:~/code/tide/.worktrees/eng-412

What the rows make possible

So far, so boring. A row per session isn't much on its own. But once every session reports in the same way, from every machine, a few useful things fall out of the data.

What's running, and where?

One board across every machine

Install the plugin and every Claude Code session shows up on its own: which machine, which worktree, which branch, and when it last did anything. Subagents are counted under the session that started them. Nobody has to remember to do anything.

The board in a terminal
$ fibers ls
needs you (1)
  ENG-409 waiting feat/eng-409-webhooks     blocked on human 12m ago
      mbp-16:~/code/tide/.worktrees/eng-409
      "retry policy: 3 attempts or 5? need a decision"
active (3)
* ENG-412 active  feat/eng-412-rate-limit   progress 2m ago  +2 subagents (1 running)
      mbp-16:~/code/tide/.worktrees/eng-412
  ENG-413 active  feat/eng-413-audit-log    claimed 6m ago
      mbp-16:~/code/tide/.worktrees/eng-413
  ENG-414 active  feat/eng-414-export       progress just now
      cloud:/home/user/tide

* = this worktree.

The same board is in the web app, grouped the same way, across every machine you're signed in on.

Which ones need me?

Sessions waiting on you

A session moves to the top when it asks you a question, stops at a permission prompt, or says it's blocked on a person. Nothing else lights up, so the list stays short enough to act on.

An agent asking for a decision
$ fibers log blocked --blocked-on human --note "retry policy: 3 attempts or 5? need a decision"
logged blocked (on human): retry policy: 3 attempts or 5? need a decision

Questions and permission prompts are picked up from hooks, so the agent doesn't have to log those. There's no desktop notification yet.

Is another agent already on this?

Claims and clash warnings

An agent claims the ticket before it starts, so the next one can see the work is taken. Every new session is also told what's on the board when it starts, with a warning if it's sharing a worktree, branch or ticket with a live session.

Claiming a ticket
$ fibers claim ENG-412 --note "rate limiter for the public API"
claimed ENG-412 · session 20260925081142-q3vd on feat/eng-412-rate-limit
What a new session is told when it starts
Board: 1 need you (oldest 12m ago) · 3 active · 2 idle
Clash: worktree ~/code/tide/.worktrees/eng-412 · this session and "ENG-412"

Claiming is the one part that isn't automatic. It's a line in your agent instructions, and the plugin's skills show the agent how.

What happened while I was away?

Catching up

fibers catchup, or /catchup inside Claude, lists what needs you, what changed since you last looked, which PRs are waiting and what's been left lying around on this machine, each with the command to open it. The web app's Today view is the same list with a Caught up button.

First thing in the morning
$ fibers catchup --md
# Catchup · 2026-09-25 08:40 · mbp-16
_scope: the workspace bound to this directory_

## tide · Tide

### Needs you (1)
- **ENG-409** blocked on you: "retry policy: 3 attempts or 5?" · waiting 12h · `fibers desktop resume 7f2a…`

### Since you last looked · 4 strands, 23 events
- **ENG-412** released done · PR 88 open · 6 events: claimed, progress ×4, released · `fibers work show ENG-412`
- **ENG-413** still active · PR 89 open · 3 events: claimed, progress ×2 · `fibers work show ENG-413`

### PRs waiting (2)
- **#88** feat(api): token bucket rate limiter · open · checks success · 0 unresolved · fetched 5m ago
- **#89** feat(audit): append-only audit log · open · checks pending · 1 unresolved · fetched 5m ago

### Loose ends · this machine (mbp-16), strands active in the last 30 days (1)
- **~/code/tide/.worktrees/eng-401** fix/eng-401-pagination · unpushed · last active 2d ago
What can I close?

Finding finished sessions

Agents leave things behind: sessions that ended without releasing their claim, worktrees with changes, branches with commits and no PR. fibers retire ls checks each ended session and says which are finished and safe to archive, and for the rest, what's holding them back. The /clear-down skill then archives the finished ones in Claude Desktop, asking each time.

Which sessions are finished
$ fibers retire ls
retirable (1)
  Rate limiter for the public API
      feat/eng-412-rate-limit · tide/api#88 merged · 94% embedded
held (1)
  Append-only audit log
      feat/eng-413-audit-log · tide/api#89 open · 71% embedded
      prs: not merged: tide/api#89 open

Works with whatever runs your agents

Orchestrators start agents and watch their own. This sits underneath all of them and never starts or schedules anything itself, so it doesn't compete with the tools you already use. It's the one view across the lot.

By hand, by script or by orchestrator

The plugin is installed once for your user, not per repo, so any Claude Code session reports in, whether you opened it, a script launched it or an orchestrator dispatched it. Subagents are folded under the session that started them.

Across machines and the cloud

Laptop, desktop and cloud sandboxes share one board. Every row says which machine and worktree it's on. Cloud sessions can claim and log work, without live presence yet.

Alongside your tracker

Agents claim Linear or GitHub tickets by their existing refs, and it never writes to your tracker.

Claude Code today, others next

Claude Code works in the terminal, the desktop app and the cloud. Cursor is partly wired up. Codex and Gemini are designed and not built yet.

If you want more

Everything above comes from hooks alone. These are opt-in: you or your agents use them through the command line tool when they're useful.

Work graph

Agents record the work they're doing against the registry: the ticket, the step they're on, what they're blocked by. So you can see what an agent is doing, which step it's up to and what's stalled. It's built for fan-out and fan-in: one session splits a job into steps with an order, agents on your machine or in the cloud each claim one, and the first session can see when they're all done.

Decision registry

When you or an agent decides something, record it with fibers decide. Recording decisions as numbered files in git breaks with parallel agents: five agents commit at once and you get five ADR-99s. The registry hands out the numbers, so they get D-98 to D-102, and a decision that's replaced points to its replacement. A daily GitHub Action writes them back to your repo as markdown files, one per decision plus an index, and opens a pull request when anything changed.

Messages between sessions

Leave a note for whichever session holds a ticket. It's delivered the next time that session touches the registry. It doesn't wake an idle session yet.

Transcript search

Keyword and semantic search over your own Claude Code transcripts, on your machine, with an MCP server so agents can search too. It still runs from a checkout of the repo.

Pull requests

PR state, checks and review threads next to the sessions that produced them, fetched with your own GitHub login.

Principles

It records what your agents do, so what it records and what it won't do matter.

Your prompts and code stay on your machine

Prompts, transcripts, tool output and code are never sent. Transcript search runs entirely on your machine.

It sends facts, and text written into it

Structure (session, machine, worktree path, branch, event kinds and times), plus notes, messages, work items, decisions and PR titles, and each session's title, which Claude may have generated from the session. That text is secret-scanned before it's sent.

No extra model calls

Nothing is summarised or generated. Session titles are the ones Claude already gave your sessions.

It can't break a session

Hooks always exit cleanly. If the registry is unreachable, facts wait on disk and are sent later.

It never runs your agents or writes to your tracker

It records. Starting, scheduling and ticket updates stay with you and the tools you already use.

No productivity dashboards

No per-person hours, no rankings, no sentiment analysis. What it shows is organised around the work, not the person.
Private beta

Try it

The beta is private: join the waitlist for an invite. With one, installing is two commands in Claude Code, then two in a terminal, on macOS, Linux or in cloud sessions.

curl -fsSL https://fibers.dev/install.sh | sh   # in a terminal: the CLI, and the Claude Code plugin
fibers login   # in the same terminal: sign in, once per machine
fibers init --workspace <slug>   # in each repo: bind it to your workspace