ekontoTURBI/gemma-4-E4B-pocket-studio

Gemma Pocket Studio — E4B

A language model that builds working web apps, on your phone, with the internet switched off.

This is a fine-tune of Google's gemma-4-E4B-it, packaged as a single .litertlm file that runs entirely on an Android device. No server. No API key. No account. After a one-time download, it never touches the network again.

It powers Gemma Pocket Studio, an open-source Android app where you describe an app in plain words and watch it get written — HTML, CSS and JavaScript — file by file, live, on the phone in your hand.

---

New here? Start with this

Large language models normally live in data centres. You type, your words travel to a rented computer somewhere, and an answer comes back — which is why they need internet, an account, and usually a credit card.

This model doesn't do that. It has been shrunk and re-packaged so the whole thing fits in a phone's memory and runs on the phone's own processor. The trade-off is that it is small, so it is not a general-purpose assistant. It has been trained for one job: writing and editing small web apps.

At that one job, it beats the model it was built from.

---

What it's actually better at

Measured against stock gemma-4-E4B-it, same prompts, same scoring code, same device class. The scorers are mechanical — code is run through a real parser, edits are applied with the app's real patch engine. Nothing here is a vibe check.

What we measured	Why it matters	Stock	This model
Produces exactly one reasoning block	Malformed output leaks into the chat UI	83.3%	100%
Its edits actually apply	A patch that doesn't apply is a wasted generation	75.0%	100%
JavaScript parses (node --check)	Broken JS means a broken app	100%	100%
References real element IDs	JS that targets non-existent elements silently does nothing	71.4%	100%
Runs out of room mid-file	Truncated file = unusable app	12.5%	0%
Complete HTML document	—	75.0%	75.0%
CSS selectors match its own HTML	—	60.0%	53.1%

The headline is the edit row. Generating a fresh app from scratch is the easy half; the hard half is changing an app that already exists without breaking it, which is what you spend most of your time doing. This model produces a valid, applicable patch every time in our set — the stock model manages three out of four.

Please read this before quoting those numbers

The sample is 4 held-out app prompts and 4 edit probes. That is enough to catch a build that is badly broken — it is not enough for a confident quality claim, and the two rows where the gap is small (HTML completeness, CSS selectors) are well inside the noise for that sample size. We are reporting it because publishing a small honest number beats publishing a big vague one. A larger evaluation is the next thing on the list.

---

Requirements — please check before downloading 5 GB

Device RAM	12 GB or more. This is the hard one — see below.
Android	12 (API 31) or newer, arm64-v8a
Free storage	~6 GB
Runtime	LiteRT-LM (bundled in the app)
Internet	Once, for the download. Never again.

Why 12 GB and not 8 GB. The file is 4.98 GB, but file size is not the whole story. The model is memory-mapped, so loading it looks almost free — and then generating text touches nearly every weight and pulls it into RAM. Measured resident memory during generation: 4.93 GB. Add ~2–2.5 GB for Android itself, plus the app and its live preview browser, and an 8 GB phone has nothing left.

It will not crash cleanly if you force it. Memory-mapped pages get evicted and re-read, so it degrades into thrashing — the app just gets slower and slower while Android quietly kills whatever else you had open. That is a worse experience than not offering it, which is why the app checks your device's RAM at launch and picks a model that actually fits.

---

How it was built

1. Data. A few hundred multi-task examples: build-an-app prompts, and edit prompts where the target is a SEARCH/REPLACE patch. Every edit example was validated by actually applying its patch — an example whose diff didn't apply never made it into training.
2. LoRA. Rank-stabilised adapters on attention and MLP projections, ~35M trainable parameters. Held-out loss 0.897 → 0.513, flat by step 60 — the binding constraint is data volume, not compute.
3. Merge. Adapter merged into bf16 weights; no adapter needed at inference.
4. Quantize + package to .litertlm for LiteRT-LM.

The quantization is the interesting part

Getting this under 5 GB was not a matter of picking a smaller number. We exported three builds and benchmarked all of them:

Build	File	RAM in use	JavaScript parses
int8 everywhere	6.44 GB	5.47 GB	3 of 4
int8 attention + int4 MLP ← shipped	4.98 GB	4.93 GB	4 of 4
int4 everywhere	4.38 GB	3.68 GB	1 of 4

Dropping everything to 4-bit gave the smallest file and would have fit an 8 GB phone — and it destroyed the model's ability to write valid code. Three of four apps came back with syntax errors: a malformed switch, a generation cut off mid-expression, JavaScript wrapped in a stray </script>. Different failures, one cause: 4-bit attention wrecks the long-range consistency that code depends on.

Keeping attention at 8-bit and quantizing only the MLP layers to 4-bit (block-wise, 32 weights per scale) recovered all of it, and still shed 1.46 GB versus the int8 build.

One more thing worth knowing if you do this yourself: the file-size-to-RAM ratio was ~85% for both uniform builds and 99% for the mixed one. Do not predict a variant's memory footprint from its file size. Measure it.

---

Known limitations

• Responsive design did not transfer. Zero out of four generated stylesheets used mobile-first breakpoints — identical to the stock model. The training data had too few responsive examples for it to stick. This is a data problem and it is the top item for the next round.
• CSS selector accuracy regressed slightly (60% → 53%): it sometimes writes utility classes it never uses in the HTML.
• 8 GB phones are not supported — see Requirements.
• Small evaluation set — see the warning above.
• It is a ~4B model specialised on one task. It is not a general assistant, it will not do your maths homework, and it does not know about events after its base model's training cutoff.

---

Bringing this to smaller phones

The device requirement is the honest weak point of this release, and it's the part Cognitra is actively working on.

A 12 GB phone is a fairly expensive phone. The people who would benefit most from a free, offline, zero-cost AI build tool are, very often, exactly the people not holding one. A tool for everyone that only runs on flagship hardware isn't really for everyone.

So the work continues on the memory floor: smarter mixed-precision recipes that protect the layers that matter and compress the ones that don't, better training data so a smaller model can carry the same behaviour, and packaging that keeps less resident during generation. The int4 experiment documented above was one attempt — it failed, we measured exactly how, and that measurement is what makes the next attempt better rather than luckier.

If you work on edge inference and want to make this fit in 6 GB, the benchmark harness and every export recipe are open in the repo. Come argue with our numbers.

---

Licence and provenance

This model is a derivative of google/gemma-4-E4B-it and is governed by the Gemma Terms of Use and the Gemma Prohibited Use Policy, which apply to this model exactly as they apply to the base model. By downloading it you agree to them.

The application code is MIT-licensed and separate: https://github.com/ekontoTURBO/gemma-pocket-studio

Gemma is a trademark of Google LLC. This project is not affiliated with or endorsed by Google.

---

Citation

@software{gemma_pocket_studio_e4b,
  title  = {Gemma Pocket Studio E4B: an on-device web-app generator},
  author = {Czekalski, Eryk},
  year   = {2026},
  url    = {https://github.com/ekontoTURBO/gemma-pocket-studio},
  note   = {Fine-tune of google/gemma-4-E4B-it packaged for LiteRT-LM}
}