A web UI (user interface) and a CLI (command-line interface) can sit on the exact same data. To a human, the choice between them is a matter of preference. To an AI agent, it's the difference between a task that costs a few thousand tokens and one that costs a few hundred thousand.

This isn't a small optimization. The interface an agent uses is usually the single largest lever on what an agentic workflow costs, how fast it runs, and how often it breaks. Here's why, and where all those tokens actually go.

The same task, two very different bills

Take one ordinary question: "Which 10 customers have the highest outstanding balance?"

A person answers it in a browser without thinking: open the app, click into the customer list, sort by balance, read the top of the screen. Fast, obvious, zero code.

An agent can do the same thing, but "the same thing" means something completely different when the user is a language model. The agent doesn't see a screen the way you do. It has to be fed the screen in tokens on every single step. Plus, a screen is an extraordinarily expensive thing to describe in tokens.

The CLI version of that question is one line of text in and a few lines of JSON out. That gap between describing a screen and exchanging text is the whole story.

Where the tokens go in a web UI

When an agent "uses" a web application, it's driving a browser through a tool like Playwright or a computer-use harness. Every turn, it needs to know what's on the page, and there are only two ways to tell it. Both are expensive.

• Screenshots. Vision models price images by area. With Anthropic's models the estimate is roughly (width × height) / 750 tokens, so a single ~1280×800 screenshot is about 1,300–1,600 tokens. That's just one frame, carrying no guarantee the data you need is even visible in it.
• Accessibility / DOM snapshots. The text alternative is a structured dump of the page's elements: every button, link, label, list row, and nested container. For a data-heavy page like a populated list view, that snapshot routinely runs 5,000 to 50,000+ tokens, most of it navigation chrome, styling hooks, and layout scaffolding the agent doesn't care about.

Now multiply by reality. A browser task is multi-step: navigate, wait for load, observe, click, wait, observe, sort, observe, scroll, observe. Each observation pulls a fresh screenshot or snapshot, and because the model carries its conversation forward, those bulky observations accumulate in context and get reprocessed turn after turn. A single "simple" lookup can easily span 8–15 turns.

Then add the tax that doesn't show up on the happy path: web UIs are brittle for agents. A modal opens, a selector shifts, a control is below the fold, a spinner hasn't resolved. Every misstep is another observe-reason-retry cycle (more screenshots, more snapshots, more tokens) for a result you haven't gotten yet.

Where the tokens go in a CLI (mostly, they don't)

A CLI collapses all of that into a text exchange:

‍

$ popdock query <list-id> --sort "Balance:desc" --top 10 
[{"CustomerId":62,"Name":"Wilbert Macejkovic","Balance":402.11,"City":"O'Keefemouth"}, …] 

‍

The command the agent composes is around 40 tokens. The response is only the data that was asked for: ten rows of clean JSON, maybe 600–1,500 tokens depending on the fields. No chrome, no layout, no pixels, and no pagination dance. There's nothing on the wire that isn't the answer.

It's also single-shot and deterministic. One process in, structured data out, and an exit code that says plainly whether it worked or not. No waiting for a render, no guessing whether the right row scrolled into view, and no retry loop because a button moved. When discovery is needed, it's the same compact contract: connectors list, lists list, fields list all return small JSON, not screens.

Side by side

For example, imagine asking for the top 10 customers by balance. Treat the numbers as illustrative (your pages and prompts will vary), but the order of magnitude is the point.

That's a 20–50× difference on a single task, and tasks rarely come alone. An agent that answers one question this efficiently can run a whole workflow (pull the accounts, cross-check balances, draft the summary. The browser approach burns your token budget just by finding the list.

It's not only the bill

Tokens are the headline, but everything downstream rides on them:

• Cost scales directly with tokens. A 30× token reduction is roughly a 30× cost reduction on that step.
• Latency tracks token volume. Fewer, smaller payloads and fewer round-trips mean a faster agent.
• Reliability improves because there's nothing to misread. JSON parses the same way every time: a screenshot has to be re-interpreted, and a snapshot can shift under the agent's feet.
• Context budget is finite. Every 50k-token page snapshot is 50k tokens not available for reasoning, history, or the actual task.

Cheaper, faster, and more reliable usually trade off against each other. Here they move together, because they all flow from the same source: how much the agent has to read to act.

The honest caveat

None of this means web UIs are bad. They're visual, discoverable, and forgiving, making them right for humans. The mismatch is specifically between a visual interface and a language model, which has to turn every pixel into tokens before it can think.

There are still cases where driving a browser is the only option: a system with no API, no CLI, and no MCP server, a workflow that genuinely depends on the rendered UI, or a one-off where building a tool surface isn't worth it. When you have to, just go in knowing the token bill, and prefer a real data tool whenever one exists.

The takeaway

When you give an agent a job, you're also choosing how it perceives the world. Point it at a web UI and it pays, in tokens, to re-read the screen on every step. Give it a CLI and it exchanges text: a short command in, the exact answer out.

That's the whole design idea behind the Popdock CLI. Take the data layer PopdockAI already built across dozens of business systems and hand it to an agent as a command, not a screen. It’s the same data a person would click through in the web app, but it takes a fraction of the tokens to reach it.