Issue Station
Sign In
Tools hereToolbox

hermes - ✅(Solved) Fix delegate_task 404 when delegation model differs from main model on opencode-go/opencode-zen [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#15319•Fetched 2026-04-25 06:22:57
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
EmidomengeEmidomenge
Participants
alt-glitchalt-glitchEmidomengeEmidomenge
Timeline (top)
labeled ×4cross-referenced ×2commented ×1

Root Cause

_resolve_delegation_credentials in tools/delegate_tool.py calls:

runtime = resolve_runtime_provider(requested=configured_provider)

resolve_runtime_provider then computes api_mode using model_cfg.get("default") — the main model, not the delegation model. When the main model is a MiniMax model (minimax-m2.7), this returns anthropic_messages, which causes the trailing /v1 to be stripped from the base URL. The subagent then calls https://opencode.ai/zen/go/messages instead of https://opencode.ai/zen/go/v1/chat/completions → 404.

resolve_runtime_provider already accepts a target_model parameter for exactly this purpose (see its docstring). It just isn't being passed.

Fix Action

Fix

# tools/delegate_tool.py, _resolve_delegation_credentials()
# Before:
runtime = resolve_runtime_provider(requested=configured_provider)
# After:
runtime = resolve_runtime_provider(requested=configured_provider, target_model=configured_model)

PR: #15320

PR fix notes

PR #15320: fix(delegation): pass target_model to resolve_runtime_provider in _resolve_delegation_credentials

Description (problem / solution / changelog)

Problem

When delegation.model differs from model.default on opencode-go or opencode-zen, delegate_task fails with a 404. _resolve_delegation_credentials calls resolve_runtime_provider(requested=configured_provider) without a target_model, so api_mode is computed from model_cfg.get("default") — the main model — instead of the delegation model.

Example: model.default=minimax-m2.7 (→ anthropic_messages) + delegation.model=glm-5.1 (→ chat_completions). The subagent inherits anthropic_messages, /v1 is stripped from the base URL, and the request hits https://opencode.ai/zen/go/messages instead of https://opencode.ai/zen/go/v1/chat/completions → 404.

Fix

resolve_runtime_provider already accepts target_model for this exact purpose (see its docstring: "Callers performing an explicit mid-session model switch should pass the new model here"). The delegation path just wasn't passing it.

# Before
runtime = resolve_runtime_provider(requested=configured_provider)
# After
runtime = resolve_runtime_provider(requested=configured_provider, target_model=configured_model)

Testing

Verified locally with opencode-go, model.default=minimax-m2.7, delegation.model=glm-5.1:

  • Before: api_mode=anthropic_messages, base_url=https://opencode.ai/zen/go → 404
  • After: api_mode=chat_completions, base_url=https://opencode.ai/zen/go/v1 → success

Closes #15319 Related: #13678

Changed files

  • tools/delegate_tool.py (modified, +1/-1)

PR #15447: fix(tools): pass target_model to resolve_runtime_provider in delegation (#15319)

Description (problem / solution / changelog)

Summary

  • When delegation.model differs from the parent model (e.g., delegating to claude-opus-4-6 on an opencode-zen provider while the parent uses a chat_completions model), resolve_runtime_provider needs the target model to select the correct api_mode
  • Without target_model, the delegate inherits the parent's api_mode and gets 404 errors
  • 1-line fix + 5 test assertion updates + 1 new test case

Test plan

  • Updated 4 existing TestDelegationCredentialResolution assertions to verify target_model kwarg is forwarded
  • Added test_target_model_forwarded_for_api_mode_resolution covering the anthropic_messages api_mode case
  • 11/11 delegation credential tests pass

Fixes #15319. Supersedes #15320.

Changed files

  • tests/tools/test_delegate.py (modified, +21/-2)
  • tools/delegate_tool.py (modified, +1/-1)

Code Example

runtime = resolve_runtime_provider(requested=configured_provider)

---

# tools/delegate_tool.py, _resolve_delegation_credentials()
# Before:
runtime = resolve_runtime_provider(requested=configured_provider)
# After:
runtime = resolve_runtime_provider(requested=configured_provider, target_model=configured_model)

---

model:
  provider: opencode-go
  default: minimax-m2.7      # uses anthropic_messages

delegation:
  provider: opencode-go
  model: glm-5.1             # should use chat_completions — but doesn't
RAW_BUFFERClick to expand / collapse

Bug

When delegation.model differs from model.default and the provider is opencode-go or opencode-zen, delegate_task fails with a 404 because the delegation subagent hits the wrong API endpoint.

Root cause

_resolve_delegation_credentials in tools/delegate_tool.py calls:

runtime = resolve_runtime_provider(requested=configured_provider)

resolve_runtime_provider then computes api_mode using model_cfg.get("default") — the main model, not the delegation model. When the main model is a MiniMax model (minimax-m2.7), this returns anthropic_messages, which causes the trailing /v1 to be stripped from the base URL. The subagent then calls https://opencode.ai/zen/go/messages instead of https://opencode.ai/zen/go/v1/chat/completions → 404.

resolve_runtime_provider already accepts a target_model parameter for exactly this purpose (see its docstring). It just isn't being passed.

Fix

# tools/delegate_tool.py, _resolve_delegation_credentials()
# Before:
runtime = resolve_runtime_provider(requested=configured_provider)
# After:
runtime = resolve_runtime_provider(requested=configured_provider, target_model=configured_model)

PR: #15320

Reproduction config

model:
  provider: opencode-go
  default: minimax-m2.7      # uses anthropic_messages

delegation:
  provider: opencode-go
  model: glm-5.1             # should use chat_completions — but doesn't

With this config, delegate_task calls resolve with minimax-m2.7 as the effective model, gets anthropic_messages + stripped base URL, and 404s.

Expected

resolve_runtime_provider is called with target_model="glm-5.1", returns chat_completions + https://opencode.ai/zen/go/v1, and the delegation request succeeds.

Related

#13678 — similar symptom (404 on opencode-go delegation) from a different root cause (env var not loaded in child process)

extent analysis

TL;DR

Pass the target_model parameter to resolve_runtime_provider to ensure the correct API endpoint is used for delegation tasks.

Guidance

  • Verify that the resolve_runtime_provider function is being called with the correct target_model parameter by checking the configured_model variable.
  • Update the _resolve_delegation_credentials function in tools/delegate_tool.py to pass the target_model parameter to resolve_runtime_provider.
  • Test the delegation task with the updated code to ensure the correct API endpoint is being used.
  • Review the resolve_runtime_provider function to ensure it correctly handles the target_model parameter and returns the expected API mode.

Example

# tools/delegate_tool.py, _resolve_delegation_credentials()
runtime = resolve_runtime_provider(requested=configured_provider, target_model=configured_model)

Notes

This fix assumes that the resolve_runtime_provider function is correctly implemented to handle the target_model parameter. If issues persist, further debugging of the resolve_runtime_provider function may be necessary.

Recommendation

Apply the workaround by updating the _resolve_delegation_credentials function to pass the target_model parameter to resolve_runtime_provider, as this should resolve the 404 error and allow delegation tasks to succeed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING