Build1 distinct publisher3 min readUpdated
Online-SDFT fine-tunes a 230M model on an Android phone from delayed, unlabeled interactions. The teacher is the same frozen base weights with the adapter off, and the write-up reports no measurements.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The economical move here is the absence of a second model. The deployed adapter acts; the same frozen base weights then re-read the finished interaction with the adapter switched off and the observed outcome appended to the original context [8][7]. Teacher and student are one network, so the only advantage the teacher holds is the outcome sitting in its input [1]. On a handset that is the difference between one resident set of weights and two: reviewing an interaction costs an extra forward pass, not a second model in memory [2].
That also explains why most of the design effort goes into what not to learn from. Supervised fine-tuning wants a correct action the phone never observes, and a reward is no better defined, since an opened notification is not proof of good timing and an ignored one is not proof of unimportance [12]. The obvious repair, mapping a dismissal onto "archive", overstates what a dismissal means, which could be irrelevance, bad timing, a preview that already did the job, or an interruption [13]. So outcomes arrive as reliability-conditioned soft targets: strong support for one action when the outcome is reliable, redistribution across the still-plausible actions when it is ambiguous, and no update at all when it reveals nothing [9]. The pseudocode puts a causal-support check in front of the buffer as well [10]. Two gates stand between a user gesture and a gradient step [3].
The limit the design cannot engineer away is the branch not taken. Archive a notification and the result of showing it is unobservable, to the reviewing pass as much as to the acting one [5]. Hindsight is richer than a label and still one-armed. The prototype's answer is exploration while the model is uncertain, tapered as confidence grows, on the argument that a greedy policy locks into an early behaviour and then collects only the evidence that confirms it [11]. Look at what the taper does to the data supply: the mechanism that produces off-policy evidence is scheduled to wind down precisely when the policy has become confident, which is also when a change in the user's routine would be hardest to notice. The bounded replay window and the category-balanced sampling are the counterweight [14], and whether they are enough is an empirical question.
Which is where the excerpt stops. There is no routing comparison with the adapter learning against the adapter frozen, no per-step latency, no battery cost [4]. For a training loop that runs inside a thermal budget, those are the numbers that decide whether it ships or stays a demo.
What the artifact does settle is narrower and still worth having. A 230M model with a rank-4 adapter, ONNX Runtime Training and a bounded buffer is enough to keep updating after deployment, with provisioning the only remote step described [2][3]. The frozen-at-ship default that shipped small models inherit [4] now needs an argument other than the hardware.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
At decision time the student sees notification, time and local context; later the teacher sees the same context plus what the user did afterward, and that better-informed soft distribution is distilled into the student, which must decide without access to the outcome.
There is no separate teacher model: the deployed model uses its LoRA adapter to act, while the same frozen base model reviews the completed interaction with the adapter disabled.
In the described loop, an interaction is added to the replay buffer only if the action and the hindsight are causally supported.
Online-SDFT is an open-source prototype that continually fine-tunes a small language model from delayed interactions while keeping the learning loop on the device.
The prototype uses LiquidAI/LFM2.5-230M, a rank-4 LoRA adapter, ONNX Runtime Training, a bounded on-device replay buffer, and an Android notification-routing testbed.
Once the model has been provisioned, inference, interaction storage, replay and adapter updates all happen locally.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-party mechanism with preliminary, self-tuned numbers
The mechanism is described precisely enough to be reimplemented, including stack, pseudocode, gating rules and replay policy, and the write-up does report quantitative results. But everything comes from a single self-published author account, the evaluation uses three synthetic streams with the winning configuration tuned on those same streams, there is no held-out benchmark, no independent replication, and no systems-cost measurement.
Open-source prototype with a single self-run device test
Adoption evidence is limited to the authors' own release and their own use: an open-source repository with an Android project and one physical-phone run. No third-party users, downstream deployments, download or usage figures, or external integrations appear in the supplied source.
Mildly overstated: prototype framing hedged, but capability implied beyond what is measured
The author hedges honestly, calling results preliminary and naming the in-sample tuning weakness. Still, the framing that a phone-resident model 'keeps learning' outruns what is shown: quality evidence is synthetic and self-tuned, the on-device proof is a single anecdote, and the operational cost of continuous LoRA training on a handset is never quantified. The gap is small rather than severe.
First-party author promoting their own open-source prototype
The single source is a developer-platform post by the project's own authors about a project they built, so promotional interest in the artifact's reception is direct. Mitigating factors: the code is open-source, and the post volunteers its own limitations, including the in-sample tuning and the preliminary status of the results.
Single-source, single-publisher, self-reported
Every claim traces to one first-party post whose supplied body is truncated mid-sentence during the device-test description. Mechanism claims are internally consistent and specific, which supports moderate confidence in what was built, but nothing in the cluster corroborates the results or the on-device practicality independently.
build
FLARE's federated VLM bet: shrink the payload first, then stream what is left1 distinct publisher
build
Geofencing beats GPS polling on power, then loses to the OEM battery optimiser1 distinct publisher
build
"No key, no SDK" is not a guarantee on Android: the manifest merger gets there first1 distinct publisher
build
CrowdStrike's own triage numbers make AI auto-close a calibration contract, not a headcount cut1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 23, 2026