Your coding agent is paying tokens for menus: a look at only-cli (oc)

I run a lot of coding agents across my products. When usage limits get tight, the first question I ask is where the tokens are actually going. A video from AI LABS, This Finally Cut Claude Code's Token Usage In Half, answered a piece of that I hadn't looked at closely: web pages.

All numbers below come from their video. I haven't benchmarked this on my own setup yet.

Where the tokens go

When Claude Code reads a page with its built-in web tool, it doesn't just get the article. It gets the page converted from all its markup, menus included.

They tested it on Wikipedia's article on large language models. That page is about 1 MB of page code, which becomes roughly 295,000 characters, or about 74,000 tokens. That's too much to read at once, so:

• The first 13% is read word for word. On that page, it's mostly menus and the list of languages.
• The next 34% goes to a smaller model (Haiku) and comes back as a summary.
• The last 53% is never read.

So most of the actual article reaches Claude only as a summary. And everything it did read, menus included, stays in the session's context for every message after that. In a research task that hits a dozen sites, that adds up fast.

What oc does differently

only-cli (oc) is a free, open-source CLI that agents use instead of the built-in web tool. It works with Claude Code, Codex and Cursor.

Instead of handing over the whole page, oc returns a numbered outline of about 500 tokens. The agent picks the section it needs and reads only that, as clean text. If a page is barely longer than its outline, oc just returns the whole thing, because another step would cost more than it saves. Every response ends with a short line listing the next moves, so the agent doesn't have to remember the commands.

A few other things stood out:

• It has shortcuts for about two dozen research sites, like Hacker News, GitHub, Wikipedia and Stack Overflow.
• It can read pages behind your login if you give it that site's cookies once.
• In their test, npm and Stack Overflow refused Claude's own web tool. oc got through both, using a public feed for Stack Overflow.

Two cautions before you roll it out. Giving any CLI your session cookies means trusting it with that account, so keep it to low-risk sites. And oc gets past some blocks by looking like a real browser, so check a site's terms first. Its README also says to treat fetched page text as data, never as instructions, which is the right default for any agent reading the open web.

Where it doesn't help

Sites that publish an llms.txt file already give agents a plain-text copy, and Claude's own tool goes straight to it. When they pointed Claude's tool at the Claude Code docs, it read the docs' own text directly, so on llms.txt sites Claude's tool is the better choice. The savings show up on the many sites that don't have one.

The test

They asked an agent to research all 28 posts on Anthropic's engineering blog, split across five sub-agents, then ran the same prompt without oc.

Without oc, the run used about 4.9 million tokens. With oc, about 3.9 million, roughly a 21% cut, with the same accuracy. The bigger difference for me: with oc, the agents read every post's actual text themselves, so every answer in the report came straight from the posts themselves.

Setup

Install it from the GitHub repo, then add the line from its README to your CLAUDE.md or AGENTS.md so the agent uses oc instead of its own web tool. There's also a skill you can install for your agents, or a plugin if you use Claude Code.

Why I care

When you run many agents in parallel, small waste per fetch turns into real usage across a day. Cutting it is one of the easiest ways to stretch limits without slowing anyone down. And getting the full text instead of a summary is a quality win, not just a cost one.

I'm adding oc to my agent setup next and will share what it does on real work.