Hephaestus 5.5 was rewritten as an outcome-first delegation contract in c3fabaaf. The deep category (spawned as sisyphus-junior under gpt-5.5) now receives a matching prose-driven category context lifted from drafts/gpt-5-5/deep.md instead of the legacy gpt-5.4-era threat-frame version.
Selection happens via a new model-aware resolvePromptAppend hook on BuiltinCategoryDefinition. When the resolved category model is gpt-5.5 the new DEEP_CATEGORY_PROMPT_APPEND_GPT_5_5 is used; older models keep the legacy DEEP_CATEGORY_PROMPT_APPEND. User prompt_append remains preserved on top of either base.
Move parseModelString into src/shared so callers can depend on a neutral module instead of reaching into delegate-task internals.
Cross-tool coupling violates module boundaries, and this keeps call-omo-agent plus runtime-fallback from importing through a sibling tool.
Update various modules to use centralized constants from plugin-identity:
- get-local-version/formatter: Use PUBLISHED_PACKAGE_NAME
- run/session-resolver: Use PUBLISHED_PACKAGE_NAME
- background-agent/task-poller: Use PUBLISHED_PACKAGE_NAME
- mcp-oauth/provider: Use PUBLISHED_PACKAGE_NAME
- auto-update-checker/constants: Use ACCEPTED_PACKAGE_NAMES
- comment-checker/downloader: Use PUBLISHED_PACKAGE_NAME
- legacy-plugin-toast/hook: Use PLUGIN_NAME
- shared/data-path: Use CACHE_DIR_NAME
- shared/external-plugin-detector: Use ACCEPTED_PACKAGE_NAMES
- shared/logger: Use LOG_FILENAME
- tools/ast-grep/downloader: Use PUBLISHED_PACKAGE_NAME
- tools/call-omo-agent/tools: Use PUBLISHED_PACKAGE_NAME
- tools/delegate-task/category-resolver: Use PUBLISHED_PACKAGE_NAME
- tools/grep/constants: Use PUBLISHED_PACKAGE_NAME
- tools/grep/downloader: Use PUBLISHED_PACKAGE_NAME
- tools/lsp/lsp-client-wrapper: Use PUBLISHED_PACKAGE_NAME
🤖 Generated with assistance of OhMyOpenCode
When users configure agents.sisyphus-junior.model, category sessions
should use that model without falling back to hardcoded
AGENT_MODEL_REQUIREMENTS. Two leaks existed:
1. Launch-time: category-resolver.ts did not check overrideModel when
deciding whether to use the hardcoded fallbackChain. Fixed by adding
overrideModel to the suppression condition.
2. Runtime retry: model-fallback hook.ts treated undefined fallbackChain
(from setSessionFallbackChain(id, undefined)) as 'no override' and
fell through to AGENT_MODEL_REQUIREMENTS on session.error/status
retry. Fixed by storing explicit empty array and checking .has()
instead of truthiness.
Tests added:
- hook.test.ts: explicit empty session fallback suppresses agent chain
- event.model-fallback-2941.test.ts: session.error does not arm retry
- category-resolver.test.ts: overrideModel suppresses fallbackChain
- tools.test.ts: sisyphusJuniorModel override assertion
- Remove kimi from auto-detected unstable agents in category-resolver (only gemini/minimax remain)
- Add resolveCallID() to safely resolve callID/callId/call_id variants from tool context
- Use resolveCallID across all 5 delegate task execution paths (sync, background, unstable, continuations)
- Update writing category test to verify kimi runs sync when kimi provider is available
- Add atlas metadata preservation tests confirming tool-execute-after does not clobber metadata
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
When a user configures a custom model for a category (e.g. quick.model),
the hardcoded CATEGORY_MODEL_REQUIREMENTS fallbackChain was overriding it.
This caused the user's model to be ignored and replaced with the default
(e.g. openai/gpt-5.4-mini).
Fix:
- Use userModelOverride directly instead of potentially stale actualModel
- Suppress hardcoded fallbackChain when explicitCategoryModel is provided
- Add regression test verifying user category model takes precedence
Closes#3040
When provider-models cache is cold (first run / cache miss),
resolveModelForDelegateTask returns {skipped: true}. Previously this
caused the subagent resolver to:
1. Ignore the user's explicit model override (e.g. explore.model)
2. Fall through to the hardcoded fallback chain which may contain
model IDs that don't exist in the provider catalog
Now:
- subagent-resolver: if resolution is skipped but user explicitly
configured a model, use it directly
- subagent-resolver: don't assign hardcoded fallback chain on skip
- category-resolver: same — don't leak hardcoded chain on skip
- general-agents: if user model fails resolution, use it as-is
instead of falling back to hardcoded chain first entry
Closes#2820
Add support for object-style entries in fallback_models arrays, enabling
per-model configuration of variant, reasoningEffort, temperature, top_p,
maxTokens, and thinking settings.
- Zod schema for FallbackModelObject with full validation
- normalizeFallbackModels() and flattenToFallbackModelStrings() utilities
- Provider-agnostic model resolution pipeline with fallback chain
- Session prompt params state management
- Fallback chain construction with prefix-match lookup
- Integration across delegate-task, background-agent, and plugin layers
When a category has no CATEGORY_MODEL_REQUIREMENTS entry (e.g.
user-defined categories like solana-re), the !requirement branch
set actualModel but never built categoryModel with variant from
the user config. The bottom fallback then created categoryModel
via parseModelString alone, silently dropping the variant.
Mirror the requirement branch logic: read variant from
userCategories and resolved.config, and build categoryModel
with it.
Fixes#2538
Allow individual categories to be disabled via `disable: true` in
config. Introduce shared `mergeCategories()` utility to centralize
category merging and disabled filtering across all 7 consumption sites.
OpenCode SDK does not expose client.model.list API. This caused the
provider-models cache to always be empty (models: {}), which in turn
caused delegate-task categories with requiresModel (e.g., 'deep',
'artistry') to fail with misleading 'Unknown category' errors.
Changes:
- connected-providers-cache.ts: Extract models from provider.list()
response's .all array instead of calling non-existent client.model.list
- category-resolver.ts: Distinguish between 'unknown category' and
'model not available' errors with clearer error messages
- Add comprehensive tests for both fixes
Bug chain:
client.model?.list is undefined -> empty cache -> isModelAvailable
returns false for requiresModel categories -> null returned from
resolveCategoryConfig -> 'Unknown category' error (wrong message)
- Create available-models.ts for model availability checking
- Create model-selection.ts for category-to-model resolution logic
- Update category-resolver, subagent-resolver, and sync modules to import
from new focused modules instead of monolithic sources
YeonGyu-Kim