fix: handle dangling tool_use blocks for LiteLLM proxy compatibility

[hendem]

Problem

When using OpenCode with LiteLLM proxies (e.g., for Vertex AI, Bedrock), session compaction fails with:

invalid_request_error: messages.2: `tool_use` ids were found without `tool_result` blocks immediately after

or:

litellm.UnsupportedParamsError: Anthropic doesn't support tool calling without `tools=` param specified

This affects users who route Anthropic/Claude API calls through corporate LiteLLM proxies and cannot modify proxy settings (e.g., modify_params=True).

Root Cause Analysis

There are two distinct issues causing these errors:

Issue 1: Missing tools parameter during compaction

When compaction runs, it calls processor.process() with tools: {} (compaction.ts:149):

const result = await processor.process({
  // ...
  tools: {},  // <-- Empty tools object
  messages: [
    ...MessageV2.toModelMessage(input.messages),  // <-- Contains tool_use/tool_result from history
    // ...
  ],
})

LiteLLM validates that if message history contains tool_use/tool_result blocks, the tools parameter must be present. While Anthropic's native API now handles this gracefully, LiteLLM enforces stricter validation.

Issue 2: Dangling tool_use blocks without tool_result

When a session is interrupted or aborted, tool calls may be left in pending or running state. The toModelMessage() function in message-v2.ts currently skips these incomplete tool calls:

if (part.state.status === "completed")
  assistantMessage.parts.push({ /* tool-result */ })
if (part.state.status === "error")
  assistantMessage.parts.push({ /* tool-result with error */ })
// pending/running are NOT handled - creates dangling tool_use!

This creates tool_use blocks in the assistant message without corresponding tool_result blocks, which Anthropic/Claude APIs strictly reject.

Solution

Fix 1: Add dummy _noop tool when message history contains tool calls

In llm.ts, detect when messages contain tool calls but no tools are provided, and inject a placeholder tool:

if (Object.keys(tools).length === 0 && hasToolCalls(input.messages)) {
  tools["_noop"] = tool({
    description: "Internal placeholder tool - not for use",
    inputSchema: jsonSchema({ type: "object", properties: {} }),
    execute: async () => ({ output: "", title: "", metadata: {} }),
  })
}

The _noop tool is excluded from activeTools so it won't be suggested or called by the LLM.

Fix 2: Convert pending/running tool calls to error results

In message-v2.ts, handle pending and running tool states by generating error tool_result blocks:

if (part.state.status === "pending" || part.state.status === "running")
  assistantMessage.parts.push({
    type: ("tool-" + part.tool) as `tool-${string}`,
    state: "output-error",
    toolCallId: part.callID,
    input: part.state.input,
    errorText: "[Tool execution was interrupted]",
    callProviderMetadata: part.metadata,
  })

This ensures every tool_use has a corresponding tool_result, satisfying Anthropic's API requirements.

Files Changed

File	Change
packages/opencode/src/session/llm.ts	Add hasToolCalls() helper and dummy _noop tool injection
packages/opencode/src/session/message-v2.ts	Handle pending/running tool states → error results
packages/opencode/test/session/message-v2.test.ts	Add test for pending/running tool conversion

Testing

• Added unit test verifying pending/running tool calls are converted to error results
• Manual testing needed with actual LiteLLM proxy setup

Related

Fixes #8246
Fixes #2915
Related to #3243 (stale PR with merge conflicts addressing similar ordering issue)

Prior Art

• Commit 0af450575 attempted a fix but was later simplified away
• LiteLLM has a modify_params=True workaround, but many corporate proxy deployments cannot change this setting

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potential duplicate/related PR:

Related PR Found

PR #8248: fix: avoid Anthropic tool-history requests without tools

• fix: avoid Anthropic tool-history requests without tools #8248

Why it's related: This PR addresses a very similar issue - handling requests that contain tool calls/history but lack the tools parameter. PR #8497 includes adding a dummy _noop tool when message history contains tool calls but no tools are provided (for LiteLLM proxy compatibility), which appears to be the same problem space that PR #8248 was tackling.

Also note: PR #3243 mentioned in the description ("Fix: Each tool_use block must have a corresponding tool_result block in the next message") is the stale/conflicted PR that #8497 is intended to supersede/fix properly.

[Copilot]

Pull request overview

This PR fixes session compaction failures when using OpenCode with LiteLLM proxies by ensuring every tool call has a corresponding tool result and that the tools parameter is present when needed.

Changes:

• Pending and running tool calls now generate error tool results to prevent dangling tool_use blocks
• A dummy _noop tool is added when message history contains tool calls but no tools are provided
• Test coverage added for pending/running tool call conversion

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
packages/opencode/src/session/message-v2.ts	Adds handling for pending/running tool states to convert them to error results
packages/opencode/src/session/llm.ts	Adds dummy tool for LiteLLM proxy compatibility and helper function to detect tool calls
packages/opencode/test/session/message-v2.test.ts	Adds test coverage for pending/running tool call error result generation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hendem]

Re: Related PR #8248

Thanks for flagging the potential duplicate. I've reviewed PR #8248 and here's how this PR differs:

PR #8248 only addresses Issue 1 (missing tools parameter) and:

• Only applies the fix for providers with "litellm" in their ID
• Does not address dangling tool_use blocks from interrupted sessions

This PR (#8497) addresses both issues:

1. Missing tools parameter - Adds dummy _noop tool universally (not just LiteLLM) since other proxies may have the same validation
2. Dangling tool_use blocks - Converts pending/running tool calls to error results, ensuring every tool_use has a corresponding tool_result

The second fix is critical because even with the dummy tool, if there are dangling tool_use blocks from interrupted/aborted tool calls, the API will still reject the request with:

messages.2: `tool_use` ids were found without `tool_result` blocks immediately after

I'd suggest either closing #8248 in favor of this more comprehensive fix, or we could cherry-pick the provider-specific check from #8248 if the team prefers a more targeted approach for Issue 1.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[seilk]

I've created #8658 which builds on this PR and addresses @rekram1-node's feedback from #8248.

The key change: Restricts _noop tool injection to only LiteLLM-backed providers instead of applying it unconditionally.

Detection logic:

const isLiteLLMProxy =
  provider.options?.["litellmProxy"] === true ||
  input.model.providerID.toLowerCase().includes("litellm") ||
  input.model.api.id.toLowerCase().includes("litellm")

Why this matters:

• Your PR injects _noop for ALL providers unconditionally
• Per @rekram1-node's comment: "There are a LOT of providers that don't have this issue... ideally this would be strictly limited to litellm"
• My change adds auto-detection (provider ID contains "litellm") + explicit opt-in (litellmProxy: true option)

Config example for custom gateways:

{
  "provider": {
    "my-gateway": {
      "options": { "litellmProxy": true }
    }
  }
}

Happy to discuss merging this into your PR or keeping them separate.

[sinwoobang]

What's the blocker of this PR? I need this to be merged.