AnSysWarden：以手機本地 AI 協助判斷開發者儲存空間清理

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

AnSysWarden: I didn’t have enough space on my PC to install the AI that was supposed to help me free up space

What I Built

AnSysWarden was born from a rather paradoxical situation.

My development PC was running out of storage.

Between node_modules, Gradle caches, builds, dependencies, development tools, and other temporary artifacts, I had less and less free space available.

The problem was not simply finding which folders were taking up the most space.

Tools for that already exist.

The real problem came afterwards:

Okay, this folder takes up several gigabytes. What exactly is it? Can I delete it? Is it reproducible? Or could I lose something important?

I wanted to build a tool that could help answer those questions.

I also wanted to experiment with local AI to interpret the more ambiguous cases.

But there was a rather funny contradiction:

I didn’t have enough free space on the PC to comfortably host the AI that I wanted to use to free up space.

Installing a multi-gigabyte model on a machine that already had a storage problem did not seem like the smartest solution.

So I decided to separate the responsibilities.

The computer would handle:

scan
↓
detect large folders
↓
apply known rules
↓
prepare uncertain cases

And inference would run on another device.

That other device ended up being something I already carried with me:

my Android phone.

That is how AnSysWarden’s architecture was born.

PC with little free space
        │
        │ scans and analyzes
        ▼
   AnSysWarden
        │
        │ only ambiguous cases
        ▼
   Android phone
        │
        ▼
   Ollama + Gemma
        │
        ▼
     AI evidence
        │
        ▼
   safety policy

The computer does the lightweight work.

The phone provides the inference capability.

And AnSysWarden acts as the layer that decides what can actually be done with that information.

The goal is to turn it into a kind of pocket SRE for developer storage.

I don’t want AnSysWarden to be just another tool that says:

This folder takes up 6.4 GB.

I want it to help answer:

This folder takes up 6.4 GB.

It looks like a known, reproducible cache.

or:

This folder takes up 6.4 GB.

There are conflicting signals.
You should review it.

One Rule From the Beginning: The AI Is Not in Charge

There was one thing I knew from the start.

I did not want a language model to have direct authority to delete files.

AnSysWarden’s main rule is:

Gemma can recommend; only AnSysWarden can authorize SAFE_CACHE.

This means the model can provide context, but it cannot grant itself permissions.

There are three different levels:

what the system observes
        ↓
what the AI recommends
        ↓
what AnSysWarden finally authorizes

And they do not have to match.

For example:

/home/user/.gradle/caches/modules-2

is a known structure.

It can be recognized by a local rule as a reproducible cache.

But:

/home/user/work/cache-backup-KEEP

contains much more ambiguous signals:

cache
backup
KEEP

Even if Gemma believes something looks reproducible, AnSysWarden should not automatically allow it to be deleted.

When in doubt:

REVIEW_REQUIRED

The philosophy is simple:

uncertainty = review

Never:

uncertainty = delete

Architecture

AnSysWarden is mainly split into two components.

PC: Scanning and Policy

The computer side is built primarily with Node.js and TypeScript.

Its job is to scan storage and reduce the problem.

Instead of sending millions of files to an AI:

Filesystem
    │
    ▼
Fast Scanner
    │
    ▼
Size Filter
    │
    ▼
Artifact Profiler
    │
    ▼
Safety Rules

AnSysWarden can first focus on large items and interesting structures such as:

node_modules
.gradle
build
dist
venv
IDE caches
dependency caches
temporary artifacts

AI is not the first step.

Deterministic rules take priority.

If a folder can be classified reliably using a local rule, there is no reason to involve an LLM.

For example:

/home/user/.gradle/caches/modules-2

can be identified locally as:

SAFE_CACHE

But context also matters.

This:

/home/user/dev/demo/node_modules

does not necessarily mean the same thing as:

/home/user/Documents/project/node_modules

even though both paths end with node_modules.

AnSysWarden tries to apply user-data protection policies first.

Mobile: Local AI Server

The least conventional part of the project lives on the phone.

I am using a Samsung S25 Ultra as a small local inference server.

The stack is roughly:

Samsung S25 Ultra
        │
        ▼
      Termux
        │
        ▼
      Debian
        │
        ▼
      Ollama
        │
        ▼
    Local Gemma

The model runs on the phone, and AnSysWarden can query it whenever local rules are not enough.

That means the PC I am trying to clean does not also need to store the model.

The architecture became:

PC
├── scanner
├── profiler
├── rules
├── safety policy
└── AI client
        │
        │ local connection
        ▼
MOBILE
└── Ollama + Gemma

The distributed architecture did not happen because I wanted to build a distributed system.

It happened because I did not have enough free space to do it any other way.

How I Built It

The principle I try to follow is to solve each problem with the simplest tool available.

1. Scan

First, AnSysWarden finds relevant directories.

There is no point asking an AI to inspect millions of entries if we can reduce the problem beforehand.

The scanner can identify large directories and turn them into candidates.

2. Build a Profile

Each candidate becomes a small structured object containing useful information.

Conceptually:

{
  "path": "/home/user/work/cache-backup-KEEP",
  "size": "6.1GB",
  "type": "directory"
}

The goal is to send only the information necessary to support a decision.

3. Apply Local Rules

Before asking Gemma anything, AnSysWarden looks for known patterns.

For example:

/home/user/.gradle/caches/modules-2

can be classified directly.

The same applies to certain development artifacts.

But the rules also need to understand priorities.

If AnSysWarden sees:

/home/user/Documents/web/node_modules

the presence of Documents should outweigh the presence of node_modules.

User documents take priority over a generic cache-like pattern.

4. Ask Gemma Only When Necessary

When the system does not have enough information, Gemma steps in.

The model does not return a deletion command.

It provides evidence.

It can indicate things such as:

regenerability = unknown
risk = medium

or:

regenerability = likely
risk = low

But that evidence still passes through the safety policy afterwards.

5. Final Safety Barrier

This is probably the most important part of the project.

Gemma can recommend.

But effective SAFE_CACHE authorization must come from a rule AnSysWarden considers safe.

If any of these happen:

timeout
invalid response
unexpected JSON
ambiguous result
model unavailable
insufficient evidence

the system can degrade the result to:

REVIEW_REQUIRED

It is intentionally conservative.

Why Does Open Innovation Matter?

AnSysWarden analyzes something quite sensitive:

the user’s filesystem structure.

A path can contain information such as:

personal names
client names
private repositories
project names
documents
tools in use
internal structures

I did not want using AI to automatically mean sending that information to a remote service.

Local inference lets me design the system so that this analysis stays within infrastructure controlled by the user.

But working with an open model also gives me control over something even more important:

Prompt
  ↓
Model
  ↓
Response
  ↓
Parser
  ↓
Policy
  ↓
Decision

I can change the prompt.

I can change the model.

I can inspect its failures.

I can build adversarial tests.

I can decide what data it receives.

I can decide how much authority it has.

And I can decide where it runs.

That last point ended up defining AnSysWarden.

At first, I thought:

local AI = model running on my PC

Now I think:

local AI = model running
           on any node I control

In my case, that node is a smartphone.

I did not need a second GPU.

I did not need a dedicated server.

I did not need to fill the disk I was already trying to clean.

I reused hardware I already owned.

Current Project Status

AnSysWarden is still under development.

I do not want to present this submission as if it were already a finished product.

The goal of the challenge is to reach a functional MVP, demonstrate the architecture, and prove that the safety barriers work.

Several important pieces already exist:

✓ AnSysWarden CLI
✓ Scanning and profiling
✓ Deterministic rules
✓ Protection policies
✓ Ollama integration
✓ Gemma running on Android
✓ Model communication
✓ Direct AI tests
✓ Adversarial tests
✓ REVIEW_REQUIRED fallback
✓ Technical logs + human-readable explanations

The current implementation can verify that Ollama is available and that Gemma responds correctly on the phone.

But there is still important work left.

Mainly:

△ finish polishing PC ↔ mobile communication
△ improve inference speed
△ complete the UI
△ simplify the user experience
△ prepare the final demo
△ expand adversarial testing

The UI Still Needs Work

This is an important part I want to be transparent about.

Right now the project can expose a lot of technical information.

For example, the tests display:

TECHNICAL TRACE
INPUT
EXPECTED
ACTUAL
CONFIDENCE
SOURCE
REASON
DURATION

followed by a more human-readable explanation.

That is extremely useful during development.

But it should not be the final interface.

The user should not need to understand concepts like:

ai-evidence
fallback
regenerability
risk
confidence

just to free some disk space.

The UI I want to build should reduce almost everything to two main lists:

┌──────────────────────────────────┐
│          AnSysWarden             │
│                                  │
│        18.4 GB found             │
├──────────────────────────────────┤
│                                  │
│ 🗑 DELETE                        │
│                                  │
│ ☑ .gradle/caches        4.2 GB  │
│ ☑ node_modules          2.8 GB  │
│                                  │
├──────────────────────────────────┤
│                                  │
│ 👀 REVIEW                        │
│                                  │
│ ☐ cache-backup          6.1 GB  │
│ ☐ old-project           3.4 GB  │
│                                  │
└──────────────────────────────────┘

The application can be complex internally.

The experience should not be.

The flow I want is:

scan
↓
see results
↓
select
↓
confirm

Nothing more.

Code

AnSysWarden is open source.

Main repository:

https://github.com/nicolasalarconrapela/AnSysWarden

For this submission, I want to keep a dedicated branch that represents the exact state of the project submitted to the challenge:

contest/devto-hacktoberfest-week3

The contest branch will be:

https://github.com/nicolasalarconrapela/AnSysWarden/tree/contest/devto-hacktoberfest-week3

This way, I can continue developing AnSysWarden after the challenge without changing the exact reference for the submitted version.

My Agent Session

During development, I am using coding agents both to implement features and to challenge my own assumptions.

I do not want to use them only as:

"write this function"

I also want to use them to ask:

what happens if this rule fails?

what happens if the AI returns something unexpected?

what happens if a path looks like an instruction?

what happens if Gemma does not answer?

what happens if it takes too long?

The safety test suite contains exactly these kinds of cases.

My goal is to always be able to distinguish:

what the system observed

what Gemma said

what AnSysWarden allowed

what the user ultimately sees

because those four answers can be different.

DevRelay session:

[TO BE ADDED]

The Lazy Payoff

When my PC was running out of space, my usual workflow looked something like this:

open File Explorer
↓
find large folders
↓
try to remember what they are
↓
search for the folder name online
↓
wonder whether I can delete it
↓
hesitate
↓
close the folder
↓
still have no space

And there was something even more absurd.

My first solution was to use AI to help me.

But:

I want to use AI
to free up space

        ↓

I need to install
the AI

        ↓

I do not have enough space
to install it

AnSysWarden aims to turn that entire process into:

scan
↓
classify
↓
review
↓
delete

The value is not just in finding what occupies disk space.

It is in reducing the mental work involved in deciding:

What on earth is this, and what is the risk if I delete it?

A Real Test With Gemma

Finally, I wanted to test something much more important than:

text
Does Gem