Rubato_Device Turns AI Waits Into Breaks

Rubato_Device is lovaxi’s open-source ESP8266 desk companion: a palm-sized retro-Mac screen that mirrors AI coding state and nudges you to take breaks. AI agents make developers wait, and those waits often turn into more sitting, staring, and context-drifting. Make agent state visible, but keep the signal narrow enough that it helps your body without becoming another dashboard.

Rubato is an AI coding state display for your desk, built around a 240×240 color screen, Wi-Fi, and a small plugin that publishes session state over MQTT. For Cursor the interesting part is not the retro shell; it is how the project turns Cursor rules, agent waits, and reviewable IDE workflows into something you can feel before you lose the afternoon.

Watch the wait, not the whole developer

Rubato’s core loop is tiny. A local plugin observes an AI coding session and publishes states like thinking, generating, and done over MQTT with TLS. The device shows those states as a breathing orb: cream while thinking, blue while generating, green when finished.

That restraint matters. The device is not trying to become a second IDE, a task tracker, or a productivity scoreboard. It watches the boring part of agentic coding: the gap between “I asked for work” and “I should review the result.”

The health layer sits on top of that wait. When a task looks long, the screen can switch into a full-screen micro-break reminder: water, bathroom break, eye rest, neck stretch, kegels, or standing desk. The README frames the project as “when AI thinks, you move,” which is exactly the right level of ambition.

Watch for over-instrumenting the human. A desk device that tracks every keystroke, app switch, or pause becomes creepy fast. Rubato is easier to like because the signal is coarse and tied to agent state, not personal surveillance.

Treat the plugin as the real boundary

The hardware is charming, but the plugin boundary is the serious engineering detail. Rubato’s firmware, hardware design, tools, and docs are open source, and the project uses a PC-side plugin to bridge AI clients to the device. As of September 2026, the repository is mainly C, GPL-3.0 licensed, and built around ESP8266 hardware.

That architecture is a good pattern for AI coding tools. Keep the desk device dumb. Keep credentials, tool-specific logic, and network publishing in a small local process you can inspect and remove.

A safe version of this pattern for a Cursor user looks like this:

• Cursor Agent runs in the editor.
• A local plugin sees only coarse session state.
• The plugin publishes thinking, generating, or done to MQTT.
• The device renders color and break prompts.
• Code, prompts, diffs, secrets, and filenames stay out of the hardware path unless you deliberately add them.

Don't treat “it only lights up” as a security model. If the bridge process can read editor state or repo files, it deserves the same review you would give a hook, MCP server, or custom agent integration. The smallness of the screen does not make the software boundary small.

For the sharper repo-safety version of this concern, see Git Hijack Lets Repos Run Code in Agents. It is the same lesson from the other side: agent-adjacent code should be boring, scoped, and reviewable.

Keep Cursor context boring and local

Rubato is not a Cursor feature, but it sits near the work Cursor users already do with rules, custom agents, skills, and review flows. Cursor subagents and skills are useful when they make the agent’s job narrower; a desk device is useful when it makes the developer’s next action clearer.

A Cursor rule is persistent instruction that helps the agent behave correctly inside a repo. If you experiment with Rubato beside Cursor, write down what must never cross the boundary. Do it in the repo, not in a private chat prompt you will forget.

Here is a small .mdc rule stub you could keep with an experiment branch:

---
description: Boundary for local AI-state desk device experiments
alwaysApply: true
---

When adding or changing integrations for a desk display or MQTT status publisher:

- Only publish coarse agent state: thinking, generating, done, error, idle.
- Do not publish source code, prompts, file paths, branch names, secrets, diffs, or user text.
- Keep credentials in local environment variables or the OS keychain, never in the repo.
- Prefer read-only observation of agent state over editor automation.
- Include a short test note showing what payloads were emitted during one sample run.

That is not paperwork. It is a reminder to your future self that the fun part is the glowing Mac face, not accidentally turning your editor into a telemetry hose.

The related Cursor Workshop topic on subagents and skills goes deeper on the same shape: keep capabilities scoped, named, and easy to review. Don't make every experiment a new always-on automation. Most of them should stay small until they prove they are worth keeping.

Decide if desk hardware is worth it

Rubato makes the most sense when your AI coding sessions have real wait time. If you mostly use inline completions, the device may be cute but unnecessary. If you regularly kick off multi-step agent work, long refactors, test generation, or review passes, a physical “you can look away now” signal starts to feel practical.

The strongest argument for Rubato is not productivity. It is interruption quality. A phone notification pulls you into a noisy general-purpose device. A browser dashboard asks you to stare at another screen. A tiny desk display can say one thing and then shut up.

The weakest argument is novelty. A retro-Mac shell will get attention for a day. The habit only survives if the signal maps to a real action: stand up while generating, drink water after a long run, review when green.

If you build your own, start with the source repository and inspect the firmware and plugin path before connecting it to your normal editor setup. If you buy one from Tindie, the same rule applies: read what the local plugin observes and what it sends.

Try it safely with one tiny experiment

Use Rubato as a weekend-sized experiment before making it part of your normal Cursor rhythm. The goal is to learn whether physical agent state helps you review better and sit less, not to wire every coding tool into one glowing status bus.

A safe first pass is deliberately boring:

• Build or set up the device from the project docs.
• Run it against a test MQTT broker or non-sensitive local setup first.
• Trigger one agent task that takes longer than 30 seconds.
• Confirm the payloads contain only coarse state.
• Watch whether the break prompt changes your behavior once.
• Remove the plugin if you cannot explain exactly what it reads.

If that sounds too cautious, good. Desk hardware is fun precisely because it feels harmless. The software bridge is where you earn that feeling.

Common questions

Is a physical AI status display overkill?

It is overkill if your agent runs are short or you already handle breaks well. It becomes reasonable when AI coding waits are long enough to create bad habits: staring at generation, missing review handoff moments, or sitting through tasks that could have been a stretch break.

Further reading

• Cursor Agent docs
• Cursor rules
• Rubato_Device on GitHub

Next step

Open the Rubato_Device repository and read the plugin boundary before you look at the enclosure. If the payload is still just agent state after your review, try one long Cursor task and see whether the little screen actually gets you out of the chair.