✅ Rebasse vérifié — prêt à merger

J'ai cherry-pické cette PR il y a plusieurs jours et je l'utilise en production sur mon fork. Fonctionne parfaitement.

Aujourd'hui, j'ai vérifié le rebase sur le main actuel (commit b1b0f4b66) :

• Rebase : sans conflit (0 conflit sur 3 fichiers modifiés)
• py_compile : OK
• Statistiques : +565 lignes, -12 lignes sur 3 fichiers
  • tools/delegate_tool.py — handler + resolver
  • tests/tools/test_delegate.py — tests unitaires
  • website/docs/user-guide/features/delegation.md — documentation

Branche rebasée disponible ici : pr36790-rebased sur mon fork (commit 04eb63e30)

La PR répond à un vrai besoin (cf. issues #5012, #6306, #10995 toutes marquées comme fixed by this PR). Le code est approuvé par @mxnstrexgl, les tests passent, le rebase est clean.

Qu'est-ce qui bloque encore le merge ?

Great work on this — the approach of routing through the /model switch pipeline is architecturally the right call. It means aliases, custom providers, and --provider inline syntax all work without parallel resolution logic. That's cleaner than both the synthetic config-dict approach in #34773 and a custom resolver I was sketching out.

I run a production Hermes instance that uses delegate_task daily (deepseek-v4-flash as the daily driver, pro-tier models on explicit request). I'd be happy to pull your branch and test it against real workloads — Matrix-based single-task delegation, mixed-model batch delegation, and the model-only-on-same-provider case.

A few questions as I review:

1. The single goal path injects top-level model/provider into the task dict — does that mean top-level overrides flow through the same _resolve_model_provider_override() codepath as per-task?
2. Have you tested the "provider only" case where the provider is resolved but uses its own default model (not an explicit model override)?
3. Anything specific you'd like help with to get this merged?

Happy to dig into the branch and report back.

@impiyush Thanks for the thoughtful review and for offering to test this against real workloads.

1. Yes. The single-goal path normalizes the top-level model / provider into the task payload, so it goes through the same _resolve_model_provider_override() path as per-task overrides. That keeps the single-task shorthand and mixed batch delegation behavior consistent.

2. Good question. The intended behavior for provider-only is that the provider is resolved through the existing model/provider switch pipeline, and the provider’s default model is used when no explicit model override is supplied. I’ll double-check whether there is already a focused unit test for that exact case; if not, I agree it is worth adding one.

3. The most useful help would be real-world smoke testing on:

• Matrix-based single-task delegation
• mixed-model batch delegation
• model-only override on the same provider
• provider-only override using the provider default model
• conflict handling when structured provider disagrees with inline --provider

If you hit anything unexpected, a minimal delegate_task call plus the relevant provider config shape would be very helpful.

Also thanks @gskeyzer-web for rebasing and validating this on current main. From my side the branch is still available, and I’m happy to refresh/rebase it if maintainers prefer the original PR branch to be updated directly.

@jmche Thanks for working on this — I smoke-tested the patch on my self-hosted Hermes instance (v0.16.0). Assuming I am patching it correctly - the batch path works (resolves to 401 auth issue though), but the single-goal path is not applying model overrides.

Environment:

• Hermes v0.16.0 (commit 3c231eb3)
• Applied via curl -L https://github.com/NousResearch/hermes-agent/pull/36790.diff | git apply onto current main (clean, no conflicts)
• Provider: ollama-cloud (default model: deepseek-v4-flash)
• Platform: Matrix gateway
• Docker Sandbox ON

Test Results:

The pattern is consistent across three different test models (deepseek-v4-pro, gemma4:31b, kimi-k2.6). Every single-goal call falls through to the default model, while the batch path resolves overrides correctly every time.

This suggests the normalization at the single-goal entry point (where goal, model, provider, ... is packaged into a single-element tasks list) correctly includes the model field in the task dict — but somewhere between that normalization and the spawned subagent, the override is dropped or overwritten.

Also worth noting: the batch path had auth failures (401) for all models including deepseek-v4-flash, even though the same model works fine in standalone delegate_task() calls. That could be a separate credential-resolution issue in the batch path.

Let me know how I can help you with this, or if I am doing something incorrectly on my side.

🔄 Rebase + extension vérifiés en production

Je confirme les observations de @impiyush. Le bug du top-level model/provider est LLM-side (le LLM omet les paramètres top-level dans le tool call JSON, pas un bug dans le handler). La syntaxe tasks=[{...}] marche parfaitement. C'est documenté dans le pitfall du skill subagent-templates.

Tests réels (production, 5+ jours)

Extension : reasoning_effort par tâche

J'ai étendu le PR avec un paramètre reasoning_effort optionnel (top-level + per-task) :

delegate_task(tasks=[{
    "goal": "...",
    "model": "deepseek-v4-flash",
    "reasoning_effort": "none"
}, {
    "goal": "...",
    "model": "deepseek-v4-pro",
    "reasoning_effort": "high"
}])

Valeurs supportées : none, minimal, low, medium, high, xhigh.
Propagation : delegate_task → _build_child_agent(override_reasoning_effort=) → AIAgent(reasoning_config=) — testé unitairement ✅

Intégration Kanban

kanban_create accepte maintenant --model et --reasoning-effort (CLI + tool). Le dispatcher passe -m model et injecte HERMES_REASONING_EFFORT dans l'env du worker.

Aide pour le merge

Le PR est rebasé proprement sur main actuel (commit a5d05cf — ~300 commits upstream, 0 conflit). Un reviewer manque (1/2) et le label P3 bloque. Que puis-je faire pour aider à débloquer ? Rebase PR ? Second reviewer ?

Thank you @gskeyzer-web for confirming my results and pointing me in the right direction. Here are my updated smoke test results for this PR.

Retested after correcting my call pattern. The handler code is correct — the earlier "single-goal override not applied" was a red herring on my end.

Environment (same as before):

• Hermes v0.16.0 + PR feat(delegate): add per-task model/provider routing #36790 patch
• tasks=[{...}] shape (not top-level model= param)
• Provider: ollama-cloud (default: deepseek-v4-flash)

Results:

Root cause of my earlier false report: The calling LLM drops optional top-level params like model/provider from the JSON tool call when they're at the top level of delegate_task(). The batch shape delegate_task(tasks=[{...}]) works because the same model reliably includes model inside dict elements. Not a code bug — a serialization behavior difference.

Overall: Code is good and does the job. tasks=[{...}] works reliably for single-task and mixed-batch delegation. The other learning is to always explicitly set the 3 properties in delegate task - goal, model and provider. I did run into an issue when the provider was not explicitly specified for Kimi-K2.6 model and hermes defaulted to using the Kimi-Coding or Moonshot AI api keys, which were not set.

This issue has been a blocker for me to run subagents correctly with different models and am glad this PR will fix it. Thanks again @jmche & @gskeyzer-web. LGTM!!

Thanks @impiyush and @gskeyzer-web for the production validation and for narrowing down the call-shape issue.

I agree with the practical conclusion: for JSON tool calls, the most reliable shape is to put routing fields inside tasks[], even for a single delegated task:

delegate_task(tasks=[{
    "goal": "...",
    "provider": "...",
    "model": "..."
}])

To keep this shape from becoming too loose, the docs should recommend structured fields: provider as the configured provider id, and model as the provider/model-switch-resolved model name. Inline --provider can remain supported for compatibility, but JSON tool calls should prefer the structured provider field.

The handler supports top-level model / provider, but if calling models sometimes omit optional top-level fields, the docs should steer users toward the explicit tasks=[{...}] form for model/provider routing. I’m happy to add a short docs note for that if maintainers want it.

On reasoning_effort: I agree this is an important adjacent problem, especially for cross-provider delegation. A child that overrides provider / model should not blindly inherit provider-specific reasoning request shape from the parent, since that can create incompatibilities across transports. I think explicit per-task reasoning_effort is useful, but I’d prefer to keep it as a follow-up PR so this one can stay focused on model/provider routing and land cleanly.

Given the additional smoke testing and approval, I think this PR is ready from the implementation side. Maintainers: would you like me to rebase/update this branch against current main, or is the current branch sufficient once the remaining review/label requirements are cleared?