DEV Community: Max

The models small enough to fit on a phone are the worst at understanding children

Max — Wed, 16 Sep 2026 11:14:01 +0000

For an ordinary voice product, the choice between processing on the device and processing in the cloud is a question of money and latency. For a children's product it is a question of market access, and it gets settled before the first line of code. We are building WhyWave, a voice companion for children aged three to five, and we went looking for how much of the pipeline actually fits on the device. What we found along the way was an unpleasant symmetry: the smaller the model, the worse it understands children specifically, and the gap here is wider than it is on adult speech.

On why the cloud is closed to a children's product

Rule 1.3 of the App Store Review Guidelines forbids apps in the Kids Category from sending personally identifiable information or device information to third parties. A child's voice is exactly that: the definition in 16 CFR § 312.2 includes an audio file containing a child's voice outright, with no further condition such as a name or an identifier attached to it.

The usual voice pipeline goes microphone, cloud recognition, cloud language model, cloud synthesis. Every arrow there hands a child's voice to an outside service. On paper this collides with rule 1.3 head on, and while Apple softens the wording on its own developer page with a caveat about explicit parental consent, the contradiction between its two texts has never been resolved.

Then the model vendors. The Gemini API Additional Terms and section 20.d of the Google Cloud Service Specific Terms prohibit using Google's generative services inside a product directed at people under eighteen. OpenAI and Anthropic took the other route and published requirements for serving minors, though those requirements include zero data retention, age verification and audit rights.

Local processing changes the legal picture entirely, and that is the main argument in its favour. If the audio never leaves the device, the operator never receives it, so no collection occurs in the COPPA sense. There is nothing for rule 1.3 to prohibit, because no third party is in the diagram. Vendor terms do not apply, because there is no vendor either.

On what already fits on the device

Over the last two years the local pipeline stopped being exotic, and the numbers make that case better than any argument.

Recognition first. The WhisperKit team published work where Whisper Large v3 Turbo, a billion parameters, runs on the Neural Engine and is compared with cloud systems directly: gpt-4o-transcribe, Deepgram nova-3, Fireworks large-v3-turbo. The result is 0.46 seconds of latency at 2.2 per cent word error, which means the local system matched the fastest cloud system and beat all of them on accuracy. That was measured on a MacBook Pro with an M3 Max chip, though, and the caveat is worth keeping in mind. Separately they show that self-distilling the encoder with block-causal masks cuts encoder latency by 65 per cent, from 602 to 218 milliseconds, while accuracy stays within one per cent of the original.

Further down in weight sits Moonshine. Tiny is 27.1 million parameters, Base is 61.5 million. Dropping the mandatory zero-padding to thirty seconds that Whisper requires gives a fivefold reduction in compute on a ten-second segment, at an average word error of 12.66 against 12.81 for Whisper tiny.en. The authors say plainly what this is for: on cheap ARM processors Whisper tiny.en had a firm lower latency bound of around five hundred milliseconds, and a variable-length input removes it.

Synthesis. Kokoro is 82 million parameters, Apache-licensed weights, roughly 327 megabytes, 54 voices across eight languages. For scale, that is less than the average mobile game.

The language model. Apple Intelligence is a three-billion-parameter model running on the Neural Engine in a phone you can buy today. Models of that class on the device are ordinary now.

It all adds up to a sense that the problem is solved. At WhyWave that sense lasted exactly until we looked at how any of it works on children.

On the price the child pays

There is a table in the children's ASR benchmark worth reading slowly. These are Whisper-family models run without fine-tuning on the OGI Kids corpus: tiny at 39 million parameters returns 53.8 per cent word error, base at 74 million returns 38.0, small 25.4, medium 20.8, large-v3 at one and a half billion 19.9.

From the smallest model to the largest, the error falls by nearly a factor of three. On spontaneous children's speech in the MyST corpus the same row runs from 20.6 at tiny to 12.5 at large, a drop of less than half. The harder the material, the more every parameter you cut away costs you.

Now set that against the previous section. What lives on a device without effort is precisely tiny and base. By this table, those are the models that get every second word wrong when a child reads a word list aloud. Local processing, which solves the entire legal problem in one move, is bought at the price of accuracy on exactly the audience the whole thing was for.

One caveat, without which the picture flatters itself. MyST is third to fifth graders, OGI Kids runs from kindergarten upward, about fifty hours from 1,100 speakers. Preschoolers are either absent from these corpora or lost inside them. Our three to five year olds are territory with no public measurements at all, so 53.8 per cent at tiny should be read as an optimistic ceiling and not a worst case.

On what to do about it

The same paper has a second table that turns all of this around. After fine-tuning on children's speech, Whisper-tiny returns 2.7 per cent word error on OGI instead of 40.1 without it. On MyST it gets 11.6 instead of 20.6. Base drops to 2.0 after fine-tuning, medium to 1.6, so the gap between the tiny model and the large one nearly disappears. Fine-tuning tiny took two hours on two GPUs.

The conclusion runs opposite to what the previous section was building towards. What the model was trained on weighs more than how large it is. A 39-million-parameter model that has seen children's speech beats a model forty times its size that has not. For a product that needs to compute locally, this is the best news available: the thing worth fine-tuning is exactly the thing that fits on the phone.

All of which runs into data, of course. There is no public transcribed corpus of preschool speech, and collecting one yourself means recording three-year-olds, which starts up precisely the machinery of consent, storage and audit that local processing was supposed to spare you. WhyWave is still looking for the way out of that circle, and if you have one, write to us.

If you are building a voice product for adults, one thought from all this is useful to you. Numbers like "2.2 per cent word error" were obtained on speech that resembles the speech the models were trained on. Worth asking in advance how much your users resemble that sample, and worth looking for the section of the documentation that describes the training data. You probably will not find one.

Five hundred milliseconds of silence: how a voice agent decides you have finished

Max — Wed, 16 Sep 2026 09:57:39 +0000

Every voice assistant makes one decision more often than any other and discusses it less than any other: the person went quiet, have they finished the thought or are they taking a breath? You can get it wrong in both directions and both are obvious. Move too early and you cut the person off mid-sentence. Play it safe and they sit in silence wondering whether they were heard at all. Between those two failures lies a gap of a few hundred milliseconds, and almost the whole industry closes it the same way, with a timer.

We are building WhyWave, a voice companion for children aged three to five, and this timer is where we came to a halt. What follows is what we found while working out why.

On the time a machine actually has

Start with how this works between people, because people are what sets the feeling of a live conversation. The largest measurement available is the 2009 PNAS paper by Stivers and colleagues: ten languages, from English and Japanese to Tzeltal and Yélî-Dnye, 350 consecutive questions in each, 101 conversations. They measured the offset between the end of a question and the start of the answer. The overall mode of the distribution is zero milliseconds, which is to say the most common case is a person starting to answer at the exact moment the other one stops. The cross-linguistic median is plus one hundred milliseconds and the mean across the whole set is plus two hundred and eight; Japanese is fastest with a mean of seven milliseconds, Danish slowest at four hundred and sixty-nine.

The consequence we keep in front of us at WhyWave is this. People answer each other faster than almost any pipeline of recognition, language model and synthesis can run. A person in conversation starts talking before the other has finished, because they predict where the sentence is going. A machine waits for silence, and half its budget is gone right there.

How that budget gets spent varies. The standard approach: a voice activity detector splits the stream into speech and non-speech, and a timer sits on top of it, so many milliseconds of continuous silence and the turn is declared over. In OpenAI's Realtime API, server_vad treats half a second as the end of a turn: silence_duration_ms defaults to 500, another three hundred milliseconds of audio before speech onset is pulled back in through prefix_padding_ms, the activity threshold sits at 0.5, and the documentation says plainly that a shorter value makes the model respond faster while it starts cutting into short pauses. Pipecat sets VAD_STOP_SECS to two tenths of a second. LiveKit Agents puts min_delay at half a second and max_delay at three, and those drop to 0.3 and 2.5 once the audio turn-detection model is switched on. Silero VAD has min_silence_duration_ms at one hundred. A fivefold spread across thresholds has a simple explanation: there is no universally correct value, and each team picks its own point on the same curve, with interruptions at one end and dithering at the other.

On silence as a signal

The trouble is that silence inside a turn and silence after a turn are physically identical. The only thing separating them is what the person was about to say, and that is not in the signal. How often people go quiet in the middle of their own thought was measured by Melissa Redford in her work on pauses in children's and adults' narratives: adults in her sample put seven per cent of their pauses in grammatically incomplete positions, after a preposition, a conjunction, an article, between an auxiliary and its main verb, while for five-year-olds that figure was eighteen per cent. The five-year-olds also stopped nearly twice as often, 1.98 times per hundred words, and that effect holds up in the paper. The sample is tiny, ten pairs of a child and their own parent, so it points a direction without settling anything, and the direction is clear enough: the younger the speaker, the more of their silence falls in the middle of a phrase.

With children the timer stops working for three reasons at once. They answer more slowly: in the work of Casillas, Bobb and Clark on a corpus of English-language dialogue the median response latency for children was 625 milliseconds against 371 for adults in the same material, and while it shrinks with age, from 867 milliseconds at one year eight months to 523 by three and a half, that trend did not reach statistical significance. Set that beside a default of five hundred milliseconds: a child who is only just getting ready to answer has already been written off as finished. Recognition is the second reason. In a published benchmark of children's speech, zero-shot Whisper-large returns 43.9 per cent word error on ages four to seven against 18.6 on teenagers, so the end of the turn is placed wrongly and the content of the turn is read wrongly too. The third is that smooth turn transitions, where a person comes in exactly on the pause, settle in around the age of six, and before that a child is still learning to predict when the other speaker will stop.

On models in place of a timer

The last two years have produced a whole class of solutions where a model decides the turn is over. OpenAI added semantic_vad to the Realtime API: a classifier looks at the words spoken, scores the probability that the person is done and sets the timeout dynamically, with an impatience setting, eagerness, that defaults to auto, which is equivalent to medium, and maximum timeouts of eight, four and two seconds for low, medium and high.

Pipecat went further and put its model in the open. Smart Turn v2 is wav2vec2 with a linear head, 360 megabytes, 12 milliseconds of inference on an L40, fourteen languages. The next version got radically smaller: eight million parameters, eight megabytes as quantised ONNX, a Whisper Tiny encoder with a shallow linear classifier on top, the same 12 milliseconds now on a CPU, and a training set of 270,429 samples across 23 languages. Its input is the raw waveform, which is how it picks up the intonation of an unfinished phrase. LiveKit has its own audio model in two sizes, the smaller one running locally on a CPU, across fourteen languages; their text model, now being retired, reported true positive rates of 99.3 to 99.4 per cent at 50 to 160 milliseconds of latency, while true negative rates ranged from 85.1 per cent on Italian to 96.3 on Hindi. Those two figures are worth reading together: recognising the end of a turn is easy, and not mistaking an ordinary pause for the end is considerably harder, with quality depending on the language.

Which brings me to the reason for writing any of this. Take the dataset card for Smart Turn's training data: 270,429 recordings, 23 languages, durations from 0.36 to 32.6 seconds, four contributing organisations. On the age of the speakers it says nothing. The same holds across every other piece of documentation I read: languages are listed everywhere, age composition nowhere. Whether those corpora contain preschoolers cannot be checked from outside, though how such sets get collected is no secret, through crowdsourcing and synthesis, which means adult voices. And general-purpose models degrade on children's speech in a way that is predictable and large. So a product for preschoolers that takes any of these models off the shelf is relying on a tool whose quality on its own audience has been measured by nobody.

On what to do about it

We have no honest answer yet, only a set of options, and since this piece is read by people working on the same thing, here they are. The cheapest is to raise the thresholds: if a child answers more slowly, give the child more time. The price is a sluggish conversation, and a child responds to a second and a half of silence no better than to being interrupted. Another option is the grammar of the incomplete: eighteen per cent of children's pauses fall after a preposition or a conjunction, exactly the class of position a partial transcript makes visible, which works but demands fast streaming recognition, itself the weak link on children's speech. A turn model can be fine-tuned on children's data, since Smart Turn is open all the way down, training code and datasets included; that runs into the supply of preschool recordings labelled for end of turn, and no such corpus is public. Or you can change the signal: a child talking to a toy behaves differently from an adult talking to an assistant, they look at it, touch it, call it by name, and some of that can be caught without a microphone.

WhyWave has not launched, and this piece describes a place where the ready-made pieces do not fit together. It may be useful for one reason. Plenty has been written about recognising children's speech, plenty about detecting the end of a turn, and the two subjects almost never appear in the same place, even though for a voice product used by a four-year-old they are one problem. If you are building a voice agent for adults, one line of all this matters to you: the default in your framework was chosen by somebody else for somebody else's scenario. Go and look at what it is set to.

What the 2026 rules actually require before you ship a voice AI for children

Max — Sat, 12 Sep 2026 16:39:50 +0000

I am building WhyWave, a voice AI companion for children aged three to five. A child asks a question out loud, the system answers out loud, and the parent configures in advance what language to use and where the boundaries sit on difficult subjects.

Before writing any product code, I sat down and read the rules. Primary sources: 16 CFR Part 312 on eCFR, the regulations on EUR-Lex, the Commission's guidelines, Apple's and Google's policies, and the terms of service of the model vendors. I had already read the summaries and the law firm blog posts by then, and they turned out to be worth very little.

Almost everything published on this subject falls into one of two shapes. Either marketing that promises "full compliance", or a legal wall of text that leaves an engineer with no decision they can act on. Several things that determine the architecture of the product appear in neither.

On the child's voice

Under COPPA, personal information includes the following. Quoting § 312.2, paragraph 8 of the definition:

A photograph, video, or audio file where such file contains a child's image or voice

An audio file of a child speaking is personal information on its own. It needs no name attached and no device identifier.

The FTC's position is that collection is complete the moment you gather the file. Deleting it afterwards leaves the fact of collection intact.

There is a consequence worth absorbing before you start. The obligation attaches during the first second of the first sentence. Before the user database exists, before conversation history, before everything people usually treat as the moment they start handling personal data.

On the voice exception

The rule contains one exception that reads as though it were written for voice. Until 2025 it lived as an FTC enforcement policy statement from 2017, and the 2025 amendments wrote it into the text itself, at § 312.5(c)(9).

It waives parental consent when four conditions hold at once. You may collect audio and nothing beyond it, no other personal information whatsoever. You may use it solely to respond to the child's specific request. You may disclose it to no one. You must delete it immediately once the response has been given. On top of that you need an online notice under the new § 312.4(d)(4) stating what you use the audio for and that you delete it right away.

Reading this the first time, I was delighted. Then I read it again.

A companion that remembers the child between turns breaks the fourth condition. One that remembers across sessions breaks it more thoroughly. One that ties the audio to a device or account identifier breaks the first. One that sends audio to a third-party cloud ASR runs into the third.

The exception was written for a voice command. "Turn on the light", "set a timer for five minutes". In WhyWave, memory is the product: the system has to recognise the child, remember what they asked yesterday, and adjust explanations to what they have already grasped. On no reading does that design fit inside the exception.

This is the first item on the list that changes the architecture itself. If you are building a voice companion for children, hiding behind the voice exception is unavailable to you, which means verifiable parental consent and everything that trails behind it.

On the minimum before the first word

Start with the age gate, because a lot of people are counting on it.

There is a concept called mixed audience: a service with a mixed audience may ask for age and treat children differently from adults. A product for three to five year olds does not qualify. It counts as primarily child-directed. The FTC's age verification statement of 25 February 2026 says plainly that such operators must treat all users as children. Asking for a date of birth and sorting it out from there will not work here.

Now the actual list of what you need, with references to the rule text:

What	Where
Online privacy notice with five required elements	§ 312.4(d)(1)–(5)
Direct notice to a parent before collection	§ 312.4(c)(1)
Verifiable parental consent	§ 312.5(b)
Separate consent for third-party disclosure	§ 312.5(a)(2)
Written information security programme, five elements	§ 312.8(b)
Written assurances from every vendor touching the data	§ 312.8(c)
Written and published data retention policy	§ 312.10

One detail about consent gets misreported constantly. § 312.5(b)(2) lists methods for obtaining it, and that list is often presented as closed. The binding criterion is § 312.5(b)(1): the method must be "reasonably calculated", meaning reasonably calculated to ensure that the person giving consent is the parent. The list illustrates that criterion, and § 312.5(b)(3) together with § 312.12(a) describe how a new method gets approved.

The maximum civil penalty today is $53,088 per violation. The FTC has published no 2026 inflation adjustment, so the January 2025 figure still stands.

On the AI Act timeline

If you are carrying last year's dates in your head, update them.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026 and entered into force on 27 July. It rewrote Article 113 and moved the obligations for Annex III high-risk systems from 2 August 2026 to 2 December 2027.

Article 50 on transparency stayed where it was. It has applied since 2 August 2026, which means today.

You have to tell the user they are talking to an AI. The article carries a caveat for cases where this is obvious anyway, and the Commission's Article 50 guidelines (content approved 20 July 2026, C(2026) 5054 final) put it this way:

the exception cannot be relied upon in order to protect those vulnerable users efficiently

Where children are among the audience, obviousness is off the table.

The same guidelines say that for companions, a single message at first launch falls short. Periodic reminders are expected.

One requirement usually gets missed here. Article 50(2) obliges you to mark synthetic output in machine-readable form. For a voice product that means marking the audio itself as generated, which a line in the interface will not do.

On Article 5

Article 5 of the AI Act lists prohibited practices, and it was the part I least wanted to find. Paragraph 1(b) prohibits systems that exploit a person's vulnerability, including vulnerability due to age, where this causes significant harm.

The Commission published guidelines on prohibited practices, C(2025) 5052 final, dated 29 July 2025. Watch the number: the web is full of citations to C(2025) 884. That number belongs to a draft, and the adopted document carries a different one.

The guidelines give this as an example of a 1(b) violation:

An AI system that is designed in an anthropomorphic way and simulates human-like emotional responses in its interactions with children

The condition that makes it a violation appears alongside: the system fosters unhealthy emotional attachment.

And in the same document, the same design appears as lawful where it causes no significant harm.

Anthropomorphic design and simulated human emotional responses in interactions with children describe an entire product category, WhyWave included. What makes the design lawful or prohibited is whether it produces dependency.

The line therefore runs through engineering decisions. How strongly the system rewards coming back. Whether it can end a conversation. What it says when a child tells it they love it. No lawyer will hand you a document that closes this question, because the question sits outside documents.

On biometrics

One distinction here decides the architecture.

A system that recognises emotions on the basis of biometric data lands in Annex III and becomes high-risk from 2 December 2027. The definition in Article 3(39) hangs on the phrase "on the basis of their biometric data".

Vocal prosody is a biometric signal. Inferring emotion from text a person wrote themselves is expressly carved out by the Commission's guidelines: sentiment analysis of written text does not count as emotion recognition.

So if the pipeline runs ASR, then text, then the model concludes "the child sounds upset" from the words, the classification appears to miss.

That reading is an argument, and it has not become a safe harbour. No regulator has addressed emotion inference from a transcript of a child's speech, and the counter-argument carries weight, since the transcript derives from biometric input and the purpose of the system is to adapt to mood. This is a question for counsel to answer.

The other half of the same subject is Article 9 GDPR, where people routinely get it backwards.

Cloning a parent's voice for playback is ordinary personal data. Speaker recognition is special category data under Article 9.

Article 4(14) draws the line: biometric data means data whose processing allows or confirms the unique identification of a person. The purpose of the processing decides which of the two you are doing. Synthesising a voice and identifying someone by their voice are different things as far as the regulation is concerned.

Worth knowing, incidentally, that the term "GDPR-K", which circulates through vendor blogs and slide decks, does not exist. It appears nowhere in Regulation 2016/679. People use it informally for Article 8. The industry invented itself a statute and now cites it in marketing material.

A data protection impact assessment is effectively mandatory for a product like this. The EDPB's guidelines on voice assistants say such services are very likely to fall into the categories requiring a DPIA, and a children's product hits several criteria at once: vulnerable subjects, innovative technology, sensitive data.

On the UK

The Children's Code, formally the Age Appropriate Design Code, is a statutory code under section 123 of the Data Protection Act 2018.

The ICO on what happens if you ignore it:

if your online service fails to conform to a provision of this code you may find it difficult to demonstrate compliance with the law and you may invite regulatory action

Standard 14 of the code covers connected toys and devices, and it offers an example. The example is a talking teddy bear with a microphone.

On top of that, section 81 of the Data (Use and Access) Act 2025 inserted Article 25(1A) into the UK GDPR, which from 5 February 2026 turned part of the code into a direct statutory duty.

On model vendors

I found this in no material on the subject, though in practice it is the first thing a product trips over.

The Gemini API Additional Terms, effective 23 March 2026, and Google Cloud Service Specific Terms § 20.d prohibit using Google's generative services as part of a service that

is directed towards or is likely to be accessed by individuals under the age of 18

A voice companion for three year olds breaches its supplier agreement before it ever reaches app review.

OpenAI and Anthropic took the opposite route and published conditions for serving minors. OpenAI requires zero data retention when processing personal data of children under thirteen and reserves audit rights. Anthropic requires age verification, moderation, monitoring, and disclosure that the counterpart is an AI.

For a children's product, compliance requirements decide the choice of model, ahead of latency, price and benchmark position.

On app stores

Rule 1.3 of the App Store Review Guidelines, for apps in the Kids Category:

may not send personally identifiable information or device information to third parties

A child's voice is personal information under § 312.2(8). A cloud pipeline with external ASR, LLM and TTS conflicts directly with that rule. On its own developer page Apple softens the wording with a caveat about explicit parental consent, and Apple has not reconciled the discrepancy.

Rule 2.3.8 closes the obvious workaround: the words "For Kids" and "For Children" are reserved for the Kids Category. Meanwhile products already on sale sit outside that category with a 4+ rating. The path everyone takes is a violation on paper.

A curious detail: neither Apple's guidelines nor Google's Families policy contains a single rule specific to AI in children's apps. Both put the hook somewhere else. Apple uses the age rating questionnaire, which asks you to account for how AI assistant and chatbot functionality affects sensitive content. Google uses its generative content policy, which requires an in-app reporting mechanism.

On state laws

Washington's ESHB 2225 takes effect on 1 January 2027. For minors it prohibits reminders and prompts to return for emotional support or companionship, excessive praise designed to foster emotional attachment, and outputs promoting exclusive reliance on an AI companion for emotional support. Three provisions, each describing retention mechanics that come built into this product category by default.

California's SB 243 has been operative since 1 January 2026, New York's General Business Law Article 47 since 5 November 2025.

Worth adding that on 11 September 2025 the FTC issued 6(b) orders to seven companies operating consumer AI companion chatbots, and the questions there cover children and COPPA compliance directly.

On what to do with all this

WhyWave has not launched. Everything above came out of reading before writing product code, which is exactly why it might be useful to someone else.

Several of these rules resist being bolted on as a checklist before release. The voice exception either shapes your memory architecture or does nothing for you. Your choice of model vendor opens or closes entire markets. Emotional attachment is settled by how the dialogue is written.

The calendar needs rechecking every few months. In the time I spent studying this, both the AI Act deadlines and Google's rules on minors changed.

The temptation to put a "COPPA compliant" badge on your landing page is strong. Unsubstantiated compliance claims fall under Section 5 of the FTC Act as deceptive, separately from COPPA itself. The WhyWave site carried such a badge. I took it down.

All references are as of 11 September 2026. This is not legal advice. If you are building something in this space, a paid hour with a children's privacy specialist pays for itself faster than you would think.