PDFMacroPDFMacro
On-device inference

The AI runs here.
Including its limits.

Every model PDFMacro uses runs on your machine — either in this browser tab, or on an AI server you run yourself. This page names them, says what each is for, what it costs to download, and where a model small enough to sit beside your document stops being good enough.

Where inference happens

Two places, and one that is never used.

In this browser tab

The built-in models. Weights are fetched once and cached on the device; after that the document and the model are in the same tab and inference makes no network request at all.

On a server you run yourself

Optional. If you already run Ollama or LM Studio, PDFMacro can use your models instead. Document excerpts then go to that endpoint — your machine — and the code refuses to send them anywhere else.

A third-party AI cloud

Never. There is no hosted inference provider in this codebase to send text to — no key, no endpoint, no client. The absence is the mechanism, not a setting.

The built-in models

Three models, named by what they do.

The names below are the ones the app itself uses in its readiness panel. “MiniLM” and “NER” are how two downloads are told apart in code; they are no help at all to someone deciding whether to spend ~110 MB of their connection, so the repository id is kept for auditing and the capability leads.

Understanding what you type
~45 MB

Understanding what you type in the command bar, and Pre-discovery search

Xenova/all-MiniLM-L6-v2
Finding names and sensitive details
~110 MB

Finding names and other sensitive details in a document, and Privilege review

Xenova/bert-base-NER
Drafting document text
~145 MB· opt-in

Draft with AI — turning your instructions into template text, on this device

(resolved per device tier)
Answering questions in the command bar
~370 MB· opt-in

The command bar assistant's conversational replies, when it cannot match what you typed to a tool

onnx-community/SmolLM2-360M-Instruct
One download, asked for once each

The two default models come to ~155 MB together, and consent is asked per model rather than once for all of them — agreeing to the smaller one for the command bar is not agreeing to the larger one for entity recognition. They are different sizes bought for different reasons.

Readiness also means “everything you can actually use is ready”: both features the second model powers are part of the licence, so a free account is never told to fetch it.

Then it works offline

Weights live in your browser's Cache Storage, on this device — not in your account. So they stay put, and they also stay subject to your browser: clearing site data, a private window, or the browser reclaiming space will remove them, and you will be asked once more rather than charged the bandwidth silently.

Capability scales with the device

Your laptop decides which model you get.

The drafting model is not one model. Before anything downloads, the app probes what this machine is — whether a WebGPU adapter exists and how many logical cores there are — and picks from a ladder. A WebGPU machine runs the model through WebLLM; a machine without one runs a smaller model through WebAssembly, which is the same runtime the two default models already use.

Then a memory gate applies. Drafting runs beside document work — page render buffers, scan workers and undo history are all still resident — so a model may claim only a fraction of reported device memory, and must leave browser storage headroom after it downloads. When the preferred model does not fit, the ladder walks down and says so. When nothing fits, the feature declines with a reason you can read, rather than failing halfway through a draft.

The drafting ladder, with memory to spare
Qwen2.5 3B
~2.4 GB
WebGPU, 8 or more cores
WebLLM on WebGPU
Qwen2.5 1.5B
~1.3 GB
WebGPU, 4 to 7 cores
WebLLM on WebGPU
SmolLM2 360M
~370 MB
No WebGPU, 8 or more cores
transformers.js on WebAssembly
SmolLM2 135M
~145 MB
No WebGPU, 4 cores or fewer
transformers.js on WebAssembly

Resolved by the same function the app calls before asking your consent, so the size you are quoted is one this browser can actually store.

The limitation, stated plainly

A model that fits beside your document is not a model that fills a data centre.

They are smaller, and it shows.

The models here are measured in hundreds of megabytes to a couple of gigabytes. Hosted frontier models are orders of magnitude larger and run on hardware you do not have. On long or subtle documents you will find the difference: shallower reasoning, weaker recall across many pages, and prose that needs editing.

What you get depends on your machine.

The same feature is a different experience on a WebGPU workstation and a four-core laptop — a different model, more slowly. That is not a licence tier; it is physics. The tier is probed rather than asked about, and the ladder above shows what each shape is offered.

We have watched one fail.

A previous drafting model was removed from the ladder after three consecutive real-device drafts degraded into fluent nonsense — Arabic characters dropped into an English demand letter, invented word endings. That is what a small quantized model failing looks like, and it is why the current ladder prefers the numerically safer build even when a cheaper one would fit.

What the built-in models are genuinely good at

Reading, not writing. Matching what you typed against what a document says. Finding names, addresses and other sensitive details across hundreds of pages without any of it leaving the tab. Those are bounded jobs with checkable output, and a small model does them well — which is exactly why they are the two that download by default and generation is a separate, opt-in choice.

If you want generation at a quality small models cannot reach, the answer is not a cloud key. It is the next section.

Your own server — Ollama or LM Studio

Point it at a bigger model you already run.

Deliberately advanced and deliberately subordinate: it is collapsed by default in the AI panel and it never competes with the one-click built-in setup. It is for someone who already runs a local model server and knows why.

Paste an endpoint — http://localhost:11434 for Ollama, http://localhost:1234 for LM Studio — and press Test connection. That click is the only thing that fetches. Nothing dials out on page load, on import or on a timer, and a saved endpoint is remembered as text that becomes a live connection only when you press the button again.

Once connected, Chat with PDF and Summarize send document excerpts to that endpoint and nowhere else. That is enforced rather than intended: every request URL is checked against the origin you configured, and one outside it throws instead of being sent.

PDFMacro never pulls models onto your server. It lists what is already installed; when a server has none, it prints the command for you to run yourself, sized for the machine it detected:

ollama pull qwen2.5:7b4.7 GB · your machine can run a 7B model comfortably
ollama pull llama3.2:3b2.0 GB · a good balance for this machine
ollama pull llama3.2:1b1.3 GB · small enough to run smoothly here
What the connection test can tell you
Connected
connected

The server answered and listed its models — exactly what `ollama list` shows, with no editorialising. Press “Use this server” and inference moves there for Chat with PDF and Summarize.

Running, but not accepting this app
origin-rejected

Something is listening and it refused this page's origin. For Ollama, set OLLAMA_ORIGINS to this app's origin and restart it. In LM Studio, enable CORS in the server settings.

Nothing answered
unreachable

The server is not running, the port is wrong, or the browser blocked the request before it left — a page served from a public address can be stopped by the browser's private-network rules before the server's own configuration is even consulted.

The middle case is the one worth knowing about in advance. A server that is running but has not been told to accept this app looks, to page JavaScript, exactly like a server that is not running — both surface as the same fetch failure. A second probe separates them, because a present-but-refusing server still returns an opaque response while an absent one throws. That is what lets the app name the actual problem instead of shrugging.

FAQ

Questions about the local AI.

Which AI models does PDFMacro download?
Two by default: understanding what you type (Xenova/all-MiniLM-L6-v2, about 45 MB) and finding names and sensitive details (Xenova/bert-base-NER, about 110 MB), for a total of roughly 155 MB. Each is asked for separately, when a feature that needs it is first used, and each is cached on your device afterwards. A third, larger drafting model is a separate opt-in and its size depends on your hardware.
Do the built-in models write text, or only read it?
The two default models read. One turns what you type into a vector so the command bar and pre-discovery search can match meaning rather than exact words; the other finds names and other sensitive details in a document, which is what redaction suggestions and privilege review are built on. Neither generates prose. Generation — drafting, Chat with PDF, summaries — needs either the separate drafting model or your own connected server.
What does “local” actually mean here?
The model weights are fetched once over the network, from a public model host, and stored in your browser's Cache Storage on this device. From then on the document and the model are in the same tab: inference is a function call, not a request. These features keep working with the network disconnected, and there is no code path that sends document text to a hosted inference API — the only exception is a local AI server you connect yourself, which is your own machine.
Are these models as good as ChatGPT or Claude?
No, and the page says so above rather than hiding it here. These are small models chosen to fit in a browser tab beside your document, and what you get scales with your hardware: a machine with WebGPU and eight cores is offered a model several times the size of the one a no-GPU laptop gets, and when even the smallest will not fit the feature declines with a reason instead of crashing halfway through. If you need more capability than your device can hold, connect your own Ollama or LM Studio server and run a larger model there.
Why does my own server need OLLAMA_ORIGINS set?
Because a browser will not let one origin's page read another origin's server unless that server says it may. Ollama refuses unknown origins by default, and the refusal reaches page JavaScript looking identical to “nothing is listening”. PDFMacro separates the two with a second probe, so it can tell you which problem you actually have — then setting OLLAMA_ORIGINS to this app's origin and restarting Ollama fixes the first one. LM Studio has a CORS toggle in its server settings.
Will PDFMacro download models to my Ollama server?
No. It never calls a pull endpoint. If a connected server has no models installed it prints the command for you to run in your own terminal, sized for the machine it detected, and otherwise it simply lists what is already there. Connecting is a click too — nothing dials out on page load, on a timer, or on import; a saved endpoint is remembered as text and becomes a live connection only when you press the button again.

Watch it download, then pull the plug.

The models come down once, in the open, with the size on the button. After that, disconnect and try the same feature again.