omp packages

omp-hub-cli0.1.1

Manage omp (oh-my-pi) coding agent profiles (provider, model, token, base URL)

sherocktong Published 1 month ago MIT ~355 downloads/mo

Built for omp

The author tagged this package oh-my-pi.

Did it work for you?

Result

One report per person. A new report replaces your old one.

Reports 0

No reports yet.

Readme

omp-hub-cli

Manage omp ("oh my pi") coding agent profiles: provider, model(s), thinking level, API token, and base URL — switched at launch, exactly like pi-hub does for pi and cc-hub does for Claude Code.

Install

npm install -g omp-hub-cli
# or from source:
npm link

Requires the omp CLI on your PATH (see https://omp.sh) and Node.js >= 18.

Quick start

# Add a profile (provider id from `omp` — e.g. kimi-code, anthropic, openai)
omp-hub profile add work -p anthropic -m claude-sonnet-4-6 -t "$ANTHROPIC_API_KEY" --thinking high

# Kimi Code subscription: provider kimi-code, model k3, no URL needed
# (omp-hub passes the token via omp's --api-key flag; env vars don't work there)
omp-hub profile add kimi -p kimi-code -m k3 -t "$KIMI_TOKEN"
# Multiple models (max 3): the first is the default
omp-hub profile add oss -p anthropic -m claude-sonnet-4-6 -m claude-haiku-4-5 -t "$ANTHROPIC_API_KEY"

# A profile pointing at a custom base URL (works for ANY provider)
omp-hub profile add px -p kimi -m kimi-k2.7-code -t "$TOKEN" -u https://proxy.example.com/coding

# Make it the default
omp-hub use work          # or: omp-hub profile default work

# Launch omp with a profile
omp-hub run work
omp-hub run               # default profile
omp-hub run work -p "explain this repo"   # extra args pass through to omp
omp-hub run --built-in    # plain omp with your existing ~/.omp/agent config

How it works

omp has no --base-url flag, and most providers (e.g. kimi) have no *_BASE_URL env var. So instead of a flag, omp-hub run:

  1. Materializes an isolated omp config dir at ~/.omp/omp-hub/profiles/<name>/:
    • config.yml — your current ~/.omp/agent/config.yml with defaultProvider / defaultModel / defaultThinkingLevel overridden by the profile (a legacy settings.json is used as the source if you migrated from pi)
    • models.yml — providers.<provider>.baseUrl override (only when the profile has a URL; this is omp's documented mechanism and works even for built-in providers)
    • symlinks to your shared extensions/, skills/, plugins/, sessions/, AGENTS.md
  2. Injects the profile's API token for the effective provider — either as <PROVIDER>_API_KEY (e.g. ANTHROPIC_API_KEY, KIMI_API_KEY; unknown providers get the normalized <PROVIDER>_API_KEY form), or, for OAuth-first providers that ignore env vars (kimi-code), as omp's --api-key <token> --model <model> launch flags. omp v18 stores credentials in the agent dir's agent.db, which a fresh profile dir doesn't have — so env-var keys are honoured.
  3. Launches omp with PI_CODING_AGENT_DIR pointing at that dir. omp's built-in --profile / OMP_PROFILE / PI_PROFILE mechanisms are stripped from the child env so they can't fight the hub-managed isolation.

Consequences:

  • Sessions stay shared — everything omp writes to sessions/ lands in your real ~/.omp/agent/sessions/, whichever profile you run.
  • Extensions/skills stay live — they're symlinks, not copies, and are refreshed on every run.
  • No credential shadowing — each profile dir has its own (initially empty) credential store, so the injected profile token is the only auth source. If you run omp /login inside a profile session, that profile keeps its own logged-in credentials afterwards.
  • omp-hub run --built-in (or default = __builtin__) unsets PI_CODING_AGENT_DIR and runs plain omp against your existing config — zero interference.

Note: omp-hub profiles are independent of omp's own built-in --profile feature (which stores state under ~/.omp/profiles/). omp-hub uses its own layout under ~/.omp/omp-hub/ and never touches native profile dirs.

Commands

omp-hub profile

Subcommand Description
add <name> Add or update a profile. Options: -p/--provider, -m/--model (repeatable, max 3), -t/--token, -u/--url, --thinking, --set key=value (repeatable), --unset key (repeatable)
update <name> Update an existing profile. Same options plus -d/--delete-model (repeatable)
list Table of profiles (* marks the default; tokens masked)
view <name> Full details, token unmasked. -j/--json for machine output
remove <name> Remove profile + its materialized dir
rename <old> <new> Rename profile + its materialized dir
default [name] Set default profile (--built-in for your existing omp config)

Thinking levels: off | minimal | low | medium | high | xhigh | max | auto.

omp-hub use [name] [--built-in]

Alias for omp-hub profile default.

omp-hub run [name] [args...]

Launches omp. The first argument matching a profile name selects it; otherwise the default profile is used and all argument pass through to omp.

Profiles file

~/.omp/profiles.json (mode 0600):

{
  "profiles": {
    "work": {
      "provider": "kimi-code",
      "model": "kimi-for-coding",
      "models": ["kimi-for-coding"],
      "thinking": "high",
      "token": "sk-...",
      "url": "https://proxy.example.com/coding",
      "settings": {
        "theme": "dark",
        "someGlobalHook": null
      }
    }
  },
  "default": "work"
}

"default": "__builtin__" means "no profile — run plain omp".

Per-profile config overrides

A profile's config.yml starts as a copy of your source ~/.omp/agent/config.yml at first materialization. On later runs the profile's existing config.yml wins over a fresh source read for every key it already has — that's deliberate: omp persists runtime state there (theme, modelThinkingLevels, …) and it must survive re-materialization. Consequences:

  • Source edits to keys a profile already has do not propagate; brand-new source keys do. To re-sync a profile with the source, delete its dir (rm -rf ~/.omp/omp-hub/profiles/<name>) — it re-materializes on the next run.
  • To change a profile's settings, use --set/--unset (or the settings key in profiles.json) — these re-apply on every run and beat the profile's stored copy:
omp-hub profile update work --set theme=dark --set 'maxTokens=8192' --set someGlobalHook=null
  • Values are parsed as JSON when possible (true, 8192, "quoted", {...}), otherwise kept as strings.
  • Merged shallowly over the source agent config; the provider/model/thinking fields still win for their own keys.
  • A null value deletes the key from the materialized config.yml — the way to drop a global setting for one profile.

Config path overrides

Path Default Env override
Profiles file ~/.omp/profiles.json OMP_HUB_PROFILES_FILE
omp dir ~/.omp OMP_HUB_OMP_DIR
Source agent dir ~/.omp/agent PI_CODING_AGENT_DIR (same variable omp itself uses)
omp-hub state ~/.omp/omp-hub/ OMP_HUB_DIR

Shell completion

omp-hub completion zsh > "${fpath[1]}/_omp-hub"   # zsh
omp-hub completion bash > /etc/bash_completion.d/omp-hub   # bash

Logging

Logs go to ~/.omp/omp-hub/logs/omp-hub-YYYY-MM-DD.log. Default level is INFO; pass --verbose or set OMP_HUB_LOG_LEVEL=DEBUG.

Development

npm install
npm test          # vitest (unit + integration, incl. fake-omp runner tests)
npm run build     # tsup → dist/index.js
npm link          # install locally

A bundled omp skill for natural-language profile management lives in skills/omp-hub/SKILL.md.

License

MIT