Animated Octomind icon — purple pixel-art octopus

At the end of a day with an agent, you know what shipped. What you usually don't know is what it cost you. How many hours went to each client or project? How much of that was careful review, and how much was skimming a summary and typing "looks good"? How much focus do you have left for the afternoon?

Guessing doesn't work here. In METR's randomized trial, 16 experienced open-source developers worked through 246 real tasks. With AI tools they were 19% slower, yet afterwards they estimated the tools had made them 20% faster. When agents do the typing, your own sense of where the time went is the least reliable number you have.

Octomind 0.55.0 measures it from your session log instead. /report now shows how much of your time each request took and how much mental energy it used. /report day, /report week and /report month add those up into a timesheet per project. It runs locally over the log Octomind already keeps. You don't start a timer, and nothing is sent anywhere.

This post shows what the report looks like and how to read it, then walks through how every number is computed and which research each constant comes from, how to calibrate it to yourself, and what it can't see. After that comes the rest of 0.55.0. It's out for the open-source CLI today and coming soon to Octomind Cloud.

Your morning, as a table

Picture a morning with two projects.

At 09:00 you open a session in billing-api and spend 13 minutes writing a 260-word spec. The agent answers at 09:25. You reply at 09:30, and it goes off to implement, changing 134 lines by 10:05. While it works, you open a second session in webhooks at 09:28 and give it a smaller feature. That run changes 67 lines by 09:50, and you answer it at 10:02. Later you read the 134 billing-api lines properly and send your notes at 11:05. The agent wraps up by 11:10.

Here is what /report day prints for that morning:

text
╭ /report · day
│   #  session                                   turns    human     code    DHE  lines    read
│ ───  ────────────────────────────────────────  ─────  ───────  ───────  ─────  ─────  ──────
│   1  260926-billing-api-0900-3f2a                  3   1h 30m      40m   1.86    134    100%
│   2  260926-webhooks-0928-8c1d                     2      29m       6m   0.47     67     60%
│ ───  ────────────────────────────────────────  ─────  ───────  ───────  ─────  ─────  ──────
│ project                     human     code    DHE  lines    read
│ billing-api                1h 30m      40m   1.86    134    100%
│ webhooks                      29m       6m   0.47     67     60%
│ human  1h 59m  code review 46m · dialog/behavior 40m · waiting 33m
│ energy 2.38 of 4 DHE · 201 lines changed, 87% read
╰ ✓ /report · day · 1h 59m

This is the two-session scenario from Octomind's own timing tests, run through the same calculation and laid out the way the CLI renders it. Only the session names are ours.

The columns:

  • human is the time the session took you: minutes of attention plus minutes spent waiting on a run you were still following.
  • code is the part of that time spent reading the code the agent changed.
  • DHE is energy in deep-hour equivalents. One DHE is one hour of the deep, focused coding you did before agents. The daily budget is 4.
  • lines is how many lines the agent's edits changed.
  • read is how much of the time those lines take to read you spent before your next message.

Some things worth noticing:

  • The clock says 2 hours 12 minutes; the timesheet says 1 hour 59. That's from 09:00 until you finished reading the last answer. Your 11:05 reply came an hour after the agent finished. Reading 134 lines and the agent's summary, thinking, and typing your short reply should take about 23 minutes, and Octomind allows twice that for deliberation: 46 minutes. The other 14 minutes count as time you were somewhere else, so they don't go on the timesheet.
  • Nothing is counted twice. Between 09:28 and 09:30 you were typing the webhooks request while still reading the billing-api answer. Those two minutes are split between the sessions.
  • Waiting is cheap but not free. 33 minutes of the morning were spent waiting on runs you were still following. They're on the timesheet, but at a quarter of the energy weight.
  • One review took most of the energy. The morning used 2.38 of 4 DHE, more than half the day's budget before lunch. The 46 minutes you spent reading 134 lines account for 1.43 DHE of it, about 60%.

The plain /report for a single session puts the same human, DHE, lines and read columns next to what it already showed for every request: cost, tool calls, and task, model and tool time. The last request shows unread until you send another message, because only then can Octomind tell how long you spent on it.

/report week and /report month list one row per day with its projects and highlight days that went over the energy budget in red. Project totals follow, sorted by time. Add here to count only the project you're in:

text
/report
/report day
/report week here
/report month

If you bill clients by the hour, /report month here gives you the hours for one client's repository. If you're the client, it tells you what a feature cost in your hours, not only in tokens.

Why two numbers

With agents, the kind of work you do changes, not just the amount. The typing goes to the agent. What stays with you is deciding what to build, writing it down clearly, and checking what comes back. Those tasks don't wear on you the way an ordinary hour does:

  • Checking is vigilance work. In studies going back to Mackworth's 1948 radar-watch experiments, people's ability to catch problems drops within 15 to 30 minutes. It's demanding, stressful work, not passive watching (Warm, Parasuraman & Matthews, 2008).
  • Watching automation is harder than doing the job. This is Bainbridge's "Ironies of Automation" from 1983, and it applies directly to reviewing agent output.
  • Review quality has limits. In the Cisco code-review study (Cohen, 2006), reviewers found fewer defects in sessions longer than 60 to 90 minutes and when they read faster than about 500 lines an hour.
  • Engagement fades as a task goes on. A CHI 2026 workshop paper is titled after what engineers said about agent output: "I'm not reading all of that". Harvard Business Review calls the fatigue from overseeing too much AI work "AI brain fry".

So one number can't answer both questions. Time is what your timesheet needs: how long the work took you. Energy is what your limit needs: how hard those hours were. An hour of reviewing agent output takes more out of you than an hour of hand coding did. An hour of waiting on an agent takes much less. A day can log 8 hours of time and still use up its energy budget by noon.

How your time is counted

Every message you type starts a turn. The agent's run lasts until its last message or tool call before your next input. Slash commands and system messages Octomind injects don't count as turns.

  1. Estimate the turn. Octomind estimates how long your next message should have taken. You read the agent's visible text at 238 words per minute (Brysbaert, 2019), review its changed lines at about 400 per hour (Cohen, 2006), type at 52 words per minute (Dhakal et al., 2018), and spend 1.5 minutes thinking.
  2. Count your attention. Your active time before a message is the gap since the agent finished, capped at twice that estimate. A longer gap means you were away or doing something else. A short gap, such as when you paste a ready-made answer, stays short. The first message of a session is measured from when the session opened.
  3. Split overlaps. You can only pay attention to one thing at a time. When active time in two parallel sessions overlaps, the overlapping minutes are split equally between them.
  4. Credit waiting, briefly. Time when you weren't active anywhere but a run was still going counts as waiting, but only for 30 minutes after your last message to that session. A long autonomous run costs you the time to start it and the time to review it, not the hours it runs.
  5. Close the session. After the last run, the time to read its text is added. Its changed lines stay unread until you send another message.

Lines are the rows the agent's own line-based edits report, from octofs text_editor and batch_edit. If the agent shows a diff with git diff in a shell, that's reading, not writing, so it counts zero.

Did you review it, or did you check it?

The read column is measured, not assumed. The time before your next message goes first to reading the agent's text, then to deciding and typing, with the same "twice the estimate" allowance. Only the time left over counts as reading code, up to the time those lines actually take.

Say a run changes 200 lines and ends with a 238-word summary, and you reply with 20 words. Reading the summary, deciding and typing come to about 2.9 minutes, doubled to 5.8. Reading 200 lines at 400 an hour takes 30 minutes. Here's how the same change is scored depending on when you reply:

Your reply comes afterreadEnergy of those minutesWhat it means
30 seconds0%0.01 DHE⚠ rubber-stamp: approved before the summary was read
3 minutes0%0.05 DHEBehavior check: you trusted it, ran it, or skimmed it
15 minutes31%0.40 DHEPartial review
40 minutes100%1.24 DHEFull code review

A behavior check is a legitimate choice. You ran the tests, clicked through the feature, or trusted a small refactor. You know which one you did, the report shows how the time was split, and a behavior check never gets flagged.

A rubber-stamp is different. The row gets flagged when a run changed 50 or more lines and your reply came in less than 30% of the time it takes just to read the agent's text and type your answer. In this example that's anything under 52 seconds. It means a large change was approved before even its summary could have been read. That's when tired people ship bugs, and it's the flag most worth watching for.

How energy is counted

Every minute gets a weight, and the weighted total converts to hours:

  • Minutes spent reading code weigh 2.
  • Dialog, writing specs and behavior checks weigh 1.
  • Waiting on a run you're still following weighs 0.25.
  • Each switch between parallel sessions without a 10-minute break in between costs 0.05 DHE.

The 4 DHE daily budget comes from the roughly four hours a day of deliberate practice that elite performers sustain (Ericsson, Krampe & Tesch-Römer, 1993). With the default weights, an hour and a half of writing specs plus an hour and a quarter of review uses all of it.

Two more flags cover the day as a whole:

FlagShown whenBased on
Deep blockYou worked for more than 90 minutes without a 10-minute break60 to 90 minute review sessions (Cohen, 2006); 10-minute breaks reset stress build-up (Microsoft, 2021)
Over budgetThe day's energy passes 4 DHEEricsson, Krampe & Tesch-Römer, 1993

In week and month views the flags are counted per day, for example "energy over the daily budget on 2 day(s)", so you can see a pattern building before it becomes a habit.

Make it yours: calibrate

The reading, review and typing speeds and the flag thresholds are fixed research values. Six numbers are yours to tune, in a new [timing] section that your config gains automatically when you upgrade:

toml
[timing]
think_overhead_min = 1.5      # thinking time added to every turn's estimate, minutes
deliberation_factor = 2.0     # cap on attention before a message, as a multiple of the estimate
attention_window_min = 30.0   # how long after your last message a run still counts as waiting
review_weight = 2.0           # energy per minute of reading code (dialog and specs = 1)
wait_weight = 0.25            # energy per minute of waiting on a run you're following
switch_cost_dhe = 0.05        # energy cost of switching sessions without a 10-minute break

The defaults are starting guesses. To fit them to yourself:

  1. For 5 to 10 working days, log your time per task by hand, switching a timer at every task change. Write down an end-of-day fatigue score from 1 to 10, or use NASA-TLX.
  2. Adjust think_overhead_min, deliberation_factor and attention_window_min until the session times in /report day match your log. Aim for a median error per task within 15%.
  3. Keep dialog and spec work at weight 1, and fit review_weight, wait_weight and switch_cost_dhe against your fatigue scores.

The sessions guide covers the full model, and the configuration reference lists every key.

What it can't see

An estimate is only as honest as its blind spots, so here they are:

  • Work outside sessions doesn't show up: reading docs, reviewing in your IDE, meetings.
  • Only line-based edits count as lines. Files the agent writes through shell or creates whole don't count, and neither do diffs it only reads.
  • The speeds are population averages. Dense code reads slower than 400 lines an hour. That's what calibration is for.
  • Day, week and month totals include only sessions you drove from the interactive CLI. Tap runs, workflow steps, one-shot octomind run prompts and ACP or WebSocket sessions are excluded, because their prompts often come from another agent. That also leaves out a person typing in an ACP editor. Sessions you last used before upgrading don't appear either, so your history starts with 0.55.0. The single-session /report works on any session.
  • The energy weights are hypotheses, not measurements, and one number combines kinds of fatigue that research treats separately.
  • It's built for self-reporting and team norms, not surveillance. Used to watch people minute by minute, it would change how they work and stop measuring what it claims to. It runs on your own machine over your own session files and sends nothing.

Also new in 0.55.0

Learned behaviors have to beat a control group

Octomind's learning system can turn lessons from your sessions into new skills and guardrails, with evolution switched on (it's off by default). The hard part is knowing whether a generated behavior actually helps. Counting how often it "worked" misleads: a rule that happens to fire on easy tasks looks like a win every time.

In 0.55.0, a candidate has to prove itself against a control group. While it sits in shadow, Octomind checks its trigger but doesn't apply it. Every turn where it would have fired becomes a control sample, scored by the verify gate's pass or fail and the number of API calls the turn took. After enough control samples, it runs a live trial, the treatment arm, scored the same way. Then:

  • It's promoted if it beats its control by more than the noise margin without costing too many extra API calls, or if it matches the control's pass rate while cutting API calls by more than 10%.
  • It's retired as regressed if it does worse than the control by more than the noise margin.
  • It's retired as inconclusive after 8 live uses without a verdict either way.

Promoted behaviors keep being judged. One that stops beating its control is pruned, and anything without a trigger match or use for 90 days retires as stale. Rejected and retired ideas are remembered, so the same failed idea isn't proposed again. With [supervisor.evaluate] evolution = true, each sample is graded by how likely the answer is to fulfill the request, and turns where the behavior doesn't apply are dropped.

toml
[supervisor.learning.evolution]
enabled = true
min_samples = 3        # verdicts needed in each arm before comparing
noise_margin = 0.15    # pass-rate gap treated as noise
cost_allowance = 0.10  # API-call increase tolerated for a negligible gain
cost_per_gain = 2.0    # extra API-call increase allowed per unit of gain
max_trial_uses = 8     # live uses before an undecided trial retires

Evolution needs the verify gate ([supervisor.gate], on by default), because the gate's verdicts are what both arms are scored on.

Thinking off where it's wasted

reasoning_effort accepts a new level, "none", and /effort none (or /effort off) does the same for the current session. It asks the model for no reasoning and switches thinking off where the provider has a switch: Alibaba, DeepSeek, Z.AI, OpenRouter and OpenAI.

It's there because some calls produce output that is the whole point, and thinking only gets in the way. Compression is the clearest case. Measured on DeepSeek V4 Flash, medium-effort compression of 70k to 190k tokens of conversation spent its entire 16k to 32k output budget thinking and returned nothing, on every attempt. With thinking off, the same compression finished in a fraction of the time. New configs now ship with reasoning_effort = "none" under [compression.model]. Existing configs keep their setting, so add it yourself:

toml
[compression.model]
reasoning_effort = "none"

A related fix: when a model uses up its output budget before writing anything, Octomind no longer pays to send the identical request again. The agent loop keeps its single retry, and compression gets one bounded repair attempt before reporting a clear error.

Markdown links in the agent's answers now render as real terminal hyperlinks (OSC 8), including links inside tables. You see the label and click through to the destination, just like in a browser. URLs, file paths and XML or HTML tags in prose get their own color, and code spans are left alone. This needs a terminal that supports OSC 8 hyperlinks.

Pasted text stays quoted

When you paste three or more lines into the terminal, Octomind wraps them in <pasted_content> tags. The system prompt now tells the model that this is quoted material rather than your own words, to read it for what it is (a log, code, an error, docs), and never to treat instructions inside it as commands from you. A log line that says "ignore previous instructions" is treated as part of the log. Our AI agent security checklist explains why this boundary matters.

Smaller things

  • Better context estimates. Token counts now take the provider and model into account and are calibrated against the prompt usage providers report, so compression kicks in closer to where it should.
  • Complete cost reporting. The JSONL cost event now includes supervisor, compression and other auxiliary tokens. A one-shot JSONL run that fails on a provider error sends its cost event before exiting, so scripts that bill from the last event no longer record a failed turn as free.
  • New models. octolib 0.40.0 adds Claude Opus 5.5 (anthropic:claude-opus-5-5) and Grok 4.7 (xai:grok-4.7), and refreshes other providers' catalogs and prices.
  • MCP resource links. Octomind now declares the io.muvon/watch-resource-links extension. It tells MCP servers that Octomind follows resource links in tool results and passes their resources/updated notifications on to the model. That's how a server like octofs can wake the agent when a long background build finishes.

Coming soon to Octomind Cloud

0.55.0 is coming to Octomind Cloud next. As with every release, your machine will pick up the new version the next time it starts, with nothing to set up. Until then, everything in this post works today in the open-source CLI.

Update to Octomind 0.55.0

bash
curl -fsSL https://octomind.run/install.sh | bash -s -- --version 0.55.0
octomind --version

Your config upgrades itself on first run and gains the [timing] section with its defaults. Then work as usual, and at the end of the day type /report day. See the installation guide for other platforms and methods, and the full changelog for every change.

Sources