Downloads · 30 days
28
41% of all-time downloads
ekontoTURBI/gemma-4-E4B-pocket-studio
gemma-4-E4B-pocket-studio is a text generation model from ekontoTURBI. Use it when you need the model to write or continue text. It is set up for litert-lm. The card lists the license as gemma.
A language model that builds working web apps, on your phone, with the internet switched off.
Downloads · 30 days
28
41% of all-time downloads
All-time downloads
69
Public
Repo size
5 GB
Likes
0
Public
Click a slice to open those files.
.litertlm5 GB · 100%
From the Hugging Face model README
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.
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.
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.
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.
| 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.
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..litertlm for LiteRT-LM.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.
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.
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.
@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}
}