PR #17329: fix(delegate): surface tool_trace on N-API-call subagent timeouts (#17308)

• Repository: NousResearch/hermes-agent
• Author: Sanjays2402
• State: open | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/17329

Description (problem / solution / changelog)

Closes #17308.

Problem

When a subagent under delegate_task times out after making >0 API calls, the lead agent gets a vague string and nothing else:

Subagent timed out after 120s with 3 API call(s) completed — likely stuck on a slow API call or unresponsive network request.

There's no way to tell apart the two failure modes:

1. Tool finished, next LLM request hung — the tool itself is fine; the provider froze.
2. Tool itself hung — network partition, blocked I/O, etc.

This was the gap between the two existing diagnostic paths:

Fix

Three pieces:

1. Extract a shared trace builder

The normal-completion branch already reconstructs tool_trace from result['messages']. Pulled that loop out into a module-level _build_tool_trace_from_messages() helper so both branches use one implementation.

2. Reconstruct trace on the N-API-call timeout branch

In _run_single_child's timeout branch (when is_timeout and child_api_calls > 0):

• Read child._session_messages and run it through the helper.
• If the trace tail has no matching tool-role response → mark status='in_progress' (the tool itself is hung).
• Read get_activity_summary().current_tool. If it disagrees with the trace tail, prefer it — the tool-role write can lag because the agent writes the assistant message first and the tool response only after the tool returns.

3. Surface the diagnostics

Return dict now carries tool_trace, last_tool, last_tool_status, current_tool. Error message gets a last_tool=X (status=Y) suffix so it shows up in logs and the lead's prompt:

Subagent timed out after 120s with 3 API call(s) completed — likely stuck on a slow API call or unresponsive network request. last_tool=terminal (status=in_progress)

0-API-call timeouts (diagnostic_path branch) and non-timeout errors leave the new fields empty/None so consumers don't read stale data.

Tests

Added two test classes in tests/tools/test_delegate_subagent_timeout_diagnostic.py:

TestRunSingleChildTimeoutToolTrace — end-to-end through _run_single_child with a tiny timeout:

• test_timeout_after_completed_tool_marks_status_ok — tool returned cleanly → status=ok, current_tool=None
• test_timeout_inside_running_tool_marks_status_in_progress — tool never returned → status=in_progress, current_tool set
• test_timeout_with_tool_error_preserves_error_status — error responses keep status=error
• test_timeout_with_parallel_tool_calls_pairs_by_id — out-of-order replies still pair correctly
• test_zero_api_call_timeout_skips_tool_trace — 0-API branch keeps the new fields empty (no stale data alongside diagnostic_path)
• test_timeout_with_no_session_messages_attr_does_not_crash — degrades to empty trace if _session_messages is absent

TestBuildToolTraceFromMessages — direct unit tests for the extracted helper (non-list input, non-dict entries, assistants without tool_calls, tool responses without tool_call_id).

$ python -m pytest tests/tools/test_delegate_subagent_timeout_diagnostic.py -q
.................                                                       [100%]
17 passed in 3.88s

Combined with the existing test_delegate.py suite: 137/137 pass.

Changed files

• tests/tools/test_delegate_subagent_timeout_diagnostic.py (modified, +254/-0)
• tools/delegate_tool.py (modified, +113/-32)

PR #17340: fix(auxiliary): preserve raw_base_url for Anthropic SDK wrapping in resolve_provider_client

• Repository: NousResearch/hermes-agent
• Author: lzsnolimit
• State: closed | merged: False
• Link: https://github.com/NousResearch/hermes-agent/pull/17340

Description (problem / solution / changelog)

Problem

After #17308 (f3371c39) threaded main_runtime through to auto_title_session, title generation started returning HTTP 404 for users on minimax-cn (and any other provider whose inference_base_url ends with /anthropic).

Root cause chain:

1. resolve_api_key_provider_credentials("minimax-cn") returns base_url = "https://api.minimaxi.com/anthropic"
2. _to_openai_base_url() converts it to "https://api.minimaxi.com/v1" (correct for the OpenAI SDK client)
3. _wrap_if_needed is called with this already-converted /v1 URL
4. Because main_runtime now carries api_mode="anthropic_messages", _maybe_wrap_anthropic decides to wrap → calls build_anthropic_client(key, "https://api.minimaxi.com/v1")
5. The Anthropic SDK appends /v1/messages → actual request hits https://api.minimaxi.com/v1/messages → 404

The correct endpoint is https://api.minimaxi.com/anthropic/v1/messages.

Fix

Preserve raw_base_url (pre-_to_openai_base_url conversion) and pass it to _wrap_if_needed, so _maybe_wrap_anthropic receives the original /anthropic-suffixed URL for both:

• endpoint detection (_endpoint_speaks_anthropic_messages)
• Anthropic SDK client construction (build_anthropic_client)

The OpenAI client continues to use the /v1-converted base_url.

Affected providers

All API-key providers whose inference_base_url ends with /anthropic when a main_runtime with api_mode=anthropic_messages is available: minimax, minimax-cn, and any compatible third-party gateway.

Changed files

• agent/auxiliary_client.py (modified, +6/-4)