create-agent skill documents per-agent model/thinking config that the runtime silently discards

[Zazzles2908]

The bundled create-agent skill (assets/skills/create-agent/SKILL.md) tells agents to set per-agent model: <provider>/<model> and a thinking: block in agents/<name>/config.yaml ("Add when: The default model is wrong for this role"). In the current runtime this mechanism does not exist:

• @mavis/local-runtime/dist/agent/sqlite-store.js normalizeConfig() keeps only defaultWorkspaceDir from the agent's config file — model and thinking keys are read and silently dropped (no warning logged).
• Resolved model comes exclusively from the session's effectiveModel (UI model picker, set via api/routes/agents.ts) or the global root config.yaml defaultModel; children inherit the session model (local-task-runner.ts).
• Additionally, thinking.effort on custom-provider model entries is not honored: model-resolver.js reads configuredEffort only on the builtin provider.* tree; the BYOK path (model-resolver-byok.js) passes none, so the emitted thinking level is the mode-derived default.

Counter-example that works: per-session model selection via the UI picker, and thinking_config.mode on model entries (verified: switchable toggle emits thinking:{type:enabled/disabled} for DeepSeek via openai-completions.js).

Ask: either implement per-agent model:/thinking: in agent config files (and wire configuredEffort for BYOK custom providers), or correct the create-agent skill docs to point at the session-picker mechanism. Silent dropping of documented config is the dangerous part.

Evidence: config.yaml agent entries containing only defaultWorkspaceDir (verified on 13 agents); runtime source quoted above; version MiniMax Code desktop v3.0.57.

[meesudzu]

Thanks for filing this — the silent-drop behavior is real and I just hit it from a different angle.

Third silent-drop surface: cron jobs

Verified 2026-08-17 on mavis cron help and mavis cron list:

• cron create accepts: agent_name, cron_name, schedule, prompt, timezone, active_hours, session, enabled — no model.
• cron update accepts: cron_id, schedule, prompt, timezone, active_hours, session, enabled — no model.
• agent create / agent update also lack model (consistent with what you found in normalizeConfig).

So even if per-agent model: were honored, there is no way to pin a model for a single cron job specifically.

Concrete use case

I'm running a cron job (blog-poster, hourly) that scrapes HN, dedupes, drafts MDX, and publishes. It's a deterministic 12-15 tool-call workflow optimized for M2.7 lean (~360K tokens/tick vs 3.1M on M3 verbose, per the bundled blog-publisher skill). The skill prompt even opens with LEAN MODE (M2.7, ~12-15 tool calls per tick).

But:

• ~/.minimax/config.yaml has defaultModel: minimax/MiniMax-M3.
• The cron uses the mavis agent (no per-agent override).
• Therefore every tick runs M3, paying ~8x the intended cost.

Suggested fix (additive to your existing ask)

Either:

1. Add model: <provider>/<model> to cron create/cron update schema (highest leverage — most cron jobs are over-provisioned).
2. Add model: to agent config files (your existing ask) so a cron can agent_name: "blog-poster-lean" pointing to a lean agent.

Precedence I'd suggest: cron model > agent model > global defaultModel. Same as the session-picker UI already overrides agent default.

Evidence

$ mavis cron help
  cron create: agent_name, cron_name, schedule, prompt, timezone, active_hours, session, enabled
  cron update: cron_id, schedule, prompt, timezone, active_hours, session, enabled
  (no `model` field in either)

$ mavis agent help
  agent create: name, display_name, system_prompt, persona, description, avatar, default_workspace_dir
  agent update: agent_name, new_name, system_prompt, persona, description, avatar
  (no `model` field in either)

$ grep defaultModel ~/.minimax/config.yaml
  defaultModel: minimax/MiniMax-M3

Environment: MiniMax Code desktop v3.0.57 (same as your report), mavis agent, runany.dev blog workflow.