mohitkrconnect/heed-tasks-qwen3-0.6b

Heed: voice notes to tasks, on the phone (Qwen3-0.6B)

This is the model inside Heed, a private, offline Android app. You speak a messy thought, and Heed returns a clean, sorted task list. Nothing leaves the phone.

This 0.6B model turns the transcript of a note into a JSON task list. Each task gets a bucket: Tasks, Buy, Watch, Ideas, Work, Journal, or one of the user's own buckets. It runs on a mid-range phone CPU with no network access.

Headline (sealed test, 617 notes, run once, int8 on a real phone):

• Judged task F1 75.6, which is 80% of Claude Sonnet 5.5 (94.8) and 84% of Sonnet on the 126 real human notes.
• +20.0 points over GPT-5.4 mini [95% CI +17.0, +23.0]. A second judge from another model family agrees (+10.3 [+3.3, +17.2]).
• Claude Haiku 5.5 (+10.1) and Gemini 3.5 Flash (+16.3) are still better. This is a 0.6B model that runs offline on a phone, not a frontier model.
• Median 5.1 s per note on a MediaTek Dimensity 8300 CPU. The model file is 614 MB (int8). The whole app uses about 1.2 GB with the model loaded.

Base model	Qwen/Qwen3-0.6B-Base (Apache-2.0), full fine-tune
Files	model.safetensors (bf16, for PyTorch / transformers) and heed-tasks-qwen3-0.6b-int8.litertlm (int8 weights, for LiteRT-LM on Android)
Input	A raw prompt (no chat template): a list of buckets plus the note
Output	Compact JSON {"tasks":[{"t":"…","c":"…"}]} followed by EOS
Language	English
Context	1,024 tokens (training and phone)
Study	Experiment EXP-061 (seed 1, epoch 3). It is the 61st pre-registered experiment of the Heed study, and was chosen for the app in decision D158

Related models: a second seed of the same recipe, the previous version without targeted data, and two earlier tasks-only models: Qwen3.5-0.8B and Qwen3-0.6B. The research checkpoints, including failed experiments, are: full output in JSON (task + bucket + time + reminder), the same in a lines format and its 4-epoch JSON baseline, tasks-only with long notes, and two Qwen3.5-0.8B runs on simulated notes: E2 and a weight average.

The whole study, with every experiment and decision: Heed study.

---

1. The problem

People think out loud: "umm okay so after church I need to call Kwabena's mum about his boots, before Tuesday's training… oh and Kojo said my phone will be ready Monday at four, so I have to go pick that up… and yeah, buy like twenty cones, the old ones are all ruined".

A to-do app needs three clean, sorted items from that, without inventing anything or dropping a detail like "Monday at four".

The constraints set the design:

• Private by construction. The app has no INTERNET permission, so the model has to run on the phone. Cloud LLMs are excluded by design, not by budget.
• Mid-range Android. It must run on the CPU, within a few seconds and about 1 GB of memory. On this hardware a sub-1B model is the only realistic option.
• Input from speech. The transcript comes from Granite Speech, which writes lowercase text with no punctuation. The model must handle that as well as typed text.
• User-defined buckets. The bucket list is part of the prompt, not built into the weights.

2. How to use it

Prompt format (exact)

Categories:
- tasks (General): general things to do
- buy (Buy): things to purchase
- watch (Watch): movies, shows, videos to see
- ideas (Ideas): thoughts to remember
- work (Work): office and job tasks
- journal (Journal): feelings, emotions, stories with no action
Note: <the note text>
Tasks:

• The prompt ends with a newline after Tasks:. There is no chat template and no system prompt.
• The default bucket text above must stay byte for byte as written, because it was trained that way.
• You can replace the list with your own buckets in the same - id (Name): meaning line format. 859 training notes used a custom list.
• The model writes compact JSON and then <|endoftext|>. A note with nothing to do gives {"tasks":[]}.
• t is the task text, with any spoken time kept inside it ("Pick up phone Monday at four"). c is a bucket id from the prompt.
• The model does not create reminders or separate time fields. That was a deliberate decision (D134); in the app, reminders are set by hand.

transformers

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

repo = "mohitkrconnect/heed-tasks-qwen3-0.6b"
tok = AutoTokenizer.from_pretrained(repo)
model = AutoModelForCausalLM.from_pretrained(repo, dtype=torch.bfloat16)

CATEGORIES = """Categories:
- tasks (General): general things to do
- buy (Buy): things to purchase
- watch (Watch): movies, shows, videos to see
- ideas (Ideas): thoughts to remember
- work (Work): office and job tasks
- journal (Journal): feelings, emotions, stories with no action
"""
note = "i have to correct the unit test papers for class 2b by monday also buy new swimming goggles for aadi"
prompt = f"{CATEGORIES}Note: {note}\nTasks:\n"

ids = tok(prompt, return_tensors="pt").input_ids
out = model.generate(ids, max_new_tokens=512, do_sample=False)  # greedy, as evaluated
print(tok.decode(out[0, ids.shape[1]:], skip_special_tokens=True))

Android (LiteRT-LM, as in the app)

This is the call the app makes, using com.google.ai.edge.litertlm 0.15.0 on the CPU with greedy decoding:

val engine = Engine(EngineConfig(modelPath = path, backend = Backend.CPU(), maxNumTokens = 1024)).also { it.initialize() }
val session = engine.createSession(SessionConfig(samplerConfig = SamplerConfig(topK = 1, topP = 1.0, temperature = 1.0)))
session.generateContentStream(listOf(InputData.Text(prompt)), callback)   // raw prompt, no chat template

• The app streams the answer through a small guard (AnswerGuard). It stops when the JSON closes, after 400 pieces, or when one task repeats 3 times. Only well-formed rows are kept (at most 30 tasks).
• LiteRT-LM 0.15 has no grammar-constrained decoding, so the guard covers that gap. Retrying is pointless because decoding is greedy.
• The .litertlm file was made with litert-torch export_hf <model dir> <out dir> --cache_length=1024 (litert-torch 0.11.0, litert-lm-builder 0.19.0). It uses the default dynamic_wi8_afp32 recipe: int8 weights, fp32 activations. sha256 6f3631648fb6aa1159946827b5ba95c980e6c2d831735f1e25b67a37f01709cc.

Examples (synthetic validation notes; real output of this model, greedy, not edited)

The input is in the speech-like "plain" form, lowercase with no punctuation, with the default buckets.

Note	Model output
chale just after church call kwabena's mother about his boots before tuesday training kojo said my phone will be ready monday at four go and pick it up and buy twenty cones for training the old ones are all spoilt	{"tasks":[{"t":"Call Kwabena's mother about his boots before Tuesday","c":"tasks"},{"t":"Pick up phone Monday at four","c":"tasks"},{"t":"Buy twenty cones for training","c":"buy"}]}
i have to correct the unit test papers for class 2b by monday also buy new swimming goggles for aadi his old ones cracked and call the swimming coach about shifting him to the saturday batch	{"tasks":[{"t":"Correct the unit test papers for class 2B by Monday","c":"work"},{"t":"Buy new swimming goggles for Aadi, his old ones cracked","c":"buy"},{"t":"Call the swimming coach about shifting Aadi to the Saturday batch","c":"tasks"}]}
kindly remind me the pension papers i have to submit them at the treasury office on the 2nd yes on the 2nd also dr sharma's appointment is on wednesday at 10 in the morning and bp tablets are finishing buy one strip of telma 40	{"tasks":[{"t":"Submit the pension papers at the treasury office on the 2nd","c":"tasks"},{"t":"Dr. Sharma's appointment on Wednesday at 10 in the morning","c":"tasks"},{"t":"Buy one strip of Telma 40 BP tablets","c":"buy"}]}

The examples were chosen for variety, not cherry-picked as the best outputs. In the first one the model drops "training" from the first task. In the third, the second task has no verb.

3. Training data

8,610 notes, each trained in two forms = 17,220 rows. Validation: 451 notes. Sealed test: 617 notes, never used for training or for any choice.

Source	Notes in training	What it is
Long brain dumps	2,697	Long (120–199 token), scattered notes written by Claude Sonnet 5.5; 70% "ADHD-style" personas
Targeted notes (EXP-061)	1,696	Written by Claude Sonnet 5.5 from a fixed plan, aimed at the errors found in a review: self-corrections ("make that 6"), details to keep (numbers, names, places), rambling, feelings with no task, one or two tasks in messy speech
HeedSet	1,662	Synthetic notes written by Claude Opus
Simulated user-style notes	1,108	Written by Claude Sonnet, Gemini and GPT-5.4 in the style of the real notes
Notes I planned	781	Planned by me and generated with ChatGPT
Claude brain dumps	480	Messy notes written by Claude Opus and Sonnet, with speakers from 16 English-speaking countries
Curated template notes	36	Picked by hand from a template-generated draft
Real human notes	150	Real brain dumps from me and five friends (140), plus 10 typed by me. Not released

• Labels. Every training note was labelled by Claude Sonnet 5.5 at temperature 0 under one frozen labelling prompt, so the whole set follows one consistent style. They are single-model "silver" labels; no human checked each note. I spot-checked samples, and the judge agrees with me at κ 0.84 (see 4.2).
• Two forms of every note. Each note appears once as written and once in "plain" form: lowercase, punctuation removed, apostrophes kept. The target keeps normal capitals.
  • Why: the speech model writes plain text.
  • What it fixed: a phone test of the previous design showed a 5.7-point drop on unpunctuated input (EXP-054). Training on both forms cut it to 0.2.
• Real notes in the evaluation sets. 325 real notes exist in total: 140 in training, 59 in validation and 126 in the sealed test. Validation and test notes never entered training and were never uploaded to the training machine.
• Known skews in the targeted notes:
  • "make that…" appears in 15.5% of them, against 0.2% in validation;
  • almost no watch or ideas items;
  • only the default buckets.

4. Training

4.1 Recipe

Setting	Value
Method	Full fine-tune (no LoRA), 596,049,920 trainable parameters
Objective	Cross-entropy on the answer tokens only (prompt masked); EOS appended to every target; no packing
Optimizer	AdamW, weight decay 0, gradient clipping 1.0
Learning rate	1e-5, 5% linear warm-up, cosine decay to 0
Batch	8 × gradient accumulation 2 = 16 rows per step
Epochs / steps	3 epochs, 3,231 steps (1,077 per epoch)
Max length	1,024 tokens (longest row 567; nothing truncated)
Precision	fp32 master weights, bf16 autocast, TF32 matmuls, gradient checkpointing; weights saved in bf16
Seed	1 (seed 0 is the sibling model)
Hardware	1 × NVIDIA RTX 4090 24 GB (rented), peak 17.4 GB
Time	32.6 minutes
Compute cost	About $2 of GPU time for the whole experiment: 2 seeds, training plus answer generation (estimate from the run time)
Software	torch 2.8.0, transformers 5.20.2, accelerate 1.15.0

Why epoch 3 and not the epoch with the lowest loss. Validation loss is lowest after epoch 1 (0.339) and rises after that. The task score keeps improving through epoch 3.

The rising loss means the model gets more confident on the tokens it gets wrong. It does not mean the answers get worse. Since what we care about is the answers, the epoch is chosen by task score on validation and not by loss (decision D115). This pattern held in every fine-tune of the study.

4.2 How it was evaluated

Why a judge. Word overlap with a Sonnet-written key punishes correct answers that are worded differently, and it rewards Sonnet's own style. So every system is scored by an independent LLM judge, Gemini 3.1 Pro.

• The judge sees only the note and an anonymous task list. It never sees the key and never knows which system wrote the list.
• It marks each task as good (usable as is), fixable (the right task, but it needs an edit) or wrong (invented, meaning changed, a remark turned into a task, or a repeat).
• It also lists the missed tasks: things the speaker clearly meant that no item covers.

Score.

• precision = good / (good + fixable + wrong)
• recall = good / (good + fixable + missed)
• F1 = 2PR / (P + R)

A fixable task counts against both precision and recall. That is strict on purpose: every fixable task costs the user an edit.

The judge was tested before it was used (EXP-060). Each check had a pass mark set in advance:

Check	Result
Planted errors caught (dropped, invented, changed detail, merged, wrong bucket)	96% (pass ≥ 80%)
Same call repeated gives the same verdict	96.2% (pass ≥ 90%)
Agreement with GPT-5.4	κ 0.63 (pass ≥ 0.6)
Agreement with me, 50 items rated blind	κ 0.84 [0.67, 0.96]
Effect of showing it the key	1.7 points (limit 5)

The comparison.

• The cloud models got the full 4,105-character labelling rulebook in their prompt. This model got none.
• The cloud models ran as served, with default reasoning settings and temperature 0.
• All 95% intervals come from a paired bootstrap over notes (4,000 resamples).

4.3 Results

Sealed test: 617 notes (126 real), run once. "Heed" here means this model as the int8 .litertlm running on the phone.

System	F1 (all)	F1 (126 real)	Precision	Recall	Notes needing no edit	Heed as % of this system	Gap to Heed [95% CI]
Claude Sonnet 5.5 (wrote the labels)	94.8	95.1	96.0	93.6	81.7%	79.7%	+19.2 [+17.2, +21.3]
Gemini 3.5 Flash	91.8	94.2	92.5	91.2	71.2%	82.3%	+16.3 [+14.2, +18.5]
Claude Haiku 5.5	85.6	92.0	86.9	84.4	65.0%	88.2%	+10.1 [+7.7, +12.4]
Heed (this model, int8, phone)	75.6	80.1	76.8	74.4	45.5%	—	—
GPT-5.4 mini	55.5	75.3	56.5	54.6	25.9%	136%	−20.0 [−23.0, −17.0]

• Second judge: GPT-5.4, on 100 notes, gives the same order: Sonnet 85.9, Flash 82.8, Haiku 81.0, Heed 74.0, GPT-5.4 mini 63.7. Under this judge Heed is at 86% of Sonnet, so the 80% headline is the conservative figure.
• Real notes only: GPT-5.4 mini is level with Heed (−4.8 [−10.9, +1.1]). Every system scores higher on real notes, which are shorter.

What the errors look like (sealed test):

• More than half of Heed's errors are near misses (fixable): the task is real but loses a detail or is worded so the user must edit it. 18% are wrong and 28% are missed.
• On real notes, Heed gets the whole list perfect on 52% of notes. Sonnet does on 83%, Haiku on 71% and GPT-5.4 mini on 40%.
• The bucket is wrong on 3.5% of items. Watch is the weakest at 14.6% of 41 items ("watch" is also a verb), then Journal at 8.9% and Ideas at 6.7%.
• Heed stays silent correctly on 39 of 42 notes with nothing to do. It wrongly returns an empty list on 9 of 575 notes that had tasks (1.6%).
• 3 of 617 replies on the phone were unreadable JSON (0.5%) and were counted as empty lists.

Validation (451 notes, same judge). This set was used to pick the epoch and the seed, so it flatters the chosen model by about 1 point.

• This model: F1 79.4 (real notes 86.2).
• The other seed of the same recipe: 77.5 (81.9).
• The previous recipe without targeted data: 76.2 (78.4).

From validation to test: F1 went from 79.4 to 75.6. Three causes are possible and have not been separated:

• the selection effect (about 1 point);
• int8 quantisation plus phone decoding;
• a harder mix in the test set (more long and synthetic notes).

They were not separated: the full-precision weights were not run on the test set.

4.4 On the phone

Device: OnePlus CPH2717 (MediaTek Dimensity 8300, 8 GB, Android 16), CPU only, LiteRT-LM 0.15.0.

Metric	Value
Time per note, text in to tasks out (617 notes)	p50 5.1 s, p95 12.7 s, p99 14.6 s, max 17.8 s
By length (p50)	2.2 s (< 15 words), 3.2 s (15–39), 7.9 s (40–99), 10.8 s (100+)
Time model	≈ 1.35 s + 17.6 ms per answer character (r = 0.97), so decoding dominates
Memory	About 1.2 GB for the whole app with the model loaded; weights memory-mapped
Heat	32.6 °C at the start of the 617-note run; thermal status 0 in the first install check
Readable JSON	614 of 617

5. Limitations and honest caveats

• "% of Sonnet" partly measures similarity to Sonnet. Sonnet wrote the training labels, so the model copies Sonnet's style. That is why the judge does not use the key.
• Long, chatty notes are the weak spot. F1 is 70.5 on 40–99 word notes and 59.8 on AI-written chatty notes, where Haiku is 22 points ahead. The model also loses details.
• Buckets the model has never seen are untested at scale. Only 17 sealed-test items used a custom list (17.6% wrong), which is too few to draw conclusions.
• Small buckets get confused, especially Watch and Journal.
• Times stay inside the task text. Measured on the previous model, about 1 in 7 spoken times is still lost or changed.
• English only. Most notes come from a few speakers plus synthetic text, so accents and other speakers are not measured. Speech-recognition errors are not part of training.
• The labels come from one model (Claude Sonnet 5.5) with no per-note human check.
• Training included 150 real notes from me and friends. They are not released, and memorisation was not tested.
• Judge-based numbers: the headline relies on an LLM judge. The judge was validated against a human (κ 0.84 on 50 items) and checked by a second judge from another family, but it is not a large human study.
• Speed: long answers are slow because a phone CPU is decode-bound.

6. The study behind it

Heed was rebuilt from scratch as an applied-science study with a fixed method:

• every experiment is pre-registered (design, predictions and pass rules frozen before it runs);
• every choice goes into a decision log (D001–D180);
• there is a sealed test set that was opened once;
• results are reported with paired-bootstrap intervals, and pass rules are not loosened after a near miss.

EXP-061, the experiment that produced this model, failed its own primary rule: +1.4 [−0.2, +2.9] against a pass mark of a clearly positive lower bound. It was recorded as a fail. The model was still chosen for the app because it cut wrong items by about a fifth and raised real-note quality by +5.5 [+1.4, +10.3]. That choice was logged as a separate decision (D158).

The path to this model:

Step	What was learned
EXP-009	Off-the-shelf sub-1B models fail every Heed decision (best 51.5% bucket accuracy vs 87.2% for TF-IDF), so fine-tuning is needed
EXP-012	A fine-tuned 0.6B classifier gets 88% bucket accuracy (81% on unseen user buckets)
EXP-022	Six sub-1B models fine-tuned as writers; Qwen3.5-0.8B best, Qwen3-0.6B close behind
EXP-028 → 031	Distilling Sonnet labels lifts the 0.8B; simulated user-style notes bring no measurable gain; seed noise is about 3 points
EXP-037 / 038	The model's job is narrowed to tasks only; switch to Qwen3-0.6B because Google's official LiteRT-LM converter supports Qwen3 and not Qwen3.5's hybrid attention
EXP-046 / 048 / 049	One consistent Sonnet relabelling plus 2,697 long notes: real-note F1 goes from 60.9 to 81.7 (word-overlap)
EXP-054	Reminders and time fields dropped; every note trained as written and plain; the punctuation gap on the phone falls from 5.7 to 0.2
EXP-055 / 060	Error review, then the blind LLM judge validated before use
EXP-061	1,696 targeted notes; this model
EXP-064	Frontier comparison and the sealed test

The rest of the app:

• Speech: IBM Granite Speech 5.0 470M (int8, LiteRT).
• Search: EmbeddingGemma-300M (4-bit, ONNX Runtime) fused with BM25. It gives +49% nDCG@10 over keywords alone, at 27 ms on the phone.
• Memory: one model is loaded at a time and unloaded after 90 s idle.

Links

• App and website: https://heed-xi.vercel.app
• Source code: https://github.com/t3chw/Heed_app
• Dataset: https://huggingface.co/datasets/mohitkrconnect/heed-voice-notes-to-tasks
• Blog: https://huggingface.co/spaces/mohitkrconnect/heed-study
• Base model: https://huggingface.co/Qwen/Qwen3-0.6B-Base

Data: the synthetic part of the training, validation and test notes, with all five systems' answers and the judge's verdicts on the public test notes, is in mohitkrconnect/heed-voice-notes-to-tasks. My real notes and my friends' are not published.

License

Apache-2.0, the same as the base model. The training labels and most training notes were produced with Claude, Gemini and GPT models. Check those providers' terms before using this model to build a competing general-purpose model.