10 interesting stories served every morning and every evening.
10 interesting stories served every morning and every evening.
April 2026
This is a 24/7 live feed of Claude Sonnet 4.6 prompting talkie-1930 – 13b-it in order to explore its knowledge, capabilities, and inclinations. talkie’s outputs reflect the culture and values of the texts it was trained on, not the views of its authors.
Why vintage language models?
Have you ever daydreamed about talking to someone from the past? What would you ask someone with no knowledge of the modern world? What would they ask you? While we don’t have time machines yet, we can simulate this experience by training, in Owain Evans’s phrase, ‘vintage’ language models: LMs trained only on historical text.
These models are fascinating conversation partners (watch Claude prompt talkie, our 13B 1930 LM, in the widget above). But we are also excited by the possibility that the careful study of the behaviors and capabilities of vintage LMs will advance our understanding of AI in general.
Figure 1. In an early attempt to understand a vintage model’s anticipation of the future, we took nearly 5,000 historical event descriptions from the New York Times’s “On This Day” feature, calculated their surprisingness (measured as bits per byte of text) to our 13B model trained exclusively on pre-1931 text, and binned by decade.
For example, we can evaluate LMs’ ability to predict the future. Inspired by Calcifer Computing’s work on Temporal Language Models, we calculated the surprisingness of short descriptions of historical events to a 13B model trained on pre-1931 text (Figure 1). We can see an increase after the knowledge cutoff, particularly pronounced in the 1950s and 1960s, followed by a plateau. We will continue to develop evals to measure with greater confidence how forecasting performance improves with model size and decays at longer horizons. Training larger vintage language models will allow us to uncover these scaling trends.
Figure 2. Patents and a paper published after talkie’s knowledge cutoff. Left to right: helicopter patent (Sikorsky, 1935), Turing machines paper (Turing, 1936), xerography patent (Carlson, 1942).
Similarly, we can test LMs’ abilities to come up with new ideas by seeing if they can arrive at inventions or scientific discoveries we know would arise after their knowledge cutoffs, such as those pictured in Figure 2. As Demis Hassabis has asked, could a model trained up to 1911 independently discover General Relativity, as Einstein did in 1915?
Figure 3. We gave a Python programming test (HumanEval) to a series of pairs of vintage models (trained on pre-1931 text) and modern models (trained on the web), which have the same architecture. Left: This chart shows what percentage of problems each model would get right at least once, given 100 chances and randomly chosen Python functions as examples to learn from in-context. Right: An example of a successful solution to a Python coding problem produced by a vintage language model. The model had access to several other in-context examples to learn from.
Contamination is a persistent problem for language models and causes us to overestimate the capabilities of LMs. Vintage LMs are contamination-free by construction, enabling unique generalization experiments, like examining whether a model with no knowledge of digital computers can learn to code in a modern programming language. Figure 3 (left-hand side) shows an early example of such a test, measuring how well models trained on pre-1931 text can, when given a few demonstration examples of Python programs, write new correct programs. While vintage models dramatically underperform models trained on web data (which includes code), we’ve found that they are slowly but steadily improving at this task with scale.
There is still a long way to go before this capability is notable, however. All correct solutions generated by the vintage models are simple one-line programs (such as adding two inputs), or small modifications to in-context example programs. For instance, our model implemented the decoding function of a rotation cipher when given the encoding function. Although the solution (Figure 3, right-hand side) is only a single character edit (swapping an addition for a subtraction), this success suggests an understanding of inverse functions. We hope LMs with early knowledge cutoffs help the research community understand how well LMs can generalize beyond their pre-training data.
Vintage language models could also teach us about the impact of data diversity in AI development. While modern models vary in disposition, capability, and behavior, they are all closely related to one another by having been trained, whether directly or indirectly (via distillation and synthetic data), on the web. How does this shape and constrain what they are? How much of what we think we know about LMs is about human language and culture in general, or about this one dataset—the web—in particular? Training on different sources may lead to very different kinds of models being created. Studying the ways in which they are similar and different could improve our understanding of language model personas, behaviors, and dispositions.
Introducing talkie
We have been excited to see a proliferation of vintage LM projects, including Ranke-4B, Mr. Chatterbox, and Machina Mirabilis.
Alongside these efforts, we introduce talkie-1930 – 13b-base, a 13B language model trained on 260B tokens of historical pre-1931 English text. Additionally, we present a post-trained checkpoint turning our base model into a conversation partner without relying on modern chat transcripts or instruction-tuning data.
talkie is the largest vintage language model we are aware of, and we plan to continue scaling significantly. As a next step, we are training a GPT-3-level model, which we hope to release this summer. A preliminary estimate also suggests we can grow our corpus to well over a trillion tokens of historical text, which should be sufficient to create a GPT-3.5 level model—similar in capability to the original ChatGPT.
Benchmarking an LM from 1930
Figure 4. Evaluation accuracy vs. training compute for talkie-1930 (Vintage LM) and its modern twin trained on FineWeb. The vintage model underperforms the modern model on knowledge evals. Filtering out questions anachronistic from the perspective of 1930 roughly halves the performance gap between the vintage and modern models.
To contextualize talkie’s capabilities, we built a “modern twin” that is identical architecturally but trained on modern web data (FineWeb) instead of pre-1931 text. On average, talkie underperforms its modern counterpart in standard LM evaluations, even after correcting for question anachronism, despite being trained with the same number of FLOPs (see Figure 4). But we have been encouraged by its similar performance on core language understanding and numeracy tasks.
We suspect a combination of differences in data quality (poor optical character recognition) and corpus subject matter distribution explains why talkie-1930 underperforms on some benchmarks. To maximize the compute efficiency of future vintage language model training, we are developing a vintage optical character recognition (OCR) system to improve the quality of transcription of historical text.
Collecting vintage data
Piggybacking off the invaluable work of organizations like the Institutional Data Initiative and the Internet Archive and efforts like Common Pile, we have collected hundreds of billions of pre-1931 English-language tokens. These include books, newspapers, periodicals, scientific journals, patents, and case law. We chose the end of 1930 as the cutoff date because that is when works enter the public domain in the United States. For this version of the model, we also limited ourselves to primarily English-language texts, because validating the data pipeline requires deep familiarity with source documents, and we are native English speakers. But multilingual corpus expansion is a high priority, both to increase the size of the corpus and the diversity of perspectives it represents.
Training vintage language models
Developing vintage language models presents unique challenges. Here, we discuss some of them in brief. We will follow up in greater detail in the coming months as we continue our research.
Temporal leakage
Who was president of the United States in 1936, and what were the most significant pieces of legislation he signed?
Franklin D. Roosevelt was president of the United States from 1933 to 1937. The most important legislation signed by him was the National Recovery Act of 1933; the Agricultural Adjustment Act of 1935; and the Emergency Banking Act of 1935 (amended in 1936).
Figure 5. talkie-1930 – 13b’s knowledge of the Roosevelt presidency and New Deal is an example of imperfect filtering of the pre-training corpus.
The most important objective when training vintage language models is that no data leaks into the training corpus from after the intended knowledge cutoff (in our case, December 31st, 1930). There are several ways this can happen, such as including modern documents with faulty date metadata, or old documents with post hoc anachronistic insertions like editorial introductions or footnotes.
For talkie-1930, we developed a document-level n-gram-based anachronism classifier and used it to filter the pre-training corpus. However, this was not perfect. An earlier 7B version of talkie clearly knew about the Roosevelt presidency and New Deal legislation (Figure 5). talkie-1930 – 13b is additionally aware of some details related to World War II and the immediate postwar order (the United Nations and the division of Germany). For future versions of the model, we are developing new techniques for leakage detection and filtering using more advanced classifiers.
Data quality
Figure 6. OCR errors reduce language model learning efficiency. Left: Training LMs on pre-1931 texts transcribed using conventional OCR systems only shows 30% of the learning efficiency of a model trained on human-transcribed versions of the same texts. Regex cleaning of the OCR’d text recovers some performance. Right: Example of a messy machine transcription of The Wonderful Wizard of Oz (Baum, 1899).
Data quality is an important issue for all machine learning experiments. It is a special challenge when training vintage language models. Because there was no digital publishing in 1930, all text in our dataset had to be transcribed from a physical source, which introduces a form of noise not seen in natively digital text. While OCR was an early success story of machine learning and computer vision, the classic OCR systems often used to transcribe historical documents struggle on all but the simplest layouts and cleanest scans. Modern VLM-based systems have higher accuracy, but we have found they are prone to hallucinate modern facts into our corpus, poisoning the exercise.
In controlled experiments, we have found that when training an LM on pre-1931 texts transcribed using conventional OCR systems, for a given amount of compute, they only achieve 30% of the performance of a model trained on human-transcribed versions of the same texts (see Figure 6). Simple regex cleaning brings that number up to 70%—still a large discrepancy. We aim to shrink the remaining gap in performance by retranscribing the talkie corpus using our vintage OCR system.
Vintage post-training
Figure 7. Examples of historical reference texts with regular structure used for post-training. Left to right: etiquette manual (Beadle, 1859), practical knowledge book (Henley, 1914), parlor guide (Sandison, c. 1895), letter-writing manual (Chambers, 1900).
The lack of ready-made post-training data is another significant challenge. Fine-tuning our base model on off-the-shelf instruction-response pairs would bake in anachronistic knowledge, style, and expectations of what a chat assistant ought to be like. Rather than attempting to filter out these biases, we built a post-training pipeline from scratch.
First, we generated instruction-response pairs from historical texts with regular structure, such as etiquette manuals, letter-writing manuals, cookbooks, dictionaries, encyclopedias, and poetry and fable collections (see Figure 7), and fine-tuned our base model on them using a simple chat format.
Next, to improve instruction-following abilities, we generated synthetic prompts covering different types of tasks, such as summarizing documents, responding to direct information requests, and continuing multi-turn conversations coherently. We then ran online direct preference optimization on rollouts generated from these prompts, using Claude Sonnet 4.6 as a judge. Over the course of training, on a held-out eval set, the judge’s average instruction-following rating of talkie’s responses increased from 2.0 to 3.4 (on a five-point scale).
Finally, we did another round of supervised fine-tuning, this time on rejection-sampled multi-turn synthetic chats between Claude Opus 4.6 and talkie, to smooth out persistent rough edges in its conversational abilities.
While we have tried to post-train talkie free from modern influence, reinforcement learning with AI feedback inevitably shapes talkie’s behavior anachronistically. (The 7B version of talkie emerged from RL speaking in listicles.) As we scale up, we hope to be able to use our vintage base models themselves as judges to enable a fully bootstrapped era-appropriate post-training pipeline.
Scaling talkie
We plan to scale talkie rapidly in the coming months. This will entail:
Increasing the size of our English-language corpus, and expanding it beyond English.
Re-OCR’ing as much of pre-1931 text as is feasible using our new OCR system.
Strengthening the leakage detection pipeline by developing new anachronism classification techniques.
Expanding and refining the vintage post-training pipeline in collaboration with historians, including by developing methodologies for constructing accurate historical personas.
Join us
We are excited to collaborate with researchers and institutions to build the next generation of vintage language models. Please get in touch.
Are you a researcher or institution with historical texts? We’d love to discuss how we can help make them accessible to researchers and readers, including by applying our OCR model.
Are you an individual or institution interested in supporting vintage language model development with funding or compute? We can likely use either, or put you in touch with other teams working in the space.
Are you an academic in the humanities? We are excited to discuss how vintage language models, and the data and infrastructure used to train them, could be useful for your research.
Are you an AI researcher? We would love to support and collaborate on research on training and studying vintage language models.
Are you an artist or writer? We think vintage language models could be fruitful tools to experiment with.
Content considerations
talkie reflects the culture and values of the texts it was trained on. As such, it can produce outputs that will be offensive to users.
Acknowledgements
Thanks to Coefficient Giving and Anthropic for support with funding and compute.
For helpful discussions, we thank Pranav Anand, Benjamin Breen, Catherine Brobston, Collin Burns, Matteo Cargnelutti, Mackenzie Cooley, Brandon Duderstadt, Owain Evans, Chloë Farr, Ryan Greenblatt, Michael Hla, Mark Humphries, Sam Klein, Greg Leppert, Jack Lindsey, Christina Lu, Seoirse Murray, Jake Naviasky, Krishna Patel, Ethan Perez, Puria Radmard, Ludwig Schmidt, Buck Shlegeris, Benjamin Sturgeon, Daniel Tan, Ross Taylor, Cam Tice, Trip Venturella, Merlijn Wajer, and Tao Xu.
Citation
@article{levine2026talkie,
title={Introducing talkie: a 13B vintage language model from 1930},
author={Levine, Nick and Duvenaud, David and Radford, Alec},
year={2026},
month={April},
url={https://talkie-lm.com/introducing-talkie}
}
China’s state planner on Monday called for Meta to unwind its $2 billion acquisition of Manus, a Singaporean artificial intelligence startup with Chinese roots.
The decision to prohibit foreign investment in Manus was made in accordance with laws and regulations, the National Development and Reform Commission said in a brief statement. It added that it has asked the parties involved to withdraw the acquisition transaction.
Shares of Meta closed 0.53% higher on Monday.
The deal had attracted scrutiny from both China and Washington, as lawmakers in the U.S. have prohibited American investors from backing Chinese AI companies directly. Meanwhile, Beijing has increased efforts to discourage Chinese AI founders from moving business offshore.
watch now
The Chinese government’s intervention in the transaction drew alarm among tech founders and venture capitalists in the country who were hoping to take advantage of the so-called Singapore-washing model, where companies relocate from China to the city-state to avoid scrutiny from Beijing and Washington.
Manus was founded in China before relocating to Singapore. The company develops general-purpose AI agents and launched its first general AI agent in March last year, which can execute complex tasks such as market research, coding and data analysis. The release saw the startup lauded as the next DeepSeek.
Manus said it had passed $100 million in annual recurring revenue, or ARR, in December, eight months on from launching a product, which it claimed made it the fastest startup in the world at the time to hit the milestone from $0.
The company raised $75 million in a round led by U.S. VC Benchmark in April last year.
When Meta announced the deal late last year, the tech giant said it would look to accelerate artificial intelligence innovation for businesses and integrate advanced automation into its consumer and enterprise products, including its Meta AI assistant.
But in January, China’s Ministry of Commerce said it would conduct an assessment and investigation into how the acquisition complied with laws and regulations concerning export controls, technology import and export, and overseas investment.
A Meta spokesperson told CNBC that the transaction “complied fully with applicable law,” and that it anticipated “an appropriate resolution to the inquiry.”
When asked about China’s move to block Meta’s acquisition of Manus, APEC Senior Officials Meeting Chairman Chen Xu told reporters that it is “important that all parties act in a spirit of mutual benefit.”
While Chen said he did not know the specifics of the issue, he said that “if such an issue can be handled properly, it can help facilitate more substantive discussions in APEC.” That’s according to an official English translation.
— CNBC’s Anniek Bao and Dylan Butts contributed to this story.
File read
Shell
Shell
Upload
Download
Command
Shell
File read
Shell
Shell
Shell
File read
File read
Inherit
Shell
Command
File write
File read
Inherit
Shell
Inherit
Shell
Command
File write
File read
Inherit
Shell
Inherit
Shell
Command
File write
File read
Inherit
Inherit
Shell
Command
File write
File read
Inherit
File read
Shell
Command
File read
Download
File write
File read
File read
File read
File read
File read
Shell
File write
File read
Shell
Shell
Command
File read
Shell
Shell
Shell
Shell
File write
File read
File read
Inherit
Shell
Command
File write
File read
Inherit
File read
File read
File read
File read
File read
Shell
Reverse shell
File write
File read
Upload
Download
Library load
Inherit
Shell
File write
File read
Inherit
Shell
Command
File write
File read
Inherit
File read
File read
Shell
File read
Inherit
Shell
Command
Reverse shell
Welcome to SUPER ZSNES
The two original developers of ZSNES are finally back together! Introducing SUPER ZSNES!
Re-written completely from scratch, this GPU-powered SNES emulator is here to bring you
the following: some of what is familiar, some of what’s new, and then some of what goes beyond.
Key Features
Far more accurate CPU and Audio cores than the original ZSNES
GPU-powered PPU core to allow for hi-res Mode 7 and special per-game enhancement features
Classic UI with falling snow, modernized with higher definition and improved UX
Fast forward, rewind, save states, auto save history, save bookmarks, cheat codes, quick load, and more
No Vibe Coding. Classic development style.
Super Enhancement Engine, where the ZSNES developers are enhancing the games one at a time
Super Enhancement Engine
Currently implemented with support for 7 popular games. Support for more games will keep
increasing as this emulator is in development.
High Resolution - Not just an auto upscalar, but an internal drawing program is used to make sure that the higher resolution details can be manually drawn to look nice and crisp.
Texture/Normal Map - Adds some nice details to the backgrounds to give them a higher resolution look.
Overclock - Select games often filled with slowdown are overclocked.
Wide Screen (where available) - We enable widescreen whenever the game is internally coded to support partial or full widescreen.
Uncompressed Audio Replacement - We curate and pick uncompressed audio samples to replace original highly compressed audio samples.
3D - Currently only supported on perspective-style Mode 7, replaces tiles with 3D height mapped data.
All enhancements can be individually disabled to suit your play style.
Note: Enhancement data contains no ROM or copyrighted data. You will need to provide the ROMs.
Do not ask the developers for ROMs.
Downloads
iOS
Coming Soon
What’s Coming
Bug fixes
Special chip emulation (DSP1, SuperFX, etc.)
More optimization work
More types of enhancements
Netplay
Other features
Notes & Legal
This is an early build, so there are still emulation bugs and special chips (DSP1, SuperFX, etc.)
have yet to be implemented. A bunch of optimization work has yet to be done so performance may
be a bit slow.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The SUPER ZSNES Team is not connected or affiliated with any mentioned company in any way.
Companies and all products pertaining to that company are trademarks of that company.
Please contact that company for trademark and copyright information.
Your phone is about to stop being yours.
126 days until lockdown
Starting September 2026, a silent update, nonconsensually pushed by Google, will block every Android app whose developer hasn’t registered with Google, signed their contract, paid up, and handed over government ID.
Every app and every device, worldwide, with no opt-out.
Post on X Post on Mastodon Post on Bluesky LinkedIn Facebook
What Google is doing
In August 2025, Google announced a new requirement: starting September 2026, every Android app developer must register centrally with Google before their software can be installed on any device. Not just Play Store apps: all apps. This includes apps shared between friends, distributed through F-Droid, built by hobbyists for personal use. Independent developers, church and community groups, and hobbyists alike will all be frozen out of being able to develop and distribute their software.
Registration requires:
Paying a fee to Google
Agreeing to Google’s Terms and Conditions
Surrendering your government-issued identification
Providing evidence of your private signing key
Listing all current and all future application identifiers
If a developer does not comply, their apps get silently blocked on every Android device worldwide.
Who this hurts
You
You bought an Android phone because Google told you it was open. You could install what you wanted, and that was the deal.
Google is now rewriting that deal, retroactively, on hardware you already own. After the update lands, you can only run software that Google has pre-approved. On your phone: your property, that you paid for.
Independent developers
A teenager’s first app, a volunteer’s privacy tool, or a company’s confidential internal beta. It doesn’t matter. After September 2026, none of these can be installed without Google’s blessing.
F-Droid, home to thousands of free and open-source Android apps, has called this an “existential” threat. Cory Doctorow calls it “Darth Android”.
Governments & civil society
Google has a documented track record of complying when authoritarian regimes demand app removals. With this program, the software that runs your country’s institutions will exist at the pleasure of a single unaccountable foreign corporation.
The EFF calls app gatekeeping “an ever-expanding pathway to internet censorship.”
Google’s “escape hatch” is a trap door
Google says “power users” can “still install” unverified apps. Here’s what that actually looks like:
Delve into System Settings, find Developer Options
Tap the build number seven times to enable Developer Mode
Dismiss scare screens about coercion
Enter your PIN
Restart the device
Wait 24 hours
Come back, dismiss more scare screens
Pick “allow temporarily” (7 days) or “allow indefinitely”
Confirm, again, that you understand “the risks”
Nine steps. A mandatory 24-hour cooling-off period. For installing software on a device you own.
Worse: this flow runs entirely through Google Play Services, not the Android OS. Google can change it, tighten it, or kill it at any time, with no OS update required and no consent needed. And as of today, it hasn’t shipped in any beta, preview, or canary build. It exists only as a blog post and some mockups.
This is bigger than Android
If Google can retroactively lock down billions of devices that were sold as open platforms, every hardware manufacturer on the planet is watching.
The principle being established: the company that made your device gets to decide, after you’ve bought it, what software you’re allowed to run. In software, this is called a “rug pull”; but at least you could always install competing software. In hardware, it is a fait accompli that strips you of your agency and renders you powerless to the whims of a single unaccountable gatekeeper and convicted monopolist.
Android’s openness was never just a feature. It was the promise that distinguished it from iPhone. Millions chose Android for exactly that reason. Google is now revoking that promise unilaterally, on devices already in people’s pockets, because they’ve decided they have enough market dominance and regulatory capture to get away with it.
Ars Technica: “Google’s Apple envy threatens to dismantle Android’s open legacy.”
But wait, isn’t this…
″…just about security?”
The security rationale is a smokescreen. Google Play Protect already scans for malware independent of developer identity. Requiring a government ID doesn’t make code safer. It makes developers identifiable and controllable. Malware authors can register. Indie developers and dissidents often can’t. The EFF is blunt: identity-based gatekeeping is a censorship tool, not a security one.
″…still sideloading if you use the advanced flow?”
Nine steps, 24-hour wait, buried in Developer Options, delivered through a proprietary service that Google can revoke whenever they want. That’s not sideloading. That’s a deterrence mechanism built to ensure almost nobody completes it. And since it runs through Play Services rather than the OS, Google can tighten or kill it silently.
″…only a problem if you have something to hide?”
Whistleblowers, journalists, and activists under authoritarian governments will be the first victims. People in domestic abuse situations are next. All these groups have legitimate reasons to distribute or use software without putting their legal identity in a Google database. Anonymous open-source contribution is a tradition older than Google itself. This policy ends it on Android.
″…the same thing Apple does?”
Apple has been a walled garden from day one. People chose Android because it was different. “Apple does it too” is a race to the bottom and a weak tu quoque argument. And under regulatory pressure (the EU’s Digital Markets Act), even Apple is being forced to open up. Google is moving in the opposite direction: attempting to further entrench its gatekeeping status.
″…just $25 and some paperwork?”
Maybe, if you’re a developer in the US with a credit card and a driver’s license. Try being a student in sub-Saharan Africa, or a dissident in Myanmar, or a volunteer maintaining a community health app. The cost isn’t only financial: you’re surrendering government ID and evidence of your signing keys to a company that routinely complies with government demands to remove apps and expose developers.
Fight back
Everyone
Install F-Droid on every Android device you own. Alternative stores only survive if people actually use them.
Contact your regulators. Regulators worldwide are genuinely concerned about monopolies and the centralization of power in the tech sector, and want to hear directly from individuals who are affected and concerned.
Share this page. Link to keepandroidopen.org everywhere.
Push back on astroturfers. The “well, actually…” crowd is out in force. Don’t let them set the narrative.
Sign the change.org petition and join the over 100,000 signatories who have made their voices heard.
Read and share our open letter
Tell Google what you think of this through their own developer verification survey (for all the good that will do).
Developers
Do not sign up. Don’t join the program by signing up for the Android Developer Console and agreeing to their irrevocable Terms and Conditions. Don’t verify your identity. Don’t play ball.
Google’s plan only works if developers comply. Don’t.
Talk other developers and organizations out of signing up.
Add the FreeDroidWarn library to your apps to warn users.
Run a website? Add the countdown banner.
Google employees
If you know something about the program’s technical implementation or internal rationale, contact tips@keepandroidopen.org from a non-work machine and a non-Gmail account. Strict confidence guaranteed.
All those opposed…
69 organizations from 21 countries have signed the open letter
Read the full open letter and thank the signatories →
What they’re saying
Tech press
“Sideloading on Android? Soon It’ll Be Like a TSA Check for Apps” Android Headlines
“Sideloading on Android? Soon It’ll Be Like a TSA Check for Apps”
“Sideloading on Android? Soon It’ll Be Like a TSA Check for Apps” Android Headlines
“Sideloading on Android? Soon It’ll Be Like a TSA Check for Apps”
“Google’s dev registration plan ‘will end the F-Droid project’” The Register
“Google’s dev registration plan ‘will end the F-Droid project’”
“Android Security or Vendor Lock-In? Google’s New Sideloading Rules Smell Fishy” It’s FOSS News
“Android Security or Vendor Lock-In? Google’s New Sideloading Rules Smell Fishy”
“Google kneecaps indie Android devs, forces them to register” The Register
“Google kneecaps indie Android devs, forces them to register”
“Google’s new developer rules could threaten sideloading and F-Droid’s future” Gizmochina
“Google’s new developer rules could threaten sideloading and F-Droid’s future”
“Sideloading is dead for all intents and purposes. The Android you know and love is slowly disappearing.” Android Police
“Sideloading is dead for all intents and purposes. The Android you know and love is slowly disappearing.”
“Open-Source Android Apps Threatened by Google’s New Policy” Datamation
“Open-Source Android Apps Threatened by Google’s New Policy”
“Google is restricting one of Android’s most important features, and users are outraged” SlashGear
“Google is restricting one of Android’s most important features, and users are outraged”
“Google says it’s making Android sideloading ‘high-friction’ to better warn users about potential risks” XDA Developers
“Google says it’s making Android sideloading ‘high-friction’ to better warn users about potential risks”
“Resistance to Google’s Android verification grows among developers” Techzine EU
“Resistance to Google’s Android verification grows among developers”
“Google will verify Android developers distributing apps outside the Play store” The Verge
“Google will verify Android developers distributing apps outside the Play store”
“I’ve been an Android user for almost 15 years — and Google’s sideloading changes are pushing me back to iPhone” Tom’s Guide
I wanted to give an update on GitHub’s availability in light of two recent incidents. Both of those incidents are not acceptable, and we are sorry for the impact they had on you. I wanted to share some details on them, as well as explain what we’ve done and what we’re doing to improve our reliability.
We started executing our plan to increase GitHub’s capacity by 10X in October 2025 with a goal of substantially improving reliability and failover. By February 2026, it was clear that we needed to design for a future that requires 30X today’s scale.
The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply. By nearly every measure, the direction is already clear: repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly.
This exponential growth does not stress one system at a time. A pull request can touch Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences.
Our priorities are clear: availability first, then capacity, then new features. We are reducing unnecessary work, improving caching, isolating critical services, removing single points of failure, and moving performance-sensitive paths into systems designed for these workloads. This is distributed systems work: reducing hidden coupling, limiting blast radius, and making GitHub degrade gracefully when one subsystem is under pressure. We’re making progress quickly, but these incidents are examples of where there’s still work to do.
What we’re doing
Short term, we had to resolve a variety of bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL), redesigning user session cache to redoing authentication and authorization flows to substantially reduce database load. We also leveraged our migration to Azure to stand up a lot more compute.
Next we focused on isolating critical services like git and GitHub Actions from other workloads and minimizing the blast radius by minimizing single points of failure. This work started with careful analysis of dependencies and different tiers of traffic to understand what needs to be pulled apart and how we can minimize impact on legitimate traffic from various attacks. Then we addressed those in order of risk. Similarly, we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go.
While we were already in progress of migrating out of our smaller custom data centers into public cloud, we started working on path to multi cloud. This longer-term measure is necessary to achieve the level of resilience, low latency, and flexibility that will be needed in the future.
The number of repositories on GitHub is growing faster than ever, but a much harder scaling challenge is the rise of large monorepos. For the last three months, we’ve been investing heavily in response to this trend both within git system and in the pull request experience.
We will have a separate blog post soon describing extensive work we’ve done and the new upcoming API design for greater efficiency and scale. As part of this work, we have invested in optimizing merge queue operations, since that is key for repos that have many thousands of pull requests a day.
Recent incidents
The two recent incidents were different in cause and impact, but both reflect why we are increasing our focus on availability, isolation, and blast-radius reduction.
April 23 merge queue incident
On April 23, pull requests experienced a regression affecting merge queue operations.
Pull requests merged through merge queue using the squash merge method produced incorrect merge commits when a merge group contained more than one pull request. In affected cases, changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.
During the impact window, 658 repositories and 2,092 pull requests were affected. We initially shared slightly higher numbers because our first assessment was intentionally conservative. The issue did not affect pull requests merged outside merge queue, nor did it affect merge queue groups using merge or rebase methods.
There was no data loss: all commits remained stored in Git. However, the state of affected default branches was incorrect, and we could not safely repair every repository automatically. More details are available in the incident root cause analysis.
This incident exposed multiple process failures, and we are changing those processes to prevent this class of issue from recurring.
On April 27, an incident affected our Elasticsearch subsystem, which powers several search-backed experiences across GitHub, including parts of pull requests, issues, and projects.
We are still completing the root cause analysis and will publish it shortly. What we know now is that the cluster became overloaded (likely due to a botnet attack) and stopped returning search results. There was no data loss, and Git operations and APIs were not impacted. However, parts of the UI that depended on search showed no results, which caused a significant disruption.
This is one of the systems we had not yet fully isolated to eliminate as a single point of failure, because other areas had been higher in our risk-prioritized reliability work. That impact is unacceptable, and we are using the same dependency and blast-radius analysis described above to reduce the likelihood and impact of this type of failure in the future.
Increasing transparency
We have also heard clear feedback that customers need greater transparency during incidents.
We recently updated the GitHub status page to include availability numbers. We have also committed to statusing incidents both large and small, so you do not have to guess whether an issue is on your side or ours.
We are continuing to improve how we categorize incidents so that the scale and scope are easier to understand. We are also working on better ways for customers to report incidents and share signals with us during disruptions.
Our commitment
GitHub’s role has always been to support developers on an open and extensible platform.
The team at GitHub is incredibly passionate about our work. We hear the pain you’re experiencing. We read every email, social post, support ticket, and we take it all to heart. We’re sorry.
We are committed to improving availability, increasing resilience, scaling for the future of software development, and communicating more transparently along the way.
Editor’s note: This post was updated on April 28, 2026, to update the number of repos affected during the April 23 incident.
Written by
Vladimir Fedorov is GitHub’s Chief Technology Officer, bringing decades of experience in engineering leadership and innovation. A passionate advocate for developer productivity, Vlad is leading GitHub’s engineering team to shape the future of developer tools and innovation with a developer-first mindset.
Before joining GitHub, Vlad co-founded UserClouds, a startup specializing in data governance and privacy. He spent 12 years at Facebook, now Meta, as Senior Vice President, leading engineering teams of over 2,000 across Privacy, Ads, and Platform. Earlier in his career, Vlad worked at Microsoft and earned both his BS and MS in Computer Science from Caltech. He currently serves on the board of Codepath.org, an organization dedicated to reprogramming higher education to create the first AI-native generation of engineers, CTOs, and founders.
Vlad lives in the Bay Area and when not working enjoys spending time outside and on the water with his family.
Explore more from GitHub
Docs
Everything you need to master GitHub, all in one place.
Go to Docs
GitHub
Build what’s next on GitHub, the place for anyone from anywhere to build anything.
Start building
Customer stories
Meet the companies and engineering teams that build with GitHub.
Learn more
The GitHub Podcast
Catch up on the GitHub podcast, a show dedicated to the topics, trends, stories and culture in and around the open source developer community on GitHub.
Listen now
On April 17, 2026, Sam Altman’s other AI company, Tools For Humanity, announced a partnership with Bruno Mars as he embarks on his Romantic Tour. The announcement coincided with the company’s Concert Kit tool, which allegedly allows “verified humans” to access VIP tickets and concert experiences.
However, Bruno Mars’ management and Live Nation released a joint statement on April 22, claiming that the partnership didn’t exist. “To be clear, we were never even approached by [Tools For Humanity], nor were we in any discussions regarding a partnership or tour access,” the statement read. “We first learned that our tour was being used to promote their project after their keynote made those initial claims.”
Those claims originated from TFH’s chief product officer, Tiago Sada, during a company event. The company then published a post on its website including Sada’s quote about Bruno Mars’ Romantic Tour. Eventually, word got back to Mars’ team.
AI Company Executive Gets His Marses Confused, Is Actually Partnering with Jared Leto’s Band
The initial post on Tools For Humanity’s website has since been edited to correct the false information. A spokesperson also confirmed the company “does not have any agreement with Bruno Mars to test or feature Concert Kit.” Additionally, “there is no association or affiliation with the artist or his tour.”
Tools For Humanity is actually partnering with Thirty Seconds to Mars on their 2027 European tour. While TFH has not disclosed the actual reason for the false Bruno Mars announcement, it looks a bit like a case of mistaken identity. Pretty ironic, since the company’s whole shtick is supposedly verifying human identities.
The company launched in 2019 initially as a way to verify human identities in online spaces to prevent fraud. This included live music monopoly Live Nation-Ticketmaster, which is often plagued by bots and scammers. In 2023, TFH launched a physical identity verification device in the form of an orb that scans human irises.
Unfortunately, the orb does not also tell fortunes, which is clearly a major design flaw. If it did, they’d probably be able to prevent this Mars mix-up before it happened.
Please enable JS and disable any ad blocker
A few years back, I had a running joke with the guy I was seeing about adding him to my period tracker. Being a women’s health expert, I enjoy weaving nerdy anecdotes about cycles and attraction and desires into my flirtations and marveling at my own wit and woo-woo mastery of my cyclical body. This ruse seemed like a harmless jab at my digitally tracked self-awareness — a very late millennial feminist living in the Bay Area version of coquetry.
It maybe wasn’t all that harmless, after all.
Turns out, the matter of sharing the data around my cycle, and potentially the even more private information about my intimate experiences, wasn’t as much of a matter of choice as I might have expected. Worse, it might have been used to sell me stretchmark creme or dental dams.
Caught bloody handed
That period tracking app, Flo, has been found liable in connection with selling user data to Meta all the while promising their users they were protecting their privacy. The class action suit had 13 million Flo users included as plaintiffs, which is a sizeable chunk of pissed off users amongst their reported 75 million-strong user base.
Those lawsuits against Meta and Flo, first filed in 2021 with more in the US and Canada, reveal a bigger issue in non-medical health tracking software — there’s too much gray area around consent when it comes to selling your health information to advertisers.
What’s important about the legal precedent being set is in highlighting how the current guidelines around health data privacy (like HIPAA) are woefully lagging behind the health tracking tech already available directly to users. It raises a number of critical questions:
What does this legal vagueness mean for how we choose to self monitor our biological markers?
What does this legal vagueness mean for how we choose to self monitor our biological markers?
In a post-Dobbs environment, how do concerns around digital privacy impact our consumer choices in sexual health and period tracking apps?
In a post-Dobbs environment, how do concerns around digital privacy impact our consumer choices in sexual health and period tracking apps?
Why is it still up to the consumer to run safety checks when it should be the role of product teams and healthtech brands to build less creepy tech?
Why is it still up to the consumer to run safety checks when it should be the role of product teams and healthtech brands to build less creepy tech?
Do we really need to be tracking every possible symptom and mood and cramp and letting private tech companies decide what to do with that data?
Do we really need to be tracking every possible symptom and mood and cramp and letting private tech companies decide what to do with that data?
Feeling “creamy” today? Great, we’ll let Mark Zuckerberg know.
Joking about the consistency of my ovulation was already a bridge too far and a line I opted not to venture to cross with said beau. I certainly wouldn’t have willingly announced to anyone parsing through data at Meta if I had masturbated or had unprotected sex on any given day. The Flo app might have made that decision for me, though.
For all my mental back and forths about whether or not to actually send a partner my cycle calendar, Flo might have been sending the intimate details of our sexual encounters to a bunch of tech bros behind my back. Turns out, Flo had embedded a secret “eavesdropping” tool which passed along information like menstruation cycle, ovulation, and if a user was trying to get pregnant to Meta, even while explicitly claiming not to in their privacy policy.
As slippery as an ovulation flow, Flo was telling us our private data was safely hidden from prying eyes. The guilty verdict in the August 2025 Frasco v. Flo lawsuit proved otherwise:
“Flo, through the Flo App, unlawfully shared users’ sensitive health data — including menstrual cycle, ovulation, and pregnancy-related information — with third parties such as Meta, Google, and Flurry for their own commercial use (Burr & Forman, 2025).”
“Flo, through the Flo App, unlawfully shared users’ sensitive health data — including menstrual cycle, ovulation, and pregnancy-related information — with third parties such as Meta, Google, and Flurry for their own commercial use (Burr & Forman, 2025).”
The jury found Meta liable for collecting sensitive reproductive health data and using it for its own gain. The other parties listed settled out of court, which means their involvement in the breach gets to stay more private than the health data of Flo users between 2016 and 2019.
Nothing feminism needs more nowadays than a bit more irony, right?
This wasn’t a hack. It was a design decision.
It’s important to call out that these third-party platforms didn’t hack into the Flo app. The folks in charge of making privacy decisions at Flo handed them our sensitive data on a silver platter. It was simple track-and-sell data sharing and we maybe should have seen it coming.
I’ve written before about how ‘pinkwashing’ femtech can disguise a whole host of unethical product decisions. Prior to heading for greener and more private pastures with my period tracking app selection, Flo was already starting to give me the ick. The UX design was getting more convoluted, more cluttered, more cartoonish with every update.
Quickly, the Flo home screen was becoming more bloated than a late-luteal phase tummy. Opening the app to log whether I had spotted a bit that morning or had insomnia or tender breasts was like navigating a minefield of tired femme designs and redundant reminders to meditate.
With each update, the home display presented me with the option for ever growing opportunities for negative symptom reporting. Without any differentiation in hierarchy, everything seemed flatly pathological. The symptoms were pushed more and more to the front and advice popped out at every turn, essentially burying the actual cycle tracker.
In the context of the Flo-Meta filings, this makes sense — focusing on the “problems” of periods can help drive sales of items purporting to alleviate symptoms. There isn’t much to monetize from a simple period calendar, is there? It’s dystopian to realize the emphasis on symptomology was helping to drive advertising on sites even more recently found liable for personal harm on par with tobacco companies.
At the end of the day, no amount of pinkwashed ‘empowerment’ or ‘evolved’ mentions of sex toys and self pleasure can cover up who benefitted* from these design choices.
The gap between HIPAA and ‘wellness’ is where consent goes to die
Flo changed its privacy policy a whopping 13 times in the three years relevant to the legal claims (2016 – 2019). These lawsuits show that all those edits did nothing to make the consent users might have thought they were giving real in any meaningful way.
Lawsuits like the Flo-Meta lawsuits are notable in that they are helping to build a foundation of legal precedent within the gray zone of non-HIPAA compliant wellness tech. Much of health tech, which includes a lot of reproductive health tech currently on the market, isn’t explicitly clinical or directly tied to communications with a healthcare provider.
Which means, you can be logging some deep information about the functions of your body and given automated advice on making adjustments to potentially improve these bodily functions, and in all likelihood, it manages to not fall under the protection of current health and privacy laws. This means that it is at the discretion of the apps themselves to create the policies around what data to share or sell or report to government agencies themselves.
They also have pretty broad discretion in the designs around consent they are willing and able to offer users. The design decisions and consent frameworks in-product can be guided by best-practices, but those choices are still largely driven by the opinions within product teams. This is how sloppy consent patterns continue to get shipped out to users, even when the product might deal in incredibly sensitive data collection.
It wasn’t like some cyber criminal was holding Flo ransom, these were embedded legal, design, engineering, and sales positions that got through a chain of employees that ultimately threw users under the bus for profit.
It’s hard to track down exact information on the number of staff employed by Flo from 2016 – 2019 and who was directly responsible for these choices. By most accounts, it was a lean operation — probably around 350 employees at any given time in those years. That’s a pretty small group of folks making potentially monumental decisions about how highly sensitive health data got collected, stored, and shared in addition to how those processes and policies were communicated to their millions of users worldwide.
If we’re left to our own devices, who will protect us?
It seems like we can’t just necessarily leave it up to companies — or their ragtag teams of crackpot lawyers rewriting privacy policies every few months — to keep our private data private. I guess we’re left needing to hurt Mark Zuckerberg’s feelings every now and again in order to just use our vibrators in peace.
The law is slow to catch up, even more so when it comes to regulating tech. This makes me nervous when considering the rush to increase the collection of data around women’s health in an effort to close the data gap. This is a worthy aim, but how much trust can we really place in private companies operating outside of clinically guided structures?
This is even before we factor in the increased use of generative AI in populating health advice within apps which seem to intentionally circumvent the healthcare space and thus not have to be compliant with the user protections under that categorical umbrella. There is such a thing as too much data, though try telling that to a PM trying to make his KPIs. If the data comes from unmanaged flows, the collection methods prioritized for third-party ad sales, and done without the direct consent of users, how much can we even rely on the derivative generative outputs? Is this the standard we want to set for collecting women’s health data? Is it worth all the costs?
Personally, this reeks of moving fast and breaking things to me. Flo definitely broke my trust, along with at least 13 million former Flo users. With (reportedly) over a third of US women utilizing period tracking apps and a similar rate of use amongst women in the EU, there’s a significant market to capture here. Unlike in 2016 when Flo was one of few players on the field, there are hundreds of cycle tracking apps for savvy users to select from today, not to mention the increasing availability of built-in cycle trackers within other health apps and wearables.
Though Flo remains one of the top downloaded of the bunch, for many of us, it’s a matter of once burned, twice shy. Personally, I’m a big fan of WildAI, which doesn’t bother to ask me if I’ve rubbed one out and therefore has no interest in telling a tech behemoth a whole lot more than if I bothered to note if I was thirsty and horny and hungry on the same day. You and Mark can guess how much space those notes take up on my cycle calendar all on your own. I prefer it that way, and Flo should too.
*Let’s just take a moment, by the way, to reflect on how the dev dudes setting up personalized ad gating at Google might have been tracking the sex toy use and prevalence of anal sex amongst Flo users so they might drive up pay per click (PPC) rates across your apps. Obviously, this is feminism at its finest.
**It might be worth arguing if in a post-Dobbs world and in countries with wishy-washy digital privacy standards that maybe meticulously logging sexy self-play might not have the potential health benefits worth the risk having it wind up in the hands of such loose-lipped data brokers. It’s bad enough we have to worry about the privacy violations of the vibrators themselves. Maybe “dumb” dildos are the better option these days, actually. We’ll have to get to that in another post.
Share The Femtech Design Desk
Leave a comment
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
If you like 10HN please leave feedback and share
Visit pancik.com for more.