Type a topic, get a real .pptx. A local language model writes the deck structure and content; a library of hand-built layouts renders it. No API key, no cloud, no per-deck cost — the model runs on your own machine.
| Version | Lines | What changed |
|---|---|---|
| v1 | 1,229 | First working build: Ollama → pptx, 6 themes, CSV charts, PDF notes |
| v2 | 876 | Trimmed and reorganised; ppt generator grew as the app shrank |
| v3 | 1,547 | Hotfix release; chart engine rewritten (3.4 KB → 13.2 KB) |
| v4 | 1,629 | 8 professional layouts, 10 slide types, batched generation to beat timeouts |
| v5 | 1,832 | Current. 13 layout templates, largest ppt generator (39.5 KB) |
The interesting design decision is that the model never describes layout. It returns a slide type — title, statistic, quote, process and so on — and the builder dispatches to the matching template. A statistic slide therefore renders completely differently from a quote slide without the model having to reason about geometry, which is exactly the kind of task small local models are bad at.
_repair() existsA hosted frontier model returns clean structured output. A 1.9 GB model running on a laptop returns output that is nearly right: arrays where a string was expected, unescaped newlines inside strings, trailing commas. Parsing that with json.loads() fails, and the whole generation is wasted after a 90-second wait.
ollama_client._repair() handles those three failure modes specifically. This is the practical difference between a demo that only works against a paid API and one that works offline on someone's own hardware — and it is the part of this project most worth reusing.
The client also discovers models dynamically through /api/tags rather than hardcoding a model name, so whatever the user has pulled appears in the picker. That is why the verification below succeeded on llama3.2 despite the documentation recommending mistral.
Environment: Windows 11, Python 3.12, Ollama 0.32.13, llama3.2:latest (1.88 GB), CPU only.
| Check | Result |
|---|---|
check_ollama() | Pass — (True, 'Connected') |
list_models() | ['llama3.2:latest'] |
generate_slides(), 4 slides | Pass — 91.5 s and 108.2 s across two runs |
build_presentation() | 35,945 bytes of valid OOXML |
PPTX reopens in python-pptx | Pass — 4 slides |
| Slide dimensions | 9,144,000 × 5,143,500 EMU (16:9) |
| Shapes per slide | 13, 22, 19, 16 |
| Streamlit boots | HTTP 200, /_stcore/health → ok |
[1] title Renewable Energy Basics [2] content What is Renewable Energy? [3] statistic Renewable Energy Growth [4] quote Renewable Energy Expert
Four different slide types, each dispatched to a different template. The run used fetch_images=False to stay fully offline.
Generation takes 90–115 seconds for a 4-slide deck on CPU with a 1.9 GB model. That is not fast. A larger model or a GPU changes it substantially, but neither was used here, so neither is claimed.
ollama serve ollama pull llama3.2 python -m venv .venv && .venv\Scripts\activate pip install -r neuroslide_v5/requirements.txt cd neuroslide_v5 streamlit run app.py # http://localhost:8501
NeuroSlide is where the local-LLM-plus-Streamlit approach the shipped BitWithBite AI tools now use was first figured out: dynamic model discovery over /api/tags, streaming generation, a JSON repair layer for small-model output, and zero API cost treated as a design constraint rather than an afterthought.
MathGenius shares the same client shape, built alongside it. Both feed into the current tools listed on the portfolio, which run on local models for the same reason.
With llama3.2 the output is structurally correct and topically reasonable, not expert-grade. No claim is made about the factual accuracy of generated slide content — it is LLM output and should be checked before use. There is also no test suite; the verification above is a scripted manual run, not CI.
Four of the nine charts NeuroSlide's chart engine produced in a single pass from one uploaded spreadsheet. These are the unmodified PNGs the app wrote to disk, arranged into a contact sheet.
Running generation locally means no key, no per-deck cost, and no document leaving the machine. The engineering that makes it viable is the repair layer around imperfect small-model output.