Qwen 3.7 Plus/Max (via OpenRouter) unknown/invalid tool calls

Description

BLUF: When using newer Qwen (3.7 Plus/Max) models via OpenRouter, tool calls sporadically fail with empty names like ✗ "" failed
followed by Tool execution aborted, causing repeated retries and aborted sessions.

Symptoms observed:

Tool calls displayed as ✗ "" failed or ✗ <toolname> failed in the TUI
Tool execution aborted errors (up to 15 per session in severe cases)
Successful tool executions followed immediately by spurious failures for the same call ID
Sessions becoming unusable due to repeated tool aborts

Affected providers: Confirmed with Qwen 3.7 Plus/Max via OpenRouter, likely affects other models and maybe other providers too.

Plugins

None

OpenCode version

1.17.9

Steps to reproduce

Configure OpenCode to use a Qwen model (e.g., qwen/qwen-3.7-plus) via OpenRouter
Start a session and request a task that requires multiple tool calls (e.g., writing code with tests using TDD
methodology)
Observe that after a successful tool execution, there are sometimes immediate spurious failures with empty tool names
The frequency increases with longer sessions and more tool calls

Note: The bug is stochastic. Therefore it might need some repetitions to reproduce it. About 50% of sessions (as described above) are affected by this.

Screenshot and/or share link

Exact prompt:

Follow the Skills. Follow the Semantic Achors. Follow the Rules.
Create using TDD a Hello World Program in TypeScript. Use bun.

Error in detail:

invalid [tool=unknown, error=Model tried to call unavailable tool 'unknown'. Available tools: bash, edit, glob, grep, invalid, question, read, skill, task, todowrite, webfetch, websearch, write.]
unknown

Execution with error visible: https://opncd.ai/share/XIq1kE7k

Operating System

Fedora 44 Silverblue / Bluefin

Terminal

Ptyxis (but not relevant)

This issue might be a duplicate of existing issues. Please check:

Unknown tool name written to DB before repair callback fires; stuck pending part permanently kills session on Bedrock (400 toolUse.name constraint) #28989: Unknown tool name written to DB before repair callback fires — describes a very similar root cause where models emit tool calls with unrecognized/empty names, the experimental_repairToolCall redirects to the invalid sentinel, and sessions end up with stuck pending parts and repeated tool aborts. The error message Model tried to call unavailable tool 'unknown' in your report maps closely to the mechanism described there.
Tool execution aborted/terminated #26063: Tool execution aborted/terminated — reports the same Tool execution aborted symptom with a Qwen model (different provider/version), may share the same underlying issue.

Corroborating this on opencode 1.17.9, openrouter/qwen/qwen3.7-plus, in headless opencode run --format json (driven by Paperclip, no TUI — version verified on the running container).

The raw --format json event stream shows each spurious unknown / Tool execution aborted part shares the same callID as a real tool part that completed successfully. opencode emits two parts for one tool call:

// same callID call_d670c32…, emitted twice:
{"type":"tool","tool":"read","callID":"call_d670c32…",
 "state":{"status":"completed","input":{"filePath":"…/x.json"},"output":"…"}}
{"type":"tool","tool":"unknown","callID":"call_d670c32…",
 "state":{"status":"error","input":{},"raw":"","error":"Tool execution aborted",
          "metadata":{"interrupted":true}}}

So the real tool does execute; the unknown is a phantom duplicate.

Quantified across multiple production runs:

~21% of tool-part events are these phantom unknown/aborted parts.
0 orphans — every unknown part is paired with a completed real-tool part on the same callID (verified by grouping parts by callID).

Net effect: in headless/automated use it's functionally non-fatal (the work completes) but it pollutes logs and any per-tool success accounting; in the TUI the same duplication is what cascades into the visible aborts. Points to part-tracking emitting a stray aborted part per tool call rather than a genuine tool failure — consistent with the repair-callback / invalid sentinel path in #28989.

getting the same issue with this model only

Getting the same issue with this model

Confirming this happens for me too. Using Qwen3.7 Max via OpenRouter in OpenCode's Build mode. In my case it wasn't just sporadic — the agent got stuck in a loop repeatedly trying to call a tool named unknown while editing index.html, failing with:

invalid [tool=unknown, error=Model tried to call unavailable tool 'unknown'. Available tools: bash, edit, glob, grep, invalid, question, read, skill, supabase_apply_migration, supabase_confirm_cost, supabase_create_branch, supabase_create_project, supabase_delete_branch, supabase_deploy_edge_function, supabase_execute_sql, supabase_generate_typescript_types, supabase_get_advisors, supabase_get_cost, supabase_get_edge_function, supabase_get_logs, supabase_get_organization, supabase_get_project, supabase_get_project_url, supabase_get_publishable_keys, supabase_list_branches, supabase_list_edge_functions, supabase_list_extensions, supabase_list_migrations, supabase_list_organizations, supabase_list_projects, supabase_list_tables, supabase_merge_branch, supabase_pause_project, supabase_rebase_branch, supabase_reset_branch, supabase_restore_project, supabase_search_docs, task, todowrite, webfetch, write.]

It retried the same "Edit index.html" → invalid tool call cycle 5+ times in a row with no progress, burning tokens (~15K tokens / $0.07) before I interrupted it. Worth noting this happened with Supabase MCP tools also registered — not sure if that's related to the longer tool list somehow tripping up Qwen's tool-call formatting, but wanted to flag it in case the tool count/list size is a contributing factor.

Can someone send me a session they hit this in? opencode export > session.json

I currently don't have a session.json. But there is a share I added to this issue: https://opncd.ai/share/XIq1kE7k

@rekram1-node

@rekram1-node
Hi,
I think I have an example prompt (and the session export) that can reproduce the error quite good:

Create an absurdly complex "Hello World" typescript app in this directory as a show case.
Violate DRY intentionally at least 5 times.
Violate KISS intentionally at least 5 times.
Violate YAGNI intentionally at least 5 times.

Use TDD everywhere.
Use Bun.

After that I used another session to refactor it again. In both session I've seen many unknown and invalid calls. The refactor sessions also asked once if I would like to continue after that many errors.

hello_world.json
hello_world_refactor.json

I really hope this helps.

Same problem for me.

Same here

same with Qwen3.7 Flash

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Navigation Menu

Repository navigation

Qwen 3.7 Plus/Max (via OpenRouter) unknown/invalid tool calls #33618

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Qwen 3.7 Plus/Max (via OpenRouter) unknown/invalid tool calls #33618

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Jun 24, 2026

laradji commented on Jun 24, 2026

adamrybak commented on Jun 26, 2026

angryelizar commented on Jul 1, 2026

PierrunoYT commented on Jul 1, 2026

rekram1-node commented on Jul 1, 2026

BernhardGruen commented on Jul 1, 2026

BernhardGruen commented on Jul 2, 2026

nullbio commented on Jul 6, 2026

Safra1976 commented on Aug 25, 2026

Kaniber commented on Aug 27, 2026

thdxr commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions