[ Byte 2.2.5 · The map ]
Six destinations. Every detail stays reachable.
The main navigation follows the work. Existing routes, deep links, shortcuts and saved views still resolve to their detailed screens.
| Screen | Path | Chord | What it answers |
|---|---|---|---|
| Home | / | g h | Attention, continue working, recent outcomes and the factual brief. |
| Work | /work | g b | Projects and tasks with their attempts, requirements, changes and evidence. |
| Sessions | /sessions | g s | Conversations, The Record, Live Feed and Compare. |
| Insights | /insights | g i | Cost, usage, limits, operational health and orchestration. |
| Library | /library | g y | Searchable decisions, handoffs, versioned recipes and verified lessons. |
| Settings | /settings | g , | Appearance, integrations, configuration and notifications. |
Organisation management remains role-gated. Session, Task, Compare, Run, Agent Config and the retained analytics routes keep their existing URLs.
Fig. 11 · The six primary destinations and their shortcuts.
- Measured
- the routing table the product ships.
- Claude Code, Codex, OpenCode and Superset
- Attention inbox with acknowledge and snooze
- Factual daily and weekly briefs
- Searchable decisions and handoffs
- Versioned recipes with launch preview
- Project and organisation budgets with coverage
- Revision-bound check evidence and persistent review
- Investigation continuity and reusable verified lessons
[ Byte 2.2 · Preserve progress ]
One task. Every attempt, decision and check.
Start with observable outcomes. Each one is Verified, Failed, Needs judgment or Not checked. A passing result names its command, code revision and environment; relevant changes make it stale.
| When work changes | What stays useful |
|---|---|
| An attempt gets part of it right | Prepare selected Git text changes separately, check their dependencies and review the candidate before applying it. |
| You come back to an investigation | Restore the question, observations, rejected approaches and next experiment, with links to their sources. |
| The requirements move | Review the impact on outcomes and checks. Each active attempt shows the requirement revision it has acknowledged. |
| A fix should stay fixed | Keep its failure conditions, correction and regression check. Verification requires the original failure and a passing correction. |
| Two tasks work alone but fail together | On Max, rehearse their combined changes in a temporary workspace and inspect demonstrated failures. |
| Work repeatedly stalls | Use a separate recovery candidate. Project automation starts off and requires explicit bounds and supported native controls. |
Your own agents and accounts do model work. Hosted Byte inspects authorized evidence and directs execution to the connected local installation. Manual review and check capture are available on Operator; Max adds rehearsal and bounded automation. Read the workflow and its limits.
[ 12 · The session mark ]
One session, one line.
Learn this drawing first. It turns up inside every other screen, at three sizes: a table row, a card, and full width.
Both scales are logarithmic over fixed absolute domains. The same session draws at the same size whatever you filter to.
The mark never claims more at a large size than it can support at a small one. The envelope is stepped and never smoothed, because a curve between two buckets would draw agent counts that never existed.
The session mark taken apart: seven channels lettered A to G, and the spine's own tone lettered H beside them, which is a property of the line the seven are drawn on rather than an eighth channel. The specimen is the record's mean session: 4h 49m long, 12.3M tokens through it, 6 agents in it and up to 6 alive at once. A, length: how long the session ran, wall clock, start to last event. It reads 4h 49m, log, fixed 1s to 30d. B, thickness: the tokens that went through it, cache reads included. Thicker is more. It reads 12.3M, log, fixed 1.0K to 100.0B. C, strands: one strand under the spine per agent alive at that moment past the first. It reads 5 strands, up to 6 at once, 12 drawn at most. D, depth: a riser off the left end, one step for each level the nesting reached. It reads 2 on this specimen, 6 drawn at most. E, notch: a tick out of the top edge. The transcript was compacted and the run went on. It reads 1 on this spine. F, bar: a bar through everything the mark draws, because an interruption stopped everything. It reads 1 on this spine. G, pale span: a dashed run over the spine. The session did not stop, it was waiting on a person. It reads specimen, the mean carries none. H, tone: the spine's own colour is the session's status. It is not an eighth channel: it is a property of the line the other seven are drawn on, and this session completed. It reads 4 statuses, 3 tones. The record's mean session carries no waiting interval, because nothing in the record states one, so G is drawn here as a specimen of the channel and not as a reading. Both scales are logarithmic over fixed absolute domains, so the same session draws at the same size whatever you have filtered to. Active and completed share one tone, because both are just this ran. Abandoned takes the idle grey. Error deliberately shares the interruption's colour rather than inventing a hue for a state with no instances: no session in the record has ever failed. Length is drawn at the scale the product draws it. Every cross section is drawn at three times, because at 2 to 14 pixels a spine cannot be read and a 4 pixel notch cannot be seen.
Fig. 12 · The mark taken apart. Seven channels, and the spine's own tone.
- Measured
- the scales and the drawing limits the product ships.
- Staged
- the session drawn through them.
[ 13 · The time spine ]
Most minutes hold nothing. The axis knows.
A ribbon under the status bar on every screen. Drag it and the whole app moves with it.
Arrow keys pan, up and down zoom, Home shows everything, End goes live. On Settings, Agent Config and Run it goes inert, but stays mounted so nothing jumps.
Two axes stacked, carrying the same events. The upper one is linear, and most of its travel is empty. The lower one is warped: stretches with no events in them are collapsed to a dashed rule and lettered with how much time each one stands for, so the stretches that hold events get the room. Nothing on the warped axis is ever stretched, only capped, which means a dataset with no long gaps draws as an ordinary linear axis.
Fig. 13 · A linear axis, and the same events on a warped one.
- Measured
- the warp rule: collapse empty stretches, cap them, stretch nothing.
- Staged
- the events placed along both axes.
[ 14 · Agent board ]
The useful column is the yellow one.
Active means the machine has it, waiting means you do. This night it stayed nearly empty, which is the good outcome.
Two board views behind a toggle that remembers your choice. The agents view has four columns: active, waiting, completed and error. The sessions view has five, adding abandoned. Each column scrolls on its own and pages ten at a time, and live refresh is coalesced at 300 milliseconds. Across the whole record there were 194 agents, 193 of which completed, one still running at the close, and no failures at all, so the error column is drawn empty. A card carries its agent, its session, its elapsed time and its session's tokens and cost.
Fig. 14 · Four columns for agents, five for sessions.
- Measured
- 194 agents across the record, 193 completed, no failures.
- Staged
- which cards sit in which column at this moment in the replay.
[ 15 · Sessions ]
Read a page of sessions as a page of drawings.
Server paginated, free text search, a directory filter, and the mark in a column called Shape.
Open one and it has four tabs: Agents, Conversation, Timeline and Replay. A banner appears when the session is waiting on you in the terminal.
A table of sessions. Eight columns: Session, Shape, Status, Last active, Duration, Agents, Cost and Directory. Shape is the session mark at its inline size, so a page of sessions reads as a page of drawings. Sorting is by recent, longest or costliest, and the sort is a saved view. The record holds 34 sessions whose mean span is 4 hours 49 minutes and whose total cost is $366.65. The per-session rows in this drawing are staged; the totals are not.
Fig. 15 · Eight columns, one of them a drawing.
- Measured
- 34 sessions in the record, mean span 4h 49m, total cost $366.65.
- Staged
- the individual rows: their names, directories and per-session figures.
[ 16 · Record and compare ]
One screen answers what you built, not what is happening.
The ask is the headline, in your own words.
Compare reads two sessions as a difference, not as two sets of totals. The selection lives in the query string, so any comparison is a link.
Compare, drawn as a comparison. Four rows: duration, agents, tokens and cost. The baseline is the mean session of the record, 4h 49m of duration, 5.7 of agents, 12.3M of tokens, $10.78 of cost, each of them the night's own total over its 34 sessions. Two sessions are plotted against it on one shared axis, which is the ratio to the baseline on a logarithmic scale from 0.001x to 100x, and the segment from the baseline to each point is the change. Session B is tools/migrate: duration 9h 21m, +4h 32m, 1.94x the baseline; agents 140, +134.3, 24.5x the baseline; tokens 226.2M, +214.0M, 18.4x the baseline; cost $194.76, +$183.98, 18.1x the baseline. Session C is server/events: duration 1m 45s, -4h 47m, 0.00605x the baseline; agents 1, -4.7, 0.175x the baseline; tokens 41.1K, -12.2M, 0.00335x the baseline; cost $0.05, -$10.73, 0.00464x the baseline. The baseline column carries raw totals and every other column carries a value, a difference and a ratio, which is the contract the screen keeps. The two sessions plotted here are the record's own widest and briefest, and per session figures on this site are staged. What they are measured against is not: every baseline is the night's published total over its 34 sessions.
Fig. 16 · Compare. Only the baseline shows totals.
- Measured
- the column contract: baseline raw, every other column value, delta and ratio.
- Staged
- the two sessions being compared.
[ 17 · Orchestration ]
Ten charts of what your agents did to each other.
One status filter drives all ten. The whole set exports as JSON, and every chart says what it shows and how to read it.
| Chart | What it draws |
|---|---|
| Orchestration DAG | Which agent spawned which, as a four column directed graph. Edge width scales with how many times that spawn happened. |
| Tool execution flow | A Sankey diagram of tool to tool transitions. A tool on both sides is split into a source node and a target node, because a Sankey collapses self-loops. |
| Agent collaboration network | A force directed graph of agent types that run in sequence. Node radius is the square root of that type's total runs. |
| Model delegation flow | Which model handed work to which, grouped by family. Edges are uniform width on purpose. |
| Concurrency timeline | A lane per agent type, showing where in a session each one runs. Fill opacity carries sample size. |
| Session complexity scatter | Duration against agent count, both axes logarithmic, bubble area proportional to tokens, colour by outcome. |
| Subagent effectiveness | A card per subagent type: a success ring, sessions, average duration, and a weekday sparkline. |
| Error propagation map | Where errors cluster by depth. Nothing errored gives you a green all-clear, not an empty chart. |
| Compaction impact | A histogram of how many sessions compacted exactly k times. |
| Workflow patterns | Agent sequences that repeat, ranked by how often, each with a rule-derived description. |
The ten Orchestration charts, drawn as small multiples. Nine of them had only ever been named on this page; the tenth, the delegation DAG, is the one the homepage carries and it is the last cell here rather than the subject. Tool execution flow. Tool to tool transitions, with any tool on both sides split into a source and a target, because a Sankey collapses a self loop. The record holds no transitions. Agent collaboration network. Agent types that run in sequence. Radius is the square root of that type's runs, and those are the record's own: 147, 34, 10, 2, 1. Which type follows which is not on the record, so the links are the form. Model delegation flow. Which model handed work to which, grouped by family, with edges drawn uniform on purpose. The record holds no model names. Concurrency timeline. A lane per agent type, showing where in a session each one runs. Fill carries sample size. Session complexity scatter. Duration against agent count, both axes logarithmic, bubble area the tokens and colour the outcome. Per session figures on this site are staged. Subagent effectiveness. A card per subagent type: a success ring, sessions, mean duration and a weekday sparkline. The rings are closed because agent success on this record was 100%. Error propagation map. Where errors cluster by depth. This record holds 0 at every one of its 11 depths, which the product draws as an all clear rather than as an empty panel. Compaction impact. How many sessions compacted exactly k times. The record publishes no compaction count, so the histogram is the form. Workflow patterns. Agent sequences that repeat, ranked by how often, each with a rule derived description. The record publishes no ranking of flows. Orchestration DAG. Who spawned whom, in four columns, edge width the number of spawns: 34 origin, 34 main, 103 spawned by a main agent and 57 by a subagent. The chart the homepage already carries, at a tenth of the room. 2 of the 10 are readings and the rest are the form each chart takes, which is what the word under every name says. The record behind the set: 34 sessions, 194 agents, 160 subagents of which 103 were spawned by a main agent and 57 by a subagent, a deepest chain of 11, a widest fanout of 85, and 100% agent success with 0 errors.
Fig. 17 · Ten charts, drawn small. Two are readings and eight are the shape each one takes.
- Measured
- 34 origin, 34 main, 103 spawned by a main agent, 57 spawned by a subagent. Widest fanout 85.
Beside them, a runs panel for the Workflow tool's fleets, which fire no hooks and are rebuilt from disk. Below, a per-session drill-in: agent tree, tool timeline, event sequence.
Six headline readouts from the Orchestration screen. The record holds 4 of them and 2 it does not. Agent depth 11, deepest chain, main agent counted as depth 1. Subagents per session 4.7, mean, 160 over 34. Agent success rate 100%, no agent failed. 193 completed, 1 still running. Average duration 4h 49m, mean session span. Most common flow is drawn as an empty cell, because the record publishes no ranking of flows. Average compactions is drawn as an empty cell, because the record publishes no compaction count. The two empty cells are drawn empty rather than filled with a plausible number, because every figure on this site traces to the record or it does not ship.
Fig. 18 · Six headline readouts, four the record holds.
- Measured
- deepest chain 11, 4.7 subagents a session over 34, 100% agent success with 193 completed and 1 still running, mean session span 4h 49m. The record publishes no ranking of flows and no compaction count, so those two cells are drawn empty.
- Staged
- the order the six cells arrive in.
[ 19 · Cost and usage ]
A year of work as one low resolution image.
Sized so the year fills its panel exactly, on whole pixel tracks. A grid whose edges land between device pixels reads as out of focus.
Five readouts share one rail above it, and a thirty day column chart sits beside it. While the data loads the region shows skeletons, so the page never flashes a zeroed axis.
A 53 week heatmap, one cell per day, 371 cells in all, on whole pixel tracks so the grid reads as low resolution rather than out of focus. The scale is a single ramp expressed as alpha, which reads as a rising glow on the dark theme and as deepening ink on the light one, so one definition serves both. A legend runs from less to more under the grid. The record it is drawn from holds 23,900 events; the spread of those events across a year is staged.
Fig. 19 · 53 weeks of days, one cell each.
- Measured
- 23,900 events in the record. The panel arithmetic: 371 cells on integer tracks, one alpha ramp for both themes.
- Staged
- the distribution of days across the year.
[ 20 · Limits ]
The window that decides whether you can keep going.
The rolling session window and the weekly one, read from the CLI's own usage report rather than guessed from spend.
A limits panel. The session window is a countdown in hours, minutes and seconds, and it ticks, because a sentence about rolling limit windows is a claim and a decrementing readout is the same fact demonstrated. The weekly window is shown as a label rather than a stopwatch, because days and hours is a different unit. Under both, four context chips: plan and rate-limit tier, tokens per hour, and per-model share. With no window reported yet the panel reads: no window reported yet. Under reduced motion the countdown stops ticking and keeps its value, because losing the motion must never lose the number.
Fig. 20 · Two windows and four chips.
- Measured
- the two windows the product reads, and the four context chips it shows under them.
- Staged
- the time left on the countdown.
[ 21 · Tasks ]
It cuts the worktree, runs the checks, and stops where you told it.
Several tasks run at once in separate checkouts of the same repository, so two agents never fight over one index.
Every card names its branch, how far it has drifted from base, and what it has cost. You do not open the CLI.
The task lifecycle as a state transition graph: 10 states, 12 actions between them, 3 stopping points and 5 barred routes. The 10 states are draft, queued, preparing, running, checking, ready, landing, landed, blocked, cancelled, and landed and cancelled are terminal, so nothing leaves either. The 12 actions: enqueue, from draft to queued: a draft becomes work somebody intends to do. prepare, from queued to preparing: cut the checkout. Transient: something is happening on disk right now. prepared, from preparing to queued: the checkout is ready and autonomy says stop. Rests in the queue. spawn, from queued, preparing, running, checking, ready to running: an agent is driving the worktree. From ready it is the follow-up gesture, and it is what makes running and checking a cycle. check, from running to checking: the project's checks are running. checks pass, from checking to ready: the checks came back green. checks fail, from checking to blocked: the checks came back red. land, from ready to landing: the work is being installed onto the base branch, or is out for review. landed, from landing to landed: positive evidence only. A pull request that is open has not landed. block, from queued, preparing, running, checking, ready, landing to blocked: always carries a reason, written in the same update. retry, from blocked to queued: back to the queue, the long way round. cancel, from draft, queued, preparing, running, checking, ready, landing, blocked to cancelled: from every state except the two nothing leaves. Autonomy has 3 positions, and each one is named by the last edge the machine will take on its own. Position 1, prepare the checkout and stop: it will not cross into running. The checkout is cut and the task rests back in the queue. Position 2, run the agent and stop for review: it will not cross into landing. The work waits at ready, which is the one state on this graph waiting on a person rather than on the machine. Position 3, carry a passing task through to a merge: the ceiling. It crosses both of the above and lands, and landed is terminal. 4 refusals bar the route from landing to landed and hold in every position: it will not force a push, it will not stash your uncommitted work, it will not create a branch you have not made, it will not delete a directory it did not create. The four refusals hold in every position and no setting opens them. When a land needs one of them the task does not stop where it is: it takes the block edge and waits on the board with the reason on it, naming which of the four it would have had to do. A fifth route is barred by default: merging into your default branch with nobody looking needs a separate opt-in and is off by default, because a pull request is reviewable and revertible and an unreviewed diff on the default branch is neither. Ready is the one state waiting on a person rather than on the machine, which is why it is marked. Landed and cancelled are terminal and nothing leaves them.
Fig. 21 · Ten states, twelve actions, three stops, and five routes it will not take.
- Measured
- the state machine and the guard rails the product ships.
- Staged
- the task riding the strip and the four timestamps.
[ 22 · Run and config ]
Connect every supported agent. Keep native controls explicit.
Integrations reports detection, connection, history and live-event health separately. Claude Code configuration remains inspectable down to the file it came from.
Run starts supported native work with its project, integration, model and permissions visible before launch. Switching the workspace never transfers ownership of an active run.
The Agent Config screen: eleven tabs over what Claude Code actually has on disk, filtered by scope, with every entry naming the exact file it was read from. The skill store carries 377 bundled skills and installs to four targets, and the composer writes real frontmatter. Beside it, the Run screen streams a live session with collapsible tool calls, a context meter, and cost and duration in the footer. Built-in slash commands stay in the terminal, because they mutate state that only the CLI has.
What Agent Config will let you edit. Of the 11 artifacts the tab rail names, 8 are editable and 3 are read-only. Editable, 8 of them: Skills, Subagents, Commands, Memory, Marketplaces, Hooks, Keybindings, Output styles. Text on disk. A timestamped backup is taken before every write. Read-only, 3 of them: Plugins, MCP servers, Settings. The running CLI writes these concurrently, so a screen that edited them would be racing it. Secrets in MCP server URLs and headers are redacted before they reach the screen.
Fig. 22 · 377 skills, four install targets, one backup before every write.
- Measured
- the store and the tab set the product ships. Eleven artifacts on the tab rail, eight editable and three read-only, one backup before every write.
[ 23 · Beyond the browser ]
One product across the places development happens.
Desktop, browser, VS Code, CLI, MCP and statusline use the same recorded facts and
permission boundaries.
One SQLite file in the middle, six surfaces around it. The desktop app runs on
macOS, Windows and Linux, hosts the server in a dedicated child process, and adds
a tray icon and start at login. The VS Code extension puts live health, tokens and
cost in the sidebar and the dashboard in a tab. The byte CLI gives you every
surface from a terminal with box-drawn tables and inline bar charts, and eleven of
its commands work with no server at all by reading the SQLite file directly. The
MCP server exposes thirty typed tools over stdio, HTTP with SSE, or a REPL:
sixteen read-only, thirteen that mutate and are refused unless mutations are
explicitly enabled, and one destructive tool that additionally needs its own flag
and a confirmation token. Ten Claude Code plugins read the same data model. The
statusline is a standard-library Python script that prints model, user, working
directory, git branch, a context bar, tokens and session cost, reads nothing else,
and exits zero whatever it is given.
Fig. 23 · One SQLite file, six surfaces.
[ What it costs ]
Start locally. Add organisation context when the work needs it.
Four tiers, per person per month. Existing commercial plans and upgrades remain intact.