alfin06/swegent-issues-filtered huggingface dataset:
Type inference broken for tool calls after dynamic tools introduction in v5.0.0-beta.29

### Description

After upgrading from `ai@5.0.0-beta.28` to `ai@5.0.0-beta.29`, TypeScript can no longer infer the correct types for tool inputs when filtering tool calls by name. This regression was introduced by PR #7595 which added support for dynamic tools.

Previously, filtering tool calls by name would correctly narrow the type of input. Now, even after checking the dynamic flag as suggested in the documentation, input remains typed as unknown, requiring explicit type assertions.

### Example

```typescript
import { generateText, tool } from 'ai';
import { z } from 'zod';

const result = await generateText({
  model: openai('gpt-4'),
  tools: {
    weather: tool({
      description: 'Get weather information',
      inputSchema: z.object({
        location: z.string(),
        unit: z.enum(['celsius', 'fahrenheit'])
      }),
    }),
  },
  prompt: 'What is the weather in NYC?',
});

// Before v5.0.0-beta.29: This worked without type assertions
const weatherCall = result.toolCalls.find(call => call.toolName === 'weather');
if (weatherCall) {
  console.log(weatherCall.input.location); // ✅ Typed as string
}

// After v5.0.0-beta.29: Even with dynamic check, type inference fails
const weatherCall2 = result.toolCalls.find(call => {
  if ('dynamic' in call && call.dynamic) {
    return false;
  }
  return call.toolName === 'weather';
});
if (weatherCall2) {
  console.log(weatherCall2.input.location); // ❌ Error: 'input' is of type 'unknown'

  // Requires explicit type assertion
  const input = weatherCall2.input as z.infer<typeof weatherInputSchema>;
  console.log(input.location); // ✅ Works with assertion
}
```

### Expected behavior


When filtering tool calls by name and checking the dynamic flag, TypeScript should be able to infer the correct type for input based on the tool definition, as shown in the documentation example.

### Impact

This breaks existing code that relied on TypeScript's type inference for tool calls, requiring developers to add explicit type assertions throughout their codebase when upgrading to the latest beta.

### AI SDK Version

- ai: 5.0.0-beta.29
- @ai-sdk/openai: 2.0.0-beta.13

Labels: bug, ai/core, ai/provider, provider/openai
State: closed
[Request] 请求阿里百炼云增加qwen3系列模型

### 🥰 需求描述

https://bailian.console.aliyun.com/?tab=model#/model-market?name=qwen3
![Image](https://github.com/user-attachments/assets/31a5b954-eca9-4207-9650-78c256621fb2)

### 🧐 解决方案

请求阿里百炼云增加qwen3系列模型

### 📝 补充信息

_No response_

Labels: released
State: closed
tokens输出问题

### 🥰 需求描述

可以增加输出文本长度吗，列如claude的6w tokens输出，在UI里面最多只有3w

### 🧐 解决方案

增加自由的文本长度，而不是最高3w

### 📝 补充信息

_No response_

Labels: released
State: closed
Human in the Loop (HITL) Example Breaks with `onFinish` Callback

### Description

@lgrammel @nicoalbanese When using the human-in-the-loop example, adding the ⁠`onFinish` callback to the ⁠`createUIMessageStream` function causes an infinite loop, resulting in the following error message being repeatedly printed:

```
@example/next-openai:dev: Error: failed to pipe response] {
@example/next-openai:dev:   [cause]: Error: tool-output-error must be preceded by a tool-input-available
@example/next-openai:dev:       at getToolInvocation (../src/ui/process-ui-message-stream.ts:108:20)
@example/next-openai:dev:       at eval (../src/ui/process-ui-message-stream.ts:502:39)
@example/next-openai:dev:       at runUpdateMessageJob (../src/ui-message-stream/handle-ui-message-stream-finish.ts:89:10)
@example/next-openai:dev:       at Object.transform (../src/ui/process-ui-message-stream.ts:99:14)
@example/next-openai:dev:       at Object.transform (../src/ui-message-stream/handle-ui-message-stream-finish.ts:67:19)
```

To reproduce the issue:

1. Clone the `vercel/ai` repository
2. Open the `examples/next-openai/app/api/use-chat-human-in-the-loop/route.ts` file
3. Add `onFinish: async () => {console.log('Done')}` to the `createUIMessageStream` function
4. Run the `next-openai` example in development.
5. Navigate to http://localhost:3000/use-chat-human-in-the-loop
6. Enter `What is the weather in SF?` into the chat
7. Press `Yes` to confirm
8. Watch the infinite loop / error in the terminal

https://github.com/user-attachments/assets/a4d58ae4-f51c-49d1-9b01-c4c61a59f997

### AI SDK Version

- ai: 5.0.0
- @ai-sdk/azure: 2.0.0
- @ai-sdk/react: 2.0.0

Labels: bug, ai/ui, ai/provider, provider/openai, provider/azure
State: closed
Qwen3 OpenRouter 不支持 function calling/tool use，默认配置文件是错的

### 📦 Platform

Vercel

### 📦 Deploymenet mode

server db(lobe-chat-database image)

### 📌 Version

1.84.5

### 💻 Operating System

Ubuntu

### 🌐 Browser

Chrome

### 🐛 Bug Description

1.84.5 增加的 Qwen3，测试之后，在 阿里官方 平台是可用的，但是 OpenRouter 不可用，因为 OpenRouter 并没有部署支持 function call 版本的 Qwen3，应用的话会报错，反馈找不到支持 tool use 的 endpoint，需要手动禁用 tool use 才能使用。代码可以快速fix一下。

问题代码：https://github.com/lobehub/lobe-chat/commit/da05f51

### 📷 Recurrence Steps

_No response_

### 🚦 Expected Behavior

_No response_

### 📝 Additional Information

_No response_

Labels: released, unconfirm
State: closed
Tool calls with invalid input remain stuck in `input-streaming` state

### Description

**Problem:**
When an LLM calls a tool with invalid input, an `AI_TypeValidationError` is thrown. However, the tool call state is not properly updated - it remains in `input-streaming` instead of transitioning to an error state like `output-error`.

**Expected behavior:**
Tool calls with validation errors should transition to an appropriate error state (e.g., `output-error` or a new `input-error` state) to allow proper UI state management.

**Current behavior:**
- No error information is streamed to the UI
- No error information is included in the `onFinish` assistant message in `streamText`
- Tool call remains stuck in `input-streaming` state

**Impact:**
Cannot properly indicate tool call status (in progress/finished/error) to users in both:
- Real-time streaming with `useChat`
- Persisted messages from database

Currently using `ToolUIPart` to check tool call states in the UI. I want to show the user the progress of a tool call. If an input error occurs, the UI got stuck in `input-streaming` (in progress) as no error state is reported.

**Example of an `AI_TypeValidationError`:**

```
{
  toolInput: '{"bomUpdates": [{"operation":"update","id":"j0k1l2m3","changes":{"quantity":50}}]}',
  toolName: 'updateBom',
  [cause]: [Error [AI_TypeValidationError]: Type validation failed: Value: {"bomUpdates":[{"operation":"update","id":"j0k1l2m3","changes":{"quantity":50}}]}.
  Error message: [
    {
      "code": "invalid_type",
      "expected": "number",
      "received": "undefined",
      "path": [
        "bomUpdates",
        0,
        "changes",
        "stage"
      ],
      "message": "Required"
    }
  ]] {
    value: { bomUpdates: [Array] },
    [cause]: [Error [ZodError]: [
      {
        "code": "invalid_type",
        "expected": "number",
        "received": "undefined",
        "path": [
          "bomUpdates",
          0,
          "changes",
          "stage"
        ],
        "message": "Required"
      }
    ]] {
      issues: [ [Object] ],
      addIssue: [Function (anonymous)],
      addIssues: [Function (anonymous)]
    }
  }
}
``` 

### AI SDK Version

- ai: 5.0.0-beta.28
- @ai-sdk/react: 2.0.0-beta.28
- @ai-sdk/anthropic: 2.0.0-beta.9

Labels: bug, ai/core, ai/ui, ai/provider, provider/anthropic
State: closed
[Request] Allow file uploads to set to context instead of rag

### 🥰 Feature Description

When i upload a file it automatically starts chunking/embedding it, i want to be able to set to use the llm's context instead of embedding it, like in OpenWebUI where i have ethe "Bypass Embedding and Retrieval" option.

### 🧐 Proposed Solution

i think one input field is enough for this request

### 📝 Additional Information

_No response_

State: closed
Provide mechanism to make toolCallId unique across multiple call of streamText.

### Description

If we have a task, which will execute a tool call in client side for mutlple times. 
Here is the example case:
1. LLM triggers a tool call, ai-sdk send it to the client.
2. client execute the tool, and send the result to LLM.
3. LLM checks the result and ask for executing the same tool for a second time.

If we want to combine the above interaction into parts of a single UIMessage, sometimes there will be duplicated toolCallId across the steps. Because some LLM(for example: google gemini flash) will produce sample toolCallId across different streamText call.

One solution is to override onChunk, and change the toolCallId to a customized one. But, this only changes toolCallId in UIMessage, while the toolCallId passed to ToolExecuteFunction will not change in this case.

Is there a general solution for this case?

### AI SDK Version

ai: 5.0.0

Labels: ai/provider, external, support, provider/google
State: closed
[Request] Support Anthropic's new native web search API

### 🥰 Feature Description

See https://www.anthropic.com/news/web-search-api?utm_source=it&utm_medium=email&utm_campaign=5-7-web-search-api 

### 🧐 Proposed Solution

Similar to Gemini models that support native web search, Claude models should also be supported 

Likely we need to add one more parameters called `max_uses` to control the numbers of searches when Claude is performing a progressive searching.

### 📝 Additional Information

_No response_

Labels: released
State: closed
`lastAssistantMessageIsCompleteWithToolCalls` should support dynamic tool calls

### Description

## Problem

Currently, `lastAssistantMessageIsCompleteWithToolCalls` checks for `isToolUIPart` in the last tool invocation to see if it has finished streaming output.

https://github.com/vercel/ai/blob/6fb1b4378f5f9f390d08ef932660bc17e65c186b/packages/ai/src/ui/last-assistant-message-is-complete-with-tool-calls.ts#L29

However, `isToolUIPart` does not support `dynamic-tool`s.

https://github.com/vercel/ai/blob/6fb1b4378f5f9f390d08ef932660bc17e65c186b/packages/ai/src/ui/ui-messages.ts#L274-L278

This makes `lastAssistantMessageIsCompleteWithToolCalls` return `false` wherever dynamic tools are used.

## Possible solutions

Checking for `dynamic-tool` part along with `isToolUIPart` `lastAssistantMessageIsCompleteWithToolCalls` would solve this issue.

Changing `isToolUIPart` could be dangerous as it is used in many places other than `lastAssistantMessageIsCompleteWithToolCalls`

## Workarounds

Implementing `lastAssistantMessageIsCompleteWithToolCalls` with support for dynamic tools and plugging it into `sendAutomaticallyWhen` of `useChat` is one workaround.

### AI SDK Version

- `ai: 5.0.0`

Labels: bug, ai/ui
State: closed
Enable urlContext, web search and code execution tools on google vertex

### Description

These tools are available on `@ai-sdk/google` but not `@ai-sdk/google-vertex`

### AI SDK Version

```
"ai": "5.0.2",
"@ai-sdk/google-vertex": "3.0.2",
```

Labels: feature, ai/provider, provider/google, provider/google-vertex
State: closed
providerOptions.openai.logprobs not forwarded to OpenAI API

### Description

## Bug Description
The `providerOptions.openai.logprobs` parameter is not being forwarded to the OpenAI API, despite being present in TypeScript types and documentation.

## Expected Behavior
When using `providerOptions.openai.logprobs: true`, the AI SDK should include logprobs parameters in the OpenAI API request.

## Actual Behavior
The logprobs parameters are stripped out and never reach the OpenAI API. The request body sent to OpenAI does not contain `logprobs` or `top_logprobs` fields.

## Reproduction Steps
```typescript
import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';

const result = await generateText({
  model: openai('gpt-4.1-nano'),
  messages: [{ role: 'user', content: 'Output Y or N.' }],
  maxTokens: 1,
  providerOptions: {
    openai: {
      logprobs: true,
      top_logprobs: 5,
    },
  },
});

console.log(result.logprobs); // undefined - should contain logprobs data

### AI SDK Version

- ai: 5.0.2
- @ai-sdk/openai: 2.0.2

Labels: bug, ai/provider, provider/openai
State: closed
Empty text part created prematurely when using Perplexity models with `extractReasoningMiddleware`

### Description

When using `extractReasoningMiddleware` with Perplexity's `sonar-reasoning-pro` model, the client receives message parts in an unexpected order compared to other providers like Claude.

## Expected Behavior

Based on Claude model behavior:
- Client receives parts in order: `['step-start', 'reasoning', 'text']`
- Reasoning content appears before main text content

## Actual Behavior

With Perplexity models:
- Client receives: `['step-start', 'text', 'reasoning']`
- An empty text part appears early in the streaming process
- Text content is positioned before reasoning in the final structure

## Key Differences

**Claude models:**
- No source chunks in server stream
- Maintains expected order throughout streaming

**Perplexity models:**
- Includes source chunks: `source → reasoning-delta → text-delta`
- Creates empty text part early in client
- Results in unexpected final order

## Reproduction

Repository with minimal reproduction: https://github.com/liby/vercel-ai-perplexity-reasoning-bug

The repository includes detailed logging to show the streaming order at both server and client sides.

## Impact

This ordering issue affects UI display, as reasoning content is expected to appear before the main response text for proper context.

## Additional Information

The issue does not occur in AI SDK v4. With v4:

- Messages maintain correct order without empty text parts appearing early
- Using `createDataStreamResponse` with `mergeIntoDataStream` works as expected
- The issue appears to be specific to v5's handling of Perplexity's source chunks

### AI SDK Version

- ai: 5.0.2
- @ai-sdk/react: 2.0.2
- @ai-sdk/perplexity: 2.0.0
- @ai-sdk/anthropic: 2.0.0

Labels: bug, ai/provider, provider/anthropic, provider/perplexity
State: closed
"Failed to compress chat history" after context grows too long, which is exactly when compression is needed

### What happened?

At 63% context left, started experiencing context rot. Looping calls, etc. I tried to `/compress`, but this failed.


 ╭──────────────────────────────────╮
 │ ✓  ReadFile src/utils/ledger.ts  │
 ╰──────────────────────────────────╯
 ╭──────────────────────────────────╮
 │ ✓  ReadFile src/utils/ledger.ts  │
 ╰──────────────────────────────────╯
 ╭──────────────────────────────────╮
 │ ✓  ReadFile src/utils/ledger.ts  │
 ╰──────────────────────────────────╯
 ╭──────────────────────────────────╮
 │ ✓  ReadFile src/utils/ledger.ts  │
 ╰──────────────────────────────────╯

ℹA potential loop was detected. This can happen due to repetitive tool calls or other model behavior. The request has been halted.
 

╭───────────────╮
│  > /compress  │
╰───────────────╯

✕ Failed to compress chat history: Unable to submit request because it has a maxOutputTokens value of 339835 but the supported range is from 1 (inclusive) to 65537 (exclusive). Update the value and try again.

 

### What did you expect to happen?

I expected compression to work. In past versions, it has been helpful. As a workaround, I will /clear.

### Client information


* **CLI Version:** 0.3.2
* **Git Commit:** ad3bc17e
* **Session ID:** 65f5789f-3b23-4b9f-9b42-8122ca2a58a0
* **Operating System:** darwin v24.7.0
* **Sandbox Environment:** no sandbox
* **Model Version:** gemini-2.5-flash
* **Memory Usage:** 341.5 MB
* **IDE Client:** VS Code


### Login information

_No response_

### Anything else we need to know?

_No response_

Labels: priority/p1, area/core, maintainer
State: closed
Refactor Fallback Logic out of frontend

Currently, the logic to set fallback and the fallback model is in both the cli and core packages. This means that the `config.getModel()` function is used to track multiple concepts (model set by user and fallback). 

As we add routing, we need to consolidate this to the core package and ensure that the model string used in the config only represents either the explicit model choice or the default routing mechanism

Labels: priority/p2, area/core
State: closed
Multiple simultaneous attempts to solve the posed request results in failed output.

### What happened?

It seems like there are multiple sub-agents trying to execute the same task, at least by looking at the repeated response messages, which then causes the resulting output to be garbage (although that is just my assumption).

<img width="792" height="442" alt="Image" src="https://github.com/user-attachments/assets/a7263af3-1ae3-48a0-a861-5fbc361509ee" />

Let me know if (and how) I can provide any traces that would help.

### What did you expect to happen?

Just one subagent performs the action and is able to save a valid file.

### Client information


* **CLI Version:** 0.3.2
* **Git Commit:** ad3bc17e
* **Session ID:** 3269ced5-dcc8-4c90-997e-629bc864b31a
* **Operating System:** darwin v24.6.0
* **Sandbox Environment:** no sandbox
* **Model Version:** gemini-2.5-pro
* **Memory Usage:** 428.1 MB
* **IDE Client:** VS Code


### Login information

GEMINI_API_KEY

### Anything else we need to know?

_No response_

Labels: priority/p1, area/core
State: closed
Exception in streamText not forwarded to response promise

### Description

When an `InvalidPromptError` (or any other early error) occurs during streamText execution, the exception is not propagated to the response promise, causing the promise to remain unsettled and bypassing the catch block. This leads to an "unsettled top-level await" warning and unexpected behavior.

Code to reproduce:

```typescript
import { createGoogleGenerativeAI } from "@ai-sdk/google";
import { streamText } from "ai";

const google = createGoogleGenerativeAI({});

async function test() {
  try {
    const result = streamText({ model: google("") });
    for await (const message of result.toUIMessageStream()) {
      console.log(message);
    }
    console.log(await result.response); // <-- NEVER PRINTS
  } catch (e) {
    console.log("caught ", e); // <-- NEVER EXECUTES
  }
}

await test()
```

This results in:

```
{ type: 'start' }
InvalidPromptError [AI_InvalidPromptError]: Invalid prompt: prompt or messages must be defined
    at standardizePrompt (/Users/xxx/src/node_modules/ai/src/prompt/standardize-prompt.ts:23:11)
    at streamStep (/Users/xxx/src/node_modules/ai/src/generate-text/stream-text.ts:1007:39)
    at fn (/Users/xxx/src/node_modules/ai/src/generate-text/stream-text.ts:1466:15)
    at <anonymous> (/Users/xxx/src/node_modules/ai/src/telemetry/record-span.ts:18:28)
    at Object.startActiveSpan (/Users/xxx/src/node_modules/ai/src/telemetry/noop-tracer.ts:21:14)
    at recordSpan (/Users/xxx/src/node_modules/ai/src/telemetry/record-span.ts:16:17)
    at new DefaultStreamTextResult (/Users/xxx/src/node_modules/ai/src/generate-text/stream-text.ts:976:5)
    at streamText (/Users/xxx/src/node_modules/ai/src/generate-text/stream-text.ts:398:10)
    at test (/Users/xxx/src/testerror.ts:8:20)
    at <anonymous> (/Users/xxx/src/testerror.ts:18:7) {
  cause: undefined,
  prompt: { system: undefined, prompt: undefined, messages: undefined },
  [Symbol(vercel.ai.error)]: true,
  [Symbol(vercel.ai.error.AI_InvalidPromptError)]: true
}
{
  type: 'error',
  errorText: 'Invalid prompt: prompt or messages must be defined'
}
Warning: Detected unsettled top-level await at /Users/xxx/src/testerror.ts:18
await test()
^
```

* The result.response promise does not resolve or reject.
* The catch block is not executed, and no exception is logged.
* An "unsettled top-level await" warning is emitted.

Expected behaviour:

* The InvalidPromptError should be propagated to the result.response promise.
* The catch block should execute, logging the error

### AI SDK Version

- ai: 5.0.5
- @ai-sdk/google: 2.0.2

Labels: bug, ai/core, ai/provider, provider/google
State: closed
Integrate MCP tools with Tool Confirmation Message Bus

## Summary

This issue tracks the integration of MCP (Model Context Protocol) tools with the Tool Confirmation Message Bus infrastructure being implemented in #7231. This represents an additional phase of work beyond the initial 3 PRs outlined in the parent issue.

## Context

MCP tools currently have their own confirmation logic with static allowlists and callback-based confirmation handling. This needs to be migrated to use the new MessageBus/PolicyEngine infrastructure for consistency across all tool types.

## Implementation Plan

### 1. Extend PolicyEngine for MCP-Specific Rules
- Add `mcpServerName` and `mcpToolName` fields to `PolicyRule` interface
- Support matching rules by MCP server and/or specific tools within a server
- Enable server-level and tool-level "always allow" policies

### 2. Enhance Message Types for MCP Metadata
- Add optional `mcpMetadata` field to `ToolConfirmationRequest`:
  ```typescript
  mcpMetadata?: {
    serverName: string;
    serverToolName: string;
    displayName: string;
    trust?: boolean;
  }
  ```

### 3. Migrate MCP Tool Confirmation
- Modify `DiscoveredMCPToolInvocation.shouldConfirmExecute()` to use MessageBus
- Convert static allowlist to dynamic PolicyEngine rules
- Bridge async messaging with existing synchronous interface using Promise/correlation pattern

### 4. Implement "Always Allow" as Policy Rules
- "Always Allow Server" → Add rule: `{ mcpServerName: 'server-name', decision: ALLOW }`
- "Always Allow Tool" → Add rule: `{ mcpServerName: 'server', mcpToolName: 'tool', decision: ALLOW }`
- Persist rules appropriately for user preferences

### 5. Handle Trust Contexts
- Integrate trusted folder checks into PolicyEngine evaluation
- Pass trust context through message metadata or PolicyEngineConfig

## Dependencies
- Requires completion of PR 2 (Core Tool Integration) from #7231
- Should be done before or alongside PR 3 (TUI Integration) to ensure UI handles MCP-specific confirmations

## Acceptance Criteria
- [ ] MCP tools use MessageBus for all confirmation requests
- [ ] Static allowlist is replaced with PolicyEngine rules
- [ ] Server-level and tool-level "always allow" functionality preserved
- [ ] Trusted folder behavior maintained
- [ ] All existing MCP tool tests pass
- [ ] New tests added for MCP-specific message bus integration

## Related Issues
- Parent issue: #7231 (Tracker: Implement Tool Confirmation Message Bus)
- Related PR 1: #7835 (Foundation & Scaffolding)

/cc @allenhutchison

Labels: area/agent
State: closed
[groq] drop chain-of-thought if assistant messages end with use of final channel

Placeholder issue to implement https://cookbook.openai.com/articles/openai-harmony#handling-reasoning-output-in-subsequent-sampling

In particular with groq + gpt-oss models.

We created a preliminary pull request with an example to reproduce the problem and some pointers where the change most likely needs to happen: https://github.com/vercel/ai/pull/7895

Labels: feature, ai/provider, provider/groq
State: closed