DEV Community: Sachchit

Origlyph — Decoding the Places Behind Culture

Sachchit — Sun, 01 Nov 2026 05:13:07 +0000

What if you could explore the world through the objects its people left behind?

Hacktoberfest Open-Source AI Challenge — Week 4: Ghost in the Machine

What if geography could be explored through history?

Most geography games test how well you recognize a place. A street, a building, a road sign, perhaps a landscape.

I wanted to experiment with a different question.

What if, instead of showing someone a photograph of a place, we showed them something that came from that place?

An ancient textile. A traditional musical instrument. A manuscript. An intricately carved doorway.

Could someone trace its origins simply by looking at the artifact?

That question became Origlyph.

Origlyph is a cultural heritage geo-guessing game where players explore artifacts from around the world and attempt to identify their geographical origins. Players drop a pin on an interactive map, submit their guesses, and receive a score based on how close they are to the actual location.

But getting the location right isn't really the point.

The interesting part begins after the guess.

Beyond the Guess: Discovering Provenance

The reveal is where Origlyph differentiates itself from conventional geography games.

Instead of displaying just the correct answer and distance, it introduces the artifact's provenance graph: a network of relationships connecting the object to its makers, geographical origins, historical context, collections, trade routes, and references.

The idea is to turn a simple guessing interaction into an opportunity for exploration.

An artifact is rarely just an isolated object. It carries traces of the people who created it, the communities that preserved it, and the journeys it made across time.

The Theme: Ghost in the Machine

For Week 4, the challenge revolved around the theme Ghost in the Machine, with an opportunity to interpret it through something spooky or through the remembrance and cultural traditions associated with Día de los Muertos.

I chose to approach it through cultural memory.

The concept of an ofrenda is about remembering people through the objects, traditions, and memories they leave behind.

Origlyph takes inspiration from that idea.

Every artifact has a human story embedded within it. The people who made it might be long gone, but their craftsmanship, traditions, and influence continue to exist through the objects they created.

The provenance reveal is designed to make those connections visible.

The ghost isn't necessarily something supernatural. It is the human story that remains inside an object long after its creator is gone.

Building the System

From an engineering perspective, I wanted Origlyph to remain relatively lightweight while keeping its different components independent.

The application is built around a React frontend, a FastAPI backend, a persistent artifact database, and an optional AI-powered hint layer.

System Architecture

flowchart TD
    A[React + Vite + TypeScript] --> B[FastAPI]
    B --> C[Game Engine]
    B --> D[Artifact Repository]
    B --> E[Hint Generation]
    B --> F[Provenance Explorer]
    C --> G[Distance Scoring]
    D --> H[MongoDB Atlas]
    E --> I[Deterministic Hints]
    E --> J[Gemma]
    F --> H

The Frontend

The frontend uses React, Vite, and TypeScript.

Leaflet, alongside OpenStreetMap tiles, powers the geographical guessing interface. This was a deliberate choice: I wanted an interactive map without introducing unnecessary dependence on paid map APIs.

The Backend

FastAPI handles the application logic and communication between the frontend and data layer.

One of the core mechanics is geographical distance scoring. Once a player submits a guess, the backend calculates the distance between the predicted coordinates and the artifact's actual location using the Haversine formula.

This provides a consistent basis for evaluating guesses regardless of where on the planet the player is guessing.

The Data Layer

The initial version uses locally available JSON seed data to keep the core experience functional without requiring external APIs during gameplay.

The data model draws inspiration from open cultural resources such as:

Internet Archive
Europeana
Wikimedia Commons

Artifact records retain their source and licensing information, making attribution and traceability part of the data model rather than an afterthought.

MongoDB Atlas provides persistent storage for artifact and provenance records.

Where AI Fits In

I didn't want AI to become a mandatory dependency for something as fundamental as a game hint.

Instead, I approached it as an enhancement layer.

Origlyph uses structured artifact metadata to generate deterministic hints based on attributes such as geographical region, historical period, and material.

Gemma adds a natural-language layer, turning these structured clues into more engaging hints.

This separation has a practical advantage: the application remains playable without model inference.

It also gives the project room to evolve. The hint-generation interface can support different open-weight models without coupling the rest of the application to a particular provider.

The broader engineering principle here is simple:

AI should improve the experience, not become a single point of failure.

Why the Open-Source Approach Matters

For a project centred on cultural preservation, openness felt like a natural architectural choice.

There are four aspects I particularly wanted to explore.

Model flexibility: Gemma sits behind a separate interface, allowing experimentation with different models and inference environments.

Graceful degradation: Deterministic hints keep the gameplay functional even when AI inference is unavailable.

Cost-conscious inference: Short, contextual hints can be cached per artifact, reducing unnecessary model calls.

Data transparency: Cultural records should retain their sources and licensing information. The provenance of the information itself matters just as much as the provenance of the artifact.

This is where the open-source ecosystem becomes more than a collection of tools. It becomes part of the product philosophy.

The Technology Stack

Component	Technology
Frontend	React, Vite, TypeScript
Maps	Leaflet, OpenStreetMap
Backend	FastAPI, Python
Database	MongoDB Atlas
AI	Gemma
Hosting	Render
Development workflow	DevRelay
Optional narration	ElevenLabs

What Was Challenging?

The most interesting engineering challenge was thinking about how to represent provenance.

A conventional database record can describe an artifact, but its history is more complicated. An object might have multiple creators, uncertain geographical origins, different ownership records, and connections to several historical events.

Representing these relationships in a way that is both technically manageable and understandable to someone playing a game is an interesting problem.

Another consideration was the boundary between AI-generated information and historical facts.

A model can make a hint more natural, but it shouldn't be treated as an authoritative historical source. Keeping structured metadata as the foundation helps maintain that distinction.

What's Next?

Origlyph is an initial exploration of how games and AI can make cultural heritage more approachable.

There are several directions I'd like to take it:

A daily artifact challenge with leaderboards.
A much larger catalogue of geographically diverse artifacts.
A richer provenance explorer with interconnected historical relationships.
Multilingual and narrated artifact discoveries.
Community contributions with source verification and attribution.

Ultimately, I'd like Origlyph to become more than a guessing game. It could be a way to explore the connections between geography, history, craftsmanship, and culture.

Explore the Project

GitHub Repository: https://github.com/SachchitNesarikar/origlyph.ai
Demo Video: https://drive.google.com/file/d/1e8nKQydXeQTLoWMzdRrW9N-YWAZLZfb3/

The Past Hasn't Disappeared. It Has Just Changed Form.

Technology is usually associated with creating something new. But I think it can also help us rediscover things that already exist.

An artifact can outlive its creator, travel across continents, pass through generations, and eventually find its way into a digital archive.

Its story doesn't end when it enters a database.

With Origlyph, I wanted to make those stories something people could actively discover rather than simply scroll past.

LazyDesk: Let AI Clean Up Your Digital Mess While You Do Absolutely Nothing

Sachchit — Mon, 26 Oct 2026 06:19:50 +0000

An open-source AI project for people who have better things to do than organize files.

Have you ever opened your Downloads folder looking for one important PDF, only to find hundreds of files named things like "final_v2.pdf", "final_final_revised.pdf", and "document(17).pdf"?

Same problem, different day.

We all know we should organize our files. We create folders, promise ourselves we'll keep everything tidy, and occasionally spend ten minutes renaming documents. Then life gets busy, the mess returns, and we start searching for files all over again.

What if your computer could handle that boring work for you?

That's the idea behind LazyDesk: a local AI-powered file organization assistant designed to turn digital clutter into a clean, manageable workspace.

And for the Hacktoberfest Open-Source AI Challenge Week 3 theme, Slow and Steady, it explores a simple philosophy:

Why spend your energy on repetitive tasks when an AI assistant can help you do them more efficiently?

The Problem: Digital Clutter Is Still Clutter

Our computers have quietly become storage rooms.

Screenshots pile up. PDFs get downloaded and forgotten. Project files end up in random folders. Documents receive filenames that make sense for approximately five seconds.

Traditional file organization tools can move files based on rules, extensions, or predefined patterns. But they don't always understand what a file is actually about.

For example, consider these files:

"IMG_20261012_091233.jpg"
"report_final_v3.pdf"
"notes_new.txt"
"download (8).pdf"

A basic script can identify their extensions. An AI model could help infer that one image might be a receipt, a PDF might be a project report, and a text file might contain meeting notes.

That contextual understanding is what makes LazyDesk interesting.

Instead of manually opening every file and deciding where it belongs, users could review AI-generated suggestions and approve the changes they want.

The Idea: Meet LazyDesk

LazyDesk is a proposed desktop-friendly application that uses open-weight AI to assist with file organization.

The goal isn't to give an AI unrestricted access to your computer. It's to give you a useful assistant that handles the tedious thinking while keeping you in control.

The initial version is designed around four capabilities.

Smart File Categorization

LazyDesk scans a user-selected folder and collects basic file information, such as filenames, extensions, and metadata.

An AI model then helps categorize files into useful groups, such as:

Documents and reports
Images and screenshots
Receipts and invoices
Study materials
Project files
Miscellaneous downloads

These categories can be customized to fit the user's workflow.

Meaningful Filename Suggestions

Instead of keeping "document(17).pdf", LazyDesk could suggest a clearer filename based on the available information.

For example:

"document(17).pdf" → "project-meeting-notes.pdf"

These suggestions would be generated only when there is enough context to justify them. A filename alone cannot reliably reveal the contents of every document, so uncertain cases should be flagged for review.

Duplicate Detection

Duplicate files waste storage and make it harder to find the right version.

LazyDesk could calculate file hashes to identify exact duplicates, then show the user which files appear identical.

This part doesn't require AI at all. A deterministic hashing algorithm is faster and more reliable for exact duplicate detection than asking a language model to make the decision.

That's an important design principle: use AI where it adds value, and conventional software where it works better.

Review Before Cleanup

The assistant prepares a proposed organization plan before changing anything.

Users can review the original filename, suggested filename, destination folder, and reason for the suggestion.

Only after approval would LazyDesk apply the selected changes.

This makes the assistant useful without making it unnecessarily risky.

The Technology Behind LazyDesk

The project is intended to demonstrate how open-weight AI can support a practical, everyday workflow.

The proposed technology stack is deliberately simple:

Gemma is an open-weight model family, while Ollama provides a convenient way to run supported models locally. The exact model variant should be chosen according to the available hardware and the quality of its output.

The application would follow a straightforward workflow:

The user selects a folder.
Python scans its files and collects relevant metadata.
The local model generates structured categorization and naming suggestions.
The application validates those suggestions and displays a preview.
The user approves the changes.
Python applies the approved operations and records a change log.

The language model would not be responsible for executing arbitrary shell commands or deciding independently to delete files. Its role would be limited to generating suggestions that the application validates.

This separation keeps the design easier to test, understand, and maintain.

Why Open-Source AI Matters

For LazyDesk, using an open-weight model isn't simply a way to add AI to a project. It affects how the application can be used and trusted.

Your files can stay on your computer

A folder organizer may encounter financial documents, personal photographs, academic work, or private business records.

Sending all of that information to an external AI service can create unnecessary privacy concerns.

A locally configured model can process information on the user's machine without sending prompts to a hosted inference API. That said, complete offline operation must be verified for the entire application, including model downloads, updates, and any optional integrations.

You have more control over the model

Different computers have different hardware limitations. Different users also have different expectations around speed, quality, and resource consumption.

An open-weight approach makes it possible to experiment with alternative supported models, compare their outputs, and select an appropriate model for the task.

If a smaller model is sufficient for basic categorization, users may not need a much larger model for every operation.

You can inspect and improve the implementation

A project built with open-source components can invite contributions from developers who want to improve classification rules, add categories, strengthen file-operation safeguards, or support additional model backends.

The project can also be extended without making every feature dependent on a single proprietary AI service.

You can reduce recurring inference costs

Once a compatible model has been downloaded, local inference can avoid per-request API charges.

It is not literally free in every sense: users still need suitable hardware, electricity, disk space, and time for setup. Nevertheless, local execution can make repeated use more economical and predictable.

For a personal utility that runs frequently, this trade-off is worth exploring.

Designing for Safety, Not Just Convenience

An AI file organizer should not be allowed to turn a messy folder into a missing-files problem.

That's why LazyDesk should include several safeguards from the beginning.

No automatic deletion. Duplicate detection should identify candidates, not silently remove them.

Preview before changes. Users should see every proposed move or rename before it happens.

Conflict handling. If a destination filename already exists, the application should stop and ask the user how to proceed rather than overwrite the file.

Undo support. A change log should record the original and new paths so completed operations can be reversed where possible.

Restricted access. The application should operate only on folders explicitly selected by the user.

Structured model output. Model responses should be validated against an expected schema. Invalid or ambiguous suggestions should not trigger file operations.

These safeguards aren't optional extras. They are part of making an AI agent dependable.

What the First Version Should Include

The initial release should focus on doing a few things well instead of attempting to become a complete desktop automation platform.

The minimum viable product would include:

A folder-selection interface.
A file scanner that collects metadata.
Local AI-based categorization.
Suggested filenames and destination folders.
A preview screen for reviewing proposed changes.
Approval-based file operations.
A log of completed changes.

Later versions could introduce content-aware document classification, configurable folder rules, natural-language organization commands, and more advanced duplicate management.

The first goal is straightforward: demonstrate that a small local AI application can save users time on an annoying, repetitive task.

📊 How I Would Evaluate It

A useful project needs more than a convincing screenshot.

To evaluate LazyDesk, I would measure:

Classification quality: How often do suggested categories match a manually reviewed reference set?
Time saved: How long does organizing a folder take manually compared with using the assistant?
Latency: How long does the model take to generate suggestions for each file?
Resource usage: How much memory and disk space does the chosen model require?
Safety: Can the application avoid overwrites, prevent unapproved operations, and recover from errors?
Privacy: Can the complete core workflow run without sending file information to an external service?

These measurements would help determine whether the AI genuinely improves the experience over a conventional rule-based organizer.

I would also compare AI-generated categorization with simple extension-based rules. If a rule is sufficient, the application should use the rule rather than spend inference time on a task that doesn't need a model.

The Bigger Picture

LazyDesk is about more than tidying up a Downloads folder.

It represents a broader idea: useful AI doesn't always need to be a chatbot, a massive cloud service, or a complicated autonomous agent.

Sometimes the best application of AI is an unobtrusive assistant that handles a small amount of annoying work, asks for approval when necessary, and gets out of the way.

Open-weight models make that approach especially interesting because developers can experiment locally, choose their own model, and build tools that respect the user's control over their data.

That's what I find compelling about the Slow and Steady theme.

The goal isn't to make people work faster at everything. It's to remove the repetitive work that doesn't deserve their attention in the first place.

Final Thoughts

LazyDesk is a proposed experiment in building a practical AI assistant with open-weight models and familiar open-source tools.

Its central idea is simple: let the computer handle the tedious parts of file organization while the user remains in control of the final decisions.

If implemented well, it could become a small but genuinely useful tool for students, developers, freelancers, and anyone whose Downloads folder has become a digital junk drawer.

And perhaps that's the real promise of open-source AI: making intelligent automation accessible, adaptable, and private enough to be useful in everyday life.

Build less busywork. Keep control. Embrace your inner sloth.

TouchGrass — AI That Gets You Off Your Screen

Sachchit — Mon, 12 Oct 2026 06:25:37 +0000

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

Built with Gemma by Google · Powered by Hugging Face · Deployed on Render · Open source on GitHub

What if AI didn't try to keep you online, but helped you step away?

Introducing TouchGrass — a lightweight, AI-powered micro-mission generator designed to turn spare time into real-world action.

Instead of another productivity dashboard, endless feed, or chatbot conversation, TouchGrass gives you one simple thing to do offline.

Try it live: https://t0uchgrass.onrender.com/

Source code: https://github.com/SachchitNesarikar/hacktober-26

The problem

We use technology to learn, build, work, and organize our lives. But sometimes, we get stuck consuming more content instead of acting on what matters.

I wanted to experiment with a different kind of AI product: one that helps you spend less time interacting with the product itself.

Meet TouchGrass

Choose one of three focuses:

Move: Take a walk, stretch gently, or change your surroundings.
Learn: Solve a problem on paper, read something meaningful, or explain a concept from memory.
Explore: Discover a new route, notice details around you, or make something by hand.

Choose whether you have 5, 15, or 30 minutes, optionally add a personal goal, and generate a micro-mission tailored to your situation.

Complete it, record a small reflection, and build a history of your wins — without needing to create an account.

The technology behind it

Gemma + Hugging Face

TouchGrass uses Google's Gemma 3 4B Instruct through Hugging Face's inference API to generate personalized, structured missions. The model receives the selected focus, available time, and optional personal goal, then returns a concise mission.

Render

The application is deployed as a Node.js web service on Render, serving the frontend and handling API requests. Model credentials stay in server-side environment variables rather than being exposed in browser code.

GitHub

The project is open source, with the implementation available for others to inspect, learn from, and extend.

Resilient by design

If inference is unavailable or the model returns an unusable response, TouchGrass can fall back to a curated library of missions. The core experience doesn't have to disappear just because an external AI service fails.

What makes it different?

Most AI products encourage you to ask another question, generate another response, or stay for another session.

TouchGrass explores the opposite approach:

Generate one useful idea. Take it into the real world. Close the tab.

It's a small experiment in making AI useful beyond the screen, with lightweight personalization and a deliberately simple interface.

What's next?

I'd love to explore knowledge-graph-based personalization, where interests, learning goals, and completed missions connect to produce more relevant suggestions over time — without requiring a complicated user profile.

Other possibilities include better mission-quality evaluation, more personalized recommendations, and measuring whether people actually complete the activities.

Try it. Build on it. Touch grass.

Live app: https://t0uchgrass.onrender.com/

GitHub repository: https://github.com/SachchitNesarikar/hacktober-26

Built as an open-AI experiment with Gemma, Hugging Face, Render, and GitHub.

The goal isn't to keep you here longer.

It's to help you find something worth doing out there.

I Built a Memory for My Friend

Sachchit — Mon, 05 Oct 2026 06:56:14 +0000

I was excited for the HacktoberFest Weekend Challenge, but there was one problem: I didn't have a friend to build for.

So I messaged my GPT for some good projects. I picked one, developed the idea with GPT, and then passed it over to Claude to actually build. A few prompts later, broke me hit the free-tier rate limit.

And suddenly, my "friend" couldn't continue. If I switched to another AI, I had to explain everything again: what we were building, why we made certain decisions, what we'd already tried, what had failed, and what I had explicitly asked it not to change. And when Claude became available again, I'd have to bring all of that context back.

I didn't need another AI.
I needed my AI friend to remember.

So I built Baton.

What I lost when the chat ended

I wasn't really losing a conversation. I was losing the project's state:

Decisions, and why — why we chose one approach over another
Dead ends — approaches we'd already tried and abandoned
Rules — constraints and conventions that shouldn't be changed
The half-finished task — and the bug I'd deliberately postponed

A new assistant doesn't know any of that.Pasting the entire transcript is slow and noisy. The new AI can cheerfully retry the failed idea, or "improve" the one thing I explicitly said to leave alone. Existing tools mostly move the transcript between assistants.

I wanted to move the state.

The idea

conversation
      ↓
local open-weight model
      ↓
structured project state
      ↓
handoff for any AI

Baton reads a conversation and fills a fixed schema instead of producing another generic summary:

{
  "goal": "...",
  "architecture": [],
  "decisions": [{"what": "", "why": ""}],
  "constraints": [],
  "user_preferences": [],
  "files": [{"path": "", "note": ""}],
  "recent_changes": [],
  "failed_attempts": [{"what": "", "why_failed": ""}],
  "known_bugs": [],
  "open_tasks": [],
  "do_not_change": [],
  "current_state": "...",
  "next_action": "..."
}

The split between decisions, failed_attempts and do_not_change is the heart of it.

Those are exactly the things a new AI can get wrong if it only sees a transcript. If a later message reverses an earlier decision, only the latest truth is kept. Baton then renders a handoff tuned for the target: XML sections for Claude, Markdown for Gemini and GPT, a compact format for small local models, or an AGENTS.md.

Every handoff ends with rules for the receiving AI:

Treat do_not_change as binding.
Don't repeat failed attempts.
Ask instead of guessing.

The goal isn't to make another summary. It's to make the next AI feel like it was there.

Why open-weight and local is the point

Your project history contains your architecture, your mistakes, and sometimes your secrets. It seems wrong to send that to yet another service just to keep your own context.

So Baton is designed around local extraction using an open-weight model:

Default: Gemma 4 E4B (Q4_K_M) through llama.cpp, downloaded from Hugging Face on first start.
Ollama, LM Studio, llamafile or any OpenAI-compatible server can also be used.
The model is instructed to produce the JSON schema, and the output is repaired and validated before reaching the UI.
Long chats are processed in chunks, with the running state fed back into subsequent extraction.

A hosted open-weight API is supported too, but the trade-off is simple: it stops being local-first.

Multi-agent mode for small models

A 4B model asked to fill 13 fields at once can miss things. So Baton has an optional multi-agent mode: four specialists each own a subset of the fields:

Archivist
Rules Keeper
Decision Analyst
Work Tracker

A Reconciler then fixes misfiled and duplicate items. There are also two safeguards:

If the Reconciler drops more than 30% of items, its output is discarded.
A deterministic check removes any filename that never appears in the conversation or git history.

You can also assign larger models to individual jobs using BATON_AGENT_MODELS.

[ADD YOUR ACTUAL EVALUATION RESULT HERE.]

Using it

Run bash scripts/run.sh to start llama.cpp, wait for the model, and open Baton. Docker is also supported with docker compose up -d --build.
Paste a conversation, or capture it with the browser extension.
Inspect the memory panel: decisions, constraints, failed attempts, do-not-change rules and open tasks.
Pick a target and generate the handoff.
Paste it into a fresh AI conversation and ask what the next task is and what must not be changed.

There's also Git awareness: point Baton at a local repository and recent commits and uncommitted changes can be included, so "recent changes" can come from repository facts rather than memory.

What's inside

Baton is intentionally small:

Plain Python with no pip dependencies
One static HTML page
A Manifest V3 browser extension
Support for Claude, ChatGPT and Gemini
24 tests against mock model servers
MIT licensed

Originality and credit

The space already has good tools.

Context-Bridge, for example, compresses transcripts into structured blocks through cloud providers. Other tools move raw sessions between coding agents or summarize conversations using your own API key.

Baton shares the broad problem, but not their code.

It's an independent implementation, and NOTICE.md lists related projects.

What I find most interesting about Baton's approach is the combination of:

the decision / failed-attempt / do-not-change split
local-first extraction
grounding checks against the conversation and git history

Honest limitations

I built Baton because I needed it, but that doesn't mean every part of it is solved.

I haven't run a rigorous benchmark across models; scripts/eval_models.py provides a rough keyword-overlap score rather than a full extraction-quality benchmark.
The browser extension's page selectors are fragile and will need maintenance when the target sites change.
The hosted demo is static and loads a reference state. Live analysis requires a local model.
Small models still miss items. The memory panel should be checked before handing the state to another AI.

What's next

This is only the beginning.

I'd like to add:

Importers for Claude Code and Codex session files
In-browser inference with WebGPU, so there is no local server at all
A verification step where the receiving AI restates the recovered state for the user to confirm
Better evaluation of extraction quality across different model sizes

And maybe, by the end of this challenge, my AI friends won't need me to introduce them to the project every time we switch between them. For now, Baton is my attempt to make project context portable.

Try it

Repo: : https://github.com/SachchitNesarikar/hacktober-26