Inspiration
We’ve all had a video call freeze, or a game stutter, because something in the background suddenly took over the computer. An update, a backup, a big build. Modern operating systems already have sophisticated ways of scheduling processes and managing priorities, but they don't inherently understand which applications matter most to you at a given moment. We wanted a computer that could understand priorities the way a person does: “This matters right now, and that can wait a bit.”
What it does
SenOS watches the programs you care about and notices when one of them is being starved for CPU. When that happens, it gives the important app a bounded priority boost. It doesn’t kill or pause anything else, so background work keeps running.
You can tell it what you want in plain English, like “Make my web app faster for 10 minutes but keep the build running.” An AI model (Gemini) turns that into a precise goal. Strict, predictable rules decide what actually changes, so the AI can never do anything reckless.
Every change is temporary and reversible. When time runs out, when you stop SenOS, or even if SenOS crashes, the original settings are restored automatically.
How we built it
SenOS is written in Python with a simple command-line interface. It uses Linux’s built-in tools (systemd and cgroups) to adjust how much CPU each app gets, and kernel pressure metrics to detect when an app is stuck waiting. Original settings are saved in SQLite so every change can be undone, and a separate recovery process restores them if SenOS crashes. Google Gemini turns plain-English requests into goals, while fixed safety rules decide what actually changes.
Challenges we ran into
- Merge conflicts: several of us built connected parts at the same time, so combining branches meant untangling overlapping changes without losing anyone’s work.
- Making changes safe: the hard part was guaranteeing every change gets undone, even after a crash.
- Making the slowdown visible: we had to tune the demo so the slowdown was obvious, and accept that the app recovers to about 75–94% instead of 100%, because we deliberately don’t starve the background job.
Accomplishments that we're proud of
- A live demo where you can see an app slow down and then recover
- Real system changes that are verified and always undone, even if SenOS crashes
- An AI that understands plain English but can’t do anything unsafe
What we learned
- How Linux decides which programs get the CPU, and how to measure when an app is stuck waiting
- That safe automation is mostly about the undo, not the action
- How to use AI to understand requests, while keeping the real decisions in predictable code
- How to work as a team on Git without breaking each other’s work
What's next for SenOS
- Managing memory, disk, and network, not just CPU
- Adjusting based on results, by checking whether the app actually got faster
- Automatically detecting which app you care about, like the one you’re using
