Skip to content

OmO (oh-my-openagent) agent slots: 23 agent packages for ~/.omo/omo.jsonc - #543

Open
huangchanghuan wants to merge 1 commit into
magpie-community:mainfrom
huangchanghuan:add-omo-agent-slots
Open

huangchanghuan wants to merge 1 commit into
magpie-community:mainfrom
huangchanghuan:add-omo-agent-slots

Conversation

@huangchanghuan

Copy link
Copy Markdown

What

23 agent packages for oh-my-openagent (OmO), one per model slot in ~/.omo/omo.jsonc's top-level agents/categories (13 agents + 10 categories). Each package is a minimal agent declaration — no connect, no network — so on magpie's Agents page every OmO agent/category gets its own row and its own model picker, and magpie writes the slot directly:

export const agent = {
  id: "omo-sisyphus",
  name: "OmO · Sisyphus",
  config: "~/.omo/omo.jsonc",
  model: "agents.sisyphus.model",
}

Why one package per slot

magpie's built-in OmO row only writes the global default (~/.omo/agent/settings.json), but OmO's per-agent and per-category assignments live in omo.jsonc. A magpie agent plugin carries exactly one model slot (the agent declaration has no multi-slot field — the multi-tier UI magpie's built-in Claude rows have is hardcoded, not pluggable), so each slot has to be its own package. Verified against magpie 0.1.x: picking a model on the row writes the top-level key, picking default restores, and OmO (both harnesses) resolves the top-level agents/categories keys (checked with omo doctor --models before/after).

Users who want a whole-set switch can script it; my install tooling (migration + plan presets) lives at huangchanghuan/magpie-omo.

Notes

  • Entries are appended to registry.json after the other agent packages, and the Agents section of the README gets a note plus one row per package (23 rows — happy to compress to a single line linking a list if preferred).
  • Happy to restructure per maintainer preference (e.g. fewer packages covering only the most-used slots), though any split must keep one slot per package for the reason above.
  • Sandbox-tested: magpie plugin add ./packages/omo-sisyphus loads the row, and model picks write agents.sisyphus.model correctly in a sandbox HOME.

@yetone yetone left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. I checked the slot names and the file against OmO's source (dev @ df6524a, docs/reference/omo-json.md, packages/omo-config-core, packages/senpi-task). OmO reads ~/.omo/omo.jsonc on every OS, the file can be JSONC, and the top-level agents.<name>.model / categories.<name>.model keys are real. All 10 category names, and the agent names for each harness, are right too. Then I ran it. As written, though, every slot points OmO at a model it can't use, so I can't merge it yet.

Blocking: the model value needs prefix: "magpie/".

magpie writes d.Prefix + ref to the model key (internal/agent/plugged.go:303), and ref is magpie's own provider/model, for example claude-max/claude-opus-4-5. OmO cuts a model string at its first / (parseModel in senpi-task/src/category/registry-models.ts and in agents/agent-model-registry.ts). So it reads claude-max as the provider, and OmO has no provider by that name. The provider magpie registers in OmO is magpie, through ~/.omo/agent/models.json (built-in OmO row) or opencode.json (OpenCode row). The value OmO needs is magpie/claude-max/claude-opus-4-5. packages/kilo does the same thing with prefix: "magpie/".

Real run: I installed omo-ai 5.1.51 (senpi 2026.10.27-1) in a sandbox HOME. I gave it a ~/.omo/agent/models.json with a magpie provider holding claude-max/claude-opus-4-5, plus an omo.jsonc that has comments and trailing commas. Then I ran omo doctor --models:

quick: unavailable (claude-max/claude-opus-4-5 is not usable)          <- what this PR writes
  1. claude-max/claude-opus-4-5   omo.json   no login
writing: magpie/claude-max/claude-opus-4-5
  1. magpie/claude-max/claude-opus-4-5   omo.json   runs first        <- with prefix magpie/
explore: unavailable (claude-max/claude-opus-4-5 is not usable)
librarian: magpie/claude-max/claude-opus-4-5   runs first

To fix it, add prefix: "magpie/" to all 23 *.agent.js, and have each test check the prefix too.

Please also say what the slots depend on. These packages have no connect, so nothing they install writes the magpie provider. The slot only works while magpie's built-in OmO row (Native) or OpenCode row (the OpenCode harness) is switched to magpie. Please put that in each notice and in the README line, for example: "needs magpie's OmO row on magpie, which registers the magpie provider". If that row is off, OmO reports the slot as "no login".

On the shape (23 packages). You're right that one plugin can't do this today: agentplug.Compile reads one agent export with one model key. But 23 market rows for one tool is a lot. On magpie's side, the better long-term home is per-slot fields on the built-in OmO row, the way the Claude rows have tiers. If that lands, these packages become redundant. For now, a small set covering the most-used slots would also be fine, if you'd rather. Your call. The prefix fix is the only thing that blocks.

What I ran at 4baee2d: HOME=$(mktemp -d) bun test (4019 pass, 0 fail) and bun scripts/check.mjs (ok; it skips agent packages). magpie's JSON editor keeps comments and trailing commas in omo.jsonc (internal/edit/json.go).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants