I haven't. Thanks for the heads up will give it a try!
I use opus to comment on code design quite often though. It became a pattern that I made a skill for me to ask for second opinions https://news.ycombinator.com/item?id=48733092
Would love to hear your feedback if you don't mind!
It was something that was used for token efficiency. Most of the settings and use cases are quite poorly communicated but asking Claude to review the latest release changelog (https://github.com/anthropics/claude-code/blob/main/CHANGELO...) is quite useful. Combined with @"claude-code-guide (agent)" to read it's own docs for settings/configs is super helpful.
The quite useful tool is to use /opusplan along with /codex:rescue (https://github.com/openai/codex-plugin-cc) means you get quite a strongly reviewed plan using native claude + codex without having to implement the mostly useless trust-me-bro plugins and other bs.
/advisor is like the old /opusplan mode but for running tasks not just pre-planning. It can work nicely with Sonnet as the main agent and escalates to Opus as needed.
Advisor-mode has been very helpful indeed, I can now plan with Opus, have Haiku code, and escalate back to Opus for review. It’s a decent flow for Pro subscribers trying to max their usage. But as I’ve said above, sometimes it’s not worth it: Sonnet and Haiku can produce stuff that’s not worth reviewing.
I ran into this exact problem building a MCP server. 85 tools in experimental mode, ~17k tokens just for the tool manifest before any work starts.
The fix I (well Codex actually) landed on was toolset tiers (minimal/authoring/experimental) controlled by env var, plus phase-gating, now tools are registered but ~80% are "not connected" until you call _connect. The effective listed surface stays pretty small.
Lazy loading basically, not a new concept for people here.
FWIW this isn’t new, using a Claude/Max subscription auth token as a general-purpose “API key” has been known (and blocked) for ages. OpenCode basically had to impersonate the official Claude Code client to make that work, and it always felt like a loophole that would get patched eventually.
This is exactly why (when OpenCode and Charm/Crush started diverging) Charm chose not to support “use your Claude subscription” auth and went in a different direction (BYOK / multi-provider / etc). They didn’t want to build a product on top of a fragile, unofficial auth path.
And I think there’s a privacy/policy reason tightening this now too: the recent Claude Code update (2.1-ish) pops a “Help improve Claude” prompt in the terminal. If you turn that ON, retention jumps from 30 days to up to 5 years for new/resumed chats/coding sessions (and data can be used for model improvement). If you keep it OFF, you stay on the default 30-day retention. You can also delete data anytime in settings. That consent + retention toggle is hard to enforce cleanly if you’re not in an official client flow, so it makes sense they’re drawing a harder line.
Yea exactly, I’m surprised people are calling this “drama”. It was from the beginning against the ToS, all the stuff supporting it just reverse engineered what Claude Code is doing and spoof being a client.
I tried something similar few months back and Claude already has restrictions against this in place. You had to very specifically pretend to be real Claude Code (through copying system prompts etc) to get around it, not just a header.
It’s bad that this is against the TOS in the first place, and reeks of anticompetitive behavior. Why does Anthropic care what frontend I use as long as I pay for their model?
https://www.alibabacloud.com/en/campaign/ai-token-plan