Speech-to-Speech:
anatomy of a spike

The curve has two engines, not one

For 22 months this repo was flat. It launched in August 2024 with a burst (~3,000 stars in six weeks), then decayed to roughly 100 stars a month and stayed there through May 2026. Then two separate things happened three weeks apart.

What actually happened, in order

The interesting part is that the technical work and the popularity are separated by a full quarter. The project was rebuilt between February and June, and discovered in July.

The wedge: substitution, not speech

Nothing in this repo is a new capability. Every component is someone else's model. What it sells is the removal of a decision.

The value proposition compresses to four lines in a terminal:

• You already wrote the client. speech-to-speech serve exposes /v1/realtime over WebSocket and WebRTC, speaking the core OpenAI Realtime GA event set. The official OpenAI Agents SDK connects to it unchanged. You change a URL.
• You stop paying per minute. The LLM slot speaks OpenAI-compatible protocols, so it points at a hosted provider, at HF Inference Providers, or at llama.cpp on your own box.
• The audio can stay on the machine. "No cloud, no API keys, no data leaving your machine" is the line in the Reachy Mini post, and it is what the offline-operation issues are about.
• It is already in production. 9,000+ Reachy Mini robots run this as their conversation backend. That is a rare thing for an open-source voice stack to be able to say.

This is why the 2026 engineering effort looks the way it does. Sorting the year's 355 issues and PRs by topic, the largest clusters are backend plumbing and protocol conformance, not modelling:

Multi-label; an item can appear in more than one row. The genuinely hard, genuinely novel work here is in turn-taking and cancellation semantics: deciding whether a pause is the end of a sentence or the middle of a thought, and unwinding a half-spoken response when the user interrupts. That work produces no paper.

How much of this is real

Three independent checks, and they disagree with each other by a lot.

Check 1: a third of recent forks come from accounts that are gone or fake

Of 1,179 forks since 26 June, 189 (16%) were made by accounts that no longer exist: deleted or suspended by GitHub in the weeks since. Of the 989 that survive, another 191 match a farm pattern: created in 2026, zero followers, a FirstnameLastname#### login, no company, and bios like "Here for the commits" attached to invented locations ("Ramirezville", "Motala, Mexico").

Check 2: 87% of forks are never touched

Across all 1,757 forks, only 222 were ever pushed to after creation. For forks made since 1 July the figure is 9%; for the 2024 cohort it was 18%. Forks here are bookmarks, not work. Only 54 forks have attracted a star of their own, and the top two are from 2024.

Check 3: installs tell a much more modest story than stars

The last two rows are the ones I would trust most. Filing a bug with a stack trace, or opening a PR, costs real effort. Outside-filed issues ran at 1–3 a month through June, then 11 in July and 11 in the first 25 days of August. Outside PRs went from 2–4 a month to 29 and 36. That is a ten-fold jump in people who ran it, hit something, and cared enough to write it up. A much better signal than the star curve, and much smaller than it.

Is 62% normal? No. Here is the baseline.

I ran the identical audit on nine other repositories over the identical window: every fork created between 26 June and 25 August 2026, every owner account resolved through the GitHub GraphQL API, the same farm heuristic. The reference set mixes direct peers, a Hugging Face control, and four repos that were themselves trending this summer.

"Worst single day" only counts days with 10+ forks. Nothing in the reference set comes near 92%. Narrowing to the identical fortnight (forks created 1–15 July 2026, so every account has had the same six weeks to be caught), the spread is: speech-to-speech 58%, Win11Debloat 20%, omarchy 19%, moshi 18%, livekit 14%, sherpa-onnx 12%, gods-eye-view 8%, pipecat 5%, trl 3%.

The obvious objection: older accounts have had longer to be deleted

True, and it does not rescue the number. Run the same check on this repo's own older fork cohorts, which have had far longer to accumulate deletions:

Two years of attrition on the 2024 cohort produced 5.9%. Eight weeks produced 16%. Deletion rate here is not a function of time; it is a function of who showed up. (The Jan–May 2026 row is 14 accounts out of 99, too small to read anything into.)

Can you tell whether GitHub stars are real?

Directly, as of today: no. I checked all three routes and every one of them is closed. Everything below is a proxy, and it is worth knowing which proxies still work.

The three dead ends

• The REST stargazers endpoint returns 404. Not 403, not a scope problem. GET /repos/{owner}/{repo}/stargazers is simply gone, for any repo, with a valid token.
• The stargazers web page returns 404 too. github.com/{owner}/{repo}/stargazers, nine bytes of response body.
• The public event firehose no longer carries stars. star-history.com now renders a placeholder image reading "GitHub restricted access to star data." The archive confirms it.

The practical consequence: nobody can currently audit a star list, and any tool that claims to score "star authenticity" is either running a proxy like the one below or serving you numbers from before spring 2026.

The four proxies that still work

• Audit the fork owners instead. Fork lists are still public, with owner logins, and each account can be resolved through GraphQL. Farms rarely buy one metric in isolation (the same traffic that stars also forks), so the fork population is a readable sample of the star population. This is the method behind everything above. It needs a same-window baseline to mean anything, which is what §05 is for.
• Watch the fork-to-star ratio. It needs no identity data at all. Across fourteen large repos the lifetime ratio sits between 0.04 and 0.27, median ~0.11. speech-to-speech's own lifetime ratio is a completely unremarkable 0.124. On 10 July it was 0.70. Humans star far more than they fork; scripts fork as readily as they star, because to a script both are one API call. A daily ratio outside the band is the cheapest fraud detector available.
• Use deletions as GitHub's own late verdict. You cannot see the abuse team's decisions, but you can see their effect: accounts that vanish. It arrives weeks late and it undercounts, but it is the one signal that is not a heuristic. The 16% here is an exact count, not an estimate.
• Cross-check against a metric that costs effort. Installs, outside PRs, filed issues with stack traces. Stars and forks are one click; a pull request is not. When those move together, the growth is real; when stars move 165% and installs move 61%, you know how much of the wave was attention versus adoption.

What this method cannot tell you

• Deleted does not mean fake. People delete accounts, rename them, and go private. That is exactly why the baseline matters: the reference repos absorb the same background rate.
• The farm pattern is a heuristic: 2026 account, zero followers, name-plus-digits login, no bio or company, few repos. It will have false positives and misses. It is applied identically to all ten repos, so the comparison is fair even where the absolute number is soft.
• Forks are a proxy for stars, not a measurement of them. A campaign that bought only stars and no forks would be invisible to this. The fork-to-star ratio is the partial defence against that case, and it is the reason to always look at both.
• None of this says the maintainers did anything. Trending repositories are targets; farms harvest visible projects to age their accounts and pad activity histories. Someone getting farm-forked is more often a victim of the flywheel than a participant in it.

The pattern has a name, and a literature

Fake GitHub engagement has been a measured market since about 2022. The 10 July burst matches its fingerprint closely enough that the research reads like a description of it, with one interesting difference.

What the research says

The reference work is "Six Million (Suspected) Fake Stars in GitHub" (Carnegie Mellon, Socket and NC State, ICSE 2026, arXiv:2412.13459). Their tool, StarScout, scanned 20 TB of GitHub metadata: 6.7 billion events and 326 million stars from 2019 to 2024. The findings that bear on this case:

• ~6 million suspected fake stars across 18,617 repositories and roughly 301,000 participating accounts. By mid-2024, 16.66% of repositories with 50+ stars had been touched by a campaign, up from near zero before 2022.
• 57.07% of flagged accounts and 90.42% of flagged repositories were deleted by GitHub within months, about 16× the baseline rate. That is the same instrument used in §05: the deletion rate is GitHub's own verdict, and the authors validated their detector against it.
• They sort the accounts into three behavioural clusters. One of them, 7.49% of accounts, does both starring and forking, with 43.74% of its events being forks. Their reading is that those accounts come from merchants who sell stars and forks together.
• Their "low activity signature" is an account with a single star plus at most one further event on the same repository on the same day.
• AI and LLM repositories are the largest non-malicious category of recipient, ahead of crypto by volume.
• Only 0.42% of campaign repositories ever reached GitHub Trending, so the ranking algorithm filters most of this out. That matters here: the July farm did not put this repo on Trending. Real stars did, three weeks later.

What these particular accounts look like

I pulled the complete public repository list for the 47 farm-pattern accounts from the 9–12 July burst that GitHub has not deleted yet. The forensics are unusually clean:

• All 120 of their fork events happened on 9 or 10 July 2026. Nothing before, nothing after. These accounts have a 48-hour lifetime of activity.
• They were provisioned as a batch: 14 created on 30 June, 14 on 1 July, the rest across the surrounding fortnight. Nine days of ageing, then one burst.
• Median 4 public repositories each, 75% of them forks.
• Each also owns one or two original repositories with plausible infrastructure names: build-vault-client, email-service-ts, cms-fixtures, loader-adapter, avro-quickstart, docs-site-pytest. Every one created and pushed exactly once, on the same day as the forks. Profile filler.
• Their other forks are deliberately decorrelated: 73 non-target forks across 37 accounts, 61 distinct parent repositories, and no parent shared by more than 4 accounts. yt-dlp, PowerToys, tensorflow, spring-boot, prettier, nuxt, Fooocus. Evergreen giants, not that week's trending list.

That last point is the interesting difference from the literature. StarScout's strongest detector is a lockstep signature: groups of accounts hitting the same set of repositories inside a short window. Scattering the noise forks across unrelated evergreen projects breaks that signal while keeping one common target. What still gives the batch away is timing, not co-occurrence: 120 events in 48 hours from accounts created nine days earlier, which then went silent forever.

Which explanation fits

Two readings are available. Either someone bought promotion for this repository, or an account farm used the day's hot repository as filler while ageing its inventory. Three pieces of evidence point at the second:

• The mix is wrong for a promotion buy. Trending ranks on stars. On 10 July the repo took 117 forks against 167 stars, a ratio of 0.70 where its own lifetime ratio is 0.124. Nobody buying visibility spends the budget on forks, which move no ranking and are invisible to most readers.
• The accounts predate the target. The batch was created 30 June to 1 July. The repo first appeared on Trending on 3 July and reached Python #3 on 10 July. The inventory existed before there was anything to promote.
• Forks are what build a profile; stars are not. A star leaves nothing on your account page. A fork puts a repository on it. For an operation whose product is aged accounts that look like working developers, forking popular projects is the cheapest way to manufacture a history, which is exactly why three quarters of these accounts' repositories are forks.

So the most likely story is not that anyone promoted this project. It is that a farm needed something popular to point 180 disposable accounts at on 10 July, and a repository sitting at #3 on Python Trending was the obvious choice. The maintainers got nothing out of it: the fork counter moved, the star curve barely did, and GitHub deleted 62% of the accounts within six weeks.

This is also the background against which 2026 open source operates more generally. A maintainer survey published in March 2026 found that after inserting a marker instruction into contributing guidelines, 21 of 40 incoming pull requests self-identified as bot-generated within a day, with the author estimating the true share nearer 70%. Fork farms are the quiet end of the same problem.

Does the issue tracker match the star count?

Not on volume. On trajectory and on quality, yes. I pulled every issue and pull request from the last twelve months for this repo and eight references, split maintainers from outsiders, and normalised by stars. Three separate things come out of it, and they do not all point the same way.

1. Volume: four to seven times below comparable live projects

Over a full year the gap is starker. speech-to-speech drew 70 distinct outside people. pipecat, at a nearly identical star count, drew 635. livekit/agents drew 1,122. That works out to 184 stars per participant for this repo against 23 for pipecat, 12 for livekit and 37 for trl. On that measure it keeps company with faster-whisper (302) and moshi (267), which are finished artefacts rather than active products.

2. Trajectory: it is the only one accelerating

The volume number is unfair on its own, because 62% of the stars are eight weeks old and engagement lags attention. Measured against each project's own twelve-month baseline, the July and August rate is:

Every other project in the set is flat or declining against its own baseline. This one is running at 4.4 times its twelve-month average. The spike did convert into participation. It is converting from a very low base, and it has not arrived yet.

3. Composition: this part really is abnormal

The consequence is that the raw issue count overstates community. Of the 355 issues and PRs filed in 2026, only about a third came from outside the three core developers. And of the 71 outside people in the last year, 51 of them (72%) contributed exactly once. Nine have contributed three or more times.

4. But what does arrive is real work

This is the part that argues against writing the whole wave off. Outside pull requests opened since 1 July, with each project's own top-three PR authors excluded:

A 40% merge rate puts it squarely with pipecat and livekit. The submissions are substantive: only 9% change fewer than ten lines and 42% change more than 200, against 6% and 43% for pipecat. These are not typo drive-bys or the AI-generated list-submission PRs that flooded maintainers earlier in 2026. They are backend ports, MLX crash fixes, language-detection bugs and protocol conformance work.

Responsiveness is mid-pack too: 26% of outside issues get no reply at all (livekit 22%, pipecat 17%, trl 19%, silero-vad 39%, fastrtc 46%), the median outside issue closes in about ten days, and 32% are still open. Nobody is being ignored.

Who is actually using it

I profiled all 989 reachable accounts that forked the repo since July, and all 69 non-core people who filed an issue or PR in 2026. The two groups look nothing alike, and neither one looks like an ML research crowd.

The people who actually engage

The 69 outside contributors and issue-filers of 2026, by what their profiles say they do:

• Freelance and indie AI developers. The single largest group. Bios reading "building AI solutions," "IA First / Vibecoding / DevOps," "AI developer focused on LLM agents."
• Small voice-agent and AI product companies. Swiftask, Podego, MindOrbi, seeway.ai, Kupasai, MYNED-AI. Also a senior technical PMM at Telnyx, which sells voice infrastructure.
• Platform engineers from outside ML. A principal engineer doing Python/Go/Rust, an observability engineer at Canonical, an AI-infrastructure SWE in Paris.
• Mac and Windows desktop users. A large share of the bug reports are Apple Silicon MLX crashes and Windows wheel failures.
• Two speech researchers. A PhD student at SJTU X-LANCE and someone at BUT Speech@FIT. Out of sixty-nine.
• One clinician. An ETH Zurich clinical-AI postdoc who filed a German-language mistranscription bug.

The downstream code that references it is the same story: a Nova Sonic sample from aws-samples, translation demos, hackathon projects, a bilingual voice app, several Japanese and Chinese local-assistant forks. Applications, not research.

Why your sphere is silent

This is not an oversight on anyone's part. There is a structural reason for every part of the gap.

1. There is nothing to cite

No model, no paper, no benchmark, no leaderboard entry, no ablation. A research community's attention is allocated by citable artefacts, and this repo produces none. The one adjacent measurement effort (Real World VoiceEQ, 15 July) is a separate HF project.

2. It is a cascade, and cascades are settled science

VAD → STT → LLM → TTS was the 2023 answer. The research conversation moved to end-to-end full-duplex speech LMs: Moshi, Qwen3-Omni, PersonaPlex. For comparison: a blog post about running Nvidia PersonaPlex 7B full-duplex on Apple Silicon got 374 points on Hacker News in March 2026. The best this repo ever did on HN was 27 points, in September 2024. Your sphere is talking about speech-to-speech, just about the architecture this project deliberately isn't.

The project says so itself, in the Reachy Mini post: "Cascades are the most flexible option in the open-source landscape today, and with the right pieces they're also the fastest." That is a product argument, and a correct one, and it is uninteresting to a researcher.

3. Its actual innovation lives in unglamorous places

Smart Turn v3.2 endpointing, speculative STT and LLM execution during a user's turn, reversible pre-confirmation audio ducking for barge-in, transactional cancellation when a response is interrupted mid-sentence. These are genuinely hard and genuinely novel engineering problems. None of them are publishable, and none of them are demoable in a tweet.

4. The pitch is aimed at a different buyer

"Drop-in replacement for OpenAI Realtime," "no API keys," "runs on your laptop," "9,000 robots in production." Those are procurement arguments. They land with someone who has a voice product and an invoice, not with someone who has a research question.

5. Its distribution channels are ones you don't read

The July surge came through GitHub Trending, a partner press release, and a long tail of SEO content farms: explainx.ai, coddykit, drose.io, theresanaiforthat, Medium reposts, Chinese tutorial sites like txtmix and 17you, a DeepWiki page. Not arXiv, not research Twitter, not NeurIPS hallways. There was no Hacker News front page and no viral thread; there did not need to be.

6. There is almost nobody to hear from

782 of the repo's commits are from one person. The second contributor has 53. There is no lab, no co-author list, no six-person team each posting about their piece. A project with one maintainer generates roughly one maintainer's worth of discourse.

A note on how it is built

Worth flagging because it explains the throughput. In August 2026 alone the repo took 295 commits, with a test suite of 1,264 tests, almost all driven by one maintainer. Issue and PR descriptions across both the core team and outside contributors follow an identical machine-generated shape: a Summary section of terse bullets, then a Testing section reporting exact pass counts, ruff, mypy file counts, and twine checks. One commit is literally titled [codex] Fix TTS benchmark input message.

This is a coding-agent-run repository, and it is worth studying as one. It is how a single engineer keeps protocol parity with a moving OpenAI spec across six STT backends, seven TTS backends and three transports. It also explains why the issue tracker reads as a task queue rather than a conversation: most items are opened and closed by the same person within a day.

What I would watch

• The install baseline, not the stars. 347/day settled. If that climbs past 600 without another trending event, adoption is compounding on its own. If it decays back toward 215, the spike was weather.
• Outside PR count. 29 and 36 in July and August against 2–4 a month before. That is the only metric here that costs the contributor something, and it is up ten-fold.
• Whether the Realtime spec stays chaseable. The entire wedge is compatibility with a protocol the project does not control. Every OpenAI Realtime GA change is maintenance debt for one person.
• Reachy Mini volume. 9,000+ units is both the credibility and the bug-report firehose. Robot owners are not developers, and their failure modes (offline operation, low-end hardware, non-English speech) are steering the roadmap.
• Whether the cascade bet holds. If a good open end-to-end full-duplex model becomes practical to self-host, the architectural argument for this project weakens fast, though the protocol-compatibility argument survives it, which may be the more durable half of the business.