Vercel's AI Gateway gains DeepSeek Search and Fetch tools

The package gains two new tools

Vercel updated the AI Gateway, the layer that centralizes calls to AI models, to include two DeepSeek tools: deepseek_search and deepseek_fetch, according to the changelog published on Vercel's website. The first returns a list of relevant pages, each with a title, URL, and summary. The second takes one of those URLs and delivers the page content already converted to Markdown, ready for the model to process.

It's not news that language models need web access to answer current questions or fetch data outside their training. What changes here is the packaging: instead of integrating a separate search API (Exa, Tavily, SerpAPI) and then writing a parser to extract text from each page, both steps arrive ready-made inside the AI SDK, behind the same AI Gateway key.

What the code looks like

To use it, you need to update the ai package to a recent version: 6.0.321 or higher in the 6.x series, or 7.0.160 or higher in the 7.x series. The command is pnpm add ai@latest, and the access key comes from the AI_GATEWAY_API_KEY environment variable (no need to open a separate account with DeepSeek).

The documentation example combines both helpers inside tools, using the deepseek/deepseek-v4.1-flash-1017 model:

import { gateway, streamText } from 'ai';

const result = streamText({
  model: 'deepseek/deepseek-v4.1-flash-1017',
  prompt: 'Find the latest Vercel AI Gateway announcement, fetch it, and summarize it.',
  tools: {
    deepseek_search: gateway.tools.deepseekSearch({ count: 3 }),
    deepseek_fetch: gateway.tools.deepseekFetch(),
  },
});

for await (const text of result.textStream) {
  process.stdout.write(text);
}

The model decides on its own when to call deepseek_search, looks at the results, picks a URL, and calls deepseek_fetch to read the full content before answering. It's the same search-agent pattern many people already build by hand with LangChain or manual function calls, just that here it's built into the SDK that Vercel itself maintains.

The part that matters: it works with any model

The most relevant part for anyone already running an agent pipeline: DeepSeek's tools don't require using a DeepSeek model. Vercel makes it clear that deepseek_search and deepseek_fetch work with any model that supports tool calling, through the same AI Gateway key, and remain available even if the team switches model providers later.

This separates two decisions that normally go together: which model generates the answer and which service does the web search. You can run a model from another provider via the Gateway and still use DeepSeek search as a tool, or switch models without rewriting the search logic.

Fallback between search providers, but no guarantee

The changelog also shows an example with fallback: if deepseek_search fails, the model tries exa_search, then parallel_search. The instruction goes in the system prompt:

import { gateway, streamText } from 'ai';

const result = streamText({
  model: 'zai/glm-5.3-flash',
  system: 'Try deepseek_search, then exa_search, then parallel_search on errors. After search succeeds, use deepseek_fetch on a result URL.',
  prompt: 'Find the latest Vercel AI Gateway announcement, fetch it, and summarize it.',
  toolChoice: 'required',
  tools: {
    deepseek_search: gateway.tools.deepseekSearch({ count: 3 }),
    deepseek_fetch: gateway.tools.deepseekFetch(),
    exa_search: gateway.tools.exaSearch({ numResults: 3 }),
    parallel_search: gateway.tools.parallelSearch({ maxResults: 3 }),
  },
});

It's worth noting a detail the documentation itself flags: this fallback is "model-directed," meaning the order of attempts and the number of retries depend on the model following the system prompt instruction, not on deterministic logic in the code. For anyone who needs a real guarantee about the search, this matters: a model can ignore the instruction, try in the wrong order, or give up earlier than expected. Anyone who needs truly reliable fallback will still have to write that logic outside the model's loop, handling each tool call manually in code.

Pricing: per request, not per token

Each successful call to deepseek_search or deepseek_fetch costs $0.75 per 1,000 billable requests. Requests that fail, time out, or come back empty are not charged. This amount is separate from the model's token cost, which continues to be billed normally by the chosen provider.

This changes how you calculate the cost of a search-enabled agent: before, the extra expense of integrating a search provider depended on that service's plan (Exa, Tavily, SerpAPI, each with its own pricing table). Now, for anyone already paying for the AI Gateway, you can estimate the search cost together with the rest of the agent on a single invoice, without opening an account with yet another service.

Where this helps and where it doesn't

For anyone prototyping an agent that needs to check current information (price, news, the status of an open-source project), the deepseek_search plus deepseek_fetch combo removes the need to build a custom scraper or integrate a second API just for that. The content already comes in Markdown, a format most models handle well, without needing to clean up HTML by hand.

But it's worth looking at the limits before putting this into production:

• Search index quality: Vercel doesn't detail where the index used by DeepSeek Search comes from, nor how it compares to more established services in this niche, like Exa or Perplexity.
• Non-deterministic fallback: as shown above, relying on the model to decide the retry order isn't the same as having a fallback circuit in the code.
• Per-request cost at scale: $0.75 per thousand calls seems cheap in isolation, but an agent that runs several searches and several fetches per task adds up fast, especially in flows with refinement loops.
• Coupling to the AI Gateway: using these helpers via gateway.tools ties the implementation to Vercel; migrating to another agent orchestrator later requires rewriting that part.

For anyone already on the AI SDK who just wanted a quick way to give the agent web access without adding another vendor to the bill, the package solves it directly. For anyone who needs fine control over the data source, predictable latency, or guaranteed fallback, it's worth testing, but without swapping out a search architecture that already works just because it got easier to plug in.