[BUG]

[TheTravel3r]

Problem (one or two sentences)

Claude Opus 4.5 fails with "no assistant messages" error requiring 3-5+ retries after PR #9643 disabled native
tools for Claude Code provider.

Context (who is affected and when)

Users of Claude Code provider with Claude Opus 4.5 model. Started after Nov 27, 2025 when PR #9643 merged,
setting supportsNativeTools: false for Claude Code models.

Reproduction steps

1. Configure Roo Code with Claude Code provider
2. Select claude-opus-4-5-20251101 model
3. Use any mode (default Code mode or custom)
4. Send a simple task like "I'm getting an ImportError in server.py"
5. Observe: Opus responds with text first, then returns empty responses on subsequent requests requiring tool
   calls

Expected result

Opus should emit tool calls with 0-1 retries, as it did before Nov 27.

Actual result

• First response: Opus emits text (e.g., "I'll help you debug...") - Second request (tool needed): Empty response, triggers retry - Retries 3-5+ times before eventually emitting XML tool call (or fails entirely with max retries exceeded) Error message: Unexpected API Response: The language model did not provide any assistant messages. This may indicate an issue with the API or the model's output.

Variations tried (optional)

• Minimal mode configuration (empty customInstructions)
• Removed all custom instructions
• Cleared Roo cache
• Various roleDefinition changes
• Increased retry limit (works but defeats purpose)

Sonnet works fine with the same setup - only Opus is affected.

App Version

3.35.4

API Provider (optional)

Anthropic

Model Used (optional)

(Claude Code) claude-opus-4-5-20251101

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Root cause: PR #9643 added supportsNativeTools: false to Claude Code models, forcing XML-only tool calling.
  However:
  1. Opus 4.5 is optimized for native tool calling (per Anthropic docs)
  2. XML tool format has ~10% failure rate with top models (per RFC #4047)
  3. Opus's extended thinking behavior conflicts with XML-first expectations

  Related issues:
  - RFC #4047: Native Tool Use for Top-Tier AI Models
  - Issue #5060: Improvements in Claude Code Provider Integration
  - Issue #9525: Similar empty response issue with Sonnet 4.5

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Problem Summary

The issue is that Claude Opus 4.5 models (claude-opus-4-5-20251101, claude-opus-4-1-20250805, claude-opus-4-20250514) have supportsNativeTools: false set in the Claude Code provider configuration, forcing them to use XML-based tool calling instead of native tools. This causes frequent failures and retries because:

1. These Opus models are optimized for native tool calling (as confirmed in the Anthropic models definition where they have supportsNativeTools: true)
2. XML tool format has a ~10% failure rate with top models
3. Opus's extended thinking behavior conflicts with XML-first expectations

Proposed Solution

Enable native tool support for Claude Opus 4.5 models in the Claude Code provider by setting supportsNativeTools: true for these specific models while keeping it false for other Claude Code models.

Implementation Plan

1. Modify packages/types/src/providers/claude-code.ts:

   • For models claude-opus-4-5-20251101, claude-opus-4-1-20250805, and claude-opus-4-20250514
   • Change supportsNativeTools: false to supportsNativeTools: true
   • Keep other Claude Code models (Sonnet, Haiku) with supportsNativeTools: false as they may still rely on Claude Code CLI's tool management

2. Add tests to verify:

   • Opus models correctly report native tool support
   • Other Claude Code models remain unchanged
   • Tool calling works correctly with the updated configuration

3. Test the fix with the reproduction steps from the issue to ensure:

   • Opus 4.5 emits tool calls with 0-1 retries
   • No more "no assistant messages" errors
   • Sonnet models continue to work as before

This targeted approach fixes the issue for Opus models while preserving the existing behavior for other Claude Code models that may depend on the CLI's tool management.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[TheTravel3r]

Update: Opus 4.5 specific - Opus 4.1 works fine

After extensive testing today:

Model	Result
Opus 4.1 (claude-opus-4-1-20250805)	✅ Works perfectly with 1 retry
Opus 4.5 (claude-opus-4-5-20251101)	❌ Empty responses, 3-5+ retries, often fails completely

Key finding: NOT caused by PR #9643

I tested on v3.34.3 (before PR #9643 was merged) and Opus 4.5 still fails. This rules out the native
tools change as the root cause.

Possibly related

PR #9526 addresses empty response handling for Claude Code provider and is still open awaiting review. This
may be the actual fix needed.

Impact

Opus 4.5 is Anthropic's latest flagship model. Users paying for Claude Max subscriptions expect to use it. This
is a regression that needs to be fixed, not worked around.

[TheTravel3r]

Further Update: Opus 4.5 works fine in Claude Code CLI directly

Tested:
echo "Hello, what is 2+2?" | claude --model claude-opus-4-5-20251101
Response: "Hello! 2 + 2 = 4."

This confirms the issue is Roo Code specific, not Claude Code CLI or Opus 4.5 itself.

Both Opus 4.1 and 4.5 have identical configuration in packages/types/src/providers/claude-code.ts - same
supportsNativeTools: false, same settings. Yet 4.1 works and 4.5 fails.

The issue appears to be how Opus 4.5 responds to Roo's XML tool format differently than 4.1.

[TheTravel3r]

Update: Issue is MCP/skills related

Created a test mode identical to Code mode but WITHOUT mcp in groups (no skills access).

Result: Opus 4.5 works perfectly in Test Opus mode - completed file read, investigation,
and proposed a fix without any empty response errors.

Opus 4.1 + MCP tools (skills) = works
Opus 4.5 + basic tools (read, edit, command) = works
Opus 4.5 + MCP tools (skills) = fails with empty responses