SKILL

Aurora Model Swap

The Quo orchestrator (Aurora) runs /home/opsadmin/.openclaw/tools/quo-thread-orchestrator/runner.js under aurora-worker.service. It calls Moonshot’s API directly (NOT through Portkey/gateway). The model is controlled by one env var.

Current state

Provider:  Moonshot (api.moonshot.ai, OpenAI-compatible API)
Model:     moonshot-v1-128k         (default)
Env var:   AURORA_MODEL             (master.env, optional override)
API key:   MOONSHOT_API_KEY         (master.env)
Process:   aurora-worker.service    (systemctl --user)
Code:      ~/.openclaw/tools/quo-thread-orchestrator/runner.js   (line ~42)

Specialists (acquisitions, dispo, betterfiles) are a SEPARATE routing path — they go through the OpenClaw gateway → Portkey → Anthropic. This skill does NOT cover specialist swaps.

Swap A — change the Kimi model variant (1 minute)

Use this when training ships a new Kimi variant or you want to A/B test.

1. Edit master.env:

   sed -i 's/^AURORA_MODEL=.*/AURORA_MODEL=kimi-k2-turbo/' /home/opsadmin/.openclaw/master.env
   # If the line doesn't exist, add it:
   grep -q '^AURORA_MODEL=' /home/opsadmin/.openclaw/master.env || \
     echo 'AURORA_MODEL=kimi-k2-turbo' >> /home/opsadmin/.openclaw/master.env

2. Restart the worker (it re-reads master.env on each tick, but restart guarantees the in-flight processes pick it up):

   systemctl --user restart aurora-worker.service

3. Validate the new model is loading:

   journalctl --user -u aurora-worker --since '1 min ago' -o cat | grep '"model":' | head -3

   Should show "model":"kimi-k2-turbo" in run_start events.

Known Moonshot/Kimi model IDs

Model ID	Use for
moonshot-v1-128k	default — proven on Aurora’s tool-calling loop
moonshot-v1-32k	smaller context, cheaper
kimi-k2-turbo	faster output, similar quality
kimi-k2.5	newer revision (verify stable on tool-use before flipping)

Swap B — change provider (Anthropic, OpenAI, etc.) — runner refactor required

The current runner is hardcoded to Moonshot at runner.js:52-54:

const MOONSHOT_API_KEY = process.env.MOONSHOT_API_KEY;
const MOONSHOT_HOST = 'api.moonshot.ai';
const MOONSHOT_PATH = '/v1/chat/completions';

To switch to Anthropic/Portkey, you need:

1. Add a provider abstraction layer in runner.js that reads AURORA_PROVIDER (=moonshot|anthropic|openai)
2. For anthropic: use the Portkey route already configured in agents/aurora/agent/models.json at http://127.0.0.1:18900/aurora — convert the request body from OpenAI chat-completions format to anthropic-messages format
3. Adapt response parsing (OpenAI: choices[0].message; Anthropic: content[] with type=tool_use/type=text)
4. Adapt tool-calling format (OpenAI: tool_calls[]; Anthropic: content[].input for tool_use blocks)

This is ~200 LOC of careful adapter work — not a config change. The aurora-on-anthropic-saturation-2026-04-21 history (memory: project_aurora_quo_live_phase_a) explains why the team moved to Moonshot in the first place.

If you actually need this, scope it as a separate phase and budget 4-8 hours including testing.

Concurrency context (why this matters)

Provider	Concurrent cap
Moonshot/Kimi (current)	~500-10000 RPM, no hard concurrent cap
Anthropic Max plan 20x	3 concurrent, hard cap, returns 502 max_plan_pool_saturated
Anthropic API tier	RPM/TPM rate-limited, no concurrent cap

Aurora was historically blocked by Anthropic Max plan cap=3. Moonshot removes that ceiling. Don’t switch back to Anthropic Max plan without first either (a) upgrading to API tier, (b) raising the Max plan tier, or (c) adding a serialization queue inside Aurora.

Validation after any swap

1. Worker active: systemctl --user is-active aurora-worker.service → active
2. No login/auth errors in logs: journalctl --user -u aurora-worker --since '1 min ago' -o cat | grep -iE 'auth|401|403|api.key' → empty
3. First run_complete succeeds: send one @-mention in Quo, watch:

   journalctl --user -u aurora-worker -f -o cat | grep -E 'run_start|run_complete'

   Should produce run_complete final_state=executed (or awaiting_clarification/awaiting_confirmation) within ~2 min.
4. Reply lands in correct thread: use parent_activity_id-based targeting from post-to-quo.js v2 — verify visually in Quo.

Rollback

Any swap is reverted by changing AURORA_MODEL (or AURORA_PROVIDER once Swap B is implemented) back and restarting:

sed -i 's/^AURORA_MODEL=.*/AURORA_MODEL=moonshot-v1-128k/' /home/opsadmin/.openclaw/master.env
systemctl --user restart aurora-worker.service

No data migration, no code changes for Swap A. Restart is idempotent.

Files referenced

• /home/opsadmin/.openclaw/tools/quo-thread-orchestrator/runner.js — the orchestrator
• /home/opsadmin/.openclaw/master.env — env vars
• /home/opsadmin/.openclaw/agents/aurora/agent/models.json — Portkey config (currently unused by the runner)
• /home/opsadmin/.config/systemd/user/aurora-worker.service — systemd unit

Invokes / Invoked by

Invokes: SKILL, SKILL Invoked by: _summary, _summary