John Carlsen, writing for CNET after testing Petlibro’s newest smart feeder with his own cat, described the standout feature plainly: the version he tested adds an AI-powered camera that can recognize which pet is eating and automatically associate the meal with the correct profile. He called it especially useful for households with more than one animal.
My first reaction was not about cats at all. It was that someone finally shipped an identity resolution service disguised as a food bowl.
I build bots for a living. Most of what I write is plumbing between a sensor, a decision, and a log entry. So when a consumer device quietly solves the hardest part of that chain, camera-based identity matching at the edge, in a form factor that sits on a kitchen floor and costs less than a mid-tier GPU, I want to understand the architecture.
The problem that made this hard
Automated feeding is trivial if you have one pet. A timer, a servo, a hopper. You can build it in a weekend with a microcontroller and a 3D printed auger. I know because plenty of people have, and their build logs are all over the internet.
Multi-pet homes break that design completely. Two cats with different dietary needs are not two schedules, they are two authorization policies sharing one physical endpoint. Cat A gets the prescription formula. Cat B gets the regular stuff and would very much like to eat Cat A’s portion. Your timer has no idea who showed up.
The traditional fix was RFID collars, essentially a hardware token. It works, but it fails the way all token-based auth fails: the token falls off, the cat refuses to wear it, or the wrong animal wanders close enough to trigger a read. Petlibro’s approach swaps the token for a biometric. The camera identifies the animal, and the meal gets written to that animal’s profile.
That is a meaningful shift in design thinking. You stop asking “what time is it” and start asking “who is here, and what are they allowed to have.”
What a builder should notice
Three things stand out to me in how this system is structured.
- Identity is inferred, not asserted. The pet does not present credentials. The system observes and classifies. That means the whole design has to tolerate uncertainty, which is a very different engineering posture from an RFID read that either succeeds or does not.
- The dispensing logic is decoupled from the schedule. Dual feeding modes mean the hardware supports more than one policy at once. That is a state machine, not a cron job.
- The device monitors itself. The feeder sends alerts for maintenance issues. Boring feature, enormous value. Most hobby automation projects fail silently, and silent failure in a feeding system is the worst kind.
That last point deserves more credit than it usually gets. I have shipped bots that broke at 3 a.m. and told nobody. A dispenser that jams and does not report it is not a neutral outcome, it is an animal that did not eat. Building self-reporting into the device acknowledges that the physical world does not care about your happy path.
The data layer is the real product
One recurring theme in coverage of this category is that the feeder is becoming a data collection point rather than a dispenser. The argument goes that the meal history a device accumulates ends up being the most useful thing you bring to a vet appointment.
I find that framing convincing, and it is the same arc I have watched in every other automation domain. You build the bot to do a task. Then you realize the log is worth more than the task. Appetite change over weeks is a signal no human notices reliably, because humans do not keep per-animal meal ledgers. A system that attributes every meal to a specific individual does, by default, as a side effect of doing its job.
The competitive picture is instructive too. Reviews comparing Petlibro to PETKIT point out that PETKIT’s dual-hopper build, two separate food compartments in one unit, allows two different foods to be dispensed from the same device, which Petlibro’s current lineup does not offer. So the two companies are answering the same question from opposite directions. One improves the recognition of who is eating. The other improves the physical ability to serve different food. Identity layer versus hardware layer.
What I would steal for my own projects
If you are building anything that serves multiple users through one physical interface, the pattern here is worth copying: identify first, apply policy second, log the attributed event third, and monitor your own health continuously. That sequence applies to a shared 3D printer queue, a family media server, or a workshop tool checkout system just as cleanly as it applies to cat food.
The cats, of course, have no idea they are participating in a per-user access control system. They just know the bowl works. Which is honestly the highest praise you can give any bot.
🕒 Published: