DEV Community: Damiano

Call a local model from plain Python: no SDK, no dependencies

Damiano — Fri, 16 Oct 2026 08:55:26 +0000

Most "use a local model" tutorials start with a virtualenv and a dozen packages. For a small tool you may not need any of them. If a local Ollama server is running, Python's standard library is enough to talk to it.

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.

Your TypeScript types disappear at runtime: validating data at the edges of a Nuxt app

Damiano — Thu, 15 Oct 2026 01:29:27 +0000

TypeScript checks your code before it runs. Once it ships, the types are gone. The compiler cannot tell you what a third-party API actually returned at 3 AM on a Sunday.

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.

Let the model explain, let the code count: a local LLM helper for Swiss administrative letters

Damiano — Thu, 15 Oct 2026 01:26:09 +0000

In Switzerland, a letter from a public office can start a clock. A Zahlungsbefehl (payment order) gives you 10 days to object. An Einsprache period is often 30. Miss the date and you lose a right. Many people read these letters in a language that isn't their first.

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.