Open weight models for New Zealand business.
What they are, when a small model you run yourself is enough, what stays in New Zealand, and how to work out what each answer really costs. Model facts are each publisher's own, checked on 18 October 2026.
The short answer
An open weight model is one whose trained weights you can download and run on hardware you control, so your prompts and documents never go to the model's publisher. Families such as Qwen3, OpenAI's gpt-oss and Google's Gemma 4 come in sizes small enough for a single machine. A small local model is usually enough for narrow, checkable work like sorting, extraction and summaries; long multi-step reasoning still favours a frontier model. Run onshore, the data stays in New Zealand. Whether it is cheaper depends on volume, measured as cost per completed task.
What an open weight model is
A language model is, underneath, a very large file of numbers called weights. With Claude or ChatGPT the weights stay with the provider and you send your text to them. With an open weight model the publisher lets you download the weights and run the model yourself. What you are allowed to do with it is set by its licence, which differs from family to family.
Three families a New Zealand business is likely to meet, as each publisher describes them on 18 October 2026:
| Family | Publisher | Sizes | Licence | Note |
|---|---|---|---|---|
| Qwen3 | Alibaba (Qwen team) | Dense 0.6B, 1.7B, 4B, 8B, 14B and 32B; mixture-of-experts 30B-A3B and 235B-A22B | Apache 2.0 | Announced 29 April 2025. |
| gpt-oss-20b | OpenAI | 21B parameters, 3.6B active | Apache 2.0 | OpenAI says it runs within 16 GB of memory. |
| Gemma 4 | E2B, E4B, 12B, 26B A4B and 31B | Gemma 4 licence; open weights that permit commercial use | Google lists about 2.9 GB to 17.5 GB to load the weights at 4-bit, before the conversation itself. |
The size that matters on your own hardware is memory, not chip speed: the model and the conversation have to fit, or it slows to a crawl. That is why publishers now quote memory figures, and why the smaller sizes exist at all.
When a small model is enough
Most of a business's AI work is narrow and repeated, and that is where a small model earns its place. The gap to a frontier model shows on long, open-ended work. Nobody has settled where the line sits for every job, so treat this as a starting point and measure your own.
- Sorting and tagging: emails, tickets, invoices
- Pulling fields out of documents into a system
- Summarising meetings, calls and long threads
- Drafting from a template the business already uses
- Answering questions from your own documents
- Long, multi-step work that has to plan and use tools
- Hard reasoning where a wrong answer is expensive
- Writing that goes to a customer without a person checking it
- New problems with no template and no examples
- Anything where you have not yet measured a smaller model
You rarely have to choose one. The common setup is both: a small model for the daily, repeated work, a frontier model for the hard cases, and a daily eval to check that the small model is still doing its share well.
What stays in New Zealand
Where the model runs decides where your data goes. For some work, health records most of all, that is a legal question before it is a technical one.
| Setup | Your data | Trade-off |
|---|---|---|
| Open weight model on hardware you own | Stays in your building | Prompts, documents and answers never leave. You own the upkeep. |
| Open weight model in a New Zealand data centre | Stays in New Zealand | The same model on a server you control, hosted onshore. |
| Frontier model pinned to an Australian cloud region | Leaves New Zealand, stays in Australia | Frontier quality with regional residency. Often accepted in New Zealand, but not onshore. |
| Frontier model through a global API | Goes where the provider processes it | The simplest and usually the most capable. Check the provider's terms for where and how long data is kept. |
Cost per query, worked out honestly
There is no single break-even number, because it depends on your volume and your work. There is a single way to find yours.
Count the work, not the tokens
Start with how many jobs a month the model will do: invoices read, emails sorted, reports drafted. That is the volume every option is compared on.
Price the API side
Tokens in and out per job, times the provider's published rate, times the jobs. It scales in a straight line, forever, and moves whenever the provider reprices.
Price the local side
Hardware paid once and spread over its useful life, plus power, plus the hours someone spends keeping it running. Divide by the same jobs.
Divide by completed tasks
A cheap model that fails a third of the time and has to be rerun, or checked by a person, is not cheap. The number that matters is cost per completed task, failures included.
Our research
What we are measuring ourselves
Published comparisons of models mostly test single questions. Business work is multi-step: read this, look that up, update that system. Whether an open weight model holds up on that kind of work is something nobody can look up yet.
So we are building our own comparison: open weight models and a frontier model given the same multi-step tasks, each run several times, scored on whether the task was completed, how long it took and what each completed task cost. We will publish the results on this page once they exist, and not before.
One thing we already hold to: the value sits in the skills, connections and knowledge around a model, not in the model itself. Built that way, a model can be swapped when it is repriced or retired, and the work keeps running. That is how our company brain work is built.
Frequently asked questions
What is an open weight model?
A language model whose trained weights the publisher lets you download and run yourself, on your own computer, server or cloud tenancy. You do not send your text to the publisher to get an answer. What you may do with it is set by its licence, which varies from family to family.
Is open weight the same as open source?
Not always. Open weight means you can download and run the model. Some families, such as Qwen3 and OpenAI's gpt-oss, use the Apache 2.0 licence; others, such as Gemma, use the publisher's own licence with its own terms. Read the licence before you build on one.
When is a small local model enough?
When the job is narrow and checkable: sorting, tagging, pulling fields out of documents, summarising, drafting from a template, answering from your own documents. The gap to a frontier model shows on long, multi-step work that has to reason and use tools, and on anything nobody checks before it goes out.
Does running a model locally keep our data in New Zealand?
If the model runs on hardware in your building or in a New Zealand data centre, the prompts and answers stay there. A frontier model pinned to an Australian cloud region keeps data in Australia, which is often accepted in New Zealand but is not the same thing. A global API sends data wherever its provider processes it.
Is a local model cheaper than an API?
It depends on volume. An API charges for every token, forever. Local hardware is paid for once, then costs power and someone's time. Below some volume the API is cheaper; above it, local wins. The honest comparison is cost per completed task, including the runs that failed and had to be redone, not cost per token.
Do you run open weight models yourselves?
We are building our own comparison of open weight models against a frontier model on the same multi-step tasks, scoring whether each task was completed, how long it took and what each completed task cost. We will publish results here once they exist, and not before.
Not sure which side of the line you are on?
In a short call we will look at the jobs you want AI to do, where the data has to stay, and whether a local model, a frontier model or both is the right fit.
Ask an AI about this page
Opens the assistant with this page loaded: read it, summarise it, cite it.
Questions we have answered
Open-weight and custom models: real questions, each answered in full. See every answer