TL;DR
APIYI’s default Claude group routes to official AWS Claude (Amazon Bedrock), and AWS itself does not support Claude’s native web search — this is a Bedrock architecture limitation, not a gateway configuration issue. To get web access, you have two options:| Path | Best for | Stability |
|---|---|---|
Option 1: ClaudeOfficial beta group (native web_search tool) | You specifically need Anthropic’s native search experience and can accept beta-level stability | ⚠️ Beta, less stable than the default group |
| Option 2: Custom search tool (works on the default group, recommended) | Production workloads that need stability and control | ✅ Same tier as the default group |
Why doesn’t the default group support it?
Claude’sweb_search / web_fetch are server-side tools: the search is executed by Anthropic’s own server infrastructure. AWS Bedrock only provides model inference and has no such search backend, so the Bedrock interface rejects these tools at the validation layer. Bedrock’s tool-type whitelist only includes client-side tools:
mcp_servers parameter) is also a server-side feature and is not supported on the default group.
Option 1: ClaudeOfficial beta group (native web_search)
APIYI offers a beta group called ClaudeOfficial (direct Anthropic official channel) that supports Claude’s nativeweb_search / web_fetch tools.
- How to enable: contact customer support to have your key added to the ClaudeOfficial group
- Stability note: this is a beta group and is less stable than the default group — for important workloads, prepare a fallback (Option 2 works well as the fallback)
Request example
| Tool | type | Notes |
|---|---|---|
| Web Search (recommended) | web_search_20260209 | With dynamic filtering, for 4.6+ models |
| Web Search (basic) | web_search_20250305 | Compatible with earlier models |
| Web Fetch | web_fetch_20260209 (legacy: web_fetch_20250910) | Fetches content from a given URL |
max_uses (limit the number of searches), allowed_domains / blocked_domains (domain filtering).
How to verify the search actually ran
A successful response containsserver_tool_use and web_search_tool_result blocks in content, with citations in the answer text, and a counter field in usage:
text blocks and usage has no server_tool_use, the request did not reach a search-capable channel.
Billing
- Tool names:
web_search,web_fetch - web_search: $10 / 1,000 searches ($0.01 per search, counted by
usage.server_tool_use.web_search_requests— one answer may trigger multiple searches) plus normal token fees; failed searches are not billed - web_fetch: no per-call fee; fetched content is billed as input tokens
- Reference cost per web-enabled Q&A (sonnet): roughly $0.02–0.08
Option 2: Custom search tool (works on the default group, recommended for production)
The default group (Bedrock) fully supports standard function calling (custom tools). Define a search tool, have your client execute the actual search (via a search API such as Tavily / Brave / Serper / Bing), and feed the results back to the model. In testing, Claude actively calls the tool, rewrites queries in both Chinese and English, and produces sourced answers after multiple search rounds.Complete example (Python)
Cost reference
- Model token fees: one multi-round search Q&A uses roughly 10k input + 1–2k output tokens (about $0.05 on sonnet)
- Search API fees: Tavily free tier 1,000 calls/month (paid roughly $0.008 per call), Brave $3 / 1,000 calls — the same order of magnitude as the official web_search
- Advantages: channel-agnostic, controllable and cacheable search sources, and you keep the default group’s stability and cache billing benefits
Advanced: MCP search sources
If you already use the MCP ecosystem (e.g. Tavily MCP, Brave MCP), connect to the MCP server on the client side and convert its tools into the custom tools shown above — the principle is identical. Note: passing themcp_servers parameter directly in the request (server-side MCP) is not available on the default group.
FAQ
Q: I sent the web_search tool on the default group and got no error — does that mean it’s supported? A: No. The default group handles server tools gracefully (ignores them); the request returns 200 but no search happens. To verify: check whether the responsecontent contains server_tool_use blocks and whether usage has the server_tool_use.web_search_requests field — if not, no search was executed.
Q: What about passing the mcp_servers parameter?
A: Also unsupported (it’s an Anthropic server-side feature as well). Important: in this case the model may generate plausible-looking “tool result” text in the answer body — that is a hallucination, not real data. Do not rely on it.
Q: How do I choose between the two options?
A: For production, prefer Option 2 (stable and controllable). If you need Anthropic’s native search quality, citation format, or don’t want to build your own search, contact customer support to enable the ClaudeOfficial beta group — and keep a fallback ready.
Related Docs
Claude API Basics
Channels, model list, setup, and billing basics
Claude Prompt Caching
Multi-round search Q&A pairs well with caching for major cost savings