Do the CodeLifter prompts work with local models?

What has been tested, and what has not

Each CodeLifter prompt page has two parts that are easy to confuse. The code on the page was written and tested by the editors, and re-run in a scripted DOM test on 2026-10-15. The prompt above it describes that code. The prompt itself has not been sent to any named assistant, which is why every page says "Not yet run against a named assistant".

So "do they work" has an honest answer in two halves. The prompts describe code that is known to work. Whether your model, at your quantisation and settings, writes code that matches the description is something only your own run can show.

Why they travel well

The prompts were written to be checkable rather than clever. Each one names the web APIs to use (showModal(), setPointerCapture, textContent), the ones to avoid (innerHTML, inline onclick) and the behaviour to get right, such as wrapping at both ends of a slideshow. There is no tool syntax, no system prompt and no special markup, and most of the prompts are around a hundred words long.

That style follows general vendor advice rather than any one model's quirks. GitHub's prompt engineering guide for Copilot recommends a broad description first and then the specific requirements, and naming the library you want. Those habits are not specific to hosted models.

What CodeLifter has not measured is how reliably any particular model keeps a list of constraints this long. Treat that as something to check on your own setup, not something to assume either way.

Running a prompt locally

1. Pick a runner and start its server. The commands below are from each project's own docs:

Runner	Licence	Start command
Ollama	MIT	ollama run gemma4:31b
LM Studio	Proprietary app, MIT lms CLI	lms server start
llama.cpp	MIT	llama-server -m model.gguf
MLX LM (Apple silicon)	MIT	mlx_lm.server --model <repo>
vLLM	Apache-2.0	vllm serve <model>

2. Paste the prompt into the runner's chat, or point a client at its local API. Ollama documents an OpenAI-compatible endpoint at http://localhost:11434/v1/, so most client libraries only need a new base URL.
3. Save the answer to a file and check it, as described at the end of this thread.

Context length is the setting that bites

A single prompt fits easily in a small context window. An agent is different: it adds your rules file, the files it opens and its own instructions on top of the prompt.

Ollama's context length page says its default depends on memory: 4k tokens under 24 GiB of VRAM, 32k from 24 to 48 GiB, and 256k at 48 GiB or more. The same page says tasks such as agents and coding tools should be set to at least 64000 tokens. To raise it from the command line:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Then run ollama ps and read the CONTEXT column to see what was actually allocated, and the PROCESSOR column to see whether the model spilled onto the CPU. A larger context needs more memory, so check the fit before you raise it. Other runners set this differently; check the docs for yours.

For a rough memory figure, CodeLifter uses its own estimate of parameters times bits per weight divided by 8, times 1.2. By that estimate a 31.3 billion parameter model at 4 bits needs about 19 GB. The local models page has the calculator and the parameter counts for current open models.

Using a local model inside a coding agent

You do not have to paste by hand. Several agents can talk to a local runner, according to their own documentation:

• Codex CLI has built-in ollama and lmstudio provider IDs.
• Aider connects to most LLMs, including models served by Ollama.
• Cline lists Ollama and LM Studio for local models.
• Zed has a "Use a Local Model" option.
• Continue supports Ollama, but its repository is now read-only and no longer actively maintained.

Each of these reads a rules file, so put your standing rules in AGENTS.md (or the file your tool expects) and they apply whichever model is behind it. The coding agents directory lists which file each tool reads.

How to check what came back

Run the same checks you would run on a hosted model's answer. They do not depend on where the code came from.

1. Search for innerHTML, outerHTML, insertAdjacentHTML and document.write. The innerHTML thread explains why and what to ask for instead.
2. Open the prompt's page and go through its list of fixes one by one. Each fix is a real difference between an editor-written sample of a one-line-prompt answer and the reviewed code, so each is a concrete thing to look for.
3. Load the code in a current browser with the console open.
4. Put the mouse away and use Tab, Enter, Space, Escape and the arrow keys. The keyboard thread lists what should happen.
5. If the model missed a line, quote that line back to it and ask for a revision, rather than rewording the whole prompt.

If you keep notes of which model and quantisation passed which checks, you will have something more useful than a general verdict: a record for your own setup.