The full-trace workflow engine for AI agents
The graph decides. The model writes. The trace remembers.
Fulltrace runs AI agents inside task graphs whose shape is fixed in code. A model writes the content of each step. Code decides what runs next, what passes, and what may be applied. One authority object grants a change, one append-only ledger records it, and every node, stage and tool call lands in a trace you can open afterwards and replay.
The demo
Fulltrace Studio, toured live.
Five guided tours of the Studio dashboard, playing right here. Hover to hold a step, click or tap to step through, or drive it with the dots.
Demos
01 sidebar02 tabs03 workflows04 runs05 findings
The Fulltrace sidebar, toured in five steps. One, STATUS: gateway health, uptime, memory and process controls. Two, Open Dashboard opens the workspace and fills the main area with the workflow catalogue. Three, USAGE: Claude, Codex and OpenRouter budget windows with reset timers. Four, TOOL USE: session and all-time counters and a per-model token breakdown. Five, MCP SERVER: Context, Commands, Memory and Hooks as live resource trees.
1 · Runtime health
The status rail: online state and uptime, memory, restarts and uptime percentage, with start, restart and stop. Open Dashboard opens the workspace.
2 · Open the workspace
Open Dashboard launches the full panel: Studio and its five views, live and ready to drive. The main area fills in with the workflow catalogue.
3 · Budget windows
Live usage against every limit at once: Claude's 5h and 7d windows, Codex's 30d window, and the OpenRouter credit balance, each with its reset time. A run is never launched into an exhausted quota.
4 · Session telemetry
Session and all-time counters (requests, context reads, commands, tokens), plus a per-model token breakdown, so spend is attributable model by model.
5 · MCP surface
The extension's own MCP server, exposing Context, Commands, Memory and Hooks as live resource trees the assistants read from and write to.
FULLTRACE DASHBOARD ···
SUBSCRIPTION
CLAUDE USAGE
5h 42%
7d 83%
5h resets in 20m 7d resets in 23h 50m
CODEX USAGE
30d 99%
resets in 24d 7h
API
OPENROUTER CREDITS
used 50%
$17.39 left $35.00
SESSION
ALL-TIME
Uptime
5h 21m
6d 5h
Requests
165
1,689
Context reads
0
14
Commands
39
185
Tokens
16K
7.9M
TOKENS BY MODEL
kimi
0
7.1M
deepseek
0
798.7K
haiku
9.5K
34.9K
sonnet
5.9K
33K
opus
594
16.1K
fable
0
2.9K
unattributed
0
10.6K
1 Runtime health. Online state, uptime, memory and restarts, with start, restart and stop controls.2 Open the workspace. Open Dashboard opens the full panel and fills the main area with the workflow catalogue.3 Budget windows. Live usage against Claude's 5h and 7d windows, Codex's 30d window, and OpenRouter credits, each with its reset timer.4 Session telemetry. Session and all-time counters, plus a per-model token breakdown for attributable spend.5 MCP surface. The extension's own MCP server: Context, Commands, Memory and Hooks as live resource trees.
The seven top-level tabs, toured. One, Studio: the run hub and its five views. Two, Config: setup, MCP, commands, settings and hooks. Three, Analytics: per-model usage and cost across Claude, Codex, Cursor and OpenRouter, with a Compare view. Four, Context: the portfolio files and their read counts. Five, Memory: shared memory entries with create and remove. Six, Logs: every stream in one place with sync checks. Seven, Development: dev slices, the live roadmap and build log, the UI/UX register and the decision inbox.
1
2
3
4
5
6
7
1 · Studio
Where workflows actually run. Pick one, see the cost up front, launch it, and follow it live through to the results.
2 · Config
Where the system gets set up and kept in shape. Installation, connections, shared commands, settings and hooks for all three AI clients, in one place.
3 · Analytics
What the AI clients are costing. Usage and spend over time, broken down by client and by model, with a side-by-side comparison.
4 · Context
The shared knowledge files the assistants draw on. Shows what is there and how often each file actually gets read.
5 · Memory
Everything the assistants remember between sessions, in one searchable place. Add new memories here, or clear out old ones.
6 · Logs
A single live view of what the whole system is doing. Every part writes here, so this is the first stop when something misbehaves.
7 · Development
How Fulltrace itself gets built. Plans, progress, open issues and the decisions still waiting on me, all tracked in one place.
1 Studio. The run hub: Workflows, Runs, Audits, Models and Agents, priced and launched from one screen.2 Config. Setup wizard, MCP servers with live probes, shared commands, settings and hooks.3 Analytics. Per-model usage and cost across Claude, Codex, Cursor and OpenRouter, with a Compare view.4 Context. The ten portfolio files, with read counts and last-read times.5 Memory. Claude and Codex memory in one list, with create and guarded remove.6 Logs. Every log stream in one place, plus per-client file sync checks.7 Development. Dev slices, the roadmap and build log, the UI/UX register, and the decision inbox.
Running a workflow, toured in ten steps. One, Studio's five views. Two, the workflow catalogue: each workflow's status, capabilities and average cost per run. Three, clicking a workflow opens its detail, which the tour then zooms through: four, the workflow's shape; five, its capabilities and configure toggles; six, the enrolled targets and parallelism; seven, the model chosen per stage for this run; eight, the cost estimated before it runs, against the real average; nine, spend, requests and tokens split by model; ten, the per-stage breakdown of what actually happened.
1
2
3
4 5 6 7 8 9 10
1 · Studio's five views
Studio is the run hub. Its five views (Workflows, Runs, Audits, Models, Agents) organise everything around the life of one run.
2 · Workflow catalogue
Every workflow, code-defined and read-only. Status marks Executable against Planned, Capabilities flags verify, challenge and gated apply, and the ones with runs behind them carry their real average cost per run.
3 · Open a workflow
Clicking a workflow opens its detail: the shape it runs, what it will cost, and what past runs actually did. Nothing launches until Run workflow is pressed.
4 · The shape
Every executable declares its graph: fan out across the enrolled targets, an optional deterministic verify gate, an advisory challenge pass, then gather to consolidate.
5 · Capabilities and options
What the workflow can do, and what this run will do. The capability line flags verify, challenge and gated apply; the Configure toggles switch the optional stages on or off for this run only.
6 · Targets and parallelism
Which projects this run fans out across, each target a tick. Parallelism sets how many run at once, and Auto lets the runtime decide.
7 · A model per stage
Each stage carries its own default (planning on DeepSeek, execution on Kimi), and any stage can be overridden for this run alone without touching the workflow's default.
8 · Priced before it runs
The estimate is computed from past runs (about $0.107 a target, times three) and recomputes as the model or target list changes, with the real average beside it as an honesty check: $0.269 a run over thirteen runs, 97% of them passing.
9 · Where the money goes
Spend, requests and tokens, each split by model. Kimi took 90.6% of the spend on 40.2% of the requests; DeepSeek did 57.3% of the requests for 2.5% of the cost. The expensive model runs the expensive stage.
10 · What actually happened
Per-stage truth: the model that ran it, how often it ran, how much passed, the tokens burned and the cost. A stage that was overridden for one run gets its own row, so the exception shows. 117 stage runs, 97% passed, $3.50 all up.
1 Studio's five views. Workflows, Runs, Audits, Models and Agents, organised around the life of one run.2 Workflow catalogue. Executable against Planned, capability flags, and a real average cost per run before launch.3 Open a workflow. Clicking a row opens its detail: the shape it runs, what it costs, and what past runs did.4 The shape. Fan out across the enrolled targets, an optional deterministic verify gate, an advisory challenge, then gather.5 Capabilities and options. What the workflow can do, and the Configure toggles for this run only.6 Targets and parallelism. Which projects the run fans out across, and how many run at once.7 A model per stage. Per-stage defaults, each overridable for a single run without touching the workflow default.8 Priced before it runs. An estimate from past runs, with the real average and pass rate beside it as an honesty check.9 Where the money goes. Spend, requests and tokens split by model: 90.6% of the spend on 40.2% of the requests.10 What actually happened. Per-stage model, runs, passes, tokens and cost, overrides included.
Inside a finished run, toured in fourteen steps. One, the Runs view: in-progress, completed and queued runs in one read-only list. Two, model reliability measured from ninety-one finished jobs, three of them killed at the ten-minute limit. Three, hovering one bucket of that histogram for what completed and what was aborted inside it. Four, the fourteen failures behind the number, each naming its node, model and the limit it hit. Five, forty-five completed runs with the cost, tokens and models joined onto each. Six, opening one run. Seven, the run header: workflow, outcome, start, duration, tokens and node tally. Eight, total cost against the workflow average, split by model into spend, requests and tokens. Nine, the run trace, and the one branch that set how long the run took. Ten, the graph it actually ran: three targets audited, verified, challenged, then gathered. Eleven, opening one fan-out node. Twelve, its five stages, each with the model that ran it and whether review approved or rejected it. Thirteen, inside one stage, down to the individual tool calls. Fourteen, the findings report: a passed verdict and seven findings written to disk.
1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 · Every run in one place
Runs still going from the run registry, finished ones from durable history, and whatever is queued locally, in a single list. Filter by workflow, outcome or window. Nothing on this screen can start or stop anything: it is a record, not a console.
2 · The limit, and what it is killing
Reliability is measured, not assumed. Ninety-one finished jobs plotted by how long they took: nineteen in twenty inside 3m 51s, the slowest 6m 59s. Three were killed at the 10m limit, and a killed job is thrown away and has to be run again.
3 · Hover any bucket
Every bar opens up. Two calls finished between 2m and 2m 24s, both of them planning, the slowest at 2m 22s. Eleven more were aborted in that same band, which is where a timeout is biting rather than where the work is slow.
4 · The failures behind the number
Fourteen failed, four recovered, and the list names each one: when it ran, which node, which model, and the limit it hit. The count is a way into the evidence rather than a summary that stands in for it.
5 · What each one cost
Forty-five completed runs, each carrying its own cost, token count and the models that did the work. A run reads as a result rather than a status word.
6 · Open one
Clicking view opens that run on its own. This one is a code audit that finished at 7:27 pm on 30 July: $0.36, across three models.
7 · What the run was
The header is the run's identity: which workflow, how it finished, when it started, how long it took, the tokens in and out, and how many nodes completed. Ten nodes in 12m 46s.
8 · What it cost, model by model
Total spend against this workflow's own running average, then split three ways. One model took 65.9% of the money on 9.1% of the requests; another made 63.6% of the requests for 1.7% of it. The expensive model runs the expensive stage, and the cheap one does the thinking around it.
9 · The branch that set the length
Every node on one timeline: 24m 12s of node time inside a 12m 46s run, because the branches ran side by side. One of them then ran alone for 6m 28s after the others had finished, which is 51% of the run. That stretch is serial, so more concurrency cannot shorten it.
10 · The graph it actually ran
The shape the run took, not the shape it declared: three targets audited in parallel, each verified, each challenged, then gathered, three of three branches complete. Every node badges twice, because COMPLETE only says it ran.
11 · Into a node
Clicking a fan-out node opens what that one target produced: the stages it ran, what each of them cost, and the report it wrote.
12 · Every stage, every model
Five stages for one target, each naming the model that ran it and its tokens in and out. Review rejected the first attempt, a correction stage rewrote it, and the second review approved it. Two attempts and four turns, on the record rather than behind a single pass mark.
13 · Inside one stage
The same run at stage resolution. Execution took 1m 43s and made six tool calls, each its own bar; the gaps between them are the model thinking, not time spent in a tool.
14 · What it found
The verdict first, then the report behind it: passed, approved, seven findings written to disk with the time they were generated. Open full report carries those findings into the review and apply flow, which is where a fix has to earn its way in.
1 Every run in one place. In-progress, completed and queued, in one read-only list with filters.2 The limit, and what it is killing. Ninety-one finished jobs by duration; three killed at the 10m limit and re-run.3 Hover any bucket. What completed in that band, which stage, and how many were aborted in it.4 The failures behind the number. Fourteen failed and four recovered, each naming its node, model and limit.5 What each one cost. Forty-five completed runs, with cost, tokens and models joined onto every one.6 Open one. A code audit that finished at 7:27 pm on 30 July: $0.36, across three models.7 What the run was. Workflow, outcome, start, duration, tokens in and out, and the node tally.8 What it cost, model by model. Spend, requests and tokens split three ways, against the workflow average.9 The branch that set the length. 24m 12s of node time in a 12m 46s run, and one serial stretch of 6m 28s.10 The graph it actually ran. Three targets audited, verified and challenged in parallel, then gathered.11 Into a node. Clicking a fan-out node opens the stages it ran and the report it wrote.12 Every stage, every model. Five stages, a rejection, a correction and a second review that approved.13 Inside one stage. Execution at 1m 43s and six tool calls, with the thinking time between them.14 What it found. A passed verdict and seven findings, ready to carry into review and apply.
A code audit findings report, toured in seven steps. One, the report one of the run's audit nodes wrote: the file it went to, when it was generated, the conventions it ran under, the surfaces it read, and its approved status. Two, the portfolio context the run was given, each file listed with what it was used for, how much of it was sent and a hash of the exact contents, none of which changes what the audit found. Three, every finding graded before it is read, by severity, model confidence and the risk of its fix, then located to a file, line and function. Four, why it matters kept separate from the suggested change, with a jump straight to the source. Five, a structural finding refused an automatic fix and offered a plan instead. Six, a finding graded safe offered Prepare fix, which drafts a change and freezes it as a hashed artefact without applying anything. Seven, the decision row: accept, reject, defer or ask for evidence, recorded against this report only and with no effect on future audits.
1
2
3
4
5
6
7
1 · The report a node wrote
What Open full report opens: one audit node's own findings, each one a card. The header names the file it wrote them to, when it generated them, the conventions it ran under, how many surfaces it read, and that review approved it.
2 · Your context, and where it stops
Every context file the run was given, with what it was used for, how much of it was sent, and a hash of the exact contents. They shape how a finding is written. They never change what it found.
3 · Graded before it is read
Every finding arrives pre-sorted: how serious it is, how confident the model is that it is real, and how risky its fix would be. Then exactly where, down to the file, the line and the function.
4 · Reasoning, then remedy
Why it matters and Suggested change are kept apart on purpose, so the argument can be judged separately from the patch. Open source jumps straight to the line being argued about.
5 · Not every finding gets a fix button
This one is structural, and a structural fix rarely fits in one self-contained edit. So the system does not offer to make it: it refuses itself the option and offers to plan the work instead. The finding still stands, it just does not come with a patch.
6 · The safe ones get a dry-run
The finding below is graded risk: safe, so it earns a Prepare fix. That drafts the change and freezes it as a hashed artefact, and applies nothing: a separate simulation has to put it through the project's own build first, and an approval binds to that exact hash.
7 · My call, and it stays mine
Accept, reject, defer, or ask for more evidence, with a note. The interface says what that does and does not do, in the label itself: no effect on future audits. Nothing recorded here trains anything.
1 The report a node wrote. What it audited, under which conventions, and that review approved it.2 Context in, findings unmoved. The files the run was given, what each was for, and a hash of what was sent.3 Graded before it is read. Severity, model confidence, and the risk of the fix, then the file, line and function.4 Reasoning, then remedy. The argument is kept separate from the patch, with a jump to the source.5 Not every finding gets a fix button. Structural findings are refused an automatic fix and offered a plan instead.6 The safe ones get a dry-run. Prepare fix drafts a change and freezes it as a hashed artefact, applying nothing.7 My call, and it stays mine. Accept, reject, defer or ask for evidence, recorded with no effect on future audits.
How it works
Model proposes. Code decides.
01
Define
Workflows are task graphs defined in code. The graph shape, the validation gates, the apply authority and the audit ledger are all deterministic; models run only inside node bodies.
02
Observe
Every node, stage and tool call lands as a span on the run's real clock. Concurrency is stated numerically, and a run that cannot be placed on a time axis says so instead of drawing one.
03
Approve
Nothing is applied without a person. A frozen artefact, a simulation through the project's own build with mandatory revert, and an approval bound to the exact change it reviewed.
The factory
A software factory that shows its working.
Work enters as a scoped slice, passes through multi-agent build and adversarial verification, and leaves with its full trace: who proposed it, what approved it, how it was verified, and what it cost to produce. One slice at a time, with a person at the gate, because a factory you can trust is one that was designed to be distrusted.
A visible production history
Every slice ships through the same protocol: kickoff, decision gates, adversarial review, closeout. The dated register of what shipped is this site's roadmap page.
Evidence, not just diffs
Proposals, verdicts, approvals and applies land in a ledger with provenance. Spans on a real clock, cost attributed model by model: every change carries its receipts.
Governed autonomy
Agents act under explicit approval grants with hard limits. Generating code is easy; this line manufactures trusted change, and it cannot quietly exceed its authority.
It runs its own roadmap.
The engine and Studio you just toured manage Fulltrace's own development: the Development tab renders the live steering board and the ceremony that ships each slice.