Models have a training cutoff, but the web doesn't stop. A library ships a breaking change, an API renames a field, a framework deprecates a pattern — and an agent working from memory will confidently get it wrong. So we wired built-in web search into all four providers, using each one's own server-side search rather than a bolted-on scraper.
Credential mode matters: capped Claude search can use Gate 15 credit, while GLM, GPT, and Gemini search requires your key for that provider. Their APIs do not expose a hard per-request search cap, so Gate 15 does not put those tools on the shared wallet.
One capability, four implementations
Each provider exposes search differently, so we meet them where they are instead of forcing a lowest-common-denominator shim:
- Claude uses its server-side web_search tool directly.
- GLM searches through its own built-in web_search tool.
- GPT searches through the Responses API's built-in web_search tool.
- Gemini 3.x uses Google Search grounding alongside its function calling.
Search you can see
When the agent searches, it shows up as its own activity in the project timeline — not a hidden side effect. You can see what it looked up and when, which matters when you're trying to understand why it chose a particular approach. The loop never runs these searches itself; they're handled server-side by the provider and surfaced back as a result.
Why it matters for code
The newest models often know more than their training data suggests, but "often" isn't good enough when a single wrong import breaks a build. Letting the agent verify the current shape of an API before it writes against it turns guesswork into something closer to how a careful engineer works: check the docs, then write the code.