"Token maxing" strikes me as a strange thing to celebrate.

Using a lot of AI is fine. A difficult investigation, a thorough review or a properly useful piece of work might deserve substantial computation. Spend it.

But consumption as an achievement in itself? Bragging about token usage is like bragging about fuel consumption. I'm more interested in how far I get.

I'm currently running between four and seven pieces of work concurrently, with multiple agents involved in each, alongside local AI. This is heavy use, far far beyond a normal working week. I'm still not exhausting my weekly allowance (Claude Max (20x) and ChatGPT Pro), which together cost me about 300 euros a month. Across the two accounts, I typically finish the week with about a quarter of it unused.

The LIOS Works board. Seven cards sit under Now, including spikes and blocked items, with forty-nine more queued under Next. Titles are redacted; labels such as feature, security, domain-rebuild and readied remain visible.
Click to view full size Figure 1, the Works board today. Seven pieces of work in flight under Now, with the rest queued under Next and Later.


I haven't found a loophole or persuaded a provider to remove the limits. It comes largely from how I organise the work: the work no longer belongs to any one agent's conversation.

Core, Works and the Arbiter Method

In When the Software Starts Building Itself (Hutchings, 2026), I wrote about using LIOS to build LIOS, and how my constraint was moving away from execution towards judgement and intent. This is what that looks like day to day. There are three parts, each sitting on the one before.

LIOS Core is the knowledge base. It holds what an organisation says matters, its strategy, principles and decisions, under bitemporal version control, and checks what actually happens against it.

LIOS Works is the tool for getting things done against that knowledge. Each piece of work is a milestone with an agreed contract: what is in scope and what done looks like. Each milestone has one exchange thread, where the investigations, findings, reviews, prompts with approvals and decisions are recorded. Agents join through work sessions that open and close in a defined way.

The Arbiter Method is the process, the way I work with the agents inside Works. It is named for what the human does. Several agents recommend, and I arbitrate between them. Gatekeeper is my role in it: I set direction, approve the work and hold a veto over any final choice.

It runs in two stages.

  1. Deciding what to do. An Architect designs a solution and looks for its gaps. I question it, rule on the open points, and the result becomes the contract.
  2. Getting it done. A Strategist helps me steer: preparing bounded prompts, reviewing what comes back and recommending next steps. A Builder carries out each approved prompt within its stated scope, then reports findings and evidence.

Claude and ChatGPT have both worked with me as Architects, Strategists and Builders, even with each swapping out models from either company mid flow. These are responsibilities, not job titles assigned to particular models.

It is also more than "one AI thinks and another types". A Builder's investigation can establish that an Architect's confident explanation is wrong. That is a useful result. I decide on the evidence available, however persuasive the paragraph.

This is not a development method

I use all of this to build software, because that is a large part of my background. So my examples are software examples.

But read the roles again. Nothing in them mentions code. Someone designs an approach and hunts for the holes in it. Someone with authority decides. Someone does the bounded task, whether that is research, drafting, analysis or checking, and reports back with evidence. Someone reviews the result against what was agreed.

Changing a supplier works like that. So does repricing a product, responding to a new regulation or preparing a tender. In LIOS's own vocabulary, a Builder executes the task an approved prompt sets, which need not be coding. The role title is a label, and they get swapped and reinvented frequently.

What the business owns is the same in each case: its intent, the decisions it has already made and a record of why. Software is simply where agents are capable enough today for me to test this hard. I will run it next with a team doing something very different, but who are dealing with same conceptual AI challenges.

One discussion, several agents

During a recent review of how new knowledge is checked before it enters the LIOS knowledge base, I brought in a second Architect.

I could have kept two separate conversations and translated each agent's argument for the other. Instead I made the milestone's message conversation thread the shared discussion. My messages in the individual chats (Claude and ChatGPT, in their browsers for now) became a nudge:

Thread updated.
One LIOS exchange thread on milestone M-141, with message text redacted. An approval from Jeremy Hutchings as a human, a report from a Builder agent, a review from a Strategist agent and a discussion post recording a Gatekeeper ruling, with each participant's reading position shown in a side panel.
Click to view full size Figure 2, one exchange thread. My approval, a Builder's report, a Strategist's review and a ruling, all on the same record.


Each agent could read the same investigation, see the same objections and add to the same record. I still had to convene the discussion, question the recommendations and decide. I no longer had to carry every report and counterargument between browser tabs.

It changed the outcome too. The work started as a narrow fix. Hearing two Architects argue from the same evidence showed that the fix rested on a question none of us could yet answer. So the work changed shape: find out first, then build.

With several pieces of work in progress at once, this matters a great deal. The agents do not need to share one conversation. They need access to the same intent, evidence and decisions.

They can still disagree about the interpretation, which is often why I bring another agent in. The disagreement should be about the work, though, and never about which version of the story each happened to receive.

Finish the session, not the work

A work session in LIOS has a defined start and a structured close-out.

At the start, the agent receives the agreed contract, the state of anything the work depends on, continuity from earlier sessions and pointers to relevant knowledge. It can read the thread updates it has not yet seen and retrieve the supporting material it needs.

At the end, it records what happened: outcomes, decisions and their rationale, discoveries, unresolved questions, the state the work was left in and what should happen next. It also records friction, including anything that cost time or had to be guessed.

The work sessions list for one LIOS milestone: nine sessions opened over two days by Strategist and Builder agents, two still open and seven closed, each closed session linking to its close-out post on the thread.
Click to view full size Figure 3, nine sessions on one milestone over two days. Each closed session links to its close-out.


So I can end an agent's conversation without abandoning the work. The next session does not start from nothing. Nor does it inherit every speculative discussion, superseded suggestion and bulky tool response its predecessor accumulated.

The handover is a starting point. The record stays authoritative. The contract, the knowledge base and the thread all remain available, so a successor can go back to the evidence and need not take its predecessor's summary on trust.

None of this is new. I first met it years ago while researching for my MSc in Systems Thinking, in the literature on how doctors hand patients over between shifts. Medicine learned it the hard way: when nine hospitals adopted a structured handover, medical errors fell by 23% and preventable harm to patients by 30% (Starmer et al., 2014).

That holds when I start a fresh conversation, change agents or bring someone else in. The record belongs to the work, not to whoever happened to be there first.

Where the token savings come from

An AI conversation has a finite working context. As Anthropic's (n.d.a) documentation on context windows describes, each new request in a full-history interaction carries the earlier messages and tool results along with it. If each step adds a similar amount of material, the input accumulates like this:

1 + 2 + 3 + 4 …

Cumulative input grows roughly with the square of the number of steps. Bounded sessions avoid carrying the whole history forward each time, though onboarding, handovers and retrieval add overhead of their own.

The real bill is kinder than that curve. Prompt caching reduces the cost of repeated context (Anthropic, n.d.b), and agent tools already use compaction to summarise earlier work (Anthropic, n.d.c). LIOS did not invent summarisation. What it adds is a shared work record with explicit intent, authority and evidence, so continuity is not left to whatever one conversation happens to preserve.

I want tokens spent on investigating, reasoning, doing and checking. I'm less keen to keep paying for the archaeological record of how we got here.

Less context is not automatically better

There is an obvious way to make an agent cheap: tell it almost nothing and accept whatever it produces. That is a false economy.

The aim is sufficient, relevant context. Anthropic's (2025) guidance on context engineering makes much the same point: the smallest useful context is not necessarily a short one, and aggressive compression can discard details that matter later.

A good handover takes effort. So does recording a decision, and explaining why an apparently sensible approach was rejected. That effort is part of doing the work properly.

A detail left out of a handover is not lost if it exists in the shared record. Something important that lived only in an outgoing agent's private conversation may well be. LIOS does not remove the need for discipline. It gives that discipline somewhere to live.

It has not made us infallible, either. A recent architecture review began because a piece of work crossed a boundary of ownership I believed should have been respected. The rule about who owned what had never been made explicit in the knowledge base, and the earlier proposal had not made the consequence visible enough.

I spotted the problem and required a broader review. The process had not prevented it. The shared record gave us somewhere to establish the discrepancy, investigate what was actually built and capture the intended boundary. It did not excuse us from making the correction.

The allowance is no longer the interesting constraint

Local inference contributes capacity too, and I have not separated its effect from session management, selective retrieval and model choice. This is a description of my current working experience and not a controlled benchmark. My workload could change, and the limits could become relevant again.

Right now, though, the allowance does not constrain what I can get done. The constraints that matter are my ability to clarify intent, recognise a weak assumption, weigh evidence and decide what deserves attention next.

There is something reassuringly familiar about that. Clear responsibilities, good records, bounded authority and proper handovers are old management ideas. I am applying them to a working arrangement that now includes AI agents.

Sometimes another investigation or an independent review is exactly where more tokens should go, so I am not trying to minimise them at any cost. I am trying to stop confusing consumption with progress.

The unused allowance is a welcome consequence. The more important change is that continuity no longer depends on keeping a particular conversation alive.