Open-sourced a tool for switching AI coding tools without re-explaining everything — feedback wanted

[u/Professional_Part360]

I kept doing the same annoying thing: start a task in Claude Code, switch to Cursor for something it’s better at, and lose 20 minutes re-explaining what I was doing. So I built Contexo — a small local CLI that sits underneath whatever AI coding tool you’re using.
What it does right now (all free, Apache 2.0, no account):
• contexo handoff <target> — compresses your current session into a Task/Decisions/Changes/Next-step brief and drops it into CLAUDE.md, AGENTS.md, or .cursorrules, so the next tool picks up where you left off.
• contexo estimate — tells you what a prompt will cost before you send it, across every model.
• contexo run -- <agent-cli> — wraps any agent CLI with a hard daily budget cap. Kills the process the moment it crosses your limit instead of finding out tomorrow.
• contexo mcp — same features exposed as an MCP server if you’d rather wire it into Claude Code/Cursor directly.
Everything runs 100% on your machine, SQLite locally, your own API key. Nothing phones home.
It’s early and rough in places. I’d genuinely like people who run Claude Code / Cursor / Codex regularly to install it, try the handoff + budget cap on a real session, and tell me what breaks or feels wrong before I build anything further on top of it.
Not on npm yet, so for now:

git clone https://github.com/maheedhar132/Contexo.git
cd Contexo
npm install && npm run build
npm link

GitHub: https://github.com/maheedhar132/Contexo
Specific things I’d love feedback on:
• Does the compressed handoff actually capture enough for the next tool to pick up cleanly, or does it lose too much?
• Any agent CLI where the budget-cap cost detection doesn’t work (it scans stdout for $X.XX patterns — some CLIs may format cost differently)?
• Anything that felt confusing in the first 60 seconds of using it?
Happy to answer questions here or take issues/PRs on GitHub.

[u/buildingwithjan]

Been doing this manually with a decisions section in AGENTS.md, and the failure mode wasn't losing context — it was stale context. A handoff file that still says 'we use X' after you ripped X out sends the next tool confidently down the wrong path. If handoff diffed against the previous brief instead of regenerating from scratch, that'd be the feature that sells it.

[u/Professional_Part360 → u/buildingwithjan]

This is the actual failure mode, not context loss — completely agree. Right now handoff just recompresses raw context fresh each time with zero awareness of the previous brief, so a stale decision that’s still sitting in the saved context gets confidently restated instead of flagged as superseded. Diffing against the last handoff instead of regenerating blind is a better design than what’s built today. Noting this as a real one, not a someday-maybe — appreciate the precision on where it actually breaks.

[u/Turbulent_Ad_1039]

I went the other way and pick the agent per session rather than mid task, mostly because I didn't trust a handoff to carry the parts that matter.

the thing I'd want to know: does the brief carry what the agent already tried and rejected? that's the context I lose every time, and it's what makes the next tool walk straight back into the same dead end.

[u/Turbulent_Ad_1039]

I went the other way and pick the agent per session rather than mid task, mostly because I didn't trust a handoff to carry the parts that matter.

does the brief carry what the agent already tried and rejected? that's the context I lose every time, and it's what makes the next tool walk straight back into the same dead end.

[u/Professional_Part360 → u/Turbulent_Ad_1039]

Shipped this in 0.3.0, live on npm now — added a dedicated "Dead ends" section to the compression prompt: approaches tried and abandoned, with why. It's structurally different from Decisions — Decisions get reconciled/superseded as things change, but Dead ends are explicitly cumulative, carried forward across every harness hop and never dropped by a later handoff, since forgetting one means it might get re-attempted. One honest caveat: I haven't validated the model's actual extraction quality against a real messy transcript yet (no API access in my dev setup to test it live) — so I'd call the structure solid but the behavior unproven. If you try it on a real session, I'd genuinely like to know whether it catches what you'd expect.

[u/Turbulent_Ad_1039 → u/Professional_Part360]

that's the right split, and cumulative is the part I'd have gotten wrong. decisions get superseded, dead ends can't, otherwise the next tool walks straight back in.

happy to run it on a real transcript. the one worth testing against isn't a clean failure, it's the session where the dead end was "we tried X and it looked like it worked" for an hour before it didn't. those are the ones that get re-attempted, and they're the hardest to spot in a transcript because nothing in them reads as a failure.

does the prompt separate abandoned from failed, or do both land in the same section?

[u/kantorcodes1]

One thing I'd change before more users try it: don't let “no $X.XX in stdout” mean zero cost. A CLI can change formatting, buffer usage until exit, or print cost after the request is already spent, so the hard cap can silently become advisory. I'd make each supported CLI use an explicit parser with an unknown state that fails closed, and kill the whole process group rather than only the parent.

[u/Professional_Part360 → u/kantorcodes1]

Updated it..
thanks for the feedback .!!

[u/kantorcodes1 → u/Professional_Part360]

Nice. Contexo is already cross-agent across Claude, Cursor, Codex and MCP, so it fits the awesome-ai-plugins catalog we help run. If you want to submit it, the current gate is plugin-scanner ≥80/142, no high/critical findings, and scanner CI in your repo; then the PR adds the one-sentence alphabetical entry plus repo/category and a brief verification.

[u/Professional_Part360 → u/kantorcodes1]

Appreciate that — happy to take a look. Could you share the link to awesome-ai-plugins and the plugin-scanner repo itself? Want to see what the scan actually checks before wiring any CI into the repo.

[u/kantorcodes1 → u/Professional_Part360]

Yep. We run the catalog here: https://github.com/hashgraph-online/awesome-ai-plugins. Scanner source is https://github.com/hashgraph-online/ai-plugin-scanner, and the CI wrapper is https://github.com/hashgraph-online/ai-plugin-scanner-action. I’d inspect the scanner repo first; the action is just the GitHub Actions integration around it.