OcHub’s core workflow is simple: choose an AI tool, then decide whether it should connect directly to a provider or go through OcHub’s local gateway. On your first run, complete only one of these paths.
Best for a first setup or one endpoint per tool
Tool writes provider settings directly
Best for shared upstreams, mapping, conversion, and fallback
Requests pass through the local OcHub gateway
What success looks like
Your first setup is complete when all three statements are true:
- The target app page shows the intended connection as Current.
- A newly opened CLI process can send one real request successfully.
- You know how to switch back to official login or the previous connection.
Do not configure MCP, skills, pricing, sync, or routing rules until this small loop works.
Before you begin
- Quit cc-switch so the two apps do not write the same tool configuration at the same time.
- Back up the target tool’s configuration directory, such as
~/.claudeor~/.codex. - Have the API endpoint and key you intend to use ready. You do not need a third-party key when using the tool’s own official login.
If you have used cc-switch for a while, read the migration guide before deciding whether to import from the first-launch prompt.
First launch
-
Review the welcome notice. Read the configuration-write explanation. If OcHub detects cc-switch, it lists the connections, MCP servers, and skill repositories available to import.
-
Decide whether to migrate. Import and start reads cc-switch data. Skip does not delete or modify cc-switch, and you can import later from Settings → Data and backups.
-
Choose the apps to manage. In Settings → Apps and plugins, keep only the tools you need. Disabling an app removes it from the sidebar and system menu without deleting its data or changing its configuration files.
-
Open an app page. Under Apps in the sidebar, choose Claude Code, Codex, Cherry Studio, Grok Build, Kimi Code, OpenCode, OpenClaw, Hermes, or Claude Desktop.
The main areas
| Area | Purpose |
|---|---|
| Apps | Manage direct connections and app-specific settings |
| MCP servers | Store MCP configuration once and sync it to supported tools |
| Skills | Discover, install, update, and distribute reusable skills |
| Usage | Inspect tokens, cost, cache, latency, and individual requests |
| Sessions | Browse local CLI conversation history |
| Advanced tools | Maintain CLIs, backups, environment variables, and app-specific files |
| Model providers | Manage local-gateway upstreams, model mapping, and fallback |
| Theme / Settings | Control appearance, app behavior, data, and remote sync |
Choose a connection method
| Goal | Recommended method |
|---|---|
| Configure one API endpoint for one tool | Direct connection |
| Keep using the tool’s own account login | Official login under Direct connections |
| Share one upstream across multiple tools | Model provider |
| Rename models, convert protocols, or switch to a backup upstream | Model provider |
For a first setup, start with a direct connection. Once the target CLI can make a real request, add MCP servers, skills, or more advanced routing rules.