Claude Studio: one workspace for every project at once.

The key is paid for and the agent works. A week can still deliver less work than planned, with the spend spread across several decisions. Each request felt useful at the time. Claude Code has mechanics underneath that affect the spend directly. Each question involves model calls, a context carried into those calls, and a cache that can be warm or cold. The mechanics are public and worth watching during the work. By the time the week ends, those decisions were made days ago. The panel brings them into view as they happen.

For a finance view of the same approach, open the Xero and MYOB dashboard: findings ranked by the dollars at stake, with a cash forecast. This article follows the workspace we use to build and run those systems.

Claude Studio shows those mechanics. More to the point, it tracks them for you while you work.

The idea is simple: a token should go into the work you ordered. Re-sending a cold session has a price, and the panel works that price out for you. The environment chooses between continuing the current session and starting a new one. It says out loud what each would cost. All else equal the key stretches over noticeably more work, with the same answer quality. The gain comes from choosing sessions with their full context costs in view.

The panel itself is a browser window over a real coding agent running on your own machine. Everything stays on that machine: the same engine as the editor plugin, the same subscription, the same computer, the same project folders. The difference is that the agent finally has a room around it.

One environment brings three places together

This is the main thing, and most of the rest follows from it.

Normally, work with an agent is smeared across several places. The agent lives in its own app or in a terminal. The code is in the editor. Checking the result from a phone adds remote access to that setup. Preparing it means flagging a session, turning access on or forwarding a connection in advance. Half the state can sit in another window, and a phone connection may show one session in ten. Bringing those views together became part of our work.

Claude Studio is one address. The panel stays online for as long as the machine running the agent is on. Open it from the work laptop: every task is there. Open it from a phone in a queue: the same tasks, live, in the same state, including the ones running right now. Open it from somebody else’s computer you can log in from: them again.

Remote access is part of the setup from the start. Every session uses the same mode and interface, with a layout that fits the mobile screen. Any task is reachable from anywhere at any moment, because it lived on the server from the start and the browser only draws it.

One more thing follows from the agent running locally: it has your whole disk. It reads and edits real files, runs the tests, reaches the database through your own MCP servers, picks up your CLAUDE.md, your skills and your hooks, the same ones as in the editor. That direct connection to the local project is central to the design. The agent works with the files and tools already on that machine.

Servers wake up when they are needed

“One environment brings three places together” has a very concrete price, and it is worth measuring as part of the work. Every connected MCP server is a set of tool descriptions, and they travel in the system prompt of every request: including requests for other tools. Thirteen servers is about forty-two thousand tokens you pay at the start of any conversation, even on a day spent entirely on other work.

Hence the habit of keeping one environment per job: one window with the database, another with the browser engine, a third one with a small tool set and its own context cost. Each with its own tabs, its own history and its own work progressing elsewhere while your attention stays here.

Here the schemas load on demand, so those tools can share one working environment.

The agent knows the tool exists. Its description reaches the context when the agent decides to use it. The measured price of forty-two thousand tokens of schemas in the window is zero. So you can keep connected everything that might conceivably be useful, with schema costs starting at the first call.

The practical consequence is exactly one, and it concerns attention as well as tokens: one working window for everything. One page holds every project and every task. Their activity stays visible together, including the rows waiting for you to read them.

Projects, tasks and their conversations

A message feed works as an interface right up to the second project. After that it becomes a heap of identical-looking sessions, and finding the one where you fixed the invoice import a week ago costs six openings.

Down the left of the panel runs a rail: projects, sub-projects inside them, tasks inside those. A task is a unit of work that lives for weeks and holds its own sessions: “invoice OCR gets multi-page PDFs wrong”. The panel changes the sessions underneath a task automatically as their costs change. The list keeps its focus on the task throughout those changes. A task outlives its sessions roughly the way a folder outlives files.

You name the task. Half a second of naming settles two things at once. In a list of fifteen rows, the right name is easy to find by eye. And it can be called by voice with your hands full. “Open Approval chain” gives voice control a specific task name. A label tied to the work stays useful across days.

Eight projects, a dozen or two tasks in each. That used to be a person’s week smeared over three editor windows and memory. Here it is one screen showing at a glance what is finished, what is waiting on you, and where something is happening right now.

That is the shift. The editor helped you handle files inside one project: an honest job, while files were written by hand. The agent writes those files now, and projects need attention too. “Which of the eight is waiting on my decision” joins “where is that function” as a daily question. Machine capacity and time still matter. Your attention ties the projects together, and attention is what has to be allocated.

Hence a small thing that saves hours: the rows show the full state. A green tick appears after the task and all its subagents finish. An earlier version showed it too soon. Correcting that restored trust in the whole list.

When the agent asks

Work regularly hits a fork that calls for your decision: trim the trailing space in supplier codes on import, or keep the value as it is and compare on TRIM. It stops and asks. This is where the time used to go: a ! beacon lit up in the list, and what was actually wanted of you sat at the end of the last turn, so to read it you had to open the task and scroll.

The beacon stays active while you read the row and goes out when you answer. That small difference is the point. The task keeps asking until you answer, so an open question stays visible after you read it.

You can see it working

A turn unfolds in the feed as it happens: the reasoning types out live, every tool call lands as a card of its own: what it read, what it found, what it changed, what it ran and how that ended.

The point is timely intervention in the work. When you can see the agent going into the wrong file at the twentieth second, you stop it at the twentieth second. Waiting until the twentieth minute carries a larger cost. And the earliest intervention is always the cheapest. While a turn runs, the send button becomes an interrupt button. The session survives interruption and remembers everything it got through.

Warm cache, cold cache, and how the panel manages them

Now for those mechanics. Worth understanding once, with the panel handling the arithmetic during the work.

While the prompt cache is warm, the whole accumulated context is re-sent at a tenth of the price. In this setup it lives for one hour from the last request (the default is five minutes). Once that hour is up the same context travels in full and at full price. And the same message in a session gone cold costs roughly twenty times what it costs in a fresh one with a short brief. Hence a rule you learn once: the price of a turn = number of calls × size of the window. Message length and question difficulty have a smaller effect. The main drivers are how many times the agent goes to the model, and how much text it carries each time.

Those moving costs are a job for the panel during the work. So the panel does three things for you:

• Predicts the size of the next turn: from your message and the task’s history. A short question and “go through the whole folder” cost differently before either of them starts.
• Says the verdict out loud, right above the input box: “continuing this session, the cache has 47 minutes left, this turn rides the cache: about A$0.11, cheaper than starting clean (≈ A$0.94)”. Or the other way round, when the other way round is cheaper.
• Carries the meaning across in a short brief. When the session does change, what travels into the new one is a compressed digest of the task, with the relevant meaning drawn from the whole transcript. The task continues from the same place. The window starts with that shorter brief.

The environment makes these choices automatically. The line above the input box reports its decision and the cost behind that choice. You can change the decision when your work calls for it.

This arithmetic broke on us once and cost real money: the context counter was fed a turn’s spend in the field meant for the window’s size, and the panel tore the session almost every turn. It has had a test of its own ever since: one that fails when the number drawn disagrees with the number measured.

A receipt under every answer

The same thing again, after the fact, in one line.

Two things matter. First: the price stands next to the decision, a month ahead of the later invoice. “Was that worth it” gets asked at the moment it can still be answered with an action.

Second: a subscription gives you a share of a weekly window, which the panel values in money. The panel knows the live rate, what one per cent of this week actually costs us, and converts the percentages into currency itself. The rate changes with the models you have been working in.

The model chosen afresh for each turn

The panel gets its model list directly from the same CLI that will do the counting afterwards. So a new model appears in the menu on the day it ships, through that live list. Each one lists exactly the effort levels it actually accepts with the menu matched to that model’s supported choices.

Their costs differ by multiples, a much larger scale than small percentage changes. The choice sits under the input box for a fresh decision on every turn. Working out somebody else’s architecture and renaming forty files from a ready list suit different models. Choosing for each job lets the price fit the work.

One window, as many columns as you like

Since attention is the scarce thing, the panel brings the views together in one place. The workspace is columns and floors inside one browser window: drag a task into the next column and watch two live feeds at once, or stack two tasks in one column.

A subtlety that surfaces after a fortnight: columns are needed less often than you would think. One task in one window reads better: whole, top to bottom, using the full screen width. The rail keeps the other eight visible through their status. Each row says whether it is running, finished or waiting on your decision.

That used to be the real chore: keeping several environments open and walking the circuit, checking whether anything had finished. Now those checks happen automatically: the beacon in the rail changes by itself, and columns open when two things genuinely have to be seen side by side.

Each lane holds a long-lived session of its own, so each lane’s cache stays independent of the others. A message sent into a busy lane queues and goes as soon as that lane becomes available. The queued message keeps the thought attached to the work while the current turn finishes.

By voice, and accurately

The microphone sits next to the send button in every window, on the computer and on the phone. It is a second way to type in the same composer, and on a long brief it is about three times faster than a keyboard.

By default, a local engine handles recognition on the same machine. Quick local dictation uses the computing you already own. But sometimes accuracy matters more than anything, and then your own key goes into the settings (an OpenAI one, for instance) and dictation runs through that. That accuracy choice helps with several languages in one sentence, proper nouns and file names. It also helps when dictating interface strings verbatim in somebody else’s language. The key is yours and lives in your own key cupboard. The panel keeps the value in that cupboard and shows its masked form.

It works the other way too: an answer can be read aloud, by the same local engine, with the cloud as the fallback.

One more feature proves useful when a turn changes course: everything dictated is recorded. If the text went into the wrong task, the turn broke, or you simply changed your mind about sending: that dictation is in a list of its own and comes back whole.

Anything at all in the input box

Drag supporting files into the input box or paste them from the clipboard. You can add screenshots, PDFs, accounting exports, Word procedures, diagrams, log archives and screen recordings. All these file types go beside the message. The brief and its supporting files travel together into the same task.

The agent reads their contents: parses the table, pulls the text out of a PDF and out of a .docx, looks at the picture. Usually that is faster than any explanation: a screenshot of broken layout, or a page of a report with the wrong total, states the task in a second where a paragraph of prose only confuses it.

Which is why a screen recording is a regular part of the work here. Thirty seconds of video showing exactly how the form breaks are worth a page of description. The recording can be watched again to inspect the same sequence of actions.

And back the other way: reports you can open

In the other direction, the feed shows the finished work directly. A picture the agent made or found appears in the answer. An HTML report, a PDF or a log opens with one tap inside the panel. Finished reports stack on a shelf inside the project, so something made last week is ready to open on that project’s shelf.

Search across everything ever said

After a month of work the main question has become “where have we done this already”. Search runs across every conversation in every project at once: your messages, the agent’s answers, task names: on a fragment of a word, using the fragment you remember.

It also finds material retained in the journal after the archive has been tidied. The journal keeps material longer than the session archive. Something said six months ago comes back, along with the task you dictated in the car and left for later.

Bookkeeping across the work

Small receipts add up into reports. Together they give us a way to answer “what did that feature cost us”.

“Sixty-one per cent of the week” is a starting point. The useful answer connects that spend to the work still ahead. The key has a screen of its own, answering five different questions. Exactly one matters on a Thursday: will the remainder last until Monday.

And the last question of the same bookkeeping, the most uncomfortable one: what, in fact, came out of the money.

A separate screen answers one specific question about each request: what is the context you pay for on every single request actually made of?

The MCP inspector lives there too. Every connected server puts its tool schemas into the system prompt of every request. The panel shows what each one costs in tokens and lets you clear the checkbox. The next session uses the set of servers you have selected.

And the machine itself

The machine has its own capacity to watch alongside the key. The agent works on a real computer, whose capacity can fill before the subscription does. Disk, memory and cores can all be busy with earlier work. A build failure mid-turn can reveal that load. Showing the capacity while work runs gives an earlier signal.

So three numbers sit right in the head of the project list: all-core load as a percentage, available memory, available disk. They form a line your eye trips over while looking for a task. When one of the three runs low the number goes yellow, then red.

The principle is the same as with money. A tool that reports somebody else’s spending in detail and stays quiet about its own earns trust by giving the same account of its own resource use.

What it weighs

That is the second question people ask, right after “what is this thing”. An environment that lives on a machine around the clock owes that machine an account. The numbers below are measured and written by the same counter that draws the cards above, one probe a minute.

Read it like this. The panel itself has a small memory footprint: forty-seven megabytes idle, eighty-five averaged over a day, seventy-three at the median. Most memory use comes from the local speech recognition, speech synthesis and translation engines. They keep models in memory to answer in fractions of a second, keeping pace with dictation. Their four hundred megabytes are the price of dictation staying inside the building.

The peaks look worse: at maximum the family held eight gigabytes. That peak belongs to agents and their MCP servers, raised for a particular turn: they appear when you ask for work and they leave with it. Those processes leave when their turn finishes, keeping their lifetime tied to the work. And on the chart that memory shows up as exactly what it is, a line separate from the panel.

The last figure is the counter-intuitive one. Thirteen connected MCP servers weigh 41.7k tokens of tool descriptions, and for years that was taken as a tax on every request: the more servers connected, the dearer every turn. We measured it. In the window they come to zero. The current CLI defers the schemas: only the names travel in the prompt, and the full description loads when the model actually reaches for a tool. Skills work the same way: a name and one line, the body read when needed. A spare server adds a name to the search list. Its full schema loads when the agent reaches for that tool.

This paragraph is precisely what the context breakdown exists for. Until the numbers are drawn, tool choices rest on habit. Half of what people habitually disable has zero schema cost in the window. The breakdown shows the paid context too, including costs that tend to escape attention.

The cage

The panel has its own domain behind Cloudflare Access. The owner enters with a one-time code by email. The server then verifies a signed token on every request, making authentication part of its own checks.

Everything above means a process on your machine executing arbitrary code in your name. So half the work on the panel is permissions and safeguards around those actions.

• The server listens on the loopback only. Exactly one tunnel connector reaches it from outside, making that connector the defined route into the server.
• A second person lives in a sandbox. Owner and colleague are separate roles. A colleague sees the folders authorised for that role. Row signing and display enforce those permissions, including explicit requests for other rows.
• One door outward. A guest of the panel is allowed exactly one outgoing action (send an email through our own CRM, with a limit and a notification to the owner). Publishing, deploying and git push stay under owner control.
• Secrets stay inside the process. Values from .env are read in the server’s memory. Only key names travel to the browser, and the config editor hands values back masked. A test of its own runs a live turn with a canary in it and fails if the canary leaks anywhere.
• The panel schedules its own restart around active work. The panel goes down for new code only after all active turns finish, and it warns beforehand: with a “later” button.

Forty-odd automatic checks run this before every “done”: the queue, the restart, row separation, secret leakage, recovery after a crash, behaviour on a phone. Each of them appeared after something broke quietly.

What else is inside

Briefly, the smaller features you feel throughout the work, each with its own place in the panel:

• Several subscriptions at once: each lane can have its own, with separate settings homes. Work on other keys continues when one key reaches its limit.
• A turn diagram: agent lanes on a timeline, the orchestration graph, and a map of where the attention went, by file.
• A turn that trips over an API error keeps its place: it parks and re-sends itself until it gets through.
• A crash is survivable. A process killed mid-turn comes back, sees the unclosed turn in the journal and carries on by itself.
• Ten themes with an automatic day / evening / night schedule, and the panel installs on a phone as an app.
• A Telegram bridge: a guest writes into the chat, the message becomes a task in the bound row, the answer goes back.
• The panel refreshes its own tab between turns, after the active work in that tab finishes.
• A first run with a tour that hands control back the moment you touch anything.
• Its own hearing, its own voice and its own translator: speech recognition, synthesis and translation run on engines on this same machine. The cloud comes in only when the local engine needs support for the request.
• The panel says when the connection is gone. A shade over the view explains the reason and shows what the panel is doing to reconnect.
• The panel picks itself up: an independent watchdog outside the panel notices the silence and opens a repair session. The repair only counts once the panel has answered three times running that it is alive.
• GitHub sync per project, by a checkbox in the project menu and only where you put it.

The usual way, and this way

The code editor keeps its place in the work. The panel works alongside it, and the end of this article returns to that shared setup. On the left is what work with an agent built into a familiar development environment looks like. On the right is the same thing here. Both arrangements support the work. The comparison centres on where the state lives.

The panel has its own job alongside the editor. That division supports the features on the right. Hand-written code stays in the editor, and both programs work with the same folder. That shared setup is what we built the panel for.

What has changed since this was written

The panel is the thing we work in every day, so it keeps moving. Eleven days after this article went up, here is what a reader who opened the demo in September would find different by the end of the month.

• A task can hang under another task. One errand, its own sub-tasks under it, all in the same rail. A piece of work that turns out to be three pieces of work stays one line in the list, and opens into three.
• The strip under the composer is a timeline of the row. It used to be one number. Now it is every turn of the errand, in order, so the whole task history reads at a glance, in order.
• The arrows walk back to what you were reading. ← and → return to the row you left, with the whole list still under it.
• A closed envelope marks a row awaiting your reading, and one button keeps the rail to what moved recently. The order of the rows follows their own tick: when a row was created, or when it last changed.
• A server hiccup is told apart from a key problem. An outage used to mark the key in use as the cause. The panel now names the actual fault. After two faults it reaches for the next key automatically.
• Every turn leaves a written report, in two languages. The outcome of the whole errand, from the first message to the last minute, lands as one page on the project’s own shelf: written in English and again in Russian, inside the same file, with a switch in the corner.
• A turn earns its done state when its own checks pass. The panel asks the project which checks guard the files the turn touched, runs them, and holds the turn open until they pass. What used to be a review after the fact is now a gate in front of it.
• An address a turn creates is pinned to its project. A live host, a deployed service, a dashboard: it goes on the project’s own shelf the same turn, where it is still there a week later.

The public demo shows the room as it was captured, so the newest of these live in the working panel. The tour retains the captured version. The shape is the part that is worth looking at.

Where the edges of it are

It is your own machine, end to end. The agent runs there, your code stays there, and the panel is a window onto it. The price of that is a machine that stays on.

It is an instrument panel for your decisions. It makes the agent visible and countable, and the decisions stay yours. You simply make them now knowing the price.

If it comes down to one thing, it is this. You stop watching the key, the spend and the tokens. The environment does that. And you start watching projects, of which one person can now have eight, growing from one, because for the first time all of them are visible at once, and it is immediately clear which one is waiting for you.

We built this for ourselves, using the same approach we take with clients. We put a process that is hard to monitor on one screen. Its cost appears beside each decision as the work happens, ahead of next month’s invoice. The other thing we built that way is open too: a dashboard over Xero and MYOB, ranked by the dollars at stake. Bringing the systems you run into a shared flow is the joining-up work. Bringing scattered knowledge together calls for a corporate knowledge base. This site is our own case study too: how it was built and what it runs on.