This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
I gave my friend an operating system for her brain.
Okay, not the whole operating system.
Mostly the scheduler.
Because apparently that was the missing part.
Somewhere around 3 AM, this became a perfectly reasonable sentence.
:D
My friend M. has a problem.
Not the usual productivity problem.
She does not procrastinate.
That is almost the problem.
For privacy, I'll call her M.
M. is the kind of person who seems to have an unreasonable number of processes running in her head at the same time.
One has music playing.
One has an unfinished math problem.
One contains a game she is building.
Two more are research ideas that absolutely did not exist yesterday.
There is probably a half-written article somewhere underneath them.
And occasionally a completely unrelated question appears, gets promoted to critical priority, and steals the CPU.
Her brain looks like a desktop nobody has restarted since 2019.
There are four terminals open.
Nobody knows what terminal number three is doing.
Including M.
My first thought was obvious:
I should build her a planner.
Then I realized that giving her another planner would probably just create another thing she had to manage.
So I stopped thinking about M. as an unorganized person.
And started thinking about her as a badly scheduled computer.
Then something clicked.
I had seen this failure before.
Not in a person.
In Operating Systems class.
When a computer keeps too many working sets active and spends more time moving context in and out than doing useful work, it starts thrashing.
M. was doing the human version.
So I did the only reasonable thing.
I gave my friend a kernel.
What I Built
THRASH is a local AI-powered human process scheduler.
It treats projects the way an operating system treats processes.
Not because I wanted to rename todo-list concepts with OS vocabulary.
The rule I used throughout development was simple:
If an operating-system metaphor does not correspond to real behavior, it does not belong in THRASH.
Projects can be RUNNING, READY, SLEEPING, STARVED, ZOMBIE, or deliberately terminated.
Switching projects saves context.
Returning to an old project restores it.
Ideas can arrive as interrupts instead of immediately creating another project.
Neglected work can starve.
Projects that quietly died while leaving TODOs and unresolved decisions behind can become zombies.
Too many active working sets create memory pressure.
Too many rapid switches create thrashing.
And eventually:
But the most important feature is not the joke.
It is what happens when M. returns to a project after hours, days, or weeks away.
A human PAGE FAULT
A computer can suspend a process and preserve enough state to resume execution later.
Humans usually don't.
We close the editor.
We open something else.
We come back three days later.
And stare at our own files like somebody else wrote them.
THRASH creates a semantic process image before that context disappears.
When M. returns, THRASH resolves a human PAGE FAULT.
It does not just say:
You were working on
game-alpha.
It tries to reconstruct:
- what she actually did,
- what she finished,
- what she deliberately decided,
- why she made that decision,
- where she stopped,
- what remains unresolved,
- what changed while she was gone,
- and what the next executable step should be.
A restoration can look like this:
PAGE FAULT
YOU WERE HERE
Built the camera prototype and checked idle poses.
Turn testing is unfinished.
YOU DECIDED
Validate the rig before engine integration.
why:
Avoid rebuilding an untested rig.
YOU STOPPED AT
Testing the 45-degree turn pose.
WHILE YOU WERE GONE
1 relevant file changed.
STILL OPEN
Does the shoulder deform during a turn?
BLOCKER
Turn pose has not been validated.
NEXT EXECUTION
Open notes.md and test the rig at a 45-degree turn
before engine integration.
FAULT RESOLVED
That is the part of THRASH I actually wanted M. to have.
She does not really need software telling her to "be productive."
She needs something that can answer:
What on earth was I doing here?
before she spends twenty minutes rebuilding the entire project inside her head.
Demo
PAGE FAULT — restoring the person who left
The project context is restored as a process image.
The program counter becomes the point where M. stopped.
Decisions become preserved state.
Unresolved questions survive the switch.
The next action becomes the next instruction.
The theatrical part is intentional.
But the state underneath it is real.
IRQ — an idea does not have to become a project
M. has another problem.
She has ideas.
A lot of them.
Previously, an interesting thought had a fairly dangerous execution path:
interesting thought
↓
browser tab
↓
notes
↓
research
↓
new folder
↓
new project
↓
what was I doing before this?
THRASH gives that thought somewhere else to go.
It can arrive as an interrupt.
IRQ RECEIVED
current execution preserved
interrupt queued
execution resumed
The idea is not lost.
But it also does not automatically deserve an entire process.
That turned out to be one of my favorite parts of the project.
When the scheduler actually starts thrashing
The interface does not glitch randomly for terminal aesthetics.
Visual instability is tied to scheduler pressure.
High switch frequency creates dispatch echoes.
Stale process images leave residue.
Working-set pressure creates page churn.
Interrupts accumulate on the IRQ rail.
The dispatch trace becomes harder to maintain because the underlying human schedule is becoming harder to maintain.
So:
The screen isn't glitching because I wanted a cool terminal aesthetic.
It's glitching because she keeps switching projects.
That distinction mattered a lot to me.
I did not want THRASH to look like an operating system.
I wanted it to behave like one.
Paging something out
Sometimes the correct answer is not to delete a project.
It is simply:
not now.
Suspending a process saves its working state and moves it across the SWAP HORIZON.
Pressure drops.
The scope stabilizes.
The project is not gone.
Its context is waiting.
The Human Kernel Scope
The interface is built around THRASH-specific primitives:
DISPATCH TRACE
SCHEDULER SCAR
RESIDENT WORKING SET
SWAP HORIZON
CORE / PROGRAM COUNTER / REGISTERS / STACK
IRQ RAIL
PAGE FAULT
KERNEL PANIC
The historical SCAR shows old scheduling behavior faintly behind the current dispatch trace.
The working-set map shows which project contexts remain resident.
The core shows exactly one running process.
Because M. may have many projects.
But she still has one human core.
If you want to see the scar itself more clearly:
Code
The project is open source here:
miclaldogan
/
thrash
A local AI human-process scheduler for people with too many projects in memory.
THRASH
She didn’t need another planner. She needed a kernel.
THRASH is a local human-process scheduler for returning to unfinished projects. PAGE FAULT restores what finished, what you decided and why, where you stopped, what changed, and the next action. Open-weight Gemma reconstructs that meaning locally from files and commits; Python measures switching and pressure. THRASH saves execution context across switches rather than organizing a task list. Project contents stay on your machine.
1 human. 1 core. Too many processes.
The human bug
My friend has more processes than cores.
She doesn't procrastinate. That's the annoying part. She is always doing something.
I considered building her a planner. She already has three. One of them contains a task called “organize task manager.” So that seemed unwise.
Then I realized I'd seen this failure before. Not in a person. In Operating Systems class.
She didn't need another planner. She needed a…
THRASH is a terminal-native Python application.
The kernel logic is deliberately separate from the interface.
The TUI is a client of the scheduler rather than the owner of its state.
That mattered because I wanted commands, tests, demos, and the full-screen Human Kernel Scope to operate on the same underlying process model.
At the time of this submission, THRASH has 159 passing tests covering the scheduler, restoration behavior, privacy boundaries, model failure handling, interrupts, starvation, zombie detection, Sentry filtering, evaluation behavior, and the visual state model.
Public demos use simulated project histories and anonymized aliases such as:
game-alpha
paper-crane
vision-lab
circuit-garden
THRASH was also verified locally against real projects in read-only mode.
Those contents were never committed and never used in public screenshots or fixtures.
How I Built It
THRASH has two intentionally different halves.
The scheduler is deterministic
Python handles everything that does not need a language model.
That includes:
- process registration,
- context-switch history,
- active/sleeping states,
- working-set pressure,
- starvation,
- zombie heuristics,
- snapshot age,
- interrupts,
- swap state,
- thrashing thresholds,
- drift timestamps,
- and scheduler telemetry.
I did not want an LLM deciding whether eleven context switches are more than four context switches.
That is code's job.
Gemma reconstructs the human part
The harder question is not:
Which files changed?
Git already knows that.
The difficult question is:
What did the human think she was doing when she left?
THRASH runs a local Gemma model through Ollama.
Gemma receives privacy-filtered project evidence and reconstructs a structured semantic process image.
Conceptually:
local project evidence
↓
privacy filter
↓
Gemma
↓
semantic process image
↓
program counter
decisions
completed work
unresolved state
blockers
relevant files
next execution
↓
PAGE FAULT resolved
The model is asked for structured output.
That output is validated before THRASH accepts it.
Unsupported or malformed model responses are rejected rather than silently becoming project history.
And this distinction became important during evaluation.
I learned very quickly that:
Valid JSON is not the same thing as valid memory.
My first evaluation looked superficially fine.
All eight scenarios produced valid schemas.
But recorded decision extraction was:
0/7.
The JSON was valid.
The memory wasn't.
So I investigated instead of hiding the result.
The evidence was still present after retrieval.
The privacy filter had not removed it.
The real problem was that my definition of a "decision" was too vague.
I tightened the extraction contract:
A decision must be an explicitly recorded choice, constraint, rejection, approval, or intentional deferral.
A task is not a decision.
A current state is not a decision.
An inferred preference is not automatically a recorded decision.
Then I reran the same evaluation scenarios with the same scoring rules.
The release revision produced:
- 8/8 valid schemas
- 8/8 completed-work coverage
- 8/8 next-action coverage
- 7/7 recorded decisions extracted
- 6/6 recorded decision reasons preserved
- 7/8 task-keyword coverage
- 2 unsupported assertions still detected
The one task-keyword miss was a faithful paraphrase, so I left the grader unchanged rather than making the metric prettier.
And the two unsupported assertions are still documented.
Because this is memory software.
Pretending that an LLM is infallible here would be a much worse design decision than admitting where it still fails.
The scheduler is ordinary Python.
The part that remembers why M. was there is Gemma.
Why the process image matters
A saved process image contains concepts such as:
PROGRAM COUNTER
the immediate execution point
REGISTERS
important project state and constraints
STACK
the chain of work around the current task
OPEN HANDLES
currently relevant project files
DECISIONS
explicit choices and their evidence
UNRESOLVED
questions that survived the context switch
NEXT EXECUTION
the smallest useful action for re-entry
The OS vocabulary is not there just for style.
It gave me a surprisingly useful way to ask:
What is the minimum state a human needs in order to resume this project without reconstructing everything from scratch?
That question became the center of THRASH.
Sentry traces THRASH
There is a slightly ridiculous recursive part to this project.
THRASH traces M.'s context switches.
Sentry traces THRASH's.
Sentry support is optional and disabled by default.
Normal THRASH operation does not require Sentry or an internet connection.
For a fresh PAGE FAULT, THRASH instruments the restoration pipeline:
thrash.page_fault
├── thrash.process_image.load
├── thrash.context.collect
├── thrash.privacy.filter
├── thrash.gemma.resume
├── thrash.schema.validate
├── thrash.drift.detect
└── thrash.restore.render
The trace exposed the bottleneck immediately.
One measured cold restoration took about 80.4 seconds.
Almost all of that time was local Gemma inference.
Roughly:
Gemma resume ~80.315 s
context collect ~6.5 ms
privacy filter ~2.3 ms
schema validate <1 ms
render <1 ms
Returning to an already saved process image was dramatically cheaper.
Milliseconds instead of another full inference.
That cold-start latency is a real limitation of the current local setup.
I would rather document it than pretend the machine suddenly became a datacenter because I like my terminal UI.
For this submission, I verified the Sentry SDK envelopes locally.
I did not have DSN/project access available for hosted Sentry verification.
So I am not presenting a fake hosted dashboard screenshot.
And I am not claiming that I performed one.
The integration itself is deliberately metadata-only.
Sentry receives:
No prompts.
No completions.
No source code.
No note contents.
No Git diffs.
No commit messages.
No absolute project paths.
No IRQ text.
No real project identities.
Only sanitized operational metadata such as duration, validation state, item counts, model timing, and scheduler state.
Observability should not destroy the privacy model it is supposed to observe.
Why Does Open Innovation Matter?
THRASH would feel fundamentally wrong if helping M. remember her projects required uploading those projects to somebody else's server.
The information needed for a useful PAGE FAULT may include:
- unfinished source code,
- research notes,
- unreleased experiments,
- abandoned ideas,
- TODO files,
- architectural decisions,
- and thoughts that were never intended to become public.
Those are exactly the things THRASH needs to understand.
And exactly the things I do not want leaving the laptop.
Gemma runs locally through Ollama.
Inference can happen without a cloud API.
The model can be swapped.
The extraction prompts can be inspected and changed.
The behavior can be tested.
There is no per-call cost forcing me to reduce the weirdness of the idea into the shape of somebody else's hosted product.
And if the internet disappears:
the human kernel still works.
That matters because privacy is not an extra feature in THRASH.
It is part of the architecture.
The project maintains explicit privacy boundaries and regression tests for things such as secret-like text, symlink escapes, excluded directories, absolute path leakage, malformed model output, and observability metadata.
Open-weight AI let me build the system around M.'s projects without requiring M.'s projects to leave her machine.
There is also a creative reason open models mattered.
THRASH is a strange use of an LLM.
I am asking a language model to help represent human project context as:
a program counter
registers
a stack
open handles
decisions
interrupts
process images
I wanted to be able to keep changing that representation.
To experiment.
To make it slightly weird.
To run it locally.
To break it.
To inspect why it failed.
And to keep going without asking permission from a hosted interface.
The strange part of THRASH is allowed to remain strange.
My Agent Session
THRASH was built heavily with a local coding agent.
I did not record the weekend build through DevRelay, so I do not have a DevRelay session to embed here.
The incremental development history is preserved in the Git repository instead:
There is something appropriately recursive about using an agent to build a scheduler for a human whose scheduler was apparently missing.
During development, THRASH itself repeatedly tried to become exactly the problem it was supposed to solve.
More ideas.
More mechanics.
More visual systems.
More things to add.
Eventually I had to give the coding agent one very specific instruction:
No more features.
We are now scheduling the scheduler.
I wish that sentence were a joke.
Prize Categories
Best Use of Gemma
Gemma is not a chatbot attached to THRASH.
There is no generic "ask my repository" interface.
The deterministic kernel can measure context switches, snapshot age, Git changes, active working sets, starvation, and scheduler pressure.
What it cannot understand is:
Why was the human here?
Gemma reconstructs the semantic process state that makes PAGE FAULT restoration useful.
Remove Gemma and THRASH can still count context switches.
It can no longer reconstruct the human state behind them.
That is why Gemma sits at the center of the restoration path rather than at the edge of the interface.
Best Use of Sentry Agent Tracing
Sentry is used to observe the semantic restoration pipeline itself.
It lets me see where a PAGE FAULT spends time, where model extraction fails, whether schema validation succeeds, and how expensive fresh inference is compared with restoring an existing process image.
The integration is optional.
It is metadata-only.
And normal THRASH behavior remains local-first.
The short version is:
THRASH watches the human scheduler.
Sentry watches THRASH.
One Last Thing
I built THRASH because M. has more processes than cores.
But after spending a weekend on it, I do not think the problem is uniquely hers.
Most productivity software assumes the hard part is deciding what task comes next.
Sometimes it isn't.
Sometimes you already know exactly which project you want to continue.
You open it.
And realize you no longer remember the person who was working on it.
What they learned.
What they rejected.
What they were worried about.
Why that TODO exists.
Why that particular file is open.
Why they stopped exactly there.
A computer would never voluntarily switch away from a process without preserving enough state to resume it.
Humans do it to themselves constantly.
THRASH does not tell M. to focus.
It does not tell her to have fewer ideas.
It does not try to turn curiosity off.
Frankly, I do not think either of us would enjoy that version of her very much.
It just gives all those ideas somewhere to wait.
And gives the projects she returns to a way to remember who left them there.
1 human.
1 core.
Too many processes.
Top comments (0)