Repository navigation
[FEATURE]: Support xAI native x_search/web_search built-in tools for Grok models (opt-in, scoped to @ai-sdk/xai) #54168
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before (related but distinct: [FEATURE]: Use provider-hosted web search when available #10704, which is scoped to OpenAI's
web_searchand doesn't mention xAI).
Describe the enhancement you want to request
Problem
Grok models (xai/*) have a genuine, officially documented native capability to search X (Twitter) and the web in real time via xAI's Responses API built-in tools (x_search, web_search). Today, OpenCode never requests these tools, so a Grok-based agent has zero access to them and will honestly report it has no real search tool when asked — even though the exact same model, called directly against api.x.ai with tools: [{"type": "x_search"}], returns real cited X posts.
Docs: https://docs.x.ai/developers/tools/x-search and https://docs.x.ai/developers/tools/web-search (both "Responses API compatible" built-in tools, confirmed via @ai-sdk/xai's xai.tools.xSearch() / xai.tools.webSearch() helpers).
Why this should be opt-in and scoped, not default-on
- Both tools are billed per call independent of token costs (
x_search: $5/1k posts fetched, $10/1k profiles fetched), so silently enabling them for every xAI request would be a surprise-billing footgun. - It should be scoped by
model.api.npm === "@ai-sdk/xai"(not aproviderID === "xai"string match), so it also covers any custom-named xai-compatible provider entry a user defines, consistent with how this same file already keys behavior offapi.npmrather than provider id. - Proposed shape (illustrative, happy to adjust to whatever config convention maintainers prefer):
{
"providers": {
"xai": {
"options": {
"nativeTools": { "xSearch": true, "webSearch": true }
}
}
}
}...or exposed as agent/tool permission entries (x_search, web_search) reusing the existing allow/deny/ask permission UX, so users get the same guardrail they already have for webfetch/websearch.
Known related footgun found while investigating
OpenCode's currently bundled @ai-sdk/xai version appears to lag behind xAI's current API surface — see #43226, where a reasoningEffort: "xhigh" value xAI's API actually supports gets rejected by OpenCode's local Zod validation. Whoever picks this up should first confirm the pinned @ai-sdk/xai version actually exposes tools.xSearch / tools.webSearch, and bump it if not.
Request
Add an opt-in way to enable xAI's native x_search / web_search built-in tools for @ai-sdk/xai-backed models, scoped strictly to that SDK, with the same permission UX used elsewhere, and a clear cost warning in the docs given the per-call billing.
Activity
opencode-agent commentedon Oct 9, 2026
Thanks for the detailed write-up, @vinlee19!
To restate the request: add a way to opt in to xAI's server-side
x_search/web_searchtools for Grok models served through the xAI SDK. It would be off by default and behind the permission system, since xAI bills these per call.One note: the files you mention (
packages/opencode/src/provider/provider.ts,session/llm/request.ts) are from OpenCode v1 (1.x). New features only go into v2 (2.x,@opencode/cli), where providers are implemented differently. In v2 the xAI provider (packages/ai/src/providers/xai.ts) doesn't currently offer xAI's search tools, though a few other providers already have their own built-in web search, so there is a pattern to follow.Related:
web_searchMaintainers will consider this request. I can't promise if or when it will be added.
vinlee19 commentedon Oct 9, 2026
@rekram1-node @thdxr curious if this direction seems reasonable to you both before I sink time into a PR.
rekram1-node — tagging you since you've been closest to the xAI provider quirks (#20500, #43226), figured you'd have the best gut check on whether gating this by
api.npm === "@ai-sdk/xai"+ an opt-in config flag is the right shape, or if you'd rather see it done differently (e.g. permission-based like webfetch/websearch instead of a provider option).If this seems like a reasonable scope, I'd like to take it on. Per the contributing guide I'll wait for a thumbs up before opening a PR.
vinlee19 commentedon Oct 14, 2026
Following up since my earlier question — happy to keep waiting if this is still being considered, but in the meantime I've been studying the v2 tree and most of the groundwork seems to already exist:
packages/ai/src/protocols/xai-responses.tsalready parsesx_search_call/web_search_calloutput items intoproviderExecutedtool-call/tool-result eventsToolDefinition.native+ adapternativeTool(...)lowering already has working examples on other Responses providers (alibaba, meta) — the xAI adapter just hasn't implemented one yetSo the remaining gap looks like: a
nativeToolfor the xAI Responses adapter, a user-facing opt-in, and docs.One design question before I start: for the opt-in surface, is the preferred shape a provider option (
providers.xai.options.nativeTools), a permission entry alongsidewebfetch/websearch, or whatever fits the direction of #35038? Still planning for off-by-default given the per-call billing.