The setup, as the author describes it
Jonker's own account is that most of his Google AI Plus use was routine lookups. He runs Gemma 4 E4B in LM Studio on a desktop with an RTX 3070 (8GB VRAM) at Q4_K_M, a 4-bit quantization. On his iPhone he uses Noema, a free iOS app for local models. He says the 8GB card handles the model with "zero lag". That is a subjective report, and it shouldn't be read as a promise for every 8GB GPU. Speed and memory use depend on the quantization, the runtime and the context length you set.
LM Studio's own model page lists E4B as roughly a 5.9 GB download. A third-party Gemma 4 LM Studio guide recommends the E4B at Q4 for machines with 8 GB of RAM. That fits Jonker's setup, though it comes from a community site and not a benchmark.
What the model actually is
Google's model card says E4B has 4.5B effective parameters, or 8B with embeddings, and that the "E" stands for "effective." Per-Layer Embeddings are why the effective count is so much smaller than the total. The embedding tables are large but are used only for lookups. So the "4B" label is a fair shorthand, but it hides a bigger file than the name suggests.
Other documented specs:
- Context window: 128K tokens for E2B and E4B, per Google's model card and launch post. That is capacity, not a guarantee of accuracy. Your app may also cap it.
- Training cutoff: January 2025, according to the model card. Anything newer has to come from tools.
- License: Apache 2.0, per Google's launch post.
- Intended use: Google positions E2B and E4B for phones and edge devices, with native audio input.
- Lineage: Google says Gemma 4 is built from the same research and technology as Gemini 3.
The model card also carries a plain warning. Models are "not knowledge bases" and can produce incorrect or outdated statements. That is exactly why the search tools matter.
Why tools do the heavy lifting
Jonker's central point is that a small model's weak memory matters less once it can retrieve information. In LM Studio he uses two Model Context Protocol (MCP) tools. A Brave Search MCP returns links and short snippets. A separate fetch tool opens the full page so the model can read it.
The split matters because snippets are only a line or two. Jonker says models that answer from snippets alone often credit facts to the wrong page. He adds that Open WebUI now cites only pages the model has actually opened.
Other setup guides back up the pattern:
- One LM Studio MCP walkthrough says that once a Brave Search MCP is enabled, the model recognizes when a query needs a web search, and LM Studio asks you to approve the request before the search runs. That approval step is a useful check on what leaves your machine.
- Parallel's guide for local agents advises keeping the tool count low, because small models degrade at tool selection faster than frontier models. It says two well-described tools, search and fetch, beat twenty. This vendor sells its own search service, so treat it as general advice and not an endorsement.
Benchmark claims, and how far they go
Google's model card lists E4B at 42.2% on Tau2 (average over three runs) against 16.2% for Gemma 3 27B without thinking. That supports Jonker's comparison. Tau2 is one benchmark of tool-driven, multi-step tasks. It doesn't show that E4B beats a bigger model in general, and it says nothing about how it behaves in your search setup.
The same table cautions against over-reading the model. E4B scores 52.0% on LiveCodeBench v6 and 25.4% on a long-context retrieval test (MRCR v2 8-needle at 128K). The larger Gemma 4 models do much better on both. The 31B scores 66.4% on the retrieval test. That suggests the 128K window is better treated as headroom than as proof the model uses it well.
Jonker also cites a community run on the Berkeley Function Calling Leaderboard. It had stock E4B at 84 out of 100 on knowing when not to call a tool, but only 7 in the web-search category that requires several searches. I couldn't confirm those figures on the official leaderboard. The official page describes BFCL as measuring accurate function calling across several categories, so treat the two numbers as a community result with unknown configuration.
His own observation matches that weakness. The model nearly always searched when it should, then answered from one search instead of digging further. That is anecdotal, but it points to a practical rule.
Privacy: local model, networked research
Running a model locally doesn't mean the research stays on your machine. Web search sends your query to a search service. Jonker says Noema routes searches through a no-log relay the developer runs on SearXNG. That is the developer's claim and has not been audited. With a Brave MCP, queries go to Brave and need an API key. The model runs offline, but the search doesn't.
Document upload and filesystem access are different. Jonker notes both LM Studio and Noema support uploading documents, and that he has a filesystem MCP in LM Studio for batch file work. Feeding the model material you have already curated keeps that content on your own hardware. That is arguably the strongest local use case.
A practical recipe for Windows users
This is general guidance synthesized from the sources above, not a tested procedure.
- Pick a size your hardware fits. E4B at Q4 is about a 6 GB download in LM Studio. Leave memory free for the context window and the OS.
- Add a search tool and a fetch tool. Keep the tool list short. Approve each call at first, so you can see what is being sent.
- Ask one clear question at a time. Jonker found this gave better answers than broad, multi-part requests.
- Prompt for more searching if the first pass is thin. The model tends to stop after one search.
- Open the cited pages yourself for anything that matters. Citations show where an answer came from. They don't prove the page says what the model claims.
- Feed it your own documents when the topic is narrow.
Where the "replacement" claim stops
Jonker keeps free Gemini access for the occasional large report. He says the free tier includes five Deep Research reports a month. I couldn't verify that quota against an official Google plan page, so check it before relying on it. Google's own Deep Research runs searches at a far larger scale than a 4B model on a desktop. His conclusion, in his words, is that the small model covers everything else, as long as it can search and has room to read what it finds.
The fair reading is narrower than the headline. A free 4B model with working tools can handle a lot of routine lookups. It won't match a cloud service on deep, multi-source reports. It also asks you to do more of the checking. For a lot of people that trade is worth it, and the cost of trying it is a download and an afternoon.