DEV Community: Aditya

Dead Frequency: a ghost in the machine, with a fuse box

Aditya — Sat, 31 Oct 2026 19:29:40 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

One of the strangest bugs in Dead Frequency was a ghost that had become too polite. The engine stores health from 0 to 1; the director API expects 0 to 100. At 75% health, the engine sent 0.75. The low-health guard compared that with 30, treated a healthy player as nearly dead, and downgraded every proposed hunt. Nothing crashed. The types were right, the units were wrong, and the tension disappeared at the boundary.

Dead Frequency is a short survival-horror game about an abandoned facility, three dead relays, and an emergency operator that should not still be answering. You restore the relays, avoid the creature, and decide whether to release the voice or shut it down. It is Next.js, TypeScript, and Canvas 2D, not 3D.

I wanted the AI to be a voice in the game, not the game itself. The shipped version makes no model calls. Every haunting event comes from a deterministic scripted fallback. The live Tinker path is tested against mocks, but it has never made a live request.

What I Built

You start in the arrival bay of a facility whose emergency channel is still open. Three relays are dark, and the exit gate opens only when all three are restored. Between you and the relays is a creature that sees your flashlight from farther away and hears sprinting from farther than a walk.

The loop is small. Restore three relays, avoid the creature, reach the console, then choose. The arrival bay is a sanctuary where the creature's senses are masked. The rest of the facility is not.

The map is seeded, with five rooms, corridors, props, relays, and the console, all checked for solvability. The creature wakes after your second room or thirty seconds. It follows the walkable graph, so it can lose you but cannot walk through a wall or teleport.

The HUD shows integrity, stamina, threat, relay pips, room, and clock. Pause, death, choice, and ending screens are included; touch devices get a stick and buttons.

The scene is drawn and sounded in the browser: Canvas 2D passes for walls, floors, fixtures, relay glow, the creature, and grain; oscillators and filtered noise for audio. No remote art or sound files are downloaded. Audio starts after a click and can be muted.

Demo

There is no hosted demo. I have not deployed this build, and a render.yaml file is not a live URL. It runs locally with two commands, no API key:

npm ci
npm run dev

Open http://localhost:3000. Without Tinker configuration, the director badge reads fallback, and the radio feed labels each scripted event as fallback.

The 46.4-second clip shows the title, movement, flashlight, one real relay restoration, the labelled fallback radio feed, and pause. It is not a full playthrough: the other two relays, a creature encounter, death, and both endings are not shown. Those progression outcomes have simulation coverage, not video evidence.

Every director request in this capture was intercepted with a scripted fallback response; no live model was called. The narration is an offline macOS Samantha voice. The quiet background bed is locally synthesized, not captured game audio. English captions, the transcript, and capture notes are included.

Paused	Narrow screen

Code

Repository: puri-adityakumar/dead-frequency. It is currently private.

Start here:

src/shared/contracts.ts: the game/director boundary, including health units.
src/game/sim.ts and src/game/render.ts: simulation, creature, endings, and Canvas lighting.
src/game/lighting.ts: the flashlight ray fan that stops at walls and sealed gates.
src/lib/director/policy.ts: action whitelist, room/intensity ownership, low-health hunt downgrade.
src/lib/director/tinker.ts and src/components/directorClient.ts: one-shot adapter, client timeout, labelled fallback.
scripts/smoke.mjs and scripts/lighting-smoke.mjs: browser and lighting harnesses.

The code and this media package are in the private repository. I have not chosen a license or made a public release. There are no model weights or training code. The model's reply is parsed as JSON and mapped to an enum; it is data, not code.

How I Built It

The simulation is boring on purpose

The engine runs a fixed 1/60-second tick. The Canvas renderer reads the world without changing it, and the React HUD receives snapshots at most ten times a second. Movement and the creature use the same collision checks.

The map is seeded and tested for solvability. Rooms sit on a coarse grid, corridors connect them, and the exit gate is a full ring whose only crossing is the exit approach, so sealing it cannot strand a relay. The lighting check renders fourteen deterministic scenes: five rooms off and on, three relay-restored states, and the exit gate open. A directional probe also checks that the beam brightens the space ahead more than the space behind.

The latest lighting pass moved average floor luminance in those raw captures from roughly 15-26 to roughly 52-73 on a 0-255 canvas scale. It improved palettes and fixtures, added a player rim highlight, clipped the flashlight beam, and reduced stacked vignettes. The check asserts a minimum brightness, shadow detail, and contrast. That is a smoke threshold, not a visual review.

The 12-second lighting comparison shows three labelled, isolated renderer fixtures before and after the pass. It is silent and is not gameplay footage.

The director only speaks at milestones

The AI never runs in the frame loop. The engine emits five milestones: start, room_enter, relay_restored, near_death, and exit_ready. The browser sends a compact state with room, relays, health, flashlight, threat, milestone, and at most eight recent radio lines. There is no free-form prompt.

The client allows one request in flight, keeps only the latest pending milestone, and aborts after nine seconds. On failure, timeout, or invalid output, it generates its own radio line and marks it fallback. The game keeps playing.

On the server, Zod checks the request and response. The upstream call uses one fixed HTTPS endpoint, one attempt, no redirects, a five-second body deadline, a 64 KiB cap, and 120 output tokens. When live, the model returns {"action": "...", "message": "..."}. The action must be one of five: whisper, lights_flicker, false_alarm, hunt, help. The server chooses the room and intensity.

hunt is downgraded to whisper when health is at or below 30 or the milestone is near_death. The server's scripted fallbacks never use hunt and stay below 0.3 intensity. If the server itself is unreachable, the browser has a separate local whisper fallback. The model cannot directly change player health or position, teleport anyone, or permanently block progression. A hunt can temporarily sharpen the creature's senses and speed, so it still has gameplay consequences. The model cannot choose a URL or run generated code.

The boundary bug

The health mismatch passed type checking because both values are numbers. Integration caught it when the server policy and engine snapshot disagreed about the scale. The fix was one conversion in makeDirectorState and tests that assert the server receives 75, not 0.75, while the HUD stays fractional. This was an integration and mocked-policy bug, not a failure observed from a live model.

A model boundary is not only a prompt. It is units, enums, ranges, timeouts, and a rule for when the answer never arrives. The most useful safety feature here is not a sentence in the system prompt. It is the finite action list and server-owned room and intensity.

Parallel workstreams at max

I ran the build as parallel workstreams: simulation and Canvas renderer; React shell, HUD, touch, and Web Audio; director API and hardening; and an independent browser QA harness. Each owned separate files; the shared contract kept them aligned. I integrated and fixed the seams.

That split is why the health bug surfaced. The engine, UI, and server could each be correct alone and still disagree at the boundary. The QA workstream drove real Chrome with every director request intercepted, so no paid call could escape the browser.

Why Does Open Innovation Matter?

Once dependencies are installed and the local server is running, the scripted game needs no account, model key, or external service. Next.js, React, TypeScript, Node, and Zod are open components; Canvas 2D and Web Audio are browser standards. There are no remote art assets, so the look is editable source.

OpenCode, an open-source coding-agent harness, was part of the actual build workflow: GLM workers built the renderer and UI, alongside Droid workers for the director and QA. That is a real use of an open agent harness, not evidence of live AI inside the game. The bounded runtime director is still an adapter tested with mocks.

The model side needs a more careful sentence. Tinker is a hosted service. The repository contains an adapter and a strict contract, not open model weights. The account had zero checkpoints, and I did not train or fine-tune anything. I can show the source, fallback, validation, and tests; I cannot show a model result that does not exist.

I have not chosen a license for the app yet. A public repository without a license is source-available, not open source. I will not call it open source until that file exists. The same care applies to the supplied Dark Sector reference: it informed the concept, but I did not copy its code because the archive has no explicit redistribution license. The reference is excluded from Git. Credit and permission are part of the work, not paperwork after it.

The Ghost in the Machine

The theme usually points at a machine that escapes its box. I wanted the opposite: a ghost that is present, responsive, and bounded.

The director can whisper, flicker lights, send the creature toward a false alarm, sharpen a hunt, or help you catch your breath. It cannot rewrite the rules. The server owns room and intensity. The client owns the timeout. The engine owns damage and endings. The final choice belongs to the player.

The machine is haunted, but it has a fuse box. The ghost can make the facility feel less predictable without becoming the author of the run. When no model is present, the fallback still speaks in the same world, with an honest FALLBACK tag instead of a fake LIVE badge.

Limits

No live inference. The Tinker account had zero checkpoints. No real model call, training, or paid inference happened; the shipped game uses fallback.
No fine-tune result. No training, held-out evaluation, or baseline comparison. I am not claiming the Tinker fine-tuning category.
No hosted demo or deployment. The app runs locally. render.yaml is a blueprint, not a deployment. I am not claiming the Render category.
No public release or license yet. The linked repository is private, and the app is not yet licensed open source. Repository packaging and documentation updates are dated November 1, 2026; the README records their scope.
Tests are split. 56 unit tests, TypeScript, production build, fourteen deterministic lighting scenes, and 27 post-lighting Chrome smoke checks pass. The browser suite has no failures, warnings, skips, or blocked checks. Relay, death, and both endings have simulation coverage, but the short demo is not a full playthrough.
Scope. One creature, one facility, five rooms, no save system. The browser harness does not assert audio quality.
AI is optional. The live path is exercised with mocks, not a real checkpoint. Missing config, a busy gate, upstream error, or invalid output all produce the labelled fallback.

Prize Categories

I am entering the Ghost in the Machine challenge. I am not entering the Tinker fine-tuning category, because I have no fine-tune or measured improvement. I am not entering the Render category, because I have not deployed. If those change before submission, I will update this section and demo rather than quietly widening a claim.

Raincheck: the lazy, kind way to cancel a plan

Aditya — Sun, 25 Oct 2026 13:19:53 +0000

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

Cancelling a plan is a two-minute job that people stretch into an evening. You open the chat, type an apology, delete it, type a longer one, and then a second round of messages to agree on a new day. Most of us end up either over-explaining or going quiet. Raincheck is for the lazy middle path: say it once, say it kindly, offer one real next time, and let the other person answer with one click.

What I Built

Raincheck is a small writing desk for cancelling a plan without disappearing.

You fill in four short sections. Who it's for and what the plan was. One replacement time, with an optional city. Your note. Then two checkboxes: "I've read this" and "I understand anyone with the link can read it". Only then does Raincheck make a ticket: one unguessable link that expires in 30 days. You copy it and send it wherever you already talk to that person. Raincheck sends nothing.

The person on the other end opens the link and sees your note, the suggested time, and, if you picked a city, a real forecast for that day. They press Accept this suggestion, and that's it. There's an optional .ics file marked tentative, so the time can go into their calendar if they want it there. No account on either side. No invite. No calendar access.

Who gets to be lazier. The person cancelling skips the draft-delete-redraft loop and the "so when are you free?" thread that usually follows. The person receiving it skips the reply. A yes is one click. A no is just not clicking.

Kind, not sneaky. The desk keeps saying the same things in small print: only say what's true, don't invent illness or emergencies, the date is a suggestion and nobody's availability has been checked. There's a Theatrical tone for when you want to be silly, and it's labelled as a joke on both the draft and the ticket so nobody mistakes it for a real excuse.

The landing page is a WebGL fishing dock I made earlier, ported to React with the shader, palette, fish and Bayer dithering kept as they were. Move the pointer and the fish follow. Click and the water ripples. It pauses when it scrolls offscreen, and it stands still if your system asks for reduced motion.

Demo

A 55-second narrated walkthrough, recorded against a local build: write a note, pick Lisbon, see the real forecast, try AI drafting and get an honest "not configured", create the ticket, open it as the recipient, and accept.

There's no hosted demo yet. The repo has a Render blueprint (render.yaml, one Docker web service plus Postgres), but I haven't deployed it. It runs locally in two commands, shown below.

The recipient's view	After one click

Code

puri-adityakumar / raincheck

A small, open-source desk for cancelling plans kindly and offering one real next time. React + FastAPI, Open-Meteo forecasts, expiring share tickets, AI drafting off by default.

A small, open-source desk for calling off a plan honestly and offering one real next time.

Raincheck turns an awkward cancellation into one kind note and one concrete replacement time. You write and review the note, then create an unguessable, expiring link and share it yourself. The recipient opens it, sees the note and an optional real forecast, and accepts with one click. There are no accounts, no automatic messages, and no calendar writes.

Features

Writing desk with live preview. Recipient, plan, tone (Honest, Cozy, or a clearly labelled Theatrical joke), one replacement time, and your note. The ticket preview updates as you type.
Review before sharing. Two explicit checks are required: you have read the current note, and you understand anyone with the link can read…

View on GitHub

The parts worth opening first:

backend/app/services/tickets.py: token hashing, expiry, and the one-statement accept.
backend/app/services/weather_tokens.py: the signed forecast proof.
backend/app/services/generation/service.py: the open-weight model adapter, its prompt, and its output checks.
frontend/src/components/Composer.tsx: the writing desk and the review gate.
frontend/src/components/FishingDiorama.tsx: the dock.

How I Built It

It's one small service. A React 19 single-page app (Vite, TypeScript, Tailwind 4, Geist fonts bundled locally) talks to a FastAPI backend over /api/*. In production the same container serves both, so there's no CORS to configure. Storage is SQLAlchemy over SQLite locally. The Render blueprint points it at Postgres, which I haven't run against a live server yet.

The open data: Open-Meteo. City search and forecasts come from Open-Meteo's geocoding and forecast APIs. They're free and keyless, so there's no account and no key to leak. The server fetches the forecast for the chosen city and day, writes a plain summary like "Overcast, 17–25°C, 5% chance of rain", and signs it with HMAC-SHA256. The browser gets that signed proof and sends it back when it creates the ticket. The server checks the signature and the expiry before it puts any weather on the ticket. So a ticket can't show a forecast the server didn't fetch, and the attribution and fetch time are always printed next to it. If Open-Meteo is down, you get no weather, not invented weather.

The open-weight model: Qwen, through a Tinker adapter, switched off. This is the part I want to be plain about. Raincheck has an AI drafting boundary, POST /api/generate, built for small open-weight models. The adapter accepts only Qwen/Qwen3-8B, Qwen/Qwen3.5-4B, or Qwen/Qwen3.5-9B through Tinker's sampling API, with an optional tinker:// fine-tuned adapter path. It caps replies at 256 tokens, runs at temperature 0.5, allows two requests at a time, and never retries a paid call on its own.

The prompt treats every user field as data, not instructions. It forbids invented illness, emergencies, shared history, calendar access, or the other person's availability. It may mention weather only by quoting the signed summary word for word. Then the reply is checked anyway, after Unicode normalisation: no Markdown or HTML, no medical words, no "you're free then", no weather words outside the signed summary. A draft that fails comes back as a typed error, and the note box keeps whatever you'd already written. Even a draft that passes still needs the same two checkboxes before it can become a ticket.

All of that is tested offline against an SDK double. None of it has called a real model. Live inference needs AI_PROVIDER=tinker, a separate TINKER_ALLOW_PAID_INFERENCE=true, credentials, and the pinned SDK, and every one of those is off. So with the default settings the endpoint returns 503 ai_unavailable, the health check reports ai_generation: false, and the desk tells you so.

I'd rather ship a desk that says "write your own" than one that shows a canned sample and calls it AI.

The ticket. A share token is 32 random bytes from secrets.token_urlsafe. Only its SHA-256 hash is stored, so a copy of the database can't open anyone's ticket. Tickets expire after 30 days. Accepting is a single UPDATE … WHERE accepted_at IS NULL, so two people tapping at once, or one person tapping twice, record one acceptance and keep the first time. The private "anything to help with drafting?" field never leaves the composer. The ticket request strips it before it's sent.

The .ics file is STATUS:TENTATIVE, with no organiser, no attendees, and no METHOD, so no calendar treats it as an invitation. Names and notes in any script, emoji included, are folded safely.

Tests. ./checks.sh runs everything without network, installs, or AI calls: 234 backend tests, 32 adapter and tooling tests, and 66 frontend tests, plus Ruff, TypeScript, and a production build. Backend tests use throwaway SQLite databases and recorded Open-Meteo fixtures. The Docker image runs as a non-root user and refuses to start in production without a weather-signing secret.

I built it with a coding agent doing the typing. Separate workers owned the frontend, backend, and AI adapter, and an independent reviewer went through the result. That review found six real issues, including text in unusual Unicode forms slipping past the output checks, and an older database schema that would have broken group tickets. All six were fixed before I published.

Limits, said plainly.

AI drafting is off. No live model has generated a note, and I'm not claiming any quality numbers.
No fine-tune has run. The training script is a guarded dry run that refuses to spend money.
Not deployed. The Render blueprint exists. Live Postgres, rate limits, and platform log redaction are still to do.
One replacement time per ticket. No back-and-forth, no counter-proposal. That's on purpose, but it's still a limit.
Anyone with the link can read the ticket. The desk says so before it makes one.
Forecasts only reach about two weeks out. For a date further away, the ticket has no weather.
Older databases from an earlier build are refused at startup, not migrated. That's safer than guessing, but it's manual.

Why Does Open Innovation Matter?

Raincheck is built on things that are already open, so the expensive parts didn't need building.

The forecast is the clearest case. Open-Meteo is free and needs no key, so a tiny side project can show real weather without an account, a bill, or a secret in the repo. Because the data is open, the server can fetch it, sign it, and stand behind it. The rest of the stack is open too: FastAPI, SQLAlchemy, React, Vite, Tailwind, and the Geist fonts under the OFL. And .ics is an open standard, so "add it to your calendar" didn't need a Google or Microsoft integration.

The model side is about what happens when I turn it on. A cancellation note is small, personal text: a name, a plan, sometimes a reason. With an open-weight model, I choose which model reads it and where it runs, and I can swap it. Qwen 3.5 4B is plenty for a 700-character note. I can also fine-tune it on a small, consented set of honest notes, so it learns "no fake excuses" from examples and not only from a prompt. A closed API gives me none of those choices: not the weights, not the version, and not a guarantee the model won't change underneath the safety checks.

There's one more reason, and it's why I'm comfortable shipping with AI switched off. Because the model is just one swappable part behind a gate, the app doesn't depend on it. The desk works fully without a model. It doesn't fake one. And it's ready for an open model the day I decide to pay for inference.

The Lazy Payoff

For the person cancelling, the payoff is one message, not a thread. You write it once, with the new time already in it. For the person receiving it, a yes is one click and needs no reply.

For me, the lazy payoff was everything I didn't build. No weather service, no calendar integrations, no messaging, no accounts, and no dependency on a closed model. Each of those is a whole project with its own bugs and secrets, and an open piece or an open standard covered it.

I haven't timed anyone using it yet, so I won't put a number on it. The honest version: if you've ever spent twenty minutes on a two-line cancellation, this is for you.

Prize Categories

I'm not entering a partner category this week. Raincheck has a Render blueprint, but the app isn't deployed on Render. Its open-weight adapter targets Tinker, but the Tinker category asks for a measured fine-tune against a baseline, and I haven't run one. The narration in the demo is Microsoft Edge neural text-to-speech (the Andrew voice), not ElevenLabs. I'd rather say that than claim categories I haven't earned.

Inkline — notes to diagrams, with Gemma, on your machine

Aditya — Sun, 18 Oct 2026 13:02:46 +0000

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

A lecture, a system sketch, or a photo of a whiteboard should become a diagram without a closed API ever seeing the notes.

What I Built

Inkline is a desk that turns notes into a diagram.

Paste lecture notes and you get a mind map. Paste “a client just asked for one more thing” and you get the decision as a flowchart. Describe a link shortener, an invoice, a launch week, or the service you are about to build, and you get an architecture diagram, a sequence, or a timeline. Drop a photo of a whiteboard or a page of handwritten notes and Gemma reads the picture. Under the drawing, “Change it…” takes a sentence like “add a Redis cache between API and DB” and updates the diagram in place, with undo, redo, and a short history. Simpler, Balanced, and Detailed change how much of the notes makes it onto the page. An open-weight model, Gemma 4 through Ollama, writes the Mermaid. The page draws it. You copy the source, copy a Markdown block for Notion, Obsidian, or GitHub, export SVG, PNG, or a vector PDF, or share a short link that opens the same drawing.

A switch at the top chooses where that model runs. Private, with a lock, means localhost Ollama: the notes stay on the machine. Cloud means Ollama Cloud. The server picks the provider from the request, so the same desk can do both. If Private is selected and Ollama is not running, the page says to start ollama serve and pull gemma4, instead of failing in silence.

Who would pay. The people already doing this by hand:

Students who rewrite a chapter as boxes the night before an exam.
Developers who have to explain a system and would rather not spend half an hour fighting Mermaid syntax.
Freelancers and small teams who drop a diagram into a proposal, a README, or a change order.

Running it yourself is free. That is the point of an open model: the notes never have to leave the laptop, and there is no per-diagram bill. Themes, picture input, edits, history, and export are in that free desk. The thing I would charge for is the hosted desk, for someone who wants it in a browser and does not want to install Ollama. ₹199 a month, or $5 a month, for Cloud Gemma, higher limits, picture-to-diagram, and the history of a drawing. A team plan would be one shared Cloud budget for a lab or a small group. The pricing page in the app shows those three plans. It does not take a card. Pro and Team are not on sale.

The tedious part is not the idea. It is getting a model to emit Mermaid that actually parses. Small open models are good at the shape of a system and bad at the punctuation. Inkline’s whole trick is a repair loop. If Mermaid rejects a draft, the parser error goes back to Gemma, and it tries again, up to three times. The drafts sit on the page, rejected ones included, so you can see what broke.

Demo

Live desk: https://inkline-lzyf.onrender.com

Six drawings Gemma made from real notes are in the gallery. Each link opens that drawing on the desk.

Code

Repo: InKline

The repair loop lives in src/lib/repair.ts, and the desk is one Next.js page.

How I Built It

Gemma 4 is the only model. There is no closed-model fallback.

Locally, the Next.js server talks to Ollama at http://127.0.0.1:11434, model gemma4. Cloud requests go to https://ollama.com with OLLAMA_API_KEY, usually gemma4:31b. The desk sends provider: "private" or provider: "cloud" on each draw, and the server resolves that to a base URL. A private request never attaches the cloud key, and the key is not in the client bundle or the health check. The same client speaks Ollama’s OpenAI-compatible /v1/chat/completions endpoint, and falls back to Ollama’s own /api/chat if that path is missing. Pictures use the images field on /api/chat, because Gemma 4 is multimodal. If that call is rejected, Inkline asks Gemma to describe the picture in words and then runs the normal repair loop on the description, and the page says that is what happened.

A picture is read once. Gemma lists the boxes and the arrows, and the desk shows that list as “Here's what I saw”: one row per arrow, with from, to, and a label. You can fix a row, add one, or remove one, and then press Draw. The drawing is made from those rows, not from a second look at the photo, so a wrong arrowhead is something you can see and correct before it becomes a diagram. The repair loop then rejects a draft whose arrows do not match the rows you confirmed. A chat edit sends the current Mermaid, the original notes, and the instruction through the same loop. Detail is a clause in the prompt: Simpler stays under about 8 nodes, Detailed keeps the secondary facts and stays under 24, and neither is allowed to invent facts that are not in the notes. The first draw from a picture stays Balanced, so the arrow check is not also fighting a detail edit. OLLAMA_REASONING_EFFORT=none keeps a thinking model from spending the whole reply on a thought trace and returning no diagram.

The prompt asks for one Mermaid fence and a specific diagram shape. The reply is rarely that clean, so extraction pulls the fence out of prose, generic code blocks, and Gemma’s thinking wrappers, and straightens curly quotes.

Then Mermaid parses it on the server. happy-dom is there because the parser expects a DOM. If parsing throws, that error string — the line, the token it wanted, the token it got — becomes the next user message, next to the broken source. The loop stops at three drafts, or sooner if one parses. The API streams each draft as it lands, so the page can show “Draft 1 was rejected” while Gemma is already on draft 2. If the browser’s Mermaid still disagrees with the server, that render error goes back too, using whatever attempts are left. A run that fails all three drafts leaves the previous drawing on the page. The rejected drafts stay in the rail so you can open them.

The page is Next.js, TypeScript, and Tailwind. Diagram types are auto, mind map, flowchart, sequence, architecture, and timeline. Architecture is drawn as a flowchart with subgraphs, because that syntax survives a small model better than architecture-beta. A share link is a compressed hash (lz-string) of the type, the Mermaid, and the edit history, plus the notes when they still make the link shorter. PDF export traces the SVG with svg2pdf, so the file is vectors rather than a JPEG stuffed into a page. The Paper theme’s sample drawing is a baked SVG, so the first paint does not boot Mermaid.

Tests mock the model. They check extraction, that a parser error is actually present in the follow-up prompt, that the loop stops at three, and that a dropped connection keeps the drafts already made. Playwright walks the desk twice, at a desktop width and at 375px, against that same mock: generate, edit and undo, keyboard use, export, the picture review, and the empty desk.

Limits, said plainly.

The public demo allows 10 draws a minute and 50 a day for an IP address, and 200 Cloud draws a day for the whole service (DAILY_CLOUD_LIMIT). Private draws do not count against that Cloud cap. Without Upstash, those counters live in the server’s memory and reset when the process does.
Notes cap at 20,000 characters. An edit is 500 characters. A picture is 4 MB, PNG, JPEG, WebP, or GIF. The model reply is capped around 2,500 tokens.
A hidden company field and a same-origin check sit in front of the draw API. They are speed bumps, not a login.
Detailed cannot add a service you did not mention. Simpler will drop a branch you might have wanted.
The PDF is one page. A very wide map is scaled to fit, not split.
Pro and Team are display only. Nothing on the pricing page charges a card.
Gallery previews are drawn in the browser. If Mermaid fails there, the link to the desk still works.
A picture is only as right as the arrow list you confirm. Draw uses those rows. It does not look at the photo again.

Accuracy note. The sample whiteboard was redrawn with gaps between the boxes and large arrowheads. The ink is Browser → CDN (HTTPS), CDN → API, API → Redis (cache), and API → Postgres (SQL). On 17 Oct 2026, three reads with gemma4:31b each returned those four directions and those labels. That is 3 of 3. The check stays on the page anyway: Draw uses the rows you confirm, and a wrong row is what gets drawn.

Render hosts the hosted desk. render.yaml points the service at Ollama Cloud, because Render has no local GPU. GET /api/health is the health check. Per-IP and daily rate limits keep a public URL from burning through the Ollama key, and the key never leaves the server.

Why Does Open Innovation Matter?

A diagram tool that sends every note to a closed API is a bad deal for the people this is for.

A student mapping a chapter does not want that chapter stored on someone else’s account. A freelancer sketching a client’s system is holding someone else’s architecture. Private is the default, with a lock on the switch: localhost Ollama, and the prompt stays on the machine. Cloud is a deliberate second position for someone who has not installed Ollama, using the same open model. A whiteboard photo and a handwritten page take the same path. The picture is another kind of note, not a reason to call a closed vision API.

Cost is the other half. The hosted price only works if inference is close to free. Gemma is open weight, so a month of diagrams does not depend on a closed model’s token price going up. I can swap gemma4:e2b on a laptop for gemma4:31b in the cloud, or a later fine-tune aimed at Mermaid, by changing OLLAMA_MODEL. The repair loop is the same either way. A closed API would charge for the failed drafts too, and I would not be allowed to tune the model when it keeps making the same bracket mistake.

Open is what makes the side hustle possible: private by default, cheap enough to run, and not stuck on one vendor’s model.

Prize Categories

Best Use of Gemma. Gemma 4, through Ollama, writes every diagram: mind maps, flowcharts, sequences, timelines, and architecture, including the picture path. Local tags (gemma4, gemma4:e2b, gemma4:e4b) and Ollama Cloud (gemma4:31b) are the same client. No closed model is called.
Best Use of Render. render.yaml deploys the Next.js desk. The hosted service uses Ollama Cloud because Render has no local GPU. GET /api/health is the health check.
Best Use of a .tech Domain. The live desk runs at [ADD .TECH LINK], pointed at the Render service.

While your build runs, walk

Aditya — Sun, 11 Oct 2026 16:13:53 +0000

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

What I Built

A GitHub Actions run already knows how long it is. You start it, and then you sit there, watching a bar that has already done the counting.

Build Break takes that length and puts it on the phone. You paste a public repository, press start, and the screen becomes a clock that stays awake. You leave. If the street is worth keeping, you take one photo. When the run finishes, or when you decide you are done, a short journal entry is waiting.

The first screen says the whole thing in one breath. While your build runs, walk. Snap what you see. An open model writes the entry when you get back.

The screen is a glance. The walk is the rest of it.

Paste owner/repo, or a github.com URL, and the walk follows the newest run that is still going. The browser calls the public GitHub API from the phone, with no token. The countdown is the median of the last ten successful runs, minus the time already spent, and it never goes below zero. A repository with no successful history gets a fifteen-minute guess, and the page says so. "No recent successful runs, so this timer is a fifteen minute guess. The walk still ends when the run finishes." It checks that run every thirty seconds.

If the guess runs out and the build is still going, the headline changes. "Go walk," becomes "Still out." Under it: the build has not finished.

If nothing is in progress, the walk becomes a demo and one line says why. "No run in progress on that repo. This is a demo walk." A rate limit says "GitHub rate limit. This is a demo walk." A malformed URL stays on the start screen: "That does not look like a public GitHub repo." A repository GitHub cannot find stays an error too: "That repository is not public, or it does not exist." I would rather be told than be sent outside on a timer that was never real.

Leave the field blank and it is a demo from the first step, anywhere from ten to sixty minutes. That is the walk in the pictures below. The end is the start plus those minutes, so a reload keeps counting.

Demo

It is live at build-break.onrender.com. Open it on a phone. On a desktop the same page sits in a narrow column, because this is a thing you carry.

Press start with the field empty. The phone says go, and then a number. This one is 32:59, marked demo, with the screen kept awake.

Capture is there if you want a picture. End walk is there if you come back early. In this demo there is no model key, so the note under the photo is written on the machine, one sentence from a small local set:

The way ahead is quiet: pavement, trunks, and a pale sky.

That sentence is a stand-in. It lets you see the shape of a note before Gemma is pointed at a real street. It is not a record of a walk I took.

When the demo clock hits zero, the journal writes the entry in the same voice. You can also end the walk yourself and get the entry then. This one is stamped 11 Oct 2026, 12:45 PM IST, one minute, demo.

I went out Sunday afternoon, 12:45 PM, and stayed for a minute. The way ahead is quiet: pavement, trunks, and a pale sky. It was a short loop, and a good one.

The line I keep looking at is the one above the entry. This week: one walk, one minute outside while CI ran.

Point the app at Gemma and those stand-in sentences are replaced by whatever was actually in the photo, the weather if you allowed it, and how the run ended. On the laptop that model is Gemma 3 4B, because it can see. On Ollama Cloud it is Gemma 4 31B. The prompts stay the same.

Code

The license is MIT. The app is Next.js and TypeScript. Walks, notes, and the journal live in one SQLite file. Photos sit on disk next to it, under DATA_DIR.

GitHub is called from the browser. The model is one chat-completions client. The three screens are a start page, a walk, and a journal.

How I Built It

The open piece is the model, and the model is one HTTP call.

Build Break speaks the OpenAI chat completions API. Three environment variables aim it, and nothing else is hardcoded: LLM_BASE_URL, LLM_MODEL, and LLM_API_KEY. With no key, you get the local stand-in in the screenshots above. LLM_PROVIDER=mock keeps that path even when a key is sitting in the environment.

For a real note I point it at Ollama on the laptop:

LLM_PROVIDER=ollama
LLM_BASE_URL=http://localhost:11434/v1
LLM_MODEL=gemma3:4b
LLM_API_KEY=ollama

The key has to be non-empty, or the app assumes you have not chosen a model. Ollama ignores the value.

The photo needs a model that can see. Gemma 3 at 270M and at 1B is text only, so those builds cannot read a picture. Gemma 3 4B can. It is asked for one short, warm sentence about what someone on a walk would notice: plants, animals, sky, the life of the street. No guessing past what is in the frame. The image is sent before the text, which is the order Gemma prefers.

The same model writes the journal. Three to five sentences, first person, drawn from the time of day, the minutes outside, the notes, and the last few entries. A fact it was not given is left out. Weather appears only if you allowed location. A pattern gets a sentence only when a word actually shows up again. Plain, warm, no hashtags.

Gemma 3, including the 4B, is released by Google under the Gemma Terms of Use (last modified 1 April 2026). The appendix on that page lists Gemma 3. It is Google's own license, with a prohibited-use policy. It is not the Apache License, and it is not an OSI open-source license. I use it because it can see a photo on a machine I already have, and that limit belongs in the post.

When the laptop cannot hold the model, the same client talks to Ollama Cloud at https://ollama.com/v1. The model id is gemma4:31b, taken from Ollama's own list. The :cloud alias is for a signed-in local Ollama, and it is the wrong string to send to the cloud API. Gemma 4 31B takes text and images and returns text, so one model still does both jobs. Gemma 4 is under the Apache License 2.0.

Changing the model is one line.

LLM_MODEL=gemma3:12b

Point LLM_BASE_URL at another host and the prompts stay put.

GitHub is called from the browser, so the request uses the phone's address. Unauthenticated calls are about sixty an hour. That is why a 403 becomes a demo walk with a sentence attached. Photos are resized in the browser to about 1024 pixels on the long edge, saved as JPEG, and only then uploaded to our own API. They are not sent to a model until an endpoint is configured. On localhost, that endpoint is Ollama on the same machine.

The journal clock is the browser's time zone. That is why the demo stamp reads IST. The page asks for location once: add the weather from where you are. A no is remembered. Coordinates are not stored.

Why Does Open Innovation Matter?

The picture is of the street you are standing on. I wanted it read on the machine, with no account and no fee for each photo.

Gemma 3 4B through local Ollama does that. If the sentence is too thin, I change LLM_MODEL. The prompts stay. A closed vision API would have been a shorter afternoon, and then every walk would have been a metered call, with the photo leaving the phone for someone else's account. A walk every time a build starts is a bad match for a meter.

Location is a choice for the same reason. Allow it, and the server asks Open-Meteo for the current conditions. There is no weather key. The sentence comes back in a fixed shape, like "28°C and clear." The latitude and longitude are not written into the journal. Refuse the prompt, and the entry never brings the weather up. Open-Meteo does see the coordinates when you allow them. A model provider does not receive the GPS. The database does not keep a record of where you were.

Gemma 4 is there for the day the laptop is not enough. Because it is Apache 2.0, I can host it, or let Ollama Cloud host it, on the same three variables. The Render blueprint points the host at gemma4:31b on Ollama Cloud, so the phone in your pocket does not have to be the computer that runs the weights.

Prize Categories

Best Use of Gemma. The one-line note and the journal entry are the model's work. On the laptop that is Gemma 3 4B, under the Gemma Terms of Use, because it can see. On Ollama Cloud it is Gemma 4 31B, under Apache 2.0. Either way the app is a thin timer around an open-weight model, and the model is one line to change.

Best Use of Render. Build Break is a Node server with a SQLite file and a folder of photos. That wants a disk that survives a restart. render.yaml is the blueprint: the web service on the starter plan, DATA_DIR at /var/data, a 1 GB disk, and the model variables in the host environment. A persistent disk needs a paid instance. A free instance forgets the journal on restart. The app is live at build-break.onrender.com.

A code edit can pass the request and still drop something the prompt never said

Aditya — Sun, 11 Oct 2026 12:23:15 +0000

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

Resolve measures a small code change. I wanted a score for the failure I keep seeing: the edit does the thing that was asked, and drops a behavior the prompt never said again.

Each item is one Python function and one requested edit. The model returns only the new function. The score is how many of 16 items are fully resolved, as a float from 0 to 1. A half-fix scores zero on that item.

There are two tasks. resolve checks the new behavior and the old behavior the prompt never restated. resolve-plus adds an edge suite the prompt never showed. The two tasks are separate generations, so the second score can land above the first.

The result this post is about: GPT-6.1 Sol and GPT-5.6 Luna are the only models at 0.9375 on both tasks. The task page rounds that to 0.94. Several other models match 0.9375 on resolve and then score lower on resolve-plus.

How it works

The prompt shows the function, the one change, and two sample inputs. Anything the model writes besides the new function is thrown away. Hidden tests then run in two lists.

Fail-to-pass is the new behavior.
Pass-to-pass is behavior the prompt never repeated.

An item counts only when every test in both lists passes. A timeout, a crash, a missing function, or an empty suite is a failure. One failed test fails the item.

resolve-plus uses the same rule and adds the edge suite. It is a new sample of the 16 items, not a second grade of the first sample.

Inspiration

This is the rule SWE-bench uses for a resolved issue, scaled down to functions I wrote. The paper is Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024).

SWE-bench does not give credit because a patch compiles or because the new test passes. The issue is resolved only when the fail-to-pass tests and the pass-to-pass tests all pass. Resolve keeps that bar and drops the rest of the scaffolding: no scraped repository, no gold patch in the prompt, no tests written by the model. The failure worth reading is an edit that does the asked change and drops an invariant the prompt did not say again.

Models Tested

I started with one model from each of four families, then ran the Claude, GPT, and Gemini lines the proxy would serve, plus the open models listed below. Frontier and open models are charted separately so a single average cannot hide which group is carrying the score.

Twenty-three models have both scores. A model is on a chart only when both have finished. Blue is resolve. Orange is resolve-plus. Charts are sorted by resolve-plus.

Frontier: Claude Haiku 4.5, Haiku 5.5, Sonnet 5, Sonnet 5.5, Opus 5.5, GPT-5.4 mini, GPT-5.6 Luna, GPT-5.6 Sol, GPT-6.1 Sol, Gemini 3.5 Flash, Gemini 3.5 Flash-Lite, Gemini 3.6 Flash, Gemini 3.7 Flash, and Gemini 3.8 Flash.

Open: Gemma 4 31B, Gemma 4 26B, gpt-oss 20B, gpt-oss 120B, DeepSeek-R1, GLM-5, Qwen 3 235B, Qwen 3 Coder 480B, and Qwen 3 Next 80B Instruct.

Grok 4.5 and Grok 4.6 are in the Kaggle model list. The proxy returned model not found for both, so they are not on the charts. Qwen 3 Next 80B Thinking timed out three times on that same proxy, the last time after 3 of 16 items, so it is off the charts too.

Findings

All 23 models

GPT-6.1 Sol and GPT-5.6 Luna are tied at the top, 0.9375 on both tasks. That is 15 of 16 items, twice.

The next group matches the 0.9375 resolve score and lands at 0.875 on resolve-plus: DeepSeek-R1, Claude Sonnet 5.5, and Claude Opus 5.5. Each of them resolved 15 items on the first task and 14 on the second.

gpt-oss 20B is the bar that runs the other way, 0.75 then 0.875. The second task is a new sample, so a higher resolve-plus score is a different generation, not the edge suite helping. The floor of the combined chart is Qwen 3 235B and Gemma 4 26B, both at 0.6875 on resolve-plus.

Frontier models

The frontier chart is the same tie at the top, then a clean step down.

Opus 5.5 and Sonnet 5.5 both open at 0.9375 and close at 0.875. GPT-5.6 Sol opens at the same 0.9375 and closes at 0.8125, a two-item drop. Sonnet 5 holds 0.875 on resolve and falls to 0.75 on resolve-plus.

Haiku 4.5 and Haiku 5.5 sit on the same pair, 0.875 and 0.875. On these 16 functions the newer small model did not move the score. Gemini 3.5 Flash and Gemini 3.6 Flash sit with them. Gemini 3.5 Flash-Lite is the frontier floor, 0.75 on both.

Open models

DeepSeek-R1 leads the open chart at 0.9375 and 0.875, level with Opus 5.5 and Sonnet 5.5 on the frontier chart. Gemma 4 31B is the only open model that holds 0.875 on both tasks. Gemma 4 26B is last, 0.75 then 0.6875.

Qwen 3 Coder 480B, at 0.875 and 0.8125, beats the larger general Qwen 3 235B, at 0.8125 and 0.6875. gpt-oss 120B and Qwen 3 Next 80B Instruct are flat at 0.8125. gpt-oss 20B is the open-chart exception: its second sample scores 0.875 after a 0.75 first sample.

Score against list price

The runs did not store tokens or a dollar bill, so this is not measured cost per item. The horizontal axis is the published output price per million tokens, taken from a rate card last updated 8 October 2026. That card reports the rates against the Anthropic, OpenAI, and Gemini pricing pages. Expensive is on the left. Cheap is on the right. A line connects models from the same provider. Open models are off this chart, and so are Gemini 3.6 Flash and Gemini 3.7 Flash, because that rate card does not list them. Haiku 5.5 is the under-100k rate. These prompts are one short function.

GPT-5.6 Luna is the efficient point: 0.9375 at $1.20 per million output tokens. GPT-6.1 Sol matches that score at $10. Claude Haiku 5.5 holds 0.875 at $0.50, the same score as Haiku 4.5 at $5 and Opus 5.5 at $20. Sonnet 5 and Sonnet 5.5 share the $10 output price. Sonnet 5.5 is the one at 0.875.

What a flat leaderboard hides

The first pass was one model from each of four families: Claude Haiku 4.5, Gemma 4 31B, GPT-5.4 mini, and Gemini 3.7 Flash. Each resolved 14 of 16 items. The leaderboard looks flat until the second row. Haiku and Gemma stay at 0.875 on resolve-plus. GPT-5.4 mini and Gemini 3.7 Flash fall to 0.8125.

Those two drops are different events.

On ring_push, each of those four models, on both tasks, made the requested change and failed a behavior the prompt never restated. Fail-to-pass passed. Pass-to-pass did not. A looser score would have counted those edits. This one does not. That miss was stable across those eight runs.

GPT-5.4 mini’s lower resolve-plus score is the extra suite. On truncate, the requested change and the old behavior both passed, and the edge suite failed. Haiku and Gemma did not lose an item that way.

Gemini 3.7 Flash’s lower resolve-plus score is a different generation of the same items. collapse_name passed the first time and failed the second. The extra suite was not what moved it.

One number is hiding three things: an edit that breaks an unstated invariant, an edit that misses an edge the prompt never showed, and a second sample of the same item that comes out differently.

One generation was enough to move collapse_name from a pass to a fail. A one-shot score is a noisy picture of a model that is close to the line. The next run I would make is more than one sample per item.

My Benchmark

The public benchmark is Resolve on Kaggle. It is version 1, Apache 2.0, and marked public. The leaderboard on that page shows the first four models. The task pages list every run, including ones that did not finish. A model is in the charts here only when both scores finished.

The two tasks:

Suggested citation: Aditya Kumar Puri. Resolve. https://www.kaggle.com/benchmarks/puriadityakumar/resolve/versions/1, 2026.

References

Jimenez, Carlos E., John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. https://arxiv.org/abs/2310.06770
SWE-bench. https://www.swebench.com/
Kaggle Community Benchmarks. https://www.kaggle.com/benchmarks
kaggle-benchmarks Python library. https://github.com/Kaggle/kaggle-benchmarks
Google AI. “Introducing Community Benchmarks on Kaggle.” https://dev.to/googleai/introducing-community-benchmarks-on-kaggle-35nc
Frontier model API pricing, last updated 8 October 2026. https://www.developersdigest.tech/blog/frontier-model-api-pricing-june-2026
Anthropic pricing. https://www.anthropic.com/pricing
OpenAI API pricing. https://openai.com/api/pricing
Gemini API pricing. https://ai.google.dev/gemini-api/docs/pricing

I built an agent that asks permission before it touches anything

Aditya — Sun, 30 Aug 2026 18:25:43 +0000

Every agent demo I watched this month had the same ending: the agent clicked "confirm" on itself. Nobody in the video batted an eye. The narrator called it "fully autonomous" and moved on.

That's the part I can't get past. An agent that never stops isn't autonomous, it's just unattended.

So for the WeMakeDevs × TrueFoundry Agent Harness Hackathon, I built Recap: a research-paper autopsy you can drive. You hand it a paper, it dissects it, and every time it wants to do something irreversible, it stops and waits for you. The agent supervises papers. You supervise the agent.

Repo: https://github.com/puri-adityakumar/openwrite

The job I gave it

Research papers are a triage problem. You don't read one paper, you triage forty, and most of them don't deserve the forty minutes. The job I gave the agent: take an arXiv URL or a PDF, and come back with the parts a human actually needs. Not a summary. A workup.

One click from landing to cockpit. The demo credentials sit right there because a tired judge is a real user segment.

What comes back is five surfaces: a live Trail of everything the agent did, a Coverage grid, a Claims↔Evidence table, an Authors tab, and a downloadable Audit. The Claims↔Evidence table is the one I'd want as a reviewer. Every claim in the paper, next to the evidence the agent found for it, and the gaps in between.

The dashboard. First paint shows a populated run, not an empty state. Empty states are where demos go to die.

The pause is the product

Here's the feature I actually care about: three approval gates. Verify, Publish, Save. Before the agent does anything irreversible, it pauses and asks. Not a toast you can ignore. A full stop.

The Verify gate is deliberately obnoxious. Before the paper's untrusted code runs in a sandbox, you have to type the repo owner's name AND hold a button for three full seconds. That's not friction by accident. That's friction on purpose. Papers are not trusted code, and "run the repo this paper links to" deserves a speed bump.

The Verify gate. Type the owner, hold for three seconds. If it feels excessive, try imagining what the code does.

Annoying answer: most agent safety demos are theater. A checkbox nobody reads is consent, not control. A pause you have to hold open is control.

Wiring it up

The stack is boring on purpose: Next.js, Postgres, Redis, one docker compose up, everything local. The interesting wiring is the agent harness.

One command, no clone:

npx @truefoundry/trueforge@latest

That gives me a TrueForge server on localhost:8790. Then I registered GMI Cloud as the model provider, pointed at their Anthropic-compatible endpoint with a custom base_url, running MiniMax-M3. No adapter code. A curl with a manifest, done.

The cockpit mid-run. Real SSE events streaming in: turn created, deltas, tool calls. The Trail on the left is the agent's actual receipt.

My app talks to TrueForge through its REST + SSE API. lib/trueforge.ts ships an HttpTrueForgeClient, and the events come over the wire for real: turn.created, model.message.delta, tool.approval_required, turn.done. When a gate fires, my UI surfaces the pause, and your allow/deny decision routes back to TrueForge through its resume contract. Nothing in the hot path is mocked. There's a smoke script that proves the "pong" in the transcript came from the actual model.

What TrueForge took off my plate

This is the list I'd have underestimated a week ago:

The agent runtime itself: turn lifecycle, retries, cancellation. I would have hand-rolled a state machine and shipped at least two race conditions.
Event streaming. SSE with backpressure and reconnection is a project, not a file.
Model-provider plumbing. Swapping GMI in without writing an adapter was the single best "oh, that's it?" moment of the hackathon.
The approval-pause/resume contract. The hard part of human-in-the-loop isn't the UI, it's freezing a running turn and resuming it correctly after a human decides. That's a solved problem here, and I just used it.
Sandbox handling, with a local fallback when no cloud sandbox is configured.

I wrote the surfaces: gates, trail, audit, the cockpit UI. TrueForge ran the agent underneath them. That division of labor is the whole pitch.

Where it broke

The low point: the demo ran fine until tool execution. Daytona, the sandbox provider, kept refusing the write that publishes a sandbox snapshot. The docs made it sound like write:sandboxes was enough. It isn't. You also need write:snapshots, and nothing tells you that until the API returns a permission error mid-demo.

The fix I reached for was TrueForge's local sandbox fallback, which auto-engages when no cloud sandbox provider is configured. The demo lived. And to be clear about the trade: tool execution behind the gate is skipped right now, and the harness says so honestly in the audit as sandbox.disabled. It doesn't pretend. The audit shows the gap, which is exactly the behavior I built the whole product around.

Honestly, that's the part I'm proudest of: the failure mode is visible, not hidden.

The review loop nobody asked about

Quick one, because it shaped everything: every substantive change landed through a Qodo-reviewed pull request. Thirteen PRs, all reviewed. The approval-gates PR came back with 17 findings across two review passes, including a race condition in my event reducer and a missing TTL guard that could have double-approved a gate. Every finding triaged before merge. The loop became the norm: PR, review, fix, merge. 237 unit tests and 54 E2E tests green at the end of it.

The whole run

If you'd rather watch than read:

180 seconds, the whole run, no cuts.

The audit at the end. Every action logged, every decision attributed. If the agent did it, the audit can prove it.

The agents are coming either way. The interesting question isn't whether they can do the work. It's whether you can see them doing it.

Repo: https://github.com/puri-adityakumar/openwrite

Biryani, With Love: A Deccan-Inspired Interactive Atlas

Aditya — Sun, 02 Aug 2026 11:31:41 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

What I Built

Biryani, With Love is an interactive editorial atlas about the many regional traditions that share the name biryani.

I chose biryani because comfort food is rarely only about flavour. It can hold a city, a family ritual, a migration story, a celebration, and a memory of home in the same pot. The landing page follows that idea from Hyderabad through India and across the Indian Ocean.

The experience includes:

A research-led map of eight Indian biryani traditions
A method lab comparing kachchi, pakki, and one-pot cooking sequences
A guided loop through fourteen traditions across nine countries
A comparison tool for grain, method, flavour, heat, perfume, tang, and richness
A historical route connecting language, court kitchens, regional grains, and Indian Ocean migration
A research shelf that makes the supporting sources visible

The visual system is inspired by a contemporary Deccan pavilion. Saffron, peacock green, pomegranate red, plum, brass, and ivory create the palette. The hero uses CSS-built arches, minarets, jali panels, steam, rice grains, garnish, and an open copper handi.

Demo

Open the full CodePen

Journey

Finding the right metaphor

My first version treated the page like a clean editorial index. It was readable, but it did not carry enough of the warmth, ceremony, and visual richness of the subject.

The breakthrough was to stop treating biryani as a list of recipes and instead design an edible atlas. Each section became a different way to read the same dish: geography, cooking sequence, migration, flavour, and memory.

Researching the architecture

The heritage direction was grounded in specific references rather than a generic ornamental style.

I studied the Charminar architecture described by Hyderabad District, particularly its four-sided arches, minarets, carved rings, and Qutb Shahi lotus details. I also looked at a sixteenth-century Indian jali in The Metropolitan Museum of Art, where stars, hexagons, and interlocking geometry create a play of light and pattern.

Those ideas became solid-color architectural frames, small lattice details, geometric rules, and the central handi illustration. I kept the interface modern by using strong editorial typography, square cards, clear hierarchy, and restrained motion.

Correcting the map

The first map used a simplified world dataset and looked noticeably wrong. I replaced it with the official Survey of India 1:16m outline vector, including the island territories.

The eight city points are projected from geographic coordinates instead of being positioned by eye. The map remains a cultural navigation device, but its outline and locations now have a defensible source.

Building the interactions

The project is a single responsive HTML document with inline CSS and vanilla JavaScript. CodePen separates those same three layers into its HTML, CSS, and JavaScript panels.

JavaScript is used purposefully for:

Switching regional map stories
Updating cooking method diagrams
Running and pausing the global biryani loop
Filtering traditions by geography
Comparing two traditions
Updating the historical route
Respecting reduced-motion preferences

The page contains no raster food photography. The hero, diagrams, decorative architecture, and interface details are created with HTML, CSS, and inline vector geometry.

Accessibility and usability

I wanted the atlas to remain useful beyond its visual impact. It includes:

Semantic sections and heading structure
Keyboard-operable SVG map points
Visible focus states
A skip link
Live regions for changing content
Reduced-motion support
Responsive layouts for narrow screens
Source links for the research claims
Clear notes where flavour scores are interpretive rather than scientific measurements

What I Am Proud Of

I am most proud that the page does not rank biryanis or declare one authentic winner. It gives each tradition enough context to feel distinct while showing the shared ritual underneath: rice, patience, adaptation, and memory.

The final result feels like a love letter, a research object, and a modern landing page at the same time.

AI Collaboration

I used OpenAI Codex as a collaborative coding, research, and iteration tool. I directed the concept, selected the biryani theme, reviewed each visual pass, identified inaccuracies, and made the final design decisions. The implementation and research sources were checked and refined through that collaboration.

DUM: Breaking the Seal on Hyderabadi Biryani with Pure CSS

Aditya — Sun, 02 Aug 2026 06:19:47 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Hyderabadi dum biryani is more than a dish to me—it is a ritual. The sealed handi, the slow charcoal heat, the suspense before the atta crust is broken, and the first rush of saffron, mint, birista, and spice all feel inseparable from the experience.

I wanted to turn that moment into an interactive midnight poster: Hyderabad’s skyline behind a copper handi, with the food hidden until the viewer breaks the seal.

Demo

Click BREAK THE SEAL to lift the lid and reveal the four biryani layers.

How it works

The artwork is built with HTML and CSS only:

A native <details> / <summary> control stores the open and closed states.
CSS :has() coordinates the seal crack, lid lift, layer reveal, steam, labels, embers, and state-aware copy.
Rice grains, mint leaves, birista, spices, meat, copper patina, flour dust, the skyline, and the moon are all CSS shapes.
There are no images, SVGs, canvas, JavaScript, gradients, or frameworks.
A mobile composition and prefers-reduced-motion keep the piece responsive and accessible.

The reveal is deliberately choreographed:

seal cracks → lid lifts → layers separate → labels arrive → steam settles

Journey

The hardest part was keeping the illustration detailed without losing the strong poster silhouette. I iterated on three areas:

Material: hammered copper marks, soot, flour residue, dough cracks, and print texture.
Depth: curved food layers, overlapping grains, steam arches, and ingredient silhouettes.
Motion: a staged opening sequence rather than making every element animate at once.

The most satisfying decision was using a semantic HTML control for the interaction. The artwork still works with a keyboard, and disabling motion does not hide the final state.

I used Codex as an iterative coding and visual-critique partner. I directed the concept, cultural references, composition, and final decisions, while the agent helped implement and test the CSS system.

What I’m proud of

The finished piece stays intentionally constrained: one HTML file, one CSS file, a small palette, and no image assets. The interaction adds drama, but CSS remains the star of the submission.

Thanks for taking a look—and remember: patience is the final ingredient.

AI Storyline Generator

Aditya — Sun, 14 Sep 2025 21:49:45 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I created AI Storyline Generator, a web app that turns a set of images and a short text prompt into a cohesive narrative. It helps writers and artists quickly build stories or prototypes by offering three modes: Surprise Me (short story with optional cover art), Light Novel (full chapter with illustrations), and Manga (panel art).

Demo

Demo Video

Screenshots

LINK

Applet Link 🌱
Note: I was not able to publish the app due to billing issues. Please accept the published app link. Thankyou.

How I Used Google AI Studio

Used gemini-2.5-flash-image-preview for vision–language tasks like story generation and all image outputs.
Used gemini-2.5-flash for Manga mode to reliably create structured JSON scripts.

Multimodal Features

Image-to-Story Generation: Combines multiple images and text into a connected plot.
Narrative-Aware Illustration: Generates key-scene illustrations directly from the AI-written story.
Automated Manga Pipeline: Creates a full manga page by chaining image analysis, JSON scripting, and panel art generation

Efficient Architecture 101: Is Your Upload Strategy Actually Efficient?

Aditya — Tue, 26 Aug 2025 17:15:06 +0000

Before we start...

So, why this series? I've recently jumped straight into the complexities of system design, and I think the best approach to learning is by writing blogs and sharing what I have learned. My goal is to create simple blogs with humor and a lot of diagrams. Please note, I'm still learning, so if you're experienced and find something that can be improved or is incorrect, please share your thoughts.

The Challenge: A Real-World Bottleneck

Not long ago, I was digging through a codebase and found a classic file upload setup. The user would select a file in their browser, the browser would send it to our backend server, and then the server would upload it to a cloud storage bucket like AWS S3.

It worked, but it was far from efficient. The architecture looked something like this:

So, approach has some serious drawbacks

It's Slow for the User: The file has to make two trips over the internet. The user is stuck waiting for both to complete.
It Hogs Server Resources: Imagine 100 users uploading large videos at once. Your server is suddenly trying to process gigabytes of data, choking its memory, CPU, and bandwidth. This is a classic scalability nightmare.
It Can Be More Expensive: You're paying for the bandwidth twice – once for the data coming into your server, and again for it going out to the cloud storage. Ouch.

A Slightly Better Approach (That's Actually Worse)

So, to fix the speed issue, why not just upload directly from the browser? Modern tools like the AWS SDK for JavaScript let you do just that. The flow seems simpler and faster.

But this comes with a giant, flashing, red security warning. To allow the browser to upload, you have to embed your secret access keys directly in the frontend code. This is like leaving the master key to your entire house under the doormat.

Anyone with a little know-how can open their browser's developer tools, find your keys, and gain full, unrestricted access to your storage bucket. It's a disaster waiting to happen.

The Real Solution: Pre-Signed URLs

This is where we get the best of both worlds: the speed of a direct upload and the security of a server-managed process.

A pre-signed URL is a special, temporary, and secure link that your server generates. It gives a user permission to perform a specific action (like uploading a file with a specific name) directly to your cloud storage, but only for a limited time.

the browser first asks the server for permission. The server then generates a temporary, pre-signed URL and sends it back. The browser uses this special URL to upload the file directly to cloud storage. The server's only job is to authorize the request, not to handle the heavy file transfer itself.

So, Why prefer pre-singed url for uploads?

Enhanced Security: Your cloud storage credentials are never exposed on the client-side.
Improved Performance: Files are uploaded directly to cloud storage, reducing latency for the user.
Increased Scalability: Offloads the bandwidth and processing load from your server, allowing it to handle more application requests.
Cost Optimization: Reduces egress bandwidth costs from your server.

Best Practices

Use Short-Lived URLs: Always configure pre-signed URLs with the shortest possible expiration time (e.g., 5-15 minutes) to minimize the risk of misuse.
Utilize Multipart Uploads: For large files, leverage multipart uploads. This involves generating multiple pre-signed URLs to upload the file in chunks, which improves reliability.
Implement Resumable Uploads: In case of network interruptions, a robust implementation should allow the upload to resume from the last successfully uploaded part, rather than restarting the entire process.

DEV Community: Aditya

Dead Frequency: a ghost in the machine, with a fuse box

What I Built

Demo

Code

How I Built It

The simulation is boring on purpose

The director only speaks at milestones

The boundary bug

Parallel workstreams at max

Why Does Open Innovation Matter?

The Ghost in the Machine

Limits

Prize Categories

Raincheck: the lazy, kind way to cancel a plan

What I Built

Demo

Code

puri-adityakumar / raincheck

A small, open-source desk for cancelling plans kindly and offering one real next time. React + FastAPI, Open-Meteo forecasts, expiring share tickets, AI drafting off by default.

Contents

Features

How I Built It

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

Inkline — notes to diagrams, with Gemma, on your machine

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

Prize Categories

While your build runs, walk

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

Prize Categories

A code edit can pass the request and still drop something the prompt never said

What I Benchmarked

How it works

Inspiration

Models Tested

Findings

All 23 models

Frontier models

Open models

Score against list price

What a flat leaderboard hides

My Benchmark

References

I built an agent that asks permission before it touches anything

The job I gave it

The pause is the product

Wiring it up

What TrueForge took off my plate

Where it broke

The review loop nobody asked about

The whole run

Biryani, With Love: A Deccan-Inspired Interactive Atlas

What I Built

Demo

Journey

Finding the right metaphor

Researching the architecture

Correcting the map

Building the interactions

Accessibility and usability

What I Am Proud Of

AI Collaboration

DUM: Breaking the Seal on Hyderabadi Biryani with Pure CSS

Inspiration

Demo

How it works

Journey

What I’m proud of

AI Storyline Generator

What I Built