DEV Community: Yuvraj Singh

Meet Moss: a 3D desktop sloth you can talk to. She does your chores and brags about it.

Yuvraj Singh — Sun, 25 Oct 2026 16:28:36 +0000

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

What I Built

The theme was "rewards laziness". So I did the laziest thing I could think of: I spent days building an AI so I would never have to right-click the recycle bin again.

Building her took far longer than the chores will ever take. I know. I'm committed to the bit.

Meet Moss 🦥, a small 3D sloth who lives on my taskbar. I talk, she listens, she thinks, she answers out loud, and when I ask nicely she does the boring stuff.

What she does for me right now:

Empties the recycle bin. She tells me how many items and how much space first, then waits for a "yes". It's permanent and I have trust issues.
Takes notes and reads them back. Ask "what did I note today?" and she summarises the day out loud.
Skips songs (next, previous) and changes the volume ("a little quieter", "a lot louder", mute).
Keeps a lazy score. Every chore she does gets counted, with an estimate of the time saved, and then she brags:

"That's 11 chores and about 9 minutes today. I'm proud of us."

Rewarding laziness is the whole challenge, so I put it in the product itself. Moss is lazy, proud of it, and keeps receipts.

She is also just a good desktop pet. She sits on my windows, follows my cursor with her eyes, dances when my music plays, and falls asleep if I go quiet for too long. Extremely on theme.

Who gets to be lazier? Me, mostly. And anyone who has ever lost a fight with the Windows volume slider.

Demo

Code

Github

How I Built It

Everything runs on my own PC. No cloud, no API keys, no "your sloth is currently unavailable".

Job	Open model / tool
Ears	Whisper large-v3-turbo
Brain	Gemma 4 (e4b) through Ollama
Voice	Kokoro-82M, a Japanese girl voice speaking English, because it's adorable
Body	Electron + three.js + three-vrm: a see-through, always-on-top window that is click-through everywhere except the sloth

Credit where it's due: the 3D character is "Zainab-Chan" by mimenn_, from VRoid Hub. I didn't make her and I'm not allowed to redistribute her, so she's not in my repo (the README explains how to download her). The voice, the brain, the chores and the code that moves her are mine.

The part I'm proud of: two brains, one bouncer

Letting an LLM decide everything would be slow, and a little scary. What if it empties the bin because I muttered "I should clean up"?

So Moss works like a club:

The bouncer (a strict matcher) handles clear commands instantly. "Next song." "Empty the recycle bin." No thinking, no delay.
The friend who gets you (Gemma) only steps in when something sounds like a command but isn't clear, like "flip to the following song". Gemma has to answer with a JSON verdict (Ollama structured output), so she can't ramble her way into deleting something.
Everything else is just chat. "Skip the intro" and "what's the next song on that album?" never trigger a chore.

I measured it instead of guessing

I wrote a script that throws 60 different ways of saying each of 9 commands at Moss (540 phrasings), plus 60 normal sentences that must not trigger anything.

Command	Strict matcher	Strict + Gemma
recycle bin	57%	98%
take a note	67%	92%
next song	57%	98%
previous song	58%	100%
volume up	70%	85%
volume down	68%	83%
mute	72%	87%
read my notes	85%	93%
lazy score	92%	92%
All commands (540)	69%	92%
Normal sentences wrongly treated as a command (of 60)	0	1

Gemma took Moss from "gets about two thirds of how I talk" to "gets about 9 in 10".

Where she still struggles: volume and mute are the weakest (83 to 87%), and Gemma let one normal sentence through as a command. 1 in 60. I'm reporting it anyway, because a sloth should be honest.

She's careful in other ways too. She only presses the media keys while Spotify is running, so she can't skip my YouTube by accident. The link between her body and her brain is localhost-only and needs a random token.

Why Does Open Innovation Matter?

A sloth who can empty my recycle bin and read my notes is basically a tiny surveillance device with great manners. I did not want her sending my voice, my notes and my file activity to somebody else's server.

Open models made that easy to avoid:

My voice and notes never leave my PC. Whisper, Gemma and Kokoro all run locally, so privacy is the default, not a setting.
I could build the "understanding" step around the model. Structured JSON output from a local Gemma is what lets a strict matcher and an LLM work as a team. I could also measure it, rerun it and fix it, which is hard to do with someone else's black box.
I picked her voice by ear. I auditioned a few Japanese voices and kept my favourite in minutes. No vendor, no sign-up.
No API bill, no rate limit, no outage. Moss never has a "service unavailable" day. Just regular sloth days.

The Lazy Payoff

Here is how Moss's time savings are counted. I wrote down how long each chore takes me by hand, and she adds them up:

These are estimates, not stopwatch readings. Treat her score as "roughly this lazy". She doesn't claim more.

The real payoff isn't the seconds. It's that I can say "volume down", "next song" or "take a note" without leaving whatever I'm doing, and it just happens.

What's Next: the big lazy idea

Right now every chore in Moss is hand-coded. One chunk of code for the bin, another for notes, another for Spotify. That is... not very lazy. 😅

The plan is to stop writing features one at a time. I want a proper framework so Moss can work with software on her own, and a new chore is something she figures out, not something I write at 2am. Think "Moss, rename these screenshots" or "Moss, clean up my Downloads folder", with her working out how to do it safely, asking before anything permanent, and telling me what she did.

The "ask first before anything permanent" habit from the recycle bin stays exactly as it is.

A word from Moss

"Thank you for reading all the way down here. That was a lot of effort. I'm going to take a nap now."

Prize Categories

Best Use of Gemma. Gemma 4 is the brain of Moss. It is the fallback that understands loose, human phrasing and answers in strict JSON, it writes the spoken summary of my notes, and it does the talking when I just want to chat. In my test it lifted command accuracy from 69% to 92% across 540 phrasings.

Thanks for participating! 🦥

Your turn 🦥

I'd love your take on these:

What's the one boring PC chore you'd hand to a voice assistant first? I'll build the best answers into Moss next.
Should she interrupt me when something looks wrong, or wait until I ask? I'm planning a version that notices suspicious processes, and I can't decide.
What's the least useful thing you've spent days automating? Mine is a recycle bin, music, taking notes, summarizing my notes next thing in morning.

The part I'm least sure about: Gemma lets 1 in 60 normal sentences through as a command. If you've handled that better, tell me how.

I Built an AI That Scores Sensitive Data Entirely Offline - No Cloud, No Data Leaks

Yuvraj Singh — Fri, 16 Oct 2026 14:48:02 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Airgap is a desktop-style web dashboard that turns a spreadsheet into risk scores, with no cloud, no training run and no data scientist. You drop in a CSV or Excel file, pick one of three jobs, and TabPFN (Prior Labs' tabular foundation model) scores every row on your own GPU. A local LLM then writes the one-page summary. Nothing leaves the machine.

The problem

Small teams sit on small, sensitive tables: a few hundred to a few thousand rows. The tools that would help them either need a data scientist to tune a model, or they send the data to a cloud service they are not allowed to use.

Who	Their table	Why the cloud is off the table
Clinical labs and researchers	Patient records with lab markers	Patient privacy rules (HIPAA / GDPR)
Small plants and machine shops	Batch records with temperature, vibration, purity	Operational data they will not put on someone else's server
Credit unions and micro-lenders	Past loan outcomes	Credit and financial privacy rules (FCRA / GLBA)

Who would pay

The buyer is whoever holds the table and cannot upload it. My hypothesis for the side hustle: one person installs Airgap on a clinic, plant or lender's own machine and charges per site or per seat. This is untested. I have not sold it yet, and the licensing note in "Why Open Innovation Matters" applies before anyone charges for it.

The three modes

Mode	You get	Built-in demo data
🩺 Clinical risk	Risk score and tier per patient, the three columns that moved each score, a one-page clinician summary	Synthetic patients, or real hospital readmission data
🏭 Industrial yield / failure	Expected yield with an 80% range (flags batches that fall outside it), or a machine-failure score	Real semiconductor sensor data, synthetic machine-failure data
💳 Credit default	Default risk, approve / review / decline bands, a cutoff slider, reason codes, an approvals-vs-bad-loans chart	Real credit-card default data

Decision support, not a decision-maker. Scores should never replace a clinician, an engineer or a credit committee. The dashboard says so, and so do the generated summaries.

Demo

What the demo shows: loading real hospital data, pressing Score it, and getting scored rows, tiers, drivers and a written summary, all on a laptop RTX 4090 with the network unplugged.

Real result: hospital readmission

Real data: Diabetes 130-US Hospitals (UCI, CC BY 4.0), 8,000 rows and 47 columns. 7,800 rows have a known outcome. 200 have a blank outcome and are scored as "new patients".

Metric	Value	What it means
Cross-validated AUC	0.67	0.5 is a coin flip, 1.0 is perfect
Event rate	12%	Share of known patients readmitted within 30 days
Top-decile lift	2.4x	The top 10% of scores hold 2.4 times the overall event rate
Run time	269 s	Full pipeline on a laptop RTX 4090 (16 GB): 5-fold CV, final fit, explanations, summary

I am showing this number on purpose. Readmission is a noisy outcome, and an AUC around 0.67 is realistic for it. A dashboard that reported 0.99 on this data would be hiding a leak. Known rows are always scored out-of-fold, so a patient's own outcome never helps score that patient.

The strongest driver, number of prior inpatient visits, is also the best-known predictor for this dataset, which is a useful sanity check. The model drivers show influence on the score, not causation. For example, "A1C result missing" mostly reflects who gets tested.

Code

https://github.com/YuvrajSHAD/Airgap

airgap/
├── server.py            FastAPI app, job queue (one analysis at a time keeps the GPU predictable)
├── app/
│   ├── engine.py        TabPFN wrapper: picks CUDA when torch sees it, exposes GPU name to the UI
│   ├── analysis.py      CSV -> features -> cross-validation -> final fit -> explanations
│   ├── narrative.py     local LLM summary with a number guardrail + template fallback
│   └── samples.py       synthetic demo data
├── static/index.html    the whole UI: one file, loads nothing from the internet
├── prepare_datasets.py  downloads and cleans the four real datasets
├── check_gpu.py         times a real TabPFN run on the GPU and caches the weights
├── install.bat          CUDA build of PyTorch, dependencies, GPU check
└── run.bat              starts the server offline

Run it (Windows, NVIDIA GPU): run install.bat once while online, then run.bat. After the first weight download, it starts in offline mode.

How I Built It

Stack: TabPFN (3.5 weights) · PyTorch with CUDA 12.8 · FastAPI · pandas and scikit-learn · Ollama running qwen3:8b · a single static HTML page.

1. TabPFN does all the scoring. There is no model to train and no hyperparameters. Your known rows are the context, and TabPFN predicts from them in one forward pass. Classification gives calibrated probabilities. Regression gives a prediction plus an 80% interval, which powers the yield mode's "outside the expected range" flag.

2. Honest accuracy by default. Rows with a known outcome are scored by 5-fold cross-validation (3-fold for very large files). Rows with a blank outcome are scored from everything known. The dashboard's accuracy numbers come from the first group, so they are not flattered by memorization.

3. Explanations by occlusion. For the 10 columns most related to the outcome, I swap in a typical value and watch the score move. The columns that move it most are listed per record, with an up or down arrow.

4. A local LLM that is not allowed to invent numbers. qwen3:8b writes the summary through Ollama from a small JSON of facts. Every number in its text is checked against the results. If the model cites a figure that was not in the facts, the summary is rejected and a built-in template is used instead. The page tells you which one you got and why.

5. Cleaning real data without cheating. prepare_datasets.py drops columns that give away the answer (for example, the five failure-type columns in the machine dataset), removes patients who died or went to hospice (they cannot be readmitted), keeps the best-filled sensors without looking at the outcome, and blanks the outcome on the last rows so the "new rows" path is exercised.

Three things that broke (and what they taught me)

"It uses my CPU, not my 4090." pip install torch on Windows gives the CPU-only build, and pip happily treated an existing CPU build as "already satisfied". The fix was a forced reinstall of the CUDA 12.8 build. No CUDA Toolkit is needed, only the NVIDIA driver. The top bar now shows the GPU name, or a red "CPU only".
TabPFN's browser licence login crashed inside a .bat file on Windows. The scripts now read an API key from a local file and turn the browser flow off.
The LLM summary silently fell back to the template. My model-name check matched on a prefix, so a different model of the same family counted as "installed". Now the check is exact, and the page states the reason whenever the LLM is not used.

Honest limits

TabPFN is slower per run than a gradient-boosting model. Its value is near-best accuracy with zero tuning, not speed.
My timing on the 8,000-row file is 269 s. Smaller tables, which are the intended use, are much faster. In my GPU check, a 1,500-train / 500-test fit and predict took 1.34 s once warm.
Results come from cross-validation on public datasets, so they show how the model does on held-out rows from the same source. I have not tested on data from a different hospital, plant or lender, so a new site’s numbers could differ.

Why Does Open Innovation Matter?

Because the whole product is a promise: your data never leaves your computer. A closed API cannot make that promise.

Open weights make the air gap real. TabPFN's weights sit on the local disk. After a one-time download, Airgap runs with the network off, and telemetry is disabled. A hosted prediction API would mean uploading patient records, plant telemetry or loan histories.
Zero cost per prediction. Score ten rows or ten thousand and nothing is metered.
Swappable parts. The summary model is one setting (LLM_MODEL). Any Ollama model works, and the guardrail keeps whichever one honest.
Inspectable. A clinic's IT team can read the code, see that nothing phones home, and decide for themselves.

A caveat I want to be upfront about: TabPFN's weights are open-weight under Prior Labs' licence. The free licence is non-commercial, so selling Airgap would need a commercial licence from Prior Labs. This is a hackathon prototype, and checking that licence is the first step of the side hustle.

Prize Categories

Best Use of TabPFN. TabPFN is the engine for all three modes and the only thing producing scores: classification probabilities, regression with 80% intervals, categorical and missing-value handling without preprocessing, and a CUDA path on a local RTX 4090. It runs on real public datasets with honest out-of-fold evaluation. The local LLM only narrates results, and its text is checked against them. Note: TabPFN is the core of a dashboard, not an MCP-driven prediction agent.

Elsewhere: Meet Your Friends In your Free Time

Yuvraj Singh — Fri, 09 Oct 2026 04:59:00 +0000

Elsewhere — Don't Remind Me. Give Me a Reason.

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

🚀 Try It and Explore the Code

Live demo: https://sidequest-touchgrass.onrender.com/
GitHub repository: https://github.com/YuvrajSHAD/touchgrass-ai
Hugging Face Space: https://huggingface.co/spaces/zoroxR/elsewhere-qwen

The web app is deployed on Render. Although the Hugging Face Space and local inference integrations have been tested separately, the active AI provider in the public deployment has not yet been verified.

Less time deciding what to do. More time actually doing it.

🌱 The Idea

We don't need another app telling us to go outside. Most of us already know we should.

The harder part is deciding what to do with the free time we have.

You're sitting at your laptop, scrolling on your phone, and a simple question comes up:

Okay, what should I actually do?

I built Elsewhere around a different idea:

Don't just remind people to go outside. Give them a reason to.

Imagine you're into photography, have 30 minutes free, and a friend happens to be nearby. Instead of throwing fifty activities at you, Elsewhere uses that context to suggest one small, actionable outdoor quest.

The AI isn't the destination. The outside world is.

⚡ How It Works

flowchart TD
    A["Your interests"] --> D["Elsewhere"]
    B["Time available"] --> D
    C["Nearby friend context"] --> D
    D --> E["Generate one outdoor quest"]
    E --> F["Close the app"]
    F --> G["Go do something"]
    style D fill:#d9f99d,stroke:#3f6212,color:#1a2e05
    style G fill:#bbf7d0,stroke:#166534,color:#14532d

Three inputs. One suggestion. No endless feed.

For example:

Your friend is nearby, and you both have 20 minutes. Meet up and explore somewhere you wouldn't normally go.

The intended experience is simple:

Open Elsewhere.
Get a reason.
Close the app.
Go outside.

🛠️ The Technical Architecture

Elsewhere is a Progressive Web App (PWA) backed by Node.js and Express. Its suggestion pipeline supports hosted Hugging Face inference, optional local inference through llama.cpp, and a deterministic fallback.

flowchart TD
    U["Browser / PWA"] --> API["Node.js + Express"]
    API --> CTX["Build suggestion prompt<br/>Interests · Duration · Friend context"]
    CTX --> HF{"Hugging Face<br/>Space configured?"}
    HF -->|Yes| HFI["Qwen3 1.7B<br/>ZeroGPU inference"]
    HFI -->|Usable response| OUT["Clean suggestion"]
    HFI -->|Failure / no usable text| LOCAL{"Local LLM configured?"}
    HF -->|No| LOCAL
    LOCAL -->|Yes| LLAMA["llama.cpp<br/>OpenAI-compatible API"]
    LLAMA -->|Usable response| OUT
    LLAMA -->|Failure / no usable text| FALLBACK["Deterministic fallback"]
    LOCAL -->|No| FALLBACK
    OUT --> RESP["Return suggestion"]
    FALLBACK --> RESP
    RESP --> U

The diagram describes the backend's intended provider-selection and fallback logic. It does not establish that every path works in the deployed Render environment.

The stack

Layer	Technology	Purpose
Frontend	HTML, CSS, JavaScript, PWA	User experience
Backend	Node.js, Express	API and suggestion orchestration
Hosted AI	Hugging Face Space	Qwen3 inference
Local AI	llama.cpp	Local OpenAI-compatible inference
Model	Qwen3 1.7B	Generates short outdoor suggestions
Deployment	Render	Hosts the web app and backend

🧠 Following a Suggestion Through the System

Here's the request lifecycle in a little more detail.

sequenceDiagram
    participant U as User
    participant W as Web App
    participant S as Express Server
    participant H as Hugging Face
    participant L as Local llama.cpp

    U->>W: Select interests and available time
    W->>S: POST /api/suggestion
    S->>S: Build contextual prompt
    alt Hugging Face configured
        S->>H: Request Qwen3 suggestion
        H-->>S: Inference result
    else Hosted provider unavailable or unusable
        S->>L: Try local inference if configured
        L-->>S: Model response or failure
    end
    S->>S: Clean result or use fallback
    S-->>W: Return suggestion
    W-->>U: Display one outdoor quest

The server owns provider selection and response handling. The browser doesn't need to know which model generated the suggestion.

That separation also makes it possible to test inference independently of the public deployment.

🔬 What I Actually Tested

I wanted to distinguish a working integration from an architecture that merely looks good on paper.

Test	Result
Local llama.cpp health endpoint	Passed
Local app → llama.cpp suggestion request	Passed during testing
Local app → Hugging Face Space inference	Successful response observed
Hugging Face Space direct demo	Tested successfully
Full browser and geolocation flow	Not fully verified
AI inference through the public Render deployment	Not verified

One successful hosted-inference test returned:

Find a quiet spot to do calisthenics and enjoy the breeze.

The local integration also returned a model-generated response through the app's suggestion endpoint.

These checks confirmed that both inference paths could produce responses during their respective tests. They don't prove continuous availability or successful inference on every request.

🔌 Why Open-Weight AI?

I wanted to explore what a small, focused application could do with open-weight AI without making every interaction dependent on a closed, hosted API.

Using Qwen3 with a Hugging Face Space gives the project a hosted inference path. Supporting llama.cpp also gives me a way to run inference locally through an OpenAI-compatible API.

The trade-offs are different:

Hosted inference: Easier to access without running a model on your own machine, but dependent on service availability and usage limits.
Local inference: More control over where the model runs, but requires a compatible server and sufficient local resources.
Deterministic fallback: Keeps the suggestion flow useful when a model isn't configured or returns no usable response.

flowchart LR
    A["Suggestion request"] --> B{"Inference available?"}
    B -->|Hosted| C["Hugging Face + Qwen3"]
    B -->|Local| D["llama.cpp + Qwen3"]
    B -->|Neither| E["Fallback template"]
    C --> F["One suggestion"]
    D --> F
    E --> F

For this project, AI is a means to an end. It should make the suggestion more relevant, not turn a five-minute decision into a twenty-minute conversation.

🔒 Privacy and Product Decisions

Elsewhere is deliberately designed to resist becoming another attention-consuming product.

No endless feeds.
No streaks or gamification loops.
No notification loops.
No endless AI conversations.
Nearby-friend context is intended to help people make plans, not encourage constant checking.

The current backend uses in-memory state for group and presence data, rounds location information, and expires presence after a limited period. The exact privacy properties still depend on the implemented flows and deployment configuration.

The guiding principle is simple: help people spend less time on the screen, not more.

🧪 My Agent Session

I used DevRelay to document the repository architecture, trace the suggestion-generation flow, and test the local LLM integration.

The session separates source-code findings from results verified through live local checks, while identifying behavior that remains untested.

Tracing Elsewhere's Local LLM Suggestion Flow

You

Inspect my existing Elsewhere project read-only. Trace suggestion generation, the local LLM integration and fallback, check local model status, and if practical perform a harmless suggestion-endpoint test. Do not read .env, reveal secrets, modify project files, or publish. Separate source-verified findings, live test results, and unverified behavior. Show the detailed findings and proposed transcript before saving.

Agent

▸ inspect_project_read_only Read README.md, web/package.json, web/server.js, web/.env.example, llm/README...

Input

Read README.md, web/package.json, web/server.js, web/.env.example, llm/README.md; inspect web/public/app.js only to trace client suggestion and nearby-context flow; inspect llm/models filenames only. Do not read .env.

Output

Source inspection: README names the project Elsewhere - TouchGrass and describes a local-first PWA for friend proximity, saved interests, and outdoor side quests. web/package.json specifies Node >=20, ES modules, Express 5, start=node server.js and dev=node --watch server.js. server.js serves public assets and JSON APIs, defaults to port 3000, stores groups/members in an in-memory Map, rounds coordinates to three decimals, and expires presence after 10 minutes. In public/app.js, makeSuggestion obtains nearby results, then sends interests, duration, and nearbyFriend to POST /api/suggestion. The normal nearby lookup obtains geolocation and posts presence, which updates in-memory state; this path was not used in the smoke test. POST /api/suggestion normalizes interests, limits them to 12, defaults duration to 20 and clamps it to 5-180, then calls llmSuggestion. With no LLM_BASE_URL it returns a deterministic template. With a base URL it posts to {LLM_BASE_URL}/chat/completions, passing model, available time, interests, and nearby-friend context in a prompt asking for one short actionable outdoor quest. Non-2xx/network/timeout errors are logged as LLM ERROR and use the template; empty model text also uses the template. LLM_TIMEOUT_MS defaults to 15000 ms. .env.example shows port 3000 and example LLM_BASE_URL http://localhost:8080/v1; the real .env was not opened. llm/README.md documents llama.cpp POST /v1/chat/completions at localhost:8080/v1 and says no cloud inference; it does not specify a concrete server launch command, only to use the command appropriate to installed llama.cpp and model. llm/models contains only .gitkeep. README web run steps are cd web; npm install; cp .env.example .env; npm run dev. No project files were changed.

▸ safe_local_live_checks GET the local llama.cpp health and model-list endpoints. Temporarily start th...

Input

GET the local llama.cpp health and model-list endpoints. Temporarily start the existing Node web server, inspect its health response, POST synthetic sample data only to the stateless /api/suggestion route, capture the returned suggestion and whether an LLM error was logged, then stop the temporary server. Do not call location or presence endpoints.

Output

Live checks: llama.cpp GET /health returned HTTP 200 and {status: ok}; GET /v1/models returned HTTP 200 with two model entries (identifiers omitted). The web server was initially not listening. It was started temporarily; GET /api/health reported llmConfigured=true. A stateless POST /api/suggestion with interests=[birdwatching], duration=20, nearbyFriend=true returned: Your friend could join you in chasing the early morning song of a flickerfoot butterfly. This differs from the deterministic template for the sample and no LLM ERROR was logged, verifying the local model was reached through the app. No real location, circle, or presence endpoint was used. The temporary app process was stopped.

Verified from source: the documented local web run steps are cd web, npm install, cp .env.example .env, npm run dev. The local LLM README expects llama.cpp at localhost:8080/v1 and does not supply one specific launch command. Verified live: llama.cpp health was OK, two model entries were listed, and the app returned a model-generated suggestion with llmConfigured=true and no LLM error. Not tested: full documented install/run flow, real browser/geolocation/circle flow, and the public Render deployment. Render AI configuration was not inspected, so no claim is made about its provider. The actual .env, credentials, and private paths were not read or included. No project files were changed.

🏆 Prize Categories

Render — Best Use of Render: Hosting the Elsewhere web app and backend on Render.
ElevenLabs — Best Use of ElevenLabs: Generating AI narration for the Elsewhere product demo.
Entire — Best Use of Entire: Sharing the DevRelay session documenting Elsewhere's architecture and local LLM integration.
GitHub — Best Use of GitHub Copilot: Using Copilot to inspect the codebase, trace suggestion generation, and test the local LLM integration.

🌍 What's Next?

The next step is to verify the full deployed inference path and browser experience, then continue refining how the app turns a person's interests and available time into a genuinely useful suggestion.

The goal isn't to build the biggest AI application.

It's to build one that gives someone a good reason to close it.

Less scrolling. More elsewhere.

If you try it, I'd love to hear: Would one personalized outdoor suggestion actually get you off your screen?