PulseOS/pulse-local-checker-qwen3-0.6b

Pulse Local checker: Qwen3-0.6B, fine-tuned to read budgeting questions (reader5)

A 0.6B Qwen3 that Pulse trained for one job: it reads one message about a person's own money records and writes the calculation that the message asks for, as JSON. It is the checker inside Pulse Local, a budgeting app where your transactions, the models and every question stay on your machine. The app downloads this file once, the first time it starts.

It is not a chat model. It does not answer questions and it writes no sentences. It only fills in a fixed form.

What it does in the app

The app reads each question about your records two times.

1. Code reads it into a calculation: what to count, about what, over which dates, how to group it.
2. This model reads it into the same form, under a grammar that allows only the names in your records.

The app runs both calculations against your records. It shows a figure only when the two give the same result. When they do not agree, the app shows no figure: since Pulse Local 0.4.27 (31 October 2026) it offers the readings, two as a choice or one to confirm, and shows a figure only after a tap; before that it said that it was not sure. This model never answers on its own, and a figure always comes from code, never from the model. Code also writes every sentence of the answer.

In the app this is "Better understanding". It is on by default on every machine since Pulse Local 0.4.19, and Settings can turn it off. A person who turned it off in an earlier version keeps it off. It replaced Qwen3-4B-Instruct-2507 (about 2.5 GB), which did the same job from 0.4.0 to 0.4.18. The app never deletes the old 4B file by itself: Settings says that it is still there and offers to remove it, after a confirm.

How the app calls it

Use the same call, or the results below do not apply.

• Prompt. A system prompt that gives today's date, the current month, the months in the records, and the lists of categories, accounts and merchants, then: "A follow-up changes only what it says; everything else stays as in the previous query." The user turn is Message: <the message>. For a follow-up, the user turn first gives the last one or two messages with their queries, then Follow-up message: <the message>. No worked examples are given.
• Grammar. A JSON schema with these fields: act, measure, subject_kind, subject, period, month, from, to, breakdown, pick, rank, exclude, versus_month, min_amount, max_amount, top. The subject and exclude values are limited to the household's own names. The app makes the grammar with node-llama-cpp's createGrammarForJsonSchema.
• Decoding. Temperature 0, at most 260 tokens, no thinking block, Qwen3's chat template.
• Context. 8,192 tokens, one sequence.

The code of the call is pulse-local/app/electron/llm/secondReader.ts and the prompt is worksheet/learned.ts (readerSystem, readerUser, READER_SCHEMA).

How it was tested

We test the app, not this model alone. BudgetBench is the app's chat benchmark: invented households in the shapes real banks and apps export, questions and follow-ups written by authors who did not see the app's code, and every expected figure computed by a separate program.

The claim comes from a sealed split of 387 conversations that no system had seen (BudgetBench v3 sealed). The test and its bar were written down before any run on that split. Each setup ran once, on the same code, with the app's strict rule ("agree or not sure", the rule the app shipped until 0.4.26; the model is the same under 0.4.27's "agree or ask"):

setup	wrong figure	right figure	not sure
code alone	89	169	99
code checked by Qwen3-4B-Instruct-2507 (as Pulse Local 0.4.18 ships it)	24	93	254
code checked by this model (Pulse Local 0.4.19)	23	158	187

"Wrong figure" counts a wrong figure shown and a wrong figure offered as a choice. "Right figure" counts a right answer with no tap and a right answer after one tap. Answers that needed review are ruled by BudgetBench's published rules.

On a sealed test of 387 conversations it had never seen, about 6 answers in 100 still showed a wrong figure, against about 23 in 100 without it. The 95% interval of the first figure is 2.6% to 9.4% (households resampled, then cases).

The bar was: no more wrong answers than the 4B, and at least 90% of its right answers. Result: passed.

Pulse Local 0.4.22 (October 2026) keeps this model unchanged and fixes the app's own code. On a later sealed test of 380 conversations (BudgetBench v4), the app with this model showed a wrong figure in about 5 conversations in 100, against about 22 in 100 with code alone.

Pulse Local 0.4.27 (31 October 2026) keeps this model and the code unchanged and changes only what the app does when the two readings differ: it offers them instead of saying that it is not sure. There is no sealed run of 0.4.27; its numbers on the public split are on the BudgetBench page.

Cost on an M4 Mac with 24 GB of memory, with nothing else running on the GPU:

	seconds a turn (median)	90th percentile	most process memory
Qwen3-4B-Instruct-2507	15.1	18.4	5,164 MB
this model	1.4	1.7	2,964 MB

The process memory includes the app's chat model and its embedding model.

These figures describe the whole app with this model as its checker. They are not a score for the model alone. The v3 sealed split is now used, so the next claim about a checker needs new sealed cases.

Earlier results (history)

• BudgetBench v2 sealed, 22 October 2026, 340 conversations, the 0.4.18 code. This run decided the switch from the 4B. Code alone: 73 wrong, 165 right. The 4B: 17 wrong, 103 right. A 0.6B checker trained the same way (reader5): 16 wrong, 140 right, 166 not sure. Its cost: 1.11 s a turn (median) against 11.65 s for the 4B, and 2,986 MB of process memory against 5,172 MB. If every answer that needed review is counted as wrong for both models, reader5 had 20 wrong and the 4B 19.

Training

• Base: Qwen/Qwen3-0.6B, Apache 2.0, with a chat template that writes no thinking block.
• Method: LoRA with mlx-lm on an M4 Mac (rank 16, scale 20, dropout 0.05, all 28 layers, AdamW, learning rate 1e-4 with a cosine decay to 1e-5 after 40 warm-up steps, batch 8, the prompt masked, seed 11, maximum length 1,536 tokens, one pass of 1,532 steps). Fused, converted to GGUF and quantized to Q4_K_M with llama.cpp. The final adapter was chosen over two earlier checkpoints on held-out validation turns.
• Data: 12,249 training rows and 1,310 validation rows from twelve held-out households. Every household is invented. The data covers totals, merchants, months, comparisons, exclusions, follow-ups, refusals, new merchants, amount limits in the ledger's own money style, and households kept in other currencies (SEK, NOK, DKK, GBP, EUR, CHF, PLN, JPY, CAD, AUD).
• Labels: each label is the correct reading, and each one was run through the app's own calculation and had to give the expected figure. A label that did not was dropped, never repaired.
• No BudgetBench case of any split is in the training data. No personal or user data was used at any point.

Limitations

• It reads English only.
• Agreement is not proof. Two readers can make the same mistake, and earlier tests found wrong answers that both readers agreed on.
• It reads only the form above. It cannot answer, explain or give advice.
• The sealed cases were written by AI agents for this benchmark. The result is about these 387 cases, not about every way a person asks.
• Some question shapes are "not sure" more often than with the 4B (on the app's release gate: how often a merchant charges, and some "by month" tables). The app shows no figure there, so the answer is safe but less complete.

Files

file	size	sha256
Qwen3-0.6B-reader5-Q4_K_M.gguf	397 MB (396,704,640 bytes)	70f9ce49fc6397df0c460d4844928871eb851e03abeb63067db6a29857e59f59

The app loads only a file with this sha256.