How it works

tokenolo is a middleware layer. It is not a new model, and it is not a new workflow. It wraps your coding agent behind a local proxy, removes redundant filler from your own messages, and forwards everything else to the model untouched. Same agent, same commands.

The three steps

1. Run one command. tokenolo wrap claude starts a local proxy on 127.0.0.1 and launches Claude Code pointed at it.
2. Work like you always do. Type prompts, run tools, edit files — nothing about your workflow changes.
3. tokenolo trims filler inline. On the way to the model, the filler in each of your messages is removed — deterministically and removal-only — and everything else is forwarded verbatim. Then it gets out of the way.

Also works with Codex — run tokenolo wrap codex instead.

Before and after

Without tokenolo, your request goes straight to the model as the agent assembled it.

prompt → agent → input → model

tokenolo inserts one local step. The agent still runs; the request still goes to the model under your own key — only the filler in your own messages is removed on the way.

prompt → agent → tokenolo wrap → filler removed → model

The agent, your commands, and everything except your message filler are unchanged.

What it does — and what it doesn't

What it does. Removes redundant filler from your own (user) messages — removal-only, so the text is always a subsequence of what you wrote. Forwards the system prompt, tools, tool output, files, and history verbatim.

What it doesn't do. Doesn't prune context, drop files, trim tool output, summarize history, or restructure your payload. Doesn't swap your model, change your commands, or route anything through a tokenolo server.

Why it's a drop-in

tokenolo works with Claude Code and Codex without rewiring. There's no new model to adopt and no workflow to relearn — it trims filler before the request is sent, then steps aside.

For exactly what gets removed and what's forwarded untouched, see What gets optimized.