What did the agents actually do today?

Faster, says the survey. Slower, said the stopwatch.

In September 2025 Google's DORA team published its State of AI-assisted Software Development report. The announcement put the headline plainly: “90% of survey respondents report using AI at work. More than 80% believe it has increased their productivity.” In the same paragraph, 30% reported little or no trust in the code the AI wrote.

The report's central line is the useful one: “AI doesn't fix a team; it amplifies what's already there.” It also found that AI adoption “does continue to have a negative relationship with software delivery stability”, and that without “strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.”

Then there is METR, which ran a randomized study with experienced open-source developers. Its early 2025 result, restated in a February 2026 update, was that “the use of AI causes tasks to take 19% longer”. The update is more interesting than the number. Developers now refuse to work without AI, even at $50 an hour, and “30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI.” METR concluded its new data “is only very weak evidence” for the size of any change, and is redesigning the study.

We cannot tell you whether running many agents makes you faster. What we can give you is DORA's “fast feedback loop” at the scale of one person and one day: a record of what the agents did, what broke, and what it cost, written so you can act on it tomorrow morning.

A quiet day should not look empty.

Solace is the part of Luminair that tracks every “I'll report back” promise across your sessions until it is done, verified and confirmed. It is event-driven: it wakes when a session finishes, a background job ends, or a verifier returns.

That design had an awkward side effect, recorded in the commit of 27 July 2026. Between events, its watching left no trace, so “an uneventful day looked empty/useless”. A log that only records changes cannot tell a day where nothing broke from a day where nothing was watched.

The fix was a patrol. While Solace is on, it runs a routine check shortly after launch and then every 15 minutes, and logs what it reviewed and what it found, including the honest “nothing needed doing”. If a tracked item has been in progress for more than 20 minutes with no update and no background job behind it, the check flags it as possibly stalled.

The collapse also shapes the recap: the model sees “Routine check ×12”, not twelve duplicate lines, which is cleaner and costs fewer tokens.

Counted by code, told by a model.

Once a day, after 17:00 local time, Solace writes a recap from that log. The split of work is deliberate. Code counts; the model only writes a short summary and suggests improvements.

• The counts are derived, not remembered. Every time the card opens, its numbers are recomputed from the day's log. Only the model's summary stays frozen as written.
• The verdict comes first and comes from the log. The source comment for the 24 September redesign says the card should answer one question, “does anything need me?”, with a verdict “computed from the log (never from the model's prose)”.
• A quiet day never reaches the model. With nothing logged, an early version handed the model an empty log and got a greeting back. Now an empty day gets a short local note explaining what the recap measures, and no model call.
• Suggestions are opt-in rules. The model may propose two to four improvements. Each has Turn on and No thanks. Turning one on asks for confirmation, then makes it a standing rule for future turns; anything that reads like granting tools, permissions or credentials, or weakening security, is refused before it can be adopted. Dismissed ideas are passed back to the model with an instruction not to suggest them again.

One bug shows why counting in code matters. On 24 September a failed background job was being filed under “maintenance”, so the recap said zero errors on a day with five failed builds. The fix classifies a log line by what it says, not only by its type: a line saying a job failed, or finished with a non-zero code, counts as an error.

Nobody should need to know what 143 means.

Two days later, on 26 September, the card was rewritten again for people who do not read exit codes. The note in the source is blunt: the old card was “horrible for general users”. Three changes came out of it.

First, one row per task, not per attempt. Three failed tries at the same deploy are one thing to look at, shown once with “Tried 3 times”. Second, the model's summary is told to write for a non-technical reader: say “the assistant” rather than internal names, never mention exit codes or log fields, and end with the one thing worth doing next. Third, exit codes became reasons:

The rest of the card follows the same idea. The small counters read Finished, Double-checked, Fixed itself and Cleanups, and every non-zero number opens the exact log lines behind it.

A ledger that costs nothing to keep.

The recap tells you what happened. The second record tells you what it cost. Since 4 August 2026, every finished turn drops one compact record into a local token ledger. The design rule is written into the code in capitals: no model call, because this must stay free.

Each record lands in a bucket for your local day, split three ways: by model, by thinking level and by session. The ledger keeps 14 days per account and prunes on every write. It is fed from both places a turn can finish: the desktop app and turns relayed from your phone.

On top of the totals, the ledger keeps two coaching counters. Each is a plain rule, not a judgement by another model:

The two counters then drive one sentence and a couple of tips. If less than 12% of the day's tokens went to those two habits, the card calls it a lean day; under 35%, balanced; above that, a rich day with room to trim. The tips are ranked by how many tokens each would move, and read like Swap quick questions onto Sonnet 5 and Ease off Max thinking. When neither counter fires, the card says so and suggests nothing.

The first version counted tokens only, on purpose: the commit says “never invented dollar prices”. Dollars arrived on 6 September with the Burn meter, and the rule survived in a stricter form. A Claude turn that reports its own cost is recorded as reported. Anything else is priced from a published list-price book and marked est. A model missing from the book stays unpriced rather than getting a guess, and turns that reported no usage at all are counted and shown, so a partial total never passes for the whole day. The panel's footnote is honest about the rest: “Subscription figures are API equivalents, not your subscription bill.”

Three places, one panel.

1. 1Click the small arrow next to the Solace chip. The MC Reports dropdown lists every step it took today, routine checks included. Click a merged row to see each check's time.
2. 2Open Solace and choose the Spend tab. The Burn meter shows today's dollars by model, project and session, and Your token diet · today shows the per-model bars, the day's verdict and the swaps.
3. 3The daily recap card appears after 17:00. For now it is switched on only for Luminair's own admin accounts: we are running it on our own work first.

Solace is part of the Pro+ plan. The pricing page has the details.

Checked, and not claimed.

Sources

• Google Cloud Blog · 23 September 2025Announcing the 2025 DORA Report
• DORA · 2025State of AI-assisted Software Development 2025
• METR · 24 February 2026We are Changing our Developer Productivity Experiment Design