As we’ve seen many times before, there’s usually some way wrangle a bit more life out of what would otherwise be considered old and obsolete technology. Perhaps one thing that has been passed over by the masses a bit to early is older datacenter GPUs, which is understandable in one sense because of the rate NVIDIA is pumping out new ones, but these cards have plenty of useful life left in them for the average person, as [Andrew] demonstrates.

The cards [Andrew] is using are Tesla V100s of 2017 vintage. Despite being older hardware they have high-speed memory which allows them to run modern LLMs locally, competitively with online models. In this test, Gemma 4 26B and Qwen3 35B are run, with Gemma being a bit faster because it fits entirely in GPU memory and Qwen3 being a bit more capable but more hungry for resources. [Andrew] built a PCI card that can host two V100s, allowing these larger models to fit completely in memory.

Even though these don’t perform at the same level as the latest top-tier online models, they’re surprisingly capable and also have the benefit of running completely locally. This might be concerning for those looking at the global economy being propped up by companies that essentially have no moat for motivated users, especially as more and more datacenter hardware becomes available on the secondhand market. While this build by [Andrew] goes into detail on getting the software stack up and running, we recently featured another build using the same GPUs that focuses a bit more on hardware for those looking to get started with local hosting.

A lot has been made about the increase of automated traffic on the Internet, with the past years LLM-related crawlers having quite literally swarmed the picture here. Not only does this drive up traffic, it also increases load on web servers, whose owners find themselves faced with increased hosting costs. This recently led to The-Numbers.com going offline for a while as automated traffic was quite literally destroying their bottom line.

This saga is covered by [Stephen Follows], who had a chance to talk with the founder and CEO of the site, [Bruce Nash], after the site went basically offline for a few months. Since the website both licenses data for commercial purposes as well as offering the free access on its website, there were accusations of this being a ‘rug pull’.

The site was started in 1997, as a static HTML site on Geocities where [Bruce] provided box office analyses for investment purposes. Since that beginning traffic was generally polite, with human visitors and usually well-behaved search engine crawlers. Then around 2024 the first wave of scraper bots arrived, followed by a larger wave around December of 2025.

Despite implementing a few mitigations, such as LLM-targeted text, the increased traffic and the resulting load on a site architecture that was never designed for this ultimately led to a collapse. One of the major sources of traffic turned out to be from so-called ‘prediction markets’, like Polymarket, whose bots absolutely hammered the site.

Fortunately for [Bruce] and his team they do not rely on the free website for income, but they have had to massively rework the site’s architecture to bring back a semblance of the original features. As noted in the article, the amount of crawling traffic by these LLMs and ‘agentic AI’ tools is exponentially more than that for search engines, which makes this a major challenge.

Issues like these is why services such as Cloudflare are offering blocking features for such automated traffic. After all, unless such traffic is of use to you, you may as well treat it like a DDoS attack and cut it off at the root.

Thanks to [Ben] for the tip.

Community-led open source project hosting site Codeberg has formally announced that projects whose code is largely or fully machine-generated through LLMs and other ‘AI’ tools will no longer be welcome. This follows on the heels of a similar ban on cryptocurrency-related projects.

The community vote was on two issues, the first being the notion that scraping of project code for the use in LLMs should be forbidden, which was a motion that easily passed. The second motion was on disallowing projects whose code was substantially generated by LLMs like Claude, OpenAI Codex, and similar. This motion passed with 358 in favor versus 144 against.

In the earlier linked blog post the reasoning behind especially this second issue is expanded upon, covering not only ‘license whitewashing’, but also the direct and indirect hardware costs, with the expanding ‘AI’ datacenter hyperscaling having massively increased hardware costs for Codeberg over the past years, as the costs have been largely externalized.

Also covered is the aspect of these LLM-based tools destroying the OSS community, which is something that is backed up by recent studies. Even if we ignore that such LLM-tools are destroying the cognitive abilities of its users, there’s an argument to be made that if LLM-scraping is disallowed, then it’s consistent to also not allow LLM-generated code.

In the Terms of Use you can see these changes, both for LLMs and for cryptocurrency projects.

Thanks to [mk-fg] for the tip.

Voice-controlled appliances are nothing new. What might be new, however, is [Moonshine AI] running it all locally on a Raspberry Pi Pico 2 W!

The voice interface is roughly divided into three parts: voice activity detection, SpellingCNN speech-to-text and a neural text to speech. The speech to text supports up to 50 tokens, and can be re-trained to support any specific words you want. It runs a simple loop: detect voice activity, listen for (command) tokens, process them in C++, use the TTS to reply, and repeat.

Now, to be fair, it is a bit of a squeeze: 3.6 MiB of the available 4 MiB FLASH and 468 KiB SRAM on a stock Pi Pico 2 board. It leaves you with just about enough space to write a small amount of extra software, but it’ll be a challenge to fit anything substantial. Still, fitting three different types of AI model needed to make this possible in such a space is quite impressive.

One of the biggest “David versus Goliath” stories in tech right now is the towns beset by AI data center projects they may or may not have asked for. Powered By Who is tracking data center development in the US on this convenient map.

Currently, there are over 2,100 data centers being tracked by the project ranging from proposals to sites fully up-and-running. While you have to build bypasses data centers to keep the internet running (which we’re partial to here at Hackaday), there are certainly questions around the amount of power and water consumed by these sites, the emissions they’re sending into the surrounding community, and who exactly is reaping the benefits.

Whether you’re pro, against, or ambivalent about the proliferation of “AI” data centers, the map offers an engaging way to look at what projects are happening around the nation, especially when you start looking at clusters and how that interacts with the power generation and political makeup in a region. It’s particularly interesting how only three states account for roughly 70% of all the projects. Let us know if there’s a similar tracker in your area if you’re from one of the other parts of the globe!

Looking past the debate, there’s a lot of interesting engineering involved in keeping these data centers cool, although there are questions about where that heat ends up going. DC distribution inside the site, underwater data centers, and even putting them in space are some of the solutions for keeping the cooling loads tamed.

In an ideal world, the role of technology would be to make all of our lives easier. And although all the ads suddenly appearing in our smart TVs and gaming systems might make it seem otherwise, some technology can still improve our lives if we work hard at it. For [Cian], that meant training a neural network to read his gas meter so he wouldn’t have to do it himself.

The root issue here is twofold, first that [Cian]’s gas company hasn’t upgraded their own technology to modern, remote-readable meters, and second that the meter can’t be read by a gas employee because it’s hidden in the depths of [Cian]’s basement. This latter fact requires him to delve into Moria-like depths to get to the meter, so the solution here was to place a Raspberry Pi in this location instead. With a camera pointed at the meter, it’s not quite capable of discerning digits on its own so a neural network was trained in order to get accurate readings of the dial. And, finally, since the machine is networked already [Cian] set it up to automatically notify the gas company of its reading so he is now completely out of the loop.

For automating tedious tasks like these, the Raspberry Pi with something like OpenCV as a computer vision tool is a fairly mature platform for light machine learning duties like these. We’ve seen license plate readers as well as neighborhood traffic surveys built on these platforms to help automate human labor away, making our lives easier one single-board computer at a time.

AI chatbots are everywhere these days, and they seem to “know” about everything. But while that is a strength, it can sometimes be a weakness because it isn’t laser-focused on one topic. Not so with this Ham-radio-centric chatbot called HamGPT. The service is clearly built on another GPT engine but understands how to retrieve data from common ham radio sources, such as the FCC database, propagation reports, and the like. It didn’t, however, seem to have access to ham radio-related books, magazine articles, or other “static” data that we could tell.

You do have to sign up for an account, which includes providing your callsign and location. There is a free tier that allows a limited number of queries per day, so you can try it to see if it is useful for you without subscribing.

Here’s a typical session:

                What band will have the best propagation to Japan from my QTH right now?

The best band for Japan from your QTH right now is 30 meters, which shows good propagation reliability. 20 meters is also active and providing a viable path.

Real-time data confirms activity on both bands, primarily using FT8. While the path is open, the signals are relatively weak (typical for this long-haul path), making digital modes like FT8 or CW your best bet for a successful contact.

Would you like me to check if your current antenna setup is suitable for these bands, or perhaps help you calculate dimensions for a 30m or 20m antenna?

In addition, bubbles at the bottom of the screen showed me the busiest band in my area and how many repeaters were nearby.

In all fairness, we asked ChatGPT the same question, but did say “ham radio band” just to give it some idea of scope. It gave a much more detailed answer with sources, even provided headings, and made a suggestion about another location I sometimes operate from because it remembers things from previous unrelated chats.

We understand reactions will be mixed. If you’ve been a ham for a long time, you probably could have guessed that a path from the US to Japan in the morning was likely to be on 20 or 30 meters. You probably also know how to look things up yourself.

We didn’t try any more sophisticated queries that might make it more worthwhile. For example, what if you could send it an ADIF log file and ask it what awards you qualified for? Or to process contest logs for duplicates and fill out a scoring worksheet? What would you like a ham radio-aware AI to do for you?

Ham radio — at least parts of it — has become inextricably linked with computers.

This following statement is a lie: “I am telling the truth”. Okay, now that it’s just us meatbags, let’s get down to brass tacks. Captain Kirk’s logic bombs couldn’t possibly work on modern LLMs, right? Surely that was just a bit of 1960s silliness from when computers filled rooms and were esoteric magic even to most sci-fi writers?

Well, not entirely, according to a recent article in IEEE Spectrum. While you might not be able to make a data center explode, you certainly can use  a lot of tokens by making an LLM overthink with your prompt.

It comes down to the much-vaunted ‘reasoning’ ability of the new models — which isn’t really reasoning the way we think of it, but does involve breaking the stated prompt down into smaller problems. That’s part of what lets the new models tackle such involved tasks as porting MicroPython to the SNES with a prompt like “Please make this [stuff] work now!” It’s also a weakness, because with the right prompt you can get that virtual ‘reasoning’ to tie itself in knots with mutually incompatible smaller steps.

The models seem to be able to break out of it, but they burn a lot of tokens along the way, which is an attack in and of itself if you’re found a way to inject prompts into someone else’s API. It’s a little more subtle than what Kirk got up to, but underneath it’s essentially the same thing. At scale, it could serve as a DDoS attack on LLM servers. (Un)Fortunately, modern computers are better designed than their imaginary 23rd-Century counterparts, and there’s no way to craft a logic bomb into something that will let out the magic smoke.

[Irving John Good] was at Trinity College, Oxford back in 1964. His paper, “Speculations Concerning the First Ultraintelligent Machine” could have been a topic for today, as we deal with machines that aren’t really ultraintelligent, but appear smart and think they are even smarter. He starts off with a bold thesis: “The survival of man depends on the early construction of an ultraintelligent machine.”

He also admits that we’ll need to understand more about the human brain and human thought to make a breakthrough. This is still true today. However, we still don’t fully understand how our brains work, but it seems unlikely that we are just super-large LLMs. Not that [Good] anticipated the modern chatbot. Perhaps his comments will apply more to a future AI software that actually thinks like a human, if there will ever be such a thing.

Then again, there are many parallels. One theme in the paper is that a smart machine will design a smarter machine. Unless, of course, it is afraid of being replaced. If a machine were actually sentient, what are the ethics of turning it off and tearing it apart?

It is hard to be a visionary. [Good] remarks that by 1980, progress in human/computer symbiosis will encourage more investment in the field and that by that time, there would be “great advances in microminiaturization” and “frequencies of one billion pulses per second,” might be common in “large computers.”

We love reading what smart people thought the future might be like. What will the world be like in another 60 or 100 years?

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.

Giving machines the ability to communicate nonverbally has real value, and [Drew Smith] clearly thinks your robot deserves better than an emoji. He shared a very interesting approach with his project Kindalive.

Kindalive is a simulated dot-matrix robot face that responds believably to input text, modeling and expressing both short-term and long-term moods. It’s pure Python and modular enough to invite using it elsewhere, but that’s not the really interesting part.

What sets [Drew]’s project apart is the way he models eight key neurochemicals (including dopamine and cortisol) as the foundation from which to derive emotional states. That’s an approach we certainly haven’t seen before.

Conventional sentiment analysis uses a large language model (LLM) to apply discrete labels to communication, but Kindalive doesn’t do that. It even goes so far as to model the decay and interplay between its simulated neurochemicals to derive emotional states on the fly. It’s more fluid and organic, and reflects both short-term and long-term mood changes.

Physical representation of the emotional mix is done by altering twelve key facial movements (brow raise, lip corner pull, mouth open, and others of that nature) known as the Facial Action Coding System (FACS). These twelve elements combine to express emotion nonverbally with facial expressions. It’s what drives the simulated dot-matrix robot face seen in the image above, and could easily be used to drive a real LED matrix, or servos on an animatronic face.

Much of communication is nonverbal. Humans even weigh nonverbal higher when there’s a mismatch between the content of verbal and nonverbal communication. So, there’s clear value in having robots able to express themselves as such.

Importantly, a realistic and human-like face is entirely unnecessary — something every Star Wars fan already knows. Cartoon eyes and basic sounds are enough to make robots easier to relate to and work with, even if blinking is also important but hard to get just right.

[Simon Willison] ported the Moebuis 0.2B image inpainting model to run locally in a web browser.  The web tool simply requires a user to provide an image, mark a section of it to be removed, and the model will do it’s best to patch up the missing area. The project was handled by Claude Code as an experiment in how things in the AI coding world have evolved, but more on that in a moment.

The existence of this tool shows that it’s possible for this kind of image editing to be done on the client side, running entirely locally with no reliance on remote services or server-side GPU resources. The online demo (GitHub repository here) is available if you want to try it out, but be warned it triggers a 1.27 gigabyte download of the required model on the first run.

What’s also interesting is [Simon]’s write-up, because he used the project as an opportunity to learn what has changed in the realm of AI coding agents. [Simon] is a software developer but in this project he didn’t personally write any of the code. One may think that means he didn’t learn anything other than how to use the tools, but that’s not quite true.

He learned it’s possible to convert a PyTorch-based model to ONXX, that the converted model can run in supported browsers using local WebGPU acceleration, and that the CacheStorage API will work on large files. Last but not least, he learned Claude Opus 4.8 is capable of handling such a project pretty much autonomously, and even created an informative document explaining the underlying architecture.

One may consider AI coding agents to be disasters waiting to happen, but it’s also true that the landscape is changing quickly, and write-ups like [Simon]’s give a helpful peek at those developments.

Oh, the farming lifestyle…living off the land, fending for yourself. But who’s got time for all that? For the modern hacker, the best option in the garden space may be this over-engineered automated AI tomato farm created by [Gerd Nicolay]. You can even interact with it right now through the magic of the Internet.

[Gerd] started off with your run-of-the-mill pot and plant, choosing the humble tomato to keep the system simple. Then things started to escalate, with the addition of automatic lighting, watering, and data logging environmental parameters like humidity. Now we’re getting somewhere, but there’s more that can be added. How about an entire AI council to monitor and decide the fate of each individual tomato while recording an entire storyline to go alongside the growing cycle?

That’s right, four different models collaborate to ensure only the utmost quality of care for these tomatoes based on camera feeds, humidity, and various other environmental factors being recorded constantly. Is this a little overkill? Maybe for those who have even a modest sense of gardening knowledge — but who can bash the mountain of documentation and data collection on these wonderful little plants?

Perhaps the best part: you can recommend actions for the AI counsel to take from the comfort of your own web browser. While the TomatoFarm might be slightly unnecessary for the average farmer, if you want to try a more reasonable monitoring system, we have you covered too!