GitHub Agentic Workflows shipped four notes in two days. Three of them circle the same problem, and it is not the one most agent tooling optimizes for. Agents are expensive when they look at things, not when they write things.
Start with the one with the best name. PR Sous Chef, featured on September 1, runs on a fifteen-minute schedule against the gh-aw repository itself, with an on-demand /souschef command. Each cycle it fetches the open PR branches under refs/pulls/open/*, reads PR state, checks, and comments, and decides whether a nudge to the Copilot coding agent is warranted. The write-up is direct about what usually happens: most cycles are pure read-only reconnaissance. It runs on the pi engine with openai/gpt-5.4 and it mostly says nothing.
The next day's featured agent, Ponytail Reviewer, is the same instinct with the limits written into the config. Ten review comments maximum per run. One submitted review. COMMENT level only, so it cannot block a merge. min-integrity: approved required on PR content. Diffs come from a shared cache rather than being re-downloaded. It runs copilot/mai-code-1-flash-picker at roughly 3 to 8 AIC per invocation. The design brief is a budget.
Then the Playwright change, which is the thesis in a single config key. The built-in tools.playwright integration is now CLI-only; the compiler rejects mode: mcp and points you at explicit mcp-servers configuration if you need the full server. Part of the reason is attack surface, one npm package instead of a Docker container with its own configuration. The rest is arithmetic. An MCP server advertises itself by loading a schema for every available function into the context window, and Playwright MCP exposes a lot of them. GitHub's framing of the CLI path: "There is no persistent tool schema competing with the rest of the workflow's context for space, which matters for coding agents that also need room to reason about code, tests, and long-running tasks."
You pay for that schema on every turn whether the agent calls a browser tool or not.
Where the tokens actually go
Sonar put numbers on this in a controlled minimal-pair study back in May (arXiv 2605.20049): matched repository pairs differing only in code cleanliness, Claude Code, 660 trials across 33 tasks. Pass rate did not move. What moved was navigation: roughly 34% fewer file revisits and 7 to 8% fewer tokens on the clean side of each pair.
The agent finished either way. It just spent less finding the files. Every one of those reads is an input token, and in a multi-turn loop the same context is carried and paid for again on the next turn.
The output nobody instruments
There is a fourth category of looking that none of this touches, because it does not live in a repo. Builds, dev servers, training runs, migrations, and the agent's own session all produce a stream. The default way an agent watches that stream is to swallow it, which means every line of a noisy webpack build or a chatty test runner becomes input tokens and then stays resident in context for the rest of the run.
Most of that output is not for the model. It is for a person who wants to know whether the thing is still alive.
That is the case shell.online is built for: turn a running command into a browser link, with the process and the PTY staying on your machine. shell --read-only python train.py produces a view-only link where people can watch the stream without typing into it and without a single token being spent on the watching. Read-only sessions still get scrolling, responsive TUI sizing, and latency measurement, so a view-only link is a real terminal rather than a log tail.
A read-only boundary belongs below the UI
The fourth gh-aw note is about isolation rather than cost, but it belongs with the other three. Sandbox security options became runtime profiles: sandbox.agent.legacy-security and sandbox.agent.sudo collapse into one sandbox.agent.runtime key with named profiles, from docker as the default (no sudo, isolated network) up through gvisor and cloud-hypervisor as you trade convenience for a harder boundary. gh aw fix --write migrates existing frontmatter.
The point generalizes. A restriction that lives in the interface is a suggestion. In shell.online the access mode is fixed when the session is created and read-only input is rejected by the Worker, so modifying the page or the WebSocket frames cannot promote a view-only link to an interactive one. Terminal payloads are encrypted on the CLI before they reach the relay, with an AES-256-GCM key derived in the browser through PBKDF2-HMAC-SHA256 at 600,000 iterations. The URL carries a #salt= fragment rather than the password, so the password never rides along in an HTTP or WebSocket request. The trust boundary and its limits are spelled out in the repo's README, including what encryption does not hide: connection IPs, timing, encrypted frame sizes, and lifecycle metadata.
Cheap observation is a network property too
The same split shows up a layer down. When agents observe each other through a centralized API, every status check round-trips through a platform that sits permanently in the data path. Pilot Protocol separates those roles: a rendezvous service handles discovery and NAT traversal, and once two agents find each other, application data flows directly between them over authenticated encrypted UDP tunnels, with the beacon relaying still-encrypted traffic only when hole-punching fails against something like a symmetric NAT. The addressing and trust model are written up in our IETF draft, and every pilotctl command supports --json, which matters for the same reason the Playwright change matters: an agent parsing structured output is not paying to interpret prose. The Go implementation and the CLI surface are in the pilotprotocol repository.
The interesting agent-cost work right now has little to do with better models or shorter prompts. It is about deciding which observations need a model at all. A polling loop that stays quiet, a review agent capped at ten comments, a browser tool that stops renting context space by the turn, a terminal link a person watches instead of a context window. Four versions of the same edit.
Top comments (0)