Repository navigation
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
Looks good to me. It follows the existing nativeTool pattern from the Meta and Alibaba Responses adapters, and XAI.xSearch() / XAI.webSearch() mirror Meta.webSearch(). I ran the xAI Responses tests, the full packages/ai suite (no failures) and the type check (clean). I also lowered both tools with and without options in a scratch test. Options you leave out are dropped from the wire body, web search domains go under filters, and wrongly typed options fail with InvalidRequest before any request is sent. I couldn't run it against the real xAI API without a key, so a recorded cassette from someone with a key would still be good to have. That would also answer your open question about custom_tool_call sub-tool items.
Public API: @opencode/ai/providers gains XAI.xSearch, XAI.webSearch, XAI.XSearchOptions and XAI.WebSearchOptions, and XAIResponses gains the XSearch / WebSearch schemas. The xAI Responses adapter now accepts native.xai tools that used to be rejected. All of this is additive and backwards compatible.
No blocking concerns.
Related: #54168
|
@rekram1-node @nexxeln — would either of you have time to review this? It's the library-only half of #54168: it adds the missing I also verified it end-to-end on the v1 side with a SuperGrok subscription login (same The one open item is a recorded cassette, since I don't have an xAI API key. The repo already has |
Issue for this PR
Part of #54168 (this is the
@opencode/ailibrary layer; the opencode-side opt-in is a follow-up, see below). Related: #35038.Type of change
What does this PR do?
packages/aialready parses xAI'sx_search_call/web_search_calloutput items into provider-executed tool events (protocols/xai-responses.ts), but there was no way to request those tools: the xAI adapter had nonativeTool, so anyToolDefinition.nativefailed with "xAI Responses does not support provider-native tool". The Alibaba and Meta Responses adapters already have this seam, so this follows them:protocols/xai-responses.ts:nativeToolon the adapter validatesnative.xaiagainst the two documented hosted search tools,{ type: "x_search", allowed_x_handles?, excluded_x_handles?, from_date?, to_date?, enable_image_understanding?, enable_video_understanding? }and{ type: "web_search", filters?: { allowed_domains?, excluded_domains? }, enable_image_search?, enable_image_understanding? }. Web search domain lists go underfiltersbecause that is how the xAI Responses API examples pass them; X search takes its handles at the top level. Anything else, including another provider's native tool, still fails withInvalidRequestbefore any network call. Compaction uses the samelowerTools, so it accepts them too.providers/xai.ts:XAI.xSearch(options)andXAI.webSearch(options)factories with camelCase options, mirroringMeta.webSearch(). The tool namesx_search/web_searchmatch what the stream parser already assigns to the hosted items.Nothing is enabled by default; the tools are only sent when a caller puts them in
tools. xAI bills them per fetched source, which is why I kept this strictly opt-in and did not add an opencode config switch here. How search gets exposed at the app level is the #35038 discussion, and I'd rather land the library piece first.One thing worth flagging for whoever has an xAI key: the X search docs say sub-tool calls (
x_keyword_search,x_semantic_search, ...) show up ascustom_tool_calloutput items. The Open Responses baseline ignores unknown item types, so if live streams use that shape instead ofx_search_call, the calls would not surface as tool events. That is pre-existing behaviour ondevand out of scope here, but a recorded cassette would settle it.How did you verify your code works?
test/provider/xai-responses.test.ts: loweredbody.toolswith and without options next to a function tool, and rejection of another provider's native tool. They failed first (XAI.xSearch is not a function), then passed.bun testinpackages/ai: 1818 pass, 0 fail.bun typecheckclean. oxlint and prettier clean on the changed files.Screenshots / recordings
Not a UI change.
Checklist
Added by the opencode bot (AI-generated).
Related: #54168
Public API: adds XAI.xSearch / XAI.webSearch hosted tool factories and their option types to @opencode/ai (backwards compatible)