So this is not a post about a new model. It is a post about the opposite experience: picking the smallest model that would run offline, giving it one boring job, and finding out that this is where the technology quietly works.

The boring job

I deal with Swiss administrative letters: payment orders from the debt-collection office, tax decisions, health-insurance adjustments. They are written in a formal register that even native speakers have to read twice. I wanted a tool that explains them in plain Italian.

The obvious path was an API. The obvious problem was the document itself. A Zahlungsbefehl contains your full name, address, the creditor, and exactly how much you owe. It is not something you upload to a server you know nothing about. So the real requirement was: it has to run entirely on my machine.

The smallest thing that works

The whole tool is about 306 lines of Python 3.10, standard library only. No pip install, no SDK, no API key, no account. It talks to Ollama over HTTP on localhost, where gemma3:1b does the language work. One billion parameters, on CPU. No GPU, no queue, no per-token cost.

This is the part that surprised me, after months of reading that everything interesting needs a frontier model: for a bounded job, the small model is not a compromise. It is the correct size.

What the model does, and what it never touches

The split is the whole design.

The code - plain, inspectable Python - handles everything that must be exact. It parses the letter, pulls out the amounts, the deadlines, the reference numbers, the office that sent it. Deterministic extraction, the kind of thing a regular expression and a date parser have done reliably for decades.

The model never sees a number it could invent. It receives the extracted fields and the letter text, and it does the one thing it is genuinely good at: explaining, in calm everyday Italian, what this letter is and what the sender is asking for. The deadline in the output is the deadline the code extracted. The model can paraphrase a sentence; it cannot paraphrase a date into existence.

That boundary is what makes the output trustworthy enough to actually use.

The one number I'll give you

On my machine, on CPU, one measured run: about 40 seconds to explain one payment-order letter end to end. That is exactly one measurement on exactly one machine - your hardware will differ, and I will not pretend otherwise.

Is 40 seconds slow? For a chatbot, yes. For a letter that sat in a drawer for a week because I did not want to read it, it is nothing. The right question was never "is it fast". It was "is it fast enough for the job", and the answer is comfortably yes.

What this taught me about the fatigue

The fatigue, I think, comes from the framing that AI is one thing that should be everywhere, doing everything, all the time. That framing produces demos that impress and products that exhaust.

My experience was the inverse. One model, one billion parameters, one machine, one job with clear edges. No account, no upload, no subscription, nothing to cancel. The tool is boring, and boring is exactly what a letter from the debt-collection office deserves.

If you are tired of the discourse, this is my suggestion: pick one small, private, slightly annoying task of yours. Put the smallest local model on it. Keep the numbers in the code and the words in the model. It is a very calm way to find out what this technology is actually for.

The tool described is real and personal. The 40-second figure is a single measurement on a single machine, stated as such.

That works, technically. It also means sending one of the most sensitive documents you own to a third-party server you know nothing about.

I wanted the explanation without the upload. So I built a small tool that explains Swiss administrative letters in plain Italian, entirely on my own machine. This post is about the constraints that shaped it, because they are the same constraints I keep seeing in the current wave of small-model projects.

Boring on purpose

The whole tool is about 306 lines of Python 3.10, standard library only. No pip install, no SDK, no API key, no account. It talks to Ollama over HTTP on localhost, where gemma3:1b does the language work.

Why a 1B model on CPU, when bigger is one download away? Because the letter is the point. A payment order, a tax decision, a health-insurance letter: these are documents people should be able to explain without a data-processing agreement. Local is not a compromise here. It is the feature.

The split that makes a small model reliable

Small models are good at paraphrasing and bad at arithmetic. A 1B model will occasionally mangle a number it just read. A regex will not.

So the tool splits the job:

• Code extracts the hard facts deterministically: amounts in CHF, dates, deadlines, reference numbers. Those are printed verbatim, exactly as found in the letter.
• The model gets the letter text and one job: explain what this document is, what the office wants, and what the reader should do next, in simple Italian.

The model never gets to invent the amount or the deadline. It explains; the code counts. That division is what makes a 1B model usable for something that matters.

The integration is the smallest part

Calling Ollama from plain Python is a POST and a JSON parse:

import json, urllib.request

def ask(prompt: str) -> str:
    req = urllib.request.Request(
        "http://localhost:11434/api/generate",
        data=json.dumps({
            "model": "gemma3:1b",
            "prompt": prompt,
            "stream": False,
        }).encode(),
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req) as r:
        return json.load(r)["response"]

With "stream": false the endpoint returns one JSON object with the full text in response. With streaming on you get one JSON object per line and concatenate the response fields, which is what I do in the real tool so the user sees the explanation appear instead of staring at a frozen terminal.

What 40 seconds buys you

On CPU, explaining one Zahlungsbefehl end to end takes about 40 seconds with gemma3:1b. That number would look embarrassing in a benchmark table. In this tool it is irrelevant: letters arrive one at a time, and 40 seconds is still faster than finding a German-speaking friend at 21:00 on a Sunday.

That is my one measurement, on my machine, on my test letter, and I am reporting it as exactly that. But it changed how I think about the current small-model benchmarks. The question is rarely "how many tokens per second" and almost always "is the latency inside the budget of the task". A batch job, a letter explainer, an offline assistant: seconds are fine. Autocomplete: they are not. Measure your task, not the leaderboard.

What I would tell anyone building the same thing

• Pick the smallest model that explains your own test document correctly, not the largest one that fits in memory.
• Keep money, dates and deadlines in deterministic code. Never ask a small model to read a number twice.
• Write the prompt in the output language you want. Asking in simple Italian works even when the source letter is German administrative prose.
• Stream the response. The perceived speed difference is bigger than the real one.
• Treat privacy as a requirement from line one. It is much harder to retrofit than a faster model.

The request in that script goes to localhost:11434 and nowhere else. The day this tool needs a bigger model, it still will not need a network.

I used this approach in Sportello chiaro, a small helper I built to explain Swiss administrative letters in plain Italian. It is Python 3.10, standard library only, and about 306 lines in total. No web framework, no HTTP client package, no SDK.

What Ollama gives you

Ollama runs a local HTTP server on port 11434. Its API documentation describes a POST /api/generate endpoint, and a "stream": false option that returns one JSON object instead of a stream of chunks. The generated text is in the response field. That is all the plumbing you need.

The call, in plain Python

This is an illustrative example written for this article, not an excerpt from the project:

import json
import urllib.request

def ask_local_model(prompt, model="gemma3:1b"):
    body = json.dumps({"model": model, "prompt": prompt, "stream": False}).encode()
    req = urllib.request.Request(
        "http://localhost:11434/api/generate",
        data=body,
        headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=300) as resp:
        return json.loads(resp.read())["response"]

Two details matter. First, set a generous timeout: a small model on a CPU is slow. Second, keep stream off unless you actually want to print tokens as they arrive. Without streaming, the function is a plain "string in, string out" call that is easy to test.

What a small model on a CPU is like

In my own test of the project, Gemma 3 1B on a CPU took about 40 seconds to explain a Zahlungsbefehl (a Swiss payment order). That is not fast, but for a letter you read once it is acceptable, and nothing leaves the machine. For documents like these, privacy was the reason to go local in the first place.

Speed is the price. If you need answers in a second, a 1B model on a CPU is the wrong tool.

Why drop the dependencies

• Nothing to install. If Python 3.10 and Ollama are there, it runs.
• Less to break. There is no package that changes its API under you.
• Easy to read. 306 lines can be read in one sitting, which matters when a tool handles personal letters.

The standard library is not always the better choice. If you need retries, connection pooling or async calls, a proper client library pays for itself. For a one-shot call per document, urllib was enough.

Takeaway

Before adding a dependency for a local model, try the plain HTTP call. For a small, single-purpose tool it may be all you need.

I've written full-stack TypeScript with Nuxt and Vue for about six years. The production bugs I remember most were rarely logic errors. Most came from one assumption: "the data has the shape I typed it as."

The examples below are small and made up for this article. They are not taken from a specific project.

The problem: a type assertion is a promise, not a check

// server/api/user/[id].get.ts
interface User {
  id: number
  email: string
  plan: 'free' | 'pro'
}

export default defineEventHandler(async (event) => {
  const id = getRouterParam(event, 'id')
  const user = await $fetch(`https://api.example.com/users/${id}`) as User
  return { label: user.email.toLowerCase(), plan: user.plan }
})

This compiles. If the API one day returns email: null for accounts created through a different sign-up flow, user.email.toLowerCase() throws. The as User told the compiler to stop asking questions. It checked nothing.

Fix: parse at the boundary with a schema

A schema library such as Zod keeps the type and the runtime check in one place:

import { z } from 'zod'

const UserSchema = z.object({
  id: z.number(),
  email: z.string().email().nullable(),
  plan: z.enum(['free', 'pro']),
})
type User = z.infer<typeof UserSchema>

export default defineEventHandler(async (event) => {
  const id = getRouterParam(event, 'id')
  const raw = await $fetch(`https://api.example.com/users/${id}`)
  const parsed = UserSchema.safeParse(raw)
  if (!parsed.success) {
    throw createError({
      statusCode: 502,
      statusMessage: 'Upstream returned an unexpected shape',
    })
  }
  const user: User = parsed.data
  return { label: user.email?.toLowerCase() ?? 'no email', plan: user.plan }
})

Two things change. The null case is now a type error you have to handle, not a surprise in production. And a bad upstream response fails loudly with a clear status, instead of a vague TypeError deep in your code.

Where to validate, and where not to bother

You don't need a schema around every object. Validate where data crosses a trust boundary:

• Responses from APIs you don't control

• Request bodies and query params in your own server routes (readValidatedBody and getValidatedQuery in Nitro/H3 take a validator for this)

• localStorage, cookies and anything else the user can edit

• Output of any model or service whose format isn't guaranteed

Inside your own code, after the boundary, trust the types.

A tradeoff to be aware of

Schemas cost a little bundle size and a little time per parse. On the server this rarely matters. In a hot client path, parse once when the data arrives, not on every render.

Also, strict schemas can make you reject responses that were fine in practice. Decide per field: .passthrough() or .strip() for unknown keys, and be careful with strict enums on upstreams that add values without warning.

Takeaway

as SomeType is documentation. A schema is a check. Use assertions for things you actually know, and parse the rest at the edge.

I built a small local tool, "Sportello chiaro", to explain such a letter in plain Italian and point out the deadline. It's an MVP. I want to describe the one design decision that I think matters, and be clear about what is and isn't tested.

The rule: the model never produces the critical facts

A language model is good at explaining. It is not reliable at date arithmetic or at quoting the right number of days. So the deadline does not come from the model. It comes from code:

SERVED_RE = re.compile(
    r"(?:zugestellt am|zustellung am|zugestellt:|notifié le|notifiée le|reçu le)"
    r"\s*(\d{1,2})[.\/](\d{1,2})[.\/](\d{4})", re.I)

The tool finds the notification date with this pattern, picks the number of days from the document type (10 for a Zahlungsbefehl or Strafbefehl, 30 for an Einsprache), and computes end = served + timedelta(days=days).

The model then gets the letter and a system prompt that says, in short: use only information present in the letter, and do not invent dates, amounts or law articles. Its job is the readable explanation, in four fixed sections.

Graceful failure

The call to the local model is plain urllib, and it returns the text of the first choice. If the model call fails, the analysis falls back to the rule-based output and records the error. The user still sees the deadline and a response template, just without the prose.

What is tested

• Stack: Python 3.10 standard library only (urllib, http.server, re, datetime, json), about 300 lines. A CLI and a local web page on 127.0.0.1:8080.

• Model: Gemma 3 1B (Q4_K_M) through llama-cpp-python for my tests. The intended default is a larger model through Ollama, which I have not tested.

• Six pytest tests, rules level only. One checks that a notification on 12.10 plus 10 days gives 22.10.2026. Another checks that a response template is selected. A third checks that an unrelated text gets low urgency.

• One end-to-end run on one invented letter. About 40 seconds with the 1B model.

What is not done

• No schema check on the model's output. The tool does not verify that the answer contains the four sections, or that the deadline in the prose matches the computed one. That's the next thing I'd add.

• Weekends and public holidays are not handled in the deadline calculation.

• No OCR and no PDF input. You paste text.

• No users yet. The repository is not public.

• It is not legal advice, and I wouldn't present it as such.

Why local

These letters contain names, addresses and debts. Keeping the model on the user's machine means the text never leaves it. A small model is slower and less fluent, which is why the rules carry the parts that must be right.

Takeaway

When a task mixes language and facts, split it. Let code produce what must be exact and let the model do the explaining. Then say plainly which parts you have tested.