Sometimes you just have to let the agent cook.
Mika vs. a multi-billion-dollar corporation, and a stupid little desktop pet.
When Ope...
For further actions, you may consider blocking this person and/or reporting abuse
I really love this idea, wondering if I'm able to create a macOS version
I would genuinely love you forever for helping port it to macOS 😂💜 I don’t have a proper macOS test environment right now, so having someone who can actually build and test it there would be amazing. Please feel free to open an issue or PR, and ping me if anything in the codebase is confusing!
Really nice idea, though I noticed a few issues... I'm getting to work🤗
Ooooh 👀 I’d love that! Feel free to open an issue for anything you find, and PRs are absolutely welcome. If you run into anything confusing in the codebase, just ping me <3
I absolutely love this. I haven’t gotten around to trying Mochi yet, but I am definitely going to very soon.
Desktop creatures are exactly the kind of slightly unnecessary but ridiculously fun software I love, and I really like that you took the idea so much further than just “cute thing that tells me what Codex is doing.” The persistent state, ambient awareness, bond system, focus sessions, all of it makes Mochi feel like an actual little desktop companion instead of basically a status indicator with a sprite attached.
Also, I really appreciate the whole “commit to the bit” philosophy here 😂. Sometimes the best projects come from taking a seemingly silly idea way more seriously than anyone reasonably needed to.
The pets that survive week two are the ones wired to real state — exit codes, failing tests, silence — not cosmetic timers. Does yours read what the agent actually did, or only what it says? That difference is the whole toy-versus-instrument line.
This is a really interesting way to approach desktop companions.
The part that stood out to me was the separation between:
That distinction becomes important once you have interruptions, persistence, and multiple sources changing the state. A single authoritative state machine seems like the right direction for keeping the behavior consistent.
I also like that the focus is not only on making the pet look alive. The lifecycle and ownership model underneath is what makes the behavior reliable.
Really nice work, especially for a solo project. I’ll definitely be looking through the code.
How did you arrive at the single authoritative state machine design? Was that planned from the beginning, or did it evolve after running into lifecycle and ownership bugs?
I think there is an important distinction here: a feature and a product don't have to solve the same problem at the same depth.
Something that is a small feature inside a larger product can be intentionally simple. But when someone turns that idea into the product itself, the architecture, state management and user experience naturally become much deeper.
So “better” isn't always about implementing more. Sometimes it's about having a different scope and being able to optimize the entire system around one specific purpose.
The interesting part for me isn't actually the pet animation. It's the state management behind it. Users see a character reacting on screen, but the real engineering problem is deciding what state the system is in, what can trigger a transition, and what should happen when events interrupt each other. The visual layer gets attention. The state machine is where the product logic actually lives.
The line that hit me: "Mochi is the thing itself, built by one person who wanted the version that actually commits to the bit."
I'm a beginner — two weeks into Python, writing tutorials about it on Dev.to. I don't have a state machine or an AmbiSense layer or a GNOME Shell helper. My project is 14 articles and a pitch tracker.
But I recognized the energy immediately. You looked at something that already existed, said "this is fine but it's not what I actually want," and built the version you wanted to exist. Not because it was a market opportunity. Because you wanted it.
The detail that stood out: "Most of Mochi's codebase manual is about lifecycle and ownership — making sure a stale animation callback can't fire after a feature's been interrupted." That's not a mascot problem. That's a systems problem. And you got there because you refused to stop at "cute status light."
I don't know if I'll ever build something with this level of architecture. But I do know the instinct — refusing to stop at the shallow version — is the thing I'm trying to build in my own work. Whether it's a tutorial that explains the why instead of just the how, or a pitch that shows the finished article instead of just promising it.
"Commit to the bit" is going on my wall.
Cool project. Mochi looks great.
The "status light with a tail" line is dead-on — I ran into the same wall building a terminal notifier last year, realized a green checkmark tells you nothing about what broke or why. The state machine approach is the right call; once you have real memory and transitions, the pet stops being decoration and starts being a debugging surface. Curious how you handle state persistence across crashes, since that's where my version fell apart.