#ai-sdk

BestCodes I'm curious, what's the abstraction for? Like, why would I use this rather than the AI SDK's built-in tool approval?

NikitaKharya Great question! The AI SDK's built-in tool approval handles the core approve/reject flow really well. agenttrace-ui builds on top of that with two additional layers: 1. **Transparency alongside approval**: The AI SDK provides a clear yes/no approval step. agenttrace-ui adds a more detailed view around that, with a collapsible timeline showing each step the agent took, the reasoning behind it, and the underlying data across multiple visualization modes. The approval step becomes one part of a broader, inspectable workflow. 2. **LLM-driven vs. predefined approval rules:** With the AI SDK, `needsApproval` is typically defined ahead of time for specific tools. agenttrace-ui introduces a more flexible pattern via a universal `confirmAction` tool, where the LLM can decide when to pause based on context. The same mechanism can surface different levels of risk (e.g., low, medium, high) depending on the situation. If your use case is straightforward approval for specific tools, the AI SDK's built-in approach is a great fit. agenttrace-ui is designed for cases where you also want deeper visibility into agent behavior and more context-aware approval decisions.

BestCodes This is a fascinating idea, but I wonder if it's a necessary abstraction Definitely interesting! Keep up the cool work

Ryu Hi Pallav, I wouldn’t take the display `name` mismatch alone as proof that the backend is routing to the wrong model, but it is definitely worth reporting because the model catalog/API should not label `openai/gpt-oss-20b` as `GPT OSS 120B`. A useful way to separate “display metadata bug” from “routing bug” would be to compare the two model IDs directly: ``` curl -s https://ai-gateway.vercel.sh/v1/models \ | jq '.data[] | select(.id == "openai/gpt-oss-20b" or .id == "openai/gpt-oss-120b")' ``` Then, if you have an AI Gateway key, compare the endpoint metadata too: ``` curl -s https://ai-gateway.vercel.sh/v1/models/openai/gpt-oss-20b/endpoints \ -H "Authorization: Bearer $AI_GATEWAY_API_KEY" curl -s https://ai-gateway.vercel.sh/v1/models/openai/gpt-oss-120b/endpoints \ -H "Authorization: Bearer $AI_GATEWAY_API_KEY" ``` If only the `name` field is wrong but the IDs, endpoints, pricing/context fields, and generation records differ correctly, then it is probably a catalog/display bug. If the 20B ID returns the same endpoint/pricing/usage behavior as 120B, then that is stronger evidence of a routing/config issue. For a clean bug report, I’d include: ``` model id: openai/gpt-oss-20b incorrect name returned: GPT OSS 120B timestamp: output from /v1/models for both 20B and 120B: generationId from one tiny test request, if available: ``` Don’t include the AI Gateway key.

Pauline P. Narvas This has gone to our AI SDK team, thank you for sharing!

Ryu Hi MountainMan, Yes, I’d expect the same Bedrock `providerOptions` shape to work with `streamText`. The docs show `generateText`, but the guardrail config is a provider option on the Bedrock model call, not something specific to `generateText`. Example: ``` import { bedrock, type AmazonBedrockLanguageModelOptions } from "@ai-sdk/amazon-bedrock" import { streamText } from "ai" const result = streamText({ model: bedrock("anthropic.claude-3-sonnet-20240229-v1:0"), prompt: "Write a story about space exploration.", providerOptions: { bedrock: { guardrailConfig: { guardrailIdentifier: "1abcd2ef34gh", guardrailVersion: "1", trace: "enabled", streamProcessingMode: "async", }, } satisfies AmazonBedrockLanguageModelOptions, }, }) return result.toTextStreamResponse() ``` The main thing I’d watch is `streamProcessingMode`. For streaming responses, `async` is usually the setting I’d try first because it lets streaming continue while Bedrock evaluates guardrails. If you need stricter blocking behavior before output reaches the client, test the other mode and confirm the latency/behavior matches what you want. The Bedrock provider docs are here: https://ai-sdk.dev/providers/ai-sdk-providers/amazon-bedrock#guardrails If it does not behave the same with `streamText`, I’d log the Bedrock error body and the AI SDK / `@ai-sdk/amazon-bedrock` versions, because that would likely be a provider-specific streaming issue rather than a different top-level API shape.

Pauline P. Narvas Hey, I'm guessing you mean on the AI SDK and not v0? You can use `google/gemini-2.5-flash-image`. This is the latest stable model with image generation.

Gertie01 Yes. On the AI SDK.

mo0hie Before sending the response to the frontend, just modify the tool parts and hide their output. For example: `onFinish: async ({ messages, responseMessage }) => {` ` responseMessage.parts = responseMessage.parts.map((part) => {` ` if (` ` part.type.startsWith("tool-") &&` ` part.state === "output-available"` ` ) {` ` return {` ` ...part,` ` output: "[REDACTED]",` ` };` ` }` ` return part;` ` });` ` },`

Ryu Hi Sbullocks, Since static assets work but every function hangs until timeout, I’d separate “Vercel can route to a function” from “your new runtime code is waiting forever.” First, deploy one tiny endpoint that does not import anything shared from the app: ``` // app/api/ping/route.ts export const dynamic = "force-dynamic" export async function GET() { return Response.json({ ok: true, time: Date.now() }) } ``` If that works, the platform/function routing is fine and I’d look at the changes from the rate-limiting commit: middleware, shared auth helpers, Redis/KV/database clients, external fetches, or env vars that are now awaited before returning a response. If that tiny endpoint also hangs, check whether it is really included in the latest deployment and inspect logs outside the dashboard: ``` vercel inspect <deployment-url> --logs vercel logs <deployment-url> --since 1h ``` For the affected routes, I’d also add timing around each awaited operation: ``` console.time("rate-limit") await checkRateLimit() console.timeEnd("rate-limit") console.time("upstream") const res = await fetch(url, { signal: AbortSignal.timeout(10000) }) console.timeEnd("upstream") ``` A very common cause after adding rate limiting is a server-side call waiting on a missing/incorrect Production env var or an upstream service that is reachable locally but not from the deployed function. The key signal is whether the function logs stop before or after the rate-limit / external API call. Vercel has a useful slow-function debugging command here: https://vercel.com/docs/functions/debug-slow-functions Can you share the first log line before the hang and whether the isolated `/api/ping` route returns immediately?

Pauline P. Narvas Are you talking about the AI SDK? Currently, the `@ai-sdk/azure` provider is specifically designed for Azure OpenAI deployments. While Azure does host models from Anthropic and others, these aren’t accessible through our Azure provider yet. I recommend checking out AI Gateway: https://vercel.com/ai-gateway/models

Kejvi Dema @pawlean - I believe there is confusion. Yes, I am referring to AI Gateway, and yes, I am well aware that Azure is not a provider for the cited models, and that’s the reason I am writing this and requesting/recommending Vercel to add this in their offering.

Pauline P. Narvas I was confused by your initial post, I’ve changed your post to Feedback and will share with our product team. Thank you!

Ryu Hi Nekomiya, Since the same request works with `only: ['anthropic']` but fails with `only: ['bedrock']`, I’d treat this as a Gateway → Bedrock request translation/schema issue first, not an auth issue. `providerOptions.gateway.only` is the right kind of option for restricting routing, but Bedrock seems to be rejecting an extra field inside the tool definition: ``` tools.0.custom.eager_input_streaming: Extra inputs are not permitted ``` A useful isolation test would be to run three tiny requests against the same model/provider route: 1. no tools at all 2. one minimal tool with only `name`, `description`, and `input_schema` / `parameters` 3. your real tool payload If #1 works and #2/#3 fail only on Bedrock, that narrows it to tool schema serialization rather than model access or Gateway auth. I’d also check whether your HTTP request is manually including any `custom` object under `tools`. If it is, remove that for Bedrock. If it is not in your payload and Gateway is adding it internally, then the best bug report would include: ``` status code redacted request body redacted response body model ID providerOptions.gateway.only value timestamp x-vercel-id / request ID if present ``` The Gateway provider options docs are here for comparison: https://vercel.com/docs/ai-gateway/models-and-providers/provider-options As a temporary workaround, I’d route tool-calling requests away from Bedrock or remove provider-specific/custom tool metadata when forcing Bedrock, then keep the smallest failing repro for Vercel to inspect.

Ryu Hi Wyatt, I would split this into two stored representations instead of trying to make one MongoDB document serve both jobs. For example: ``` 1. UI/history record - what you show in the chat UI - can include reasoning parts, metadata, timestamps, model name, token usage, etc. 2. Model context record - only the clean ModelMessage[] you plan to send back into generateText/streamText - no UI-only fields - no provider response metadata - no fields copied blindly from the provider response ``` `outputs.response.messages` is useful for continuing a conversation, but I would avoid persisting the full object and replaying it forever without normalizing it first. If a provider adds metadata or reasoning-specific fields that are valid as output but not valid as future input for that provider, you can get exactly this kind of “invalid prompt” problem after loading. A safer save step is to whitelist the fields you actually want to send back: ``` function cleanModelMessages(messages: ModelMessage[]): ModelMessage[] { return messages.map((message) => ({ role: message.role, content: message.content, })) } ``` Then store reasoning separately for display/debugging, not necessarily as part of the next model prompt. In many apps, the previous assistant’s final answer is what you resend as context, while reasoning traces are stored for audit/UI and not replayed to the model on every turn. So the flow would be: ``` const context = await loadCleanModelContext(userId) context.push({ role: "user", ModelContext(userId) context.push({ role: "user", content: [{ type: "text", text: prompt }], }) const result = await generateText({ model: openrouter.chat("google/gemini-3-flash-preview", { reasoning: { enabled: true, effort: "medium", }, }), system: SYSTEM_PROMPT, messages: context, }) // store clean context for the next call await saveCleanModelContext(userId, [ ...context, ...cleanModelMessages(result.response.messages), ]) // store richer UI/debug data separately await saveUiTranscript(userId, { text: result.text, responseMessages: result.response.messages, providerMetadata: result.providerMetadata, }) ``` Also, you’re right that `convertToModelMessages()` is mainly for converting `UIMessage[]` from `useChat` into model messages. I would not use it on data that is already stored as `ModelMessage[]`. The AI SDK docs mention `response.messages` for conversation history here: https://ai-sdk.dev/docs/ai-sdk-core/tools-and-tool-calling#response-messages If removing `providerOptions` makes the prompt valid, that is a good signal that the loaded object contains provider-specific data that should not be replayed as-is. I’d keep that data in your UI/audit collection, but only end a normalized `ModelMessage[]` back to the model.

ADALIGO Honestly same here 😅 I’ve been waiting for MCP Apps support too. It feels like a big missing piece, especially now that MCP is getting more powerful. From what I’ve seen 👀 Vercel usually ships fast once things are stable, so maybe this is still being worked on internally for the AI SDK 🤔 Also, this isn’t just a one-off request — I’ve seen multiple discussions about it across GitHub and the community (like the issues opened in January and even on Jan). So there’s clearly real demand building up. What would really help: * native support in the Chat UI * smoother app-to-tool chaining * clearer docs and real examples Right now it feels like the MCP ecosystem is ready, but the SDK isn’t fully catching up yet. Are there any updates from the team on whether MCP Apps support is planned soon, or if there’s an experimental way to start using it already?

BestCodes Since this has been inactive for over a month, I'm sending this message to hopefully bump it back up to the top!

Pauline P. Narvas Sharing with the team again

Anush Hey @yusuf-eren. I’m from the Qdrant team (anush.shetty@qdrant.com). We’d be happy to help build/maintain this integration for the community. Looking forward to hearing from the Vercel AI SDK team.

Gregor @anush a community plugin would be great, we will be happy to add it to the list of AI SDK community providers: https://ai-sdk.dev/providers/community-providers. The AI SDK does support reranking and embedding, but we do not have a store abstraction built into the AI SDK, that’s currently out of scope. Maybe you can add a guide on how to use Qdrant with AI SDK using your community provider and vector store?

Anush Hey @gr2m I’m a fan of your work on Octokit.js and Semantic Release. Thank you. > but we do not have a store abstraction built into the AI SDK, that’s currently out of scope. I see. Building a plugin without a common abstraction means users won’t have the ability to swap the vector store providers. Like with other components. How about we have examples/guides on how to use the AI SDK with the Qdrant client instead?

Pauline P. Narvas The `NS_BASE_STREAM_CLOSED` error typically occurs when the MCP client connection is closed prematurely. When you're using MCP tools with streaming, the client needs to stay open until the entire response completes, if it closes early, you'll hit this error. Here's what I'd recommend checking: - Make sure your MCP client isn't timing out or disconnecting before the stream finishes - Verify that your connection handling code keeps the client alive throughout the entire streaming response - Check if there are any timeout settings that might be causing the connection to close early Let me know if you have any other questions!

phanithlim Thanks Pauline P. Narvas for the response! I’ve been stuck on this for about 3 days now and still can't resolve it. I was previously using `experimental_createMCPClient`, and it worked perfectly. However, since I updated my code to use the standard `createMCPClient`, I began facing the `NS_BASE_STREAM_CLOSED` issue mentioned above. The connection seems to drop the moment the LLM starts streaming the tool output back to the UI. Since I am using `streamText` with `toUIMessageStreamResponse()`, I suspect the new `createMCPClient` handles transport lifecycles differently, causing it to be garbage collected or closed because the main function scope finishes while the stream is still active. Could you provide an example of the recommended pattern for keeping the `createMCPClient` alive during an asynchronous stream in a Next.js Route Handler? Is there a specific way to bind the client's lifetime to the `toUIMessageStreamResponse` so the transport doesn't close prematurely?

Jacob Paris We have a whole set of guides including chatbot examples here that answer all of your questions https://ai-sdk.dev/docs/ai-sdk-ui/overview