web_search on Chat Completions and Messages. Lume 2 does not support this server-side tool.
Before you start
Create an API key in the dashboard withchat:completions for Chat Completions or messages:create for Messages. If your key has a model allowlist, include lume-3.5. Keep the key on your server and set it in the shell where you run the examples:
Authorization: Bearer or x-api-key. Supplying both with values returns HTTP 401.
For SDK examples, install the client you use. cURL examples do not need an SDK.
.py file.
Messages accepts an optional anthropic-version header. If supplied, it must be one valid calendar date in YYYY-MM-DD form. It is a compatibility hint and does not change the supported features. The SDK supplies its version header automatically.
Chat Completions
CallPOST /v1/chat/completions with chat:completions. Declare the tool in tools and use the named choice shown below to require it. Omit tool_choice when the model should decide whether it needs the tool.
choices[0].message.content. Source references appear in choices[0].message.annotations with type: "url_citation". Each url_citation has url, title, start_index, and end_index. Use those offsets to associate a source with the cited text, and display source links with the answer.
Chat returns the final answer and annotations; it does not return the native Messages server-tool result blocks. An absent citation is not evidence that a claim was verified. Check the answer and successful-operation counts when the task depends on retrieval.
Messages
CallPOST /v1/messages with messages:create. The named choice is {"type":"tool","name":"web_search"}. The declaration uses the same tool options as Chat.
content array with server tool calls, tool results, and answer text. Read all blocks; content[0] may be a tool call rather than text. HTTP 200 does not imply every tool operation succeeded.
A server_tool_use block identifies the search. Its paired web_search_tool_result contains source entries with URLs and titles, or a web_search_tool_result_error. Text citations use type: "web_search_result_location" with a source URL, title, and cited text. Preserve opaque fields when you reuse the returned history.
Control the search
Each domain list supports up to 100 entries. Use hostnames without a scheme or port, such as
docs.python.org. Search also accepts a path restriction such as docs.python.org/3/tutorial/; path patterns may use *. Do not combine nonempty allowed_domains and blocked_domains lists.
Search citations are enabled by default. Use the returned source information to make links available to your reader. The citations and max_content_tokens controls described for fetch are not search controls.
You can declare web_fetch alongside search when the model should read a discovered page. A search result can supply an eligible fetch URL. Search and fetch each have their own max_uses budget; a successful search does not mean a page has also been fetched.
Continue a conversation
For Chat, include the earlier user and assistant turns with your next question. The returned annotations are source metadata, not a reusable server-tool transcript. To fetch a previously cited URL on a new Chat request, include that URL explicitly in user text. For Messages, preserve the full returned assistantcontent, including server calls, results, citations, and opaque fields, before appending the next user turn. Keep the relevant tool declarations on the follow-up. The returned server-tool history is account-bound and has a seven-day replay lifetime. Do not fabricate or edit source blocks, and do not reuse another account’s history. Expired or invalid history is rejected; start a fresh retrieval when needed.
Streaming and output limits
Setstream: true to receive protocol-native events. This server-side workflow runs before emitting the result: the connection can send SSE comment keepalives while model and tool work completes, then emits the answer and source events. It does not provide live token-by-token or per-operation progress during that work.
Chat citations arrive in choices[].delta.annotations. To receive final usage, add stream_options: {"include_usage":true} and handle the usage-only chunk with choices: [] before [DONE]. Messages sends server-tool/result blocks, text and citation deltas, and final usage in message_delta, followed by message_stop. Check in-stream errors as well as the initial HTTP status. Streaming provides complete SDK stream readers.
The supported models have a 400,000-token context window and up to 32,768 output tokens. Both APIs reduce the output budget to the model maximum and remaining context space. Messages requires a positive max_tokens; Chat defaults to the model maximum when no budget is supplied. The examples set 512 output tokens and one tool use. Tool output and intermediate model work also need context; high max_uses does not guarantee every permitted operation will run.
Usage and pricing
The request consumes model tokens plus successful tool operations. Retrieved content and intermediate model turns contribute to token usage. Failed operations do not incur the successful-operation charge, but model tokens already used can still consume allowance. Declaring a tool does not itself incur an operation charge. Readusage.server_tool_use.web_search_requests for successful operations and the normal token fields for model usage. Streaming clients must read final usage. Pricing lists rates per 1,000 successful operations and a combined-cost example.
Before execution, the request reserves estimated usage; unused reserved usage is released afterward. Set an explicit output budget and a small max_uses to bound work. A request can require more available usage to start than its final cost. max_uses is an operation ceiling, not a complete monetary ceiling.
Common failures
Messages tool errors appear inside the tool-result
content object as an error_code, even on HTTP 200. Chat exposes the final answer, annotations, and usage rather than those native error blocks. On Chat, inspect the answer and counters instead of looking for a Messages result object. Keep X-Request-Id for support; Messages also returns request-id.
