A veteran technology journalist tired of reading the same story across five different news apps decided to build his own solution: a self-hosted news aggregator that clusters duplicate coverage and summarizes articles using a local language model running on his home server. The experiment revealed both the promise and the practical challenges of running AI inference on consumer hardware, and how open-source tools like Ollama are enabling developers to reclaim control over their digital workflows.

Why Did One Journalist Abandon Traditional News Apps?

The problem started simple but became increasingly frustrating. Every morning, the same story appeared across multiple outlets with different headlines. A Samsung Galaxy Watch announcement, for example, appeared as "New leak reportedly reveals nearly full spec sheet for Samsung Galaxy Watch Ultra 2" on one site and "Samsung teases the next Galaxy Watch and its AI-powered 'Health Companion'" on another. The articles were identical in substance, but the different framing made them look like separate stories, forcing the journalist to read through multiple versions of the same news.

This wasn't a problem with the journalism itself. The issue was structural: news aggregators and social media feeds surface individual articles without truly merging duplicate reporting. Cloud-based AI summarization services existed, but they required paid subscriptions with minimal free tiers. So the journalist began searching for an open-source, self-hosted alternative he could control and manage himself.

What Tools Did He Use to Build His Solution?

The solution came in the form of MuckScraper, an open-source news aggregator designed specifically for self-hosting. The application's technology stack included several familiar components: Python for the backend, PostgreSQL for the database, Ollama for local language model inference, Meilisearch for search and sorting, and Docker for deployment.

The critical component was Ollama, which enabled the journalist to run a small language model entirely on his home server without relying on cloud APIs. He chose the Qwen 2.5 model at 1.5 billion parameters, a size small enough to run on CPU-only inference on his repurposed Dell Latitude 7480 laptop server. This decision came with trade-offs: the model consumed 4.4 gigabytes of RAM and required careful tuning to prevent the entire server from becoming unresponsive.

How to Configure a Self-Hosted News Aggregator for Your Interests

• Customize Feed Sources: Replace default RSS feeds and news APIs with sources aligned to your interests. The journalist swapped out US politics feeds for self-hosting, homelab, local AI, consumer tech, and operating systems content from XDA, Hacker News, subreddits, and GitHub blogs.
• Tune Memory and Performance Settings: Adjust the language model's context length and keep-alive duration to prevent resource exhaustion. The journalist reduced Ollama's memory footprint from 4.4GB to a manageable level by modifying these parameters.
• Debug API and Feed Blocklists: Identify and fix configuration issues with news APIs and feed sources. The journalist discovered that GNews rejected hyphenated search terms and that Reddit and GitHub were in the default blocklist, requiring manual intervention to enable.
• Allow Time for Dashboard Population: Run the aggregator for at least 24 hours before evaluating results, giving the system time to fetch, cluster, and summarize articles from your chosen sources.

The initial setup took far longer than expected. What the journalist assumed would be a five-minute deployment turned into two to three days of configuration, debugging, and customization. Out of the box, MuckScraper assumed a US-centric audience interested in Congress and the White House. The backend contained errors, several feeds weren't behaving correctly, and the default blocklists prevented some sources from working.

What Were the Real-World Performance Challenges?

Running a 1.5 billion parameter language model on a Dell Latitude 7480 with a Core i5-6300U processor and 11.6 gigabytes of RAM created immediate resource constraints. When the journalist first deployed MuckScraper and left it running for a few hours, the server's memory usage climbed to 100 percent, with swap space completely exhausted. Ollama alone was consuming 4.4 gigabytes, leaving almost no headroom for other services running on the same machine.

The fix required reducing the language model's context length, which controls how much text the model can consider at once, and lowering the keep-alive duration, which determines how long the model stays loaded in memory before being unloaded. These adjustments brought resource usage under control, but they also reduced the model's ability to process longer articles or maintain context across multiple summaries.

This experience highlights a fundamental trade-off in self-hosted AI: the hardware constraints of consumer machines mean that running state-of-the-art models locally requires either accepting reduced performance or investing in more powerful hardware. The journalist's solution worked, but only after accepting these limitations.

What Does This Mean for the Future of Local AI?

The journalist's experiment demonstrates that Ollama and similar tools are making it feasible for individual developers to deploy language models on consumer hardware for practical applications. However, the experience also reveals that self-hosting AI is not yet a plug-and-play experience. Configuration, debugging, and hardware tuning remain necessary skills.

The broader implication is that as language models become smaller and more efficient, the barrier to self-hosting will continue to lower. The 1.5 billion parameter model that required careful tuning on a 2016-era laptop represents a middle ground: too large for trivial deployment, but small enough to be feasible on consumer hardware. Future models optimized for efficiency could shift this balance further toward accessibility.

For developers and journalists tired of relying on cloud-based AI services, the path forward involves learning to manage the trade-offs between model capability, hardware constraints, and operational complexity. The tools exist; the challenge now is making them easier to use for non-specialists.