Web search not working in Whizi: why it did not run

The short answer

In most cases no search was ever issued. With the toggle on, Whizi first sends the model a cheap probe tool of about 50 tokens, and a real web search only runs on a turn where the model actually calls that tool. If the model judged it could answer from what it already knew, no search happens and you get an unsourced answer with the toggle still showing green.

The causes, in the order worth checking:

What you saw	Most likely cause	What to do
Toggle on, answer has no sources	The model never called the probe tool, so no search was issued	Nothing on your side forces a search: the model decides per turn
Toggle looks off in this chat	The toggle is stored per conversation, not per account	Switch it on again in this conversation
Only two or three sources came back	An ordinary search is capped at 3 results	Nothing to change: 3 per search and 3 in total is the cap
An error mentioning a boolean	The request body was malformed	Reload the page and resend
The whole message errored	A model provider failure	Retry, then contact support if it repeats

Why the toggle being on does not mean a search ran

A request runs in one of three search modes: off, probe, or native.

Probe mode is the cheap stand-in. The model is handed an ordinary function it can call, costing roughly 50 tokens, and only a message where it actually calls that function gets re-issued with real search attached. On messages that never needed the web, probe mode is about 46 times cheaper than native, and on the ones that do need it, it costs about 0.8 percent extra.

Native mode runs the provider real web search tool directly. It is not free: the tool definition injects a fixed preamble of roughly 4,400 input tokens. The same two-message prompt measured 36 tokens without the tool and 4,472 with it.

The toggle permits a search. The model decides whether to run one, which is why a question like "what is a good CRM" can come back with no sources while "what did this company announce this week" comes back searched, in the same conversation, with the toggle untouched.

Web search is a per-request user toggle rather than a per-model capability flag, so there is no published list of models that can browse and models that cannot.

The exact error strings and what each one means

Whizi clients render the backend error.message directly, so the string in front of you is the one the route emitted. If you have one of these in front of you, this is what it is telling you.

Error string	HTTP and code	Trigger
webSearchEnabled must be a boolean.	400, invalid_generate_request	The website send route received a webSearchEnabled field that was not true or false
webSearch must be a boolean.	400, invalid_chat_request	The app chat route received a webSearch field that was not true or false
Web searches failed. You have not been charged.	Written onto a failed run	Fewer than the minimum number of searches completed on a Deep Research run

The two boolean errors report a malformed request. The value the client sent for the search flag was not a boolean, and nothing about your account, plan or model caused it. Reload the page and send the message again. If a reload does not clear it, contact support.

Web searches failed. You have not been charged. is written onto a failed Deep Research run when fewer than the minimum number of searches complete. The credits are not taken. Try the request again later.

The results came back, but there were only three

An ordinary search request is capped at 3 results per search and 3 results in total, at low search context size. A thorough looking question and a trivial one both come back with at most three pages behind them.

One route behaves differently. The Canadian CPA agent is the only route that forces web search on every turn, capped at 7 searches, and its searches are restricted to an allowed domain list and an approximate Canadian user location. On that agent, results from a narrow set of sites are the allowed domain list at work.

If the answer is out of date rather than unsourced, or you want to check a figure against more than one retrieval, that is covered in using web search and in the troubleshooting hub.

When the whole message fails

A search turn can also die for reasons that have nothing to do with search. These strings come from the model provider layer and mean the generation itself failed.

Error string	HTTP and code	Meaning
The model is temporarily rate-limited. Please retry shortly.	429, provider_rate_limited	The upstream provider refused the connection, not Whizi
The model provider rejected the request.	502, provider_error	The provider error body could not be read
The model provider returned an empty stream.	502	The upstream response was fine but carried no body
The model stream was interrupted.	In-stream error event	The stream failed part way through
Too many requests. Please wait and try again.	429, rate_limit_reached	You hit a Whizi rate window

Chat messages are limited to 10 per minute and 60 per hour per user, flat across every plan, with a shared ceiling of 30 requests per minute across all routes. A refused request costs nothing: rate-limit refusals are unwound, so a 429 never spends a message off your allowance.

None of these have a setting on your side that prevents them. Wait a moment and send again. If the same model keeps failing across several minutes, switch to a different model to keep working and contact support so it can be looked at on your account.