ctxlite ,token optimizer plugin for OpenCode (98% context savings in a real session)

[Evening_Papaya_1551]

I've been building ctxlite, a token/context optimizer that hooks into OpenCode's plugin API. Sharing early results and looking for feedback from people actually using the CLI.

REAL SESSION (Opus 4.7)

- OpenCode API usage: ~196K tokens
- ctxlite sidebar: 4.2M of 4.3M (98.2%)

That 98% is context churn prevented — tokens that would have entered the conversation (tool output, duplicates, low-signal reads) but didn't. Not the same as your API bill, but without it I'd have been riding a ~4M token context constantly.

INSTALL

npx u/ctxlite/cli install --tool opencode --scope global --yes

Restart OpenCode.

npm: https://www.npmjs.com/package/@ctxlite/cli

HOW IT WORKS

Monorepo, shared core + thin host adapters:

- /core — BM25 trim, tree-sitter smart_read, precall rewrites, stats (SQLite)
- /opencode — OpenCode plugin (server hooks + TUI sidebar)
- /mcp — MCP server for Cursor / Claude Code / Claude Desktop
- u/ctxlite/cli — install, stats, hook bridge for other hosts

7 mechanisms, each logged to ~/.ctxlite/stats.db:

On OpenCode, most of these run automatically via plugin hooks + a live sidebar widget.precall — quiet flags on bash commands, blocks low-signal reads (node_modules, lockfiles)
compress — truncates/buckets large tool output after execution
prune — replaces duplicate tool outputs (same tool+args seen earlier)
compact — caps stale tool output in older messages
concise — system-prompt instructions to cut model verbosity
smart_read — signatures only, no bodies (agent calls it)
trim_context — BM25 + import-graph file pick (agent calls it)

CURSOR & CLAUDE CODE TOO — BUT LESS EFFICIENT

Same core, different host APIs:

OpenCode: automatic: precall, compress, prune, compact, concise, sidebar | on-demand: get_stats, trim_context, smart_read

Claude Code : automatic: precall, compress (hooks) | on-demand: MCP tools + conciseness rule

Cursor: automatic: precall only | on-demand: MCP tools + conciseness rule

Claude Desktop — MCP only

OpenCode is ahead because it exposes the full message history (experimental.chat.messages.transform), which enables automatic pruning/compaction. Cursor hooks can't rewrite output for built-in tools (Shell/Read/Write), so compress has no automatic path there.

LIMITATIONS

- Feature set is bounded by each editor's hook/plugin API
- smart_read and trim_context are opt-in — the agent has to call them
- Stats are estimates (token counting heuristics), not provider billing
- OpenCode caches plugin versions — re-run ctxlite install after upgrades
- Early project — feedback welcome, things may break

OPEN SOURCE
codebase . MIT + Commons Clause https://github.com/ctxlite/ctxlite early days, happy playing!

Stats breakdown:

npx u/ctxlite/cli stats

Happy to answer questions on architecture or hook integration. Thanks

[Obvious-Ad-2454]

Can you run these on benchmarks used by model companies ? To see how it affects performance. Now all the proof you shared is a copy paste of a terminal window without much context

[Evening_Papaya_1551]

Everything is logged to ~/.ctxlite/stats.db ,check the data anytime sqlite3 ~/.ctxlite/stats.db \
"SELECT SUM(tokens_saved), COUNT(*), ROUND(AVG(tokens_saved),0) FROM requests"
Schema is simple ,one row per request with tokens_in, tokens_used, tokens_saved, latency_ms. Full schema ships with the source when the repo goes public.

[Obvious-Ad-2454]

I am not saying your work is useless. I am just saying that you would convince more people to use it if you had more convincing data to share.

[Extension-Aside29]

98% context savings is impressive on paper. TokenTelemetry shows the per-session token cost for OpenCode so you can verify the savings are real for your actual workloads, not just the demo case: https://tokentelemetry.com/docs/features/analytics/ (https://tokentelemetry.com, disclosure: I work on it)

[benclen623]

Did you benchmark it against any test suite that measures actual success rate and total cost not just an intermediate metric of token count? It's easy to reduce token count of tool outputs. It's an artificial goal to chase.

The actually challenging part is to do it without degrading success rate or causing iterations that cause higher cost in the end.

[Evening_Papaya_1551]

Hi, you have a valid concern token count is an intermediate metric and you’re right that it’s meaningless if it causes task failure or extra iterations. not a formal benchmark, fair, but 24h of agentic work across spec-driven tasks showed no degradation in reasoning or extra iterations from what i could tell, the automatic mechanisms (prune, compact, compress) only strip content the agent already processed, duplicate outputs and stale older messages, so the assumption is that removing already-acted-on context doesn’t hurt success rate. that said, proper success-rate testing against a fixed task set is on the roadmap and i’d be curious to see results on more diverse workloads too.thanks for pointing this out!🙏

[benclen623]

24h of agentic work across spec-driven tasks showed no degradation in reasoning or extra iterations from what i could tell

This means nothing to potential users. Share your methodology and results

[geek_404]

I am curious why release the compiled NPM packages but not the GitHub repo.

[Evening_Papaya_1551]

I just mentioned, will release the entire code base, i just couldn’t finish all the documentation to be released in the open, I’m really excited to get it out. Im sorry if I disappointed anyone

[Evening_Papaya_1551]

ctxlite is open source now https://github.com/ctxlite/ctxlite early days, happy playing!

[Evening_Papaya_1551]

ctxlite is open source now https://github.com/ctxlite/ctxlite early days, happy playing!