hello2cc: a Claude Code plugin that makes third-party models behave more like Opus

A plugin, not a gateway

The README's first technical sentence is the one that decides everything else. hello2cc does not replace your gateway, provider mapping or account setup. It sits in the plugin layer and keeps third-party models closer to Claude Code's native behavior around tool choice, agent routing, task and team workflow, failure handling and response style. The stated goal is to make third-party models inside Claude Code behave closer to a native Opus session. The package description is even more precise: a Claude Code alignment plugin that drives third-party models toward Opus-compatible workflows, tool usage and output style. The audience is therefore defined by what the user already has. The overview says hello2cc is for users who already run GPT, Kimi, DeepSeek, Gemini, Qwen or other third-party models in Claude Code through CCSwitch or a similar mapping layer, and the Best for list adds sessions already connected to third-party models, repositories exposing skills, workflows, MCP resources or plugins, and users who want fewer detours and less prompt-shape sensitivity. The Not for list is equally specific: setting up API keys, providers or model gateways, exposing tools that Claude Code itself did not surface, replacing CCSwitch or another provider-mapping layer, and overriding repository rules such as AGENTS.md, CLAUDE.md or direct user instructions.

Three behaviour layers, one of them fail-closed

The How it works section gives a flowchart and a table of three main behavior layers, and the table is the more informative of the two. The first is host-state guidance, which surfaces tools, agents, workflows, MCP resources and continuity state so the model chooses within the real session boundary. The second is pre and post tool guardrails, which normalize inputs, strip placeholders, record failure memory and keep deterministic checks fail-closed. The third is the native style shell, which keeps replies closer to Claude Code's direct, restrained, execution-first style. The flowchart tells the same story in five steps: a third-party model already connected in Claude Code, Claude Code surfaces tools, agents, skills or MCP, hello2cc adds host-aware routing and protocol guardrails, the model chooses a more native path, and there is less drift in tools, teams, tasks and reply style. Two words in the table are worth pausing on. Host-aware means the plugin reads the actual session state rather than assuming what the model can see, and fail-closed means a deterministic check that cannot be satisfied blocks rather than warns, which is the safer default for a tool that sits between a model and a repository.

Installing it as a local Claude Code plugin

The prerequisites are Node.js 18 or later, Claude Code with plugin support, and a working third-party model mapping layer such as CCSwitch if you are not using native Claude models. Installation is four steps, and step two is the part that is specific to a local clone. You clone the repository:

   git clone https://github.com/hellowind777/hello2cc.git
   cd hello2cc

Then you add the local marketplace entry, replacing the placeholder with your local repository path:

   claude plugins marketplace add "<repo-path>"

Then install and enable the plugin:

   claude plugins install hello2cc@hello2cc-local
   claude plugins enable hello2cc@hello2cc-local

And finally reload Claude Code:

   /reload-plugins

The marketplace name hello2cc-local is what ties the install to your clone rather than to a published listing, which is how you develop against a local copy. To verify, run claude plugins list and check that hello2cc@hello2cc-local is installed and the plugin status is enabled.

Two configuration keys, and what they do not do

The recommended configuration section offers two minimal setups, and the framing matters more than the keys. The minimal configuration is good when your model mapping is already handled elsewhere and you only want hello2cc to align behaviour:

{
  "mirror_session_model": true
}

The stable default agent slot adds a second key, and it is good when you want most spawned agents to use the same Claude slot:

{
  "mirror_session_model": true,
  "default_agent_model": "opus"
}

The values to use for default_agent_model are Claude slot values such as inherit, opus, sonnet or haiku, and the README is careful about a specific trap here. If your real target model is mapped through CCSwitch, keep that mapping in CCSwitch instead of writing third-party aliases into hello2cc. The distinction is the whole design: hello2cc chooses which Claude slot a spawned agent should use, and CCSwitch decides which provider answers for that slot. Two further details are worth noting. The plugin no longer ships a settings.json that force-selects hello2cc:native, and the verification step notes that new sessions no longer rely on such a file.

What 0.5.11 actually changed

The release notes are unusually specific, and they explain a lot about the project's shape. The current release adds two practical fixes and one behaviour tightening pass over the previous public release v0.5.9. The first is in task completion: TaskCompleted and TaskUpdate(status=completed) no longer get hard-blocked just because the description is thin, and the hook now warns without breaking completion-state sync. The second is Claude Code compatibility: the old Task subagent tool name is now treated as an alias of Agent, covering hooks, capability detection, session continuity and real-session regression checks. The third is output discipline, where explanation and comparison prompts are less likely to trigger team or task-board demos, and the native style pushes replies toward concise, direct, low-ceremony wording. The feature list carries the same themes in longer form: native-first routing guidance that keeps the model closer to Claude Code's surfaced capability order instead of falling back to broad keyword-driven choices, agent and team guardrails that distinguish plain workers from real teammate flows and reduce accidental team_name pollution, and response-style tightening that reduces over-planning, forced confirmations, tool theater, meta narration, jargon-heavy phrasing and invitation-style endings. There is also a ccstatusline bridge that backfills status-line usage from transcripts when Claude Code surfaces zeroed usage fields in third-party sessions.

Troubleshooting the three states that confuse people

The Troubleshooting section documents the failure modes a user will actually hit. If the plugin seems inactive, the checks are to reload Claude Code or reopen the session, confirm the plugin is installed and enabled, and, if you updated a local clone, reinstall it cleanly. The second case is stranger: hello2cc:native still shows after a disable or a reload. The explanation is that Claude Code can keep thread-level agent state across resumed sessions, and since current versions no longer ship a plugin-side settings.json that force-selects hello2cc:native, a clean reinstall and a fresh session should stop new unintended injection. The third case is TaskCompleted or TaskUpdate(status=completed) still getting stuck, which the fix for is to upgrade to 0.5.11 or later and reload the plugin, because current versions downgrade thin completion descriptions from a hard block to a warning-first guard so task-board state can still move to completed. A fourth entry covers new Claude Code builds where Agent and Task no longer match, again fixed by upgrading, since hello2cc now treats Task as an alias of Agent across its internal compatibility surface.

A plugin that follows the host it depends on

The structural limitation of this project is the one implied by its whole design. hello2cc does not add capability, it adjusts behaviour inside a host it does not control, and the compatibility surface tracks the host's own renames and semantics. The Task to Agent alias is the clearest example: a Claude Code build that renames a subagent tool breaks plugins that assumed the old name, and the fix here was to alias rather than to depend. The second structural fact is the same one the README states as a boundary, that the plugin does not expose tools Claude Code itself did not surface, so it can shape selection among what is available but cannot widen the set. Third, the repository is a plugin package rather than an application, and the layout shows it: a .claude-plugin directory, agents/, hooks/, output-styles/, scripts/ and tests/ at the root, with package.json carrying no runtime dependencies and a node engine requirement of 18 or later. The test script runs node --test, and there is a separate test:real script pointing at a claude-real-regression script, which is the closest thing to an end-to-end check available. The version history shows the same churn: v0.5.11 on 2026-05-23, v0.5.9 on 2026-04-12 and v0.5.8 the same day, with the last push on 2026-05-23.

Editorial conclusion

hello2cc suits a developer who already runs a non-Anthropic model inside Claude Code through CCSwitch or a similar mapping layer and is frustrated by the model picking the wrong tool, spawning agents that behave like plain workers, or padding replies with preamble. It is the wrong tool if you have not settled the provider mapping yet, because the README states plainly that it does not replace your gateway, provider mapping or account setup, and it is the wrong tool if you want to change the repository's own rules, since it does not override rules such as AGENTS.md, CLAUDE.md or direct user instructions. Verify first that your Claude Code build has plugin support and that the plugin is enabled after install, and note that the last push was on 2026-05-23 with the newest release v0.5.11 from the same day, so the plugin is on a 0.5.x line with patch releases rather than a stable 1.x.

Frequently asked questions

Official sources

1. hellowind777/hello2cc on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases