This is a submission for the Gemma 4 Challenge: Build with Gemma 4
Most “read later” links quietly die in browser tabs. At some point I realized I wasn’t actually trying to consume more content anymore. I was trying to reduce the cost of deciding what deserved my attention in the first place.
That realization eventually turned into TLDR Radio — a Telegram bot that converts long-form articles and discussion threads into short audio briefings you can consume while walking, commuting, cooking, or doing literally anything except staring at another glowing rectangle.
But while building it, I accidentally discovered something much more interesting than “AI summaries”. I swapped the underlying model, and almost nothing important broke. That realization stayed in my head much longer than any benchmark chart.
What I Built
TLDR Radio is an audio-first article triage system. You send a link. The bot:
- fetches the article
- extracts readable content
- optionally pulls discussion context
- generates a structured summary
- converts it into audio
- sends the result back through Telegram
The original problem was surprisingly simple. My browser had basically become a graveyard of tabs I was never going to read anyway. And the real issue wasn’t lack of time. It was decision fatigue. Choosing what deserved attention started feeling more exhausting than the actual reading itself. So I stopped treating summarization as “compression”. I started treating it as attention routing.
The core UX decision was intentional from the beginning: I did not want another AI chat interface. I wanted passive consumption.
The product only started feeling genuinely useful once I could:
- listen while walking
- listen while driving
- listen while cooking
- listen while cleaning
- stay away from the screen entirely
That constraint ended up influencing almost every architectural decision. The system itself looks less like a chatbot and more like a media-processing pipeline.
High-level flow:
Demo
Landing: https://tldr-radio.humifylab.com
Telegram Bot: https://t.me/TldrRadioBot
How to use: send one or two links and get a short audio summary.
[UX demo: from link to detailed audio summary]
[Conversation in Telegram, audio list and lock screen]
Each audio summary has a message with a caption, tags, a few first sentences of the summary, and sources. You can see the difference between Gemma and ChatGPT by comparing those messages yourself. For the rest of the article, Gemma is on the left.
[Gemma on the left and ChatGPT on the right]
One thing I really like is pulling in discussion context from places like Hacker News and Reddit. An article is just one perspective. The comment threads usually surface the real signal way faster than the article itself. There's also an option to go deeper and get a more detailed summary, which works really well for long HN threads.
[Gemma on the left and ChatGPT on the right]
Code
One thing I wanted very deliberately was separating:
- webhook latency
- durable job execution
- asynchronous processing
- execution snapshots
The architecture is heavily queue-oriented. The webhook itself stays lightweight and returns quickly. Long-running work happens asynchronously in workers.
[Architecture diagram]
The stack currently includes:
- ASP.NET Core Minimal API
- PostgreSQL
- OpenTelemetry
- LLMs providers
- Telegram Bot API
- TTS providers
- Fly.io deployment
The LLM is only one component inside the pipeline, not the entire product.
One small feature to mention is procedural-generated images as covers. For each summary mp3 ID3 tags are written, including "Album" cover. How do you like these?
[Procedural-generated images as covers]
The actual TLDR Radio repository is currently private. But during development I extracted part of the infrastructure into an open-source production-oriented Telegram bot starter for .NET:
https://github.com/lemesevkirill/telegram-bot-starter-dotnet
It contains the asynchronous webhook/worker architecture that heavily influenced TLDR Radio itself.
How I Used Gemma 4
Originally, TLDR Radio used ChatGPT-based summarization. That felt like the obvious choice. Then the Gemma 4 challenge appeared and I started wondering: What actually happens if I swap the model without changing anything else?
For the core reasoning engine of TLDR Radio, I selected the Gemma 4 31B Instruct model, deploying it via OpenRouter's free tier. Within the Gemma 4 ecosystem, developers often choose between the high-throughput Mixture-of-Experts (MoE) models (like the 26B variant) and dense architectures. I intentionally chose the 31B Dense model for a specific architectural reason: script-writing and role-preservation.
While MoE models are incredibly cost-efficient because they activate fewer parameters per token, dense models utilize their entire parameter weight (all 30.7B parameters) for every single token generated. For an audio-first product like TLDR Radio, this full-scale dense processing is critical. It delivers more cohesive narrative structures, better flow, and firmly holds the "radio host personality" across complex, multi-layered summaries without breaking character.
Using OpenRouter allowed me to plug this 31B dense powerhouse into my .NET pipeline instantly, gaining a massive 256K context window and native multilingual support without managing complex local infrastructure.
Honestly, I expected the quality to collapse. That’s not what happened. This became the most interesting part of the entire experiment.
[Gemma on the left and ChatGPT on the right]
I intentionally kept:
- the same prompts
- the same orchestration
- the same summary structure
- the same Telegram UX
- the same audio generation flow
The only thing that changed was the model. And the result did not feel like smart AI vs dumb AI or high-quality vs low-quality. It felt more like swapping podcast hosts.
[Gemma on the left and ChatGPT on the right]
ChatGPT often sounded patient and explanatory. Gemma frequently sounded denser and more compressed, almost like:
“here’s the essence, let’s move”
The factual quality was often surprisingly close for this workflow.
What changed more noticeably was:
- pacing
- sentence density
- narration rhythm
- listening feel
- emotional texture
That was the moment where the whole thing stopped feeling like “model evaluation”. It started feeling more like media production for the same show with different hosts. And that realization stayed in my head much longer than expected. Because I originally assumed TLDR Radio was basically a model experiment. Smarter model equals better product. Simple. Then I started swapping models and something uncomfortable happened: The model quietly stopped feeling like the whole product.
[Gemma on the left and ChatGPT on the right]
Real-World Observations
One thing that became obvious very quickly: Operational reliability matters enormously in audio products.
The free Gemma endpoints through OpenRouter were heavily throttled during peak usage. The paid endpoint was dramatically more stable. Which mirrors a broader AI product lesson: Raw intelligence matters less if the operational experience becomes unreliable.
As long as the endpoint is stable, Gemma is totally fine on the pipeline side. You can do everything with Gemma that you do with ChatGPT - latency, limits, context, all the technical details work.
Another interesting observation: I expected prompt portability to be much worse. Instead, both models handled the orchestration surprisingly well. That made the models feel far more interchangeable than I originally expected. Multilingual behavior also changed the feel of the product in interesting ways. Not just translation quality. Personality. Different combinations of model / language / TTS provider started producing noticeably different listening experiences.
Again: less like swapping engines, more like swapping hosts.
Final Thought
Building TLDR Radio changed how I think about AI products. I expected swapping models to feel like replacing the engine. Instead, it felt more like replacing the host of the same radio show.
Gemma didn’t replace GPT in this project. It changed the pacing, tone, and listening feel of the experience. And that turned out to be much more interesting than a benchmark comparison.
The biggest surprise wasn’t realizing that open models got good. It was realizing how quickly the model itself stopped feeling like the whole product.
While building TLDR Radio, I ended up thinking about something larger: What happens when intelligence itself becomes infrastructure? I wrote a more philosophical version of that realization here:
https://futurehangover.substack.com/p/nobody-cares-about-your-frontier
And if you want to try the bot itself: