DEV Community: Senthil raja .R

Ghost in the Machine: DEADLOOP, a Local-First Reliability Monitor for AI Agents

Senthil raja .R — Thu, 29 Oct 2026 18:28:28 +0000

This Halloween I built DEADLOOP: a reliability and safety monitor for AI agents that detects when they get trapped in repetitive tool calls, unproductive loops, or circular workflows. It records execution traces, raises evidence-backed incidents, and lets a human acknowledge, resolve, dismiss, or request a pause. The core is fully deterministic; an optional open-weight model only explains the findings. It never changes a finding or executes an intervention.

What I built

DEADLOOP is a monitor, not an agent framework. Your agent keeps running as-is. DEADLOOP ingests its tool-call trace and answers:

Is this repetition, or legitimate retrying?
What exactly supports that conclusion?
What should a human look at first?
Can we stop the run without claiming control we do not have?

Detectors:

Exact repetition
Near-duplicate repetition
A-B-A-B oscillation
Repeated failure
Explicit no-progress
Session budgets (tool calls, duration, tokens, cost)

Every incident cites real event IDs, the observed sequence, measured metrics, confidence basis, and stated uncertainty. Risk scores are heuristics in [0, 100], not probabilities.

The spooky part

Every developer has watched an agent whisper the same command into the void over and over, burning tokens while nothing moves. DEADLOOP is the thing in the machine that notices the ghost repeating itself and breaks the cycle. It is not a horror game aesthetic; it is a forensic one: dark, precise, and readable.

Why open innovation matters for this

The open pieces are what make the project work:

It runs offline. Detection, risk scoring, ingestion, and incident management are deterministic and local. No API key is required for the core product to function.
It keeps data off servers you do not control. Execution traces can contain tool arguments, outputs, and errors. DEADLOOP redacts credential-shaped fields at two layers: the SDK before transport, and the backend before storage. Raw ingestion keys are never returned after creation.
It is not locked inside a disappearing service. The stack is FastAPI, SQLAlchemy, SQLite/PostgreSQL, React, and Vite. The detector never depends on a hosted model. If the optional AI provider is disabled, slow, or returns invalid output, the deterministic explanation remains available.
Optional open-weight AI. Explanations can use an OpenAI-compatible endpoint, verified with Gemma 2 2B through Ollama. No API key is required for a local endpoint. Detection remains on-device either way.
Cost. The basic product requires no paid external services.

Where the open-based approach worked better than a closed one: a closed tracing service would show that calls happened, but it would not let me keep traces local, swap or disable the model, or explain exactly why a finding occurred. DEADLOOP can run with the internet off and still tell you what happened.

Demo walkthrough

The sample simulator generates real execution events through the same ingestion, persistence, detection, and incident paths as production. The exact-repetition scenario creates four identical failing calls and produces both exact-repetition and repeated-failure findings. Evidence references the real event IDs; you can open the incident, inspect the timeline, acknowledge it, request a pause, approve it, and verify the simulator acknowledges it.

Code that matters

# Send one event from any agent
from deadloop import DeadLoopClient

client = DeadLoopClient(
    endpoint="http://127.0.0.1:8000",
    api_key="dl_...",
)
client.send_event(
    agent_id="research-agent",
    session_id="run-42",
    tool_name="search_web",
    action="Search",
    input={"query": "database connection error"},
    output={"results": 3},
    status="success",
    progress=True,
)

# Run the backend
cd backend
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
python -m alembic -c alembic.ini upgrade head
$env:DEADLOOP_ADMIN_TOKEN = "choose-a-long-random-token"
$env:DEADLOOP_AUTO_CREATE = "0"
python -m uvicorn app.main:app --host 127.0.0.1 --port 8000

# Build the frontend
cd frontend
npm ci
npm run build

Open http://127.0.0.1:8000 and sign in with the configured admin token.

Verification

Backend pytest: 62 passed, 0 failed
SDK pytest: 8 passed, 0 failed
Frontend Vitest: 8 passed, 0 failed
Frontend production build: passed
Clean-database Alembic migration: passed, 11 tables
Live API acceptance workflow: passed with 0 failures

Security notes

Secrets are not hardcoded; they come from environment variables.
Inputs and configuration values are validated.
Protected endpoints enforce authorization on the backend.
Intervention operations require approval and are audited.
External AI data transfer requires explicit configuration.
Known limitations are documented, including single-node scope, no multi-tenant RBAC, and no built-in TLS.

GhostShift AI: The Local Automation Studio That Does the Chores You Keep Putting Off

Senthil raja .R — Sun, 25 Oct 2026 14:51:17 +0000

The lazy payoff

We all have that folder. The Downloads folder. The Documents dumping ground. The logs directory that's grown to ten thousand lines. You know you should tidy it, sort it, review it — but it's boring, it's repetitive, and it always feels like it can wait until tomorrow.

GhostShift AI is built for exactly that procrastination. It's a local-first automation studio that scans, classifies, analyzes, and archives the files and logs already on your machine — but only after you approve each step. It does the work so you don't have to.

GhostSort watches a folder you register, proposes where each file should go, shows you a preview, and moves only what you explicitly approve. Fingerprint-verified undo means if you change your mind, it goes back exactly where it came from.

GhostDev reads your log files, groups errors deterministically, and (if you have a local model) adds a clearly labelled interpretation — without sending your logs anywhere.

GhostCapture records an allowlisted sequence of file actions (no screen recording, no browser snooping), lets you edit and reorder the steps, then replays them as a dry run or live run whenever you want.

GhostBrain drafts new workflows from a plain-language prompt using a local open-weight model — and nothing executes until you say so.

It's slow and steady by design: AI suggests, deterministic code validates, you authorize, the engine executes, history records.

Why open innovation matters here

GhostShift runs entirely on your laptop. There is no account, no cloud control plane, no telemetry, and no hosted model provider. The optional AI layer uses Ollama with an open-weight model (default: gemma2:2b), which means:

No internet required. The deterministic pipeline — scan, classify, hash duplicates, analyze logs, guard moves — works completely offline. The model is only needed for interpretation and workflow drafting.
Your data never leaves your machine. Filenames, log signatures, and file contents stay in a local SQLite database and local reports. Nothing is uploaded, scanned by a third party, or used to train someone else's model.
Set it up once, never pay again. Local inference costs nothing per token. There's no subscription, no API credit burn, and no rate limit from a hosted provider.
Swap the model, fine-tune it, change the behavior. Because the model talks to a standard Ollama endpoint, you can point GhostShift at any local model you prefer, swap in a fine-tuned version, or run it CPU-only. The AI is never an authority — it can't name a destination path, add a workflow action, or run a command. All it can do is suggest, and the application code decides whether to act.

The stack

Layer	Choice
Backend	Java 25, Micronaut 5.2, Gradle 9.8, Netty
Frontend	Vue 3 + TypeScript + Vite, Pinia, custom CSS design system
Database	SQLite (WAL mode, direct JDBC)
AI runtime	Ollama (optional, local open-weight models)
Packaging	Docker Compose (loopback-only ports)

The UI binds to 127.0.0.1:3000, the API to 127.0.0.1:8080, and both are loopback-only by default. An optional bearer token can lock the API down further.

Try it

# Clone
git clone https://github.com/Senthil455/GhostShift-AI.git
cd GhostShift-AI

# Configure
cp .env.example .env
# Edit .env if you want an API token or a different Ollama model

# Run with Docker
docker compose up --build

# UI:  http://127.0.0.1:3000
# API: http://127.0.0.1:8080

If you have Ollama running locally:

ollama serve
ollama pull gemma2:2b

Then open GhostBrain in the UI and click Test model. If Ollama isn't available, GhostShift still works — every deterministic feature runs without it, and AI-specific panels show an honest notice instead of inventing a result.

Honest limitations

No browser or screen recording. GhostCapture records reviewed file actions only.
No file deletion. Duplicate detection reports exact matches; it does not remove them.
Docker images are packaged but were not runtime-tested in the build environment.
Single-user local design — SQLite and an in-process worker are for one person on one machine.

Build it your way

GhostShift is open source because the automation that touches your files should be inspectable, auditable, and yours to modify. If you want a sloth-speed automation studio that conserves your energy and keeps your data under your control, this is the repo to fork, extend, and run on your own hardware.

View on GitHub

Built for the Hacktoberfest Open-Source AI Challenge: Week 3 — "Slow and Steady."

SellCraft AI: a listing writer that runs on the seller's laptop, not my server

Senthil raja .R — Mon, 19 Oct 2026 03:35:22 +0000

(alt: SellCraft AI — a fully local Etsy/eBay listing writer with Gemma 4 and Ollama)
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

SellCraft AI is a listing writer that runs on the seller's laptop, not on anyone else's server. A handmade seller drops in up to four product photos, types the few facts only the maker knows — materials, size, price — picks a platform (Etsy or eBay) and a tone, and gets back a finished listing: a keyword-front-loaded title inside the platform's character limit, a 120–180 word description in the shop's own voice, and tags that respect Etsy's 13-tags-by-20-characters rule.

I built it for one specific person — the seller I kept picturing while writing it: forty active listings, a day job, a phone full of product photos. Photographing six new mugs takes an evening. Writing the six listings takes another evening, and that's the evening the box stays closed and the mugs stay unlisted. SellCraft turns each listing into about a minute of work — and it doesn't sound like a template, because it writes from the photos and the seller's own words instead of from a blank prompt box.

Would someone pay for it? I think so, and not much has to be true for that to hold: it saves a seller an evening a week, and it's sold as a flat one-time download. There's no API bill behind it, so there's no meter to hide inside a subscription — the seller can regenerate a description twenty times without watching a counter. Tooling for a side hustle shouldn't be one of the side hustle's fixed costs, and only a locally-running model makes that price possible.

Demo

There's no live link, deliberately. SellCraft's whole argument is that it runs on the seller's machine — a hosted demo would be a different, worse product. The honest demo is two commands:

ollama pull gemma4      # one-time: the model now lives on this machine
python sellcraft.py     # opens http://127.0.0.1:8765

The repo ships three sample photos (a mug, soap bars, earrings), so you can go from clone to a finished listing in about a minute without hunting for product photos.

Code

Everything lives in one repo: https://github.com/Senthil455/Sell-Carft-AI

One Python file (~600 lines, standard library only), one plain HTML/CSS/JS front end, one SQLite file. No pip install, no build step, no framework, no account. Built end-to-end for this challenge.

How I Built It

A single-file backend, on purpose. The server is http.server + urllib + sqlite3 — every import is in Python's standard library. If you're going to ask a stranger to run AI on their own laptop, "you can read the entire backend in one sitting" is the feature. The trust story is the source code, not a policy page.

Gemma reads the photos. The app talks to Ollama on 127.0.0.1:11434 and runs Gemma's vision model. Seeing the photo is what makes or breaks the output: it has to recognize speckled stoneware with a chunky handle, because "handmade ceramic mug" is the listing every other seller already has. Any vision model you've pulled shows up in a dropdown, so a slower laptop can swap down.

The prompt is where the product actually lives. It's one carefully-built template with hard rules: never invent materials, sizes, prices or origins; work only from the seller's facts and what's clearly visible in the photos; plain text only; exactly four labelled sections (NOTES / TITLE / DESCRIPTION / TAGS). Each platform carries its own constraints — Etsy gets a 100–140 character title and 13 tags of ≤20 characters; eBay gets a keyword-first 80-character title and 8 keywords. My favourite part is NOTES: instead of inventing a size, the model says what it saw and asks about the one thing it couldn't read — "roughly how much does this hold?" A writer that asks is worth more than one that guesses.

Trust is enforced a second time, in code. Prompts drift, so every draft passes through a tidy_listing() cleanup before it reaches the UI: titles are truncated at a word boundary to the platform's limit, tags are deduplicated, lowercased and trimmed to 20 characters — and when trimming would gut a tag into nonsense, it's dropped instead of shipped broken. (Etsy silently ignores over-long tags, which is how sellers end up with nine working tags and no idea why.)

Streaming, because good writing feels written. The server relays Ollama's token stream to the browser, so you watch the title fill in, character counters tick against each platform's limits, and tags that run long light up red before Etsy ever sees them. A full draft lands in about [X] seconds at [Y] tok/s on my laptop — the app prints both numbers under every draft, so the machine is honest about its speed with the seller.

It learns the shop's voice, locally. Saved listings go into SQLite, and the last three are fed back into the next prompt as a style sample: match this voice, never copy it. The output sounds more like the shop with every listing — and the examples never leave the machine that wrote them. Revision works the same way: type "less flowery" or "make the description shorter", and the model receives the previous draft plus the instruction, and rewrites the whole thing.

Small kindnesses where they matter. Photos are downscaled in the browser to 1000 px before they hit the local model. The app opens its own tab on startup. When Ollama isn't running, the page says so in plain words and offers a re-check button instead of dying. And there's a one-click CSV export, because a seller's catalogue is their business, not my database.

What it deliberately doesn't do: it won't post to Etsy for you. The output is plain text with copy buttons, because holding a seller's marketplace credentials is a commitment a v1 shouldn't make. It's probably the first thing a real user will ask for — and that's a decision to make with a real user, not on their behalf.

Why Does Open Innovation Matter?

Privacy is the architecture, not a promise. The only hostname that appears anywhere in SellCraft's source is 127.0.0.1. A handmade seller's photos are their original work — often photographed before the listing exists anywhere — and their drafts contain pricing and positioning they haven't published yet. Running Gemma locally means there is no server to trust. That's a different category of claim from "we don't store your data": you can verify it by reading one file.

The business model only works because inference is local. With a closed API, every draft is a line item, and the builder pays for every user forever. That cost structure is exactly what pushes small tools into subscriptions, credit packs, and "fair use" limits. Gemma on the laptop makes the hundredth listing cost the same as the first — nothing — so the product can be sold as a flat one-time download. A price that works for a seller in a craft economy only exists because the marginal cost is zero.

Swapping models is a feature, not an escape hatch. The model dropdown is just "whatever you've pulled with Ollama." When a better open-weight vision model ships next month, a seller gets it with one command: no waitlist, no repricing, no migration project. Whole product roadmaps have been broken by a provider deprecating a single endpoint.

The agent's behaviour is a text file. "Never invent a size" is a visible rule in one f-string that a seller — or anyone forking the repo — can change in a line. Closed systems hand you a prompt box; open ones hand you the harness. And because Gemma's weights are open, the natural next step stays on the table instead of on a waitlist: fine-tuning a small model on a shop's own back catalogue, so the writer learns their catalogue the way a hired copywriter would.

It works with the Wi-Fi off. Once the model is pulled, SellCraft doesn't need the internet to write a listing — on a train, at a market stall, during an outage. That still feels slightly magic, and it's the property that most cleanly separates what open weights make possible from what closed APIs allow.

My Agent Session

My First User

Prize Categories

Best Use of Gemma. Gemma is the core of the product, running locally through Ollama: it reads the seller's photos and writes every word of the listing — the description, the title, the tags, and the questions it asks back. The default pull is gemma4:latest; any Gemma vision build works, and there is no other model or cloud API anywhere in the stack.

SunSeat: Touch Grass in 20 Minutes with Offline Gemma

Senthil raja .R — Sun, 11 Oct 2026 18:22:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

SunSeat: a 20-minute sunny-bench finder for night-shift workers, SAD winters, and overstimulated brains. Enter location + minutes + needs (flat / quiet / toilet / shade / dog), get 3 sun pockets with a 0-100 go-now score + a 60-second mission card. Screen time under a minute, the rest is outside.

I built it for myself in Chennai: short October evenings, no time for a hike, need sun fast without scrolling.

Demo

Live: https://sun-seat.onrender.com (verified /api/health ok, frontend serves)
Video (90s): screen search -> walk -> sunny bench -> mission card read aloud (narration in demo-narration.txt, MP3 via ElevenLabs).
Offline proof: load once online, airplane mode on, reload / - results render from localStorage sunseat_last. Screenshot in repo docs/ after you test.
Cover: frontend/cover.svg (1000x420).

Local fallback if needed: pip install -r requirements.txt && uvicorn backend.main:app --port 8000.

Code

Repo: https://github.com/Senthil455/Sun-Seat (MIT)

backend/main.py - FastAPI, solar math, OSM Overpass, Open-Meteo, best_hour_tabpfn(), gemma_brief() via Ollama
frontend/index.html - single-file PWA, offline cache, free TTS Speak button
scripts/tabpfn_demo.py + data/weather_history.csv - TabPFN evidence, CI check
tests/test_api.py - 3 tests, all passing
Dockerfile + render.yaml + .github/workflows/ci.yml

How I Built It

Open core, not decoration:

Gemma via Ollama writes the mission card. Prompt + output logged in /api/brief. Local run returns mode:local-open-weight - proof in docs/ollama-proof-gemma2-2b.json (full gemma2:2b, tested on laptop; docs/ollama-proof.json shows the lighter gemma3:270m swap). Render free has no GPU/Ollama so it returns an honest hosted-template-fallback - cite the proof files as evidence.
OSM Overpass supplies parks / benches / toilets + surface/smoothness/incline tags. Open-Meteo supplies cloud + radiation. Pure-python solar elevation + transparent sun_score() 0-100.
TabPFN: scripts/tabpfn_demo.py trains TabPFNRegressor on data/weather_history.csv when installed, else sklearn fallback with stderr log. Backend best_hour_tabpfn() does the same live. Run python scripts/tabpfn_demo.py --json and paste output.
SerpApi /api/foliage: live search when SERPAPI_KEY set, else cached-offline. Sentry inits when SENTRY_DSN set - paste trace + latency_ms from /api/pockets.

Swap models in one var: OLLAMA_MODEL=llama3.2:1b.

Why Does Open Innovation Matter?

Closed maps hide the tags I filter on - surface, smoothness, bench, toilets. I cannot build flat/quiet/toilet search on Google Maps API. OSM exposes them freely.

Closed AI dies on the trail: needs signal, per-token cost, uploads your location + photo. SunSeat caches OSM + weather JSON after first fetch, then Gemma 2B runs on the laptop with no internet, $0, private. I edited the prompt locally, swapped models, no approval, no bill. That offline airplane-mode run is the whole point - and only possible open.

My Agent Session

Built with GitHub Copilot CLI + this coding agent. Process evidence: commit history + CI run .github/workflows/ci.yml (health + tabpfn check). Screenshots attached: Ollama mode:local-open-weight brief, airplane-mode reload.

Prize Categories

Best Use of Gemma (local gemma2:2b mission card)
Best Use of Render (Dockerfile + live URL)
Best Use of TabPFN (CSV forecast, scripts/tabpfn_demo.py)
Best Use of SerpApi (live foliage grounding / cached fallback)
Best Use of GitHub Copilot (Copilot CLI + Actions CI)
Best Use of ElevenLabs (demo-narration.txt -> MP3 narration)