DEV Community: SHREYANSH GIRI

CodeClash: 1v1 Codeforces Duels, Now Haunted by a Local-LLM Ghost Racer for friends

SHREYANSH GIRI — Tue, 27 Oct 2026 16:58:21 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

CodeClash is a real-time 1v1 competitive programming arena. Two players are matched by Elo, handed the same authentic Codeforces problem, and race to land the first Accepted verdict. It has ranked matchmaking, private 6-character challenge rooms, an embedded multi-language IDE, live verdict tracking, and a global leaderboard.

For Ghost in the Machine, I took the theme literally from racing games. In a racing game, a ghost is a translucent replay of a past run that you race against: a dead lap that still drives. CodeClash's Ghost Racer is that idea for competitive programming: an open-weight-model agent, running locally, that races you on the same problem, attempting solutions, failing sample tests, retrying, and either beating you or fading out. No second human required, and no queue wait at 3 a.m.

Demo

Live app: https://code-clash-kohl.vercel.app

Backend API: https://codeclash-hmgz.onrender.com

Code

ShreyanshGiri08 / CodeClash

CodeClash is a real-time 1v1 competitive programming platform built for speed and precision. Race head-to-head against rival coders or challenge friends on curated Codeforces problems, track live submission verdicts, and climb the global Elo leaderboard in real-time.

⚡ CodeClash — Real-Time 1v1 Competitive Programming Esports Platform

🚀 Live App Deployment: https://code-clash-kohl.vercel.app
⚡ Backend API Server: https://codeclash-hmgz.onrender.com

CodeClash is a state-of-the-art, real-time competitive programming esports platform designed for high-speed duels on authentic Codeforces problems. Featuring Elo-rated matchmaking, 6-character private challenge rooms, Valorant-style match entrances, an embedded multi-language IDE with local execution, a smart non-destructive algorithm snippet vault, dynamic analytics radar charts, 3D holographic badges, zero-asset Web Audio synthesis, and an advanced client-side TeX math statement parser.

📑 Table of Contents

🛠 Technical Stack

Frontend Subsystems

Core Framework: React 18, Vite 5, React Router v6
Styling & Micro-Interactions: Tailwind CSS v4, Vanilla CSS Custom Variables, Framer Motion (3D spring physics, layout…

View on GitHub

How I Built It
The arena (the nuts and bolts)

Stack: React 18 + Vite + Tailwind v4 + Framer Motion on the frontend; FastAPI on Uvicorn, asyncpg, and Neon serverless PostgreSQL on the backend. Frontend on Vercel, API on Render.

Matchmaking without Redis. Ranked queue is an in-memory structure behind an asyncio.Lock with an expanding band search: ±100 Elo at 0–10s, widening in steps to ±500 by the 120s timeout. Both sides are checked, so a new player's band is tested against the queued player's expanded band. For a single-process free-tier deploy this gives zero-latency lookups with no extra infra. (Multi-worker would move to Redis sorted sets with ZRANGEBYSCORE and Redlock; I documented that trade-off rather than pretending the problem doesn't exist.)

Verdicts come from Codeforces itself. There is no custom judge to cheat. The server polls the official user.status endpoint and decides the winner from real submissions. Two details that mattered:

A 60-second clock-drift buffer (effective_start = after_timestamp - 60) so server clock offsets don't cause a legit AC to be missed.
Tie-break by creationTimeSeconds when both players solve it, so the earliest Accepted wins.

Idempotent finalization. Race results can be triggered at the same moment by player 1, player 2, or background polling. A check-before-write plus an atomic SQL guard (UPDATE races SET status='finished', elo_applied=TRUE ... WHERE id=$1 AND elo_applied=FALSE) means Elo is applied exactly once. Without it you get +24 instead of +12. Elo is standard zero-sum with K = 32 (with a provisional K period for new accounts).

Scraping that survives Codeforces. Codeforces has no statement API, so statements are scraped (httpx + BeautifulSoup) and cached with a TTL. When direct access fails there's a fallback cluster: Jina Reader → AllOrigins → CodeTabs. On the client, a custom statement slicer strips nav bars, flags and footers, and a TeX cleaner turns \ldots, \leq, 10^{9}, a_1, \dots, a_n into ..., ≤, 10⁹, a₁, ..., aₙ.

Code Studio. Embedded editor for C++17, Python 3.10, Java 17 and JavaScript. Non-JS languages run through the Piston API; JS runs in a client-side sandbox. Output is diffed against expected sample output. A snippet vault (Fast I/O, DSU, ModPow, Segment Tree) inserts non-destructively: Fast I/O goes inside main(), helper structs go above it.

Small things that make it feel alive. A Web Audio synthesizer with zero audio assets (oscillators and gain nodes for every UI sound), a Valorant-style 3.5s match entrance, 3D holographic badges, a Ctrl+K command palette, and a 6-axis skill radar computed as min(100, max(25, Elo/25 + 7·CF_solved_T + 12·clash_wins_T)).

Boring-but-real engineering: pool recycling for Neon (max_inactive_connection_lifetime=180), sliding-window rate limits (5 queue requests/min, 15 verdict checks/min), and a /health endpoint that actually pings the DB.

The Ghost (the open-source AI part)

The Ghost is an agent, not a single prompt. It runs on an open-weight model served locally, and the model is a config value, so swapping it is a one-line change.

Agent loop: Read statement → plan approach → write solution → run it against the sample tests in a sandbox → read the failure → revise. The loop is bounded to a fixed number of attempts, so it can lose, and losing convincingly is the point.
Tools it can call: read_problem, run_code(lang, source, stdin) and submit_attempt.
Pacing: The Ghost's visible progress is paced to a target Elo, so a 1200-rated Ghost doesn't solve a 2000 problem in 8 seconds.
Integration: The Ghost joins the existing race room as a participant, emitting the same RACE_UPDATE events a human opponent would, so the arena needed almost no changes.
Why Does Open Innovation Matter?
Cost. Racing the Ghost costs nothing per match. A closed API charges per token on every attempt of every retry loop, and an agent that iterates several times per problem would burn through a free tier fast.
Swappable brains. Because the model is a config value, I can drop in a bigger or smaller open-weight model and feel the difficulty change. That is the difficulty slider, and it's impossible when the model behind an API can change or be deprecated underneath you.
No lock-in. A ghost that depends on a hosted service dies when the service does. Fitting for the theme, a ghost built on open weights can't be switched off by someone else.
Control of the agent loop. With open tooling I decide the sandbox, the attempt cap, the retry policy and the pacing. Those are product decisions here, not API parameters.! -->

CodeClash: 1v1 Codeforces Duels, Now Haunted by a Local-LLM Ghost Racer

SHREYANSH GIRI — Tue, 27 Oct 2026 05:56:12 +0000

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

What I Built

CodeClash is a real-time 1v1 competitive programming arena. Two players are matched by Elo, handed the same authentic Codeforces problem, and race to land the first Accepted verdict. It has ranked matchmaking, private 6-character challenge rooms, an embedded multi-language IDE, live verdict tracking, and a global leaderboard.

For Ghost in the Machine, I took the theme literally from racing games. In a racing game, a ghost is a translucent replay of a past run that you race against: a dead lap that still drives. CodeClash's Ghost Racer is that idea for competitive programming: an open-weight-model agent, running locally, that races you on the same problem, attempting solutions, failing sample tests, retrying, and either beating you or fading out. No second human required, and no queue wait at 3 a.m.

Demo

Live app: https://code-clash-kohl.vercel.app

Backend API: https://codeclash-hmgz.onrender.com

Code

ShreyanshGiri08 / CodeClash

CodeClash is a real-time 1v1 competitive programming platform built for speed and precision. Race head-to-head against rival coders or challenge friends on curated Codeforces problems, track live submission verdicts, and climb the global Elo leaderboard in real-time.

⚡ CodeClash — Real-Time 1v1 Competitive Programming Esports Platform

🚀 Live App Deployment: https://code-clash-kohl.vercel.app
⚡ Backend API Server: https://codeclash-hmgz.onrender.com

📑 Table of Contents

🛠 Technical Stack

Frontend Subsystems

Core Framework: React 18, Vite 5, React Router v6
Styling & Micro-Interactions: Tailwind CSS v4, Vanilla CSS Custom Variables, Framer Motion (3D spring physics, layout…

View on GitHub

How I Built It

The arena (the nuts and bolts)

Stack: React 18 + Vite + Tailwind v4 + Framer Motion on the frontend; FastAPI on Uvicorn, asyncpg, and Neon serverless PostgreSQL on the backend. Frontend on Vercel, API on Render.

Matchmaking without Redis. Ranked queue is an in-memory structure behind an asyncio.Lock with an expanding band search: ±100 Elo at 0–10s, widening in steps to ±500 by the 120s timeout. Both sides are checked, so a new player's band is tested against the queued player's expanded band. For a single-process free-tier deploy this gives zero-latency lookups with no extra infra. (Multi-worker would move to Redis sorted sets with ZRANGEBYSCORE and Redlock; I documented that trade-off rather than pretending the problem doesn't exist.)

Verdicts come from Codeforces itself. There is no custom judge to cheat. The server polls the official user.status endpoint and decides the winner from real submissions. Two details that mattered:

A 60-second clock-drift buffer (effective_start = after_timestamp - 60) so server clock offsets don't cause a legit AC to be missed.
Tie-break by creationTimeSeconds when both players solve it, so the earliest Accepted wins.

Idempotent finalization. Race results can be triggered at the same moment by player 1, player 2, or background polling. A check-before-write plus an atomic SQL guard (UPDATE races SET status='finished', elo_applied=TRUE ... WHERE id=$1 AND elo_applied=FALSE) means Elo is applied exactly once. Without it you get +24 instead of +12. Elo is standard zero-sum with K = 32 (with a provisional K period for new accounts).

Scraping that survives Codeforces. Codeforces has no statement API, so statements are scraped (httpx + BeautifulSoup) and cached with a TTL. When direct access fails there's a fallback cluster: Jina Reader → AllOrigins → CodeTabs. On the client, a custom statement slicer strips nav bars, flags and footers, and a TeX cleaner turns \ldots, \leq, 10^{9}, a_1, \dots, a_n into ..., ≤, 10⁹, a₁, ..., aₙ.

Code Studio. Embedded editor for C++17, Python 3.10, Java 17 and JavaScript. Non-JS languages run through the Piston API; JS runs in a client-side sandbox. Output is diffed against expected sample output. A snippet vault (Fast I/O, DSU, ModPow, Segment Tree) inserts non-destructively: Fast I/O goes inside main(), helper structs go above it.

Small things that make it feel alive. A Web Audio synthesizer with zero audio assets (oscillators and gain nodes for every UI sound), a Valorant-style 3.5s match entrance, 3D holographic badges, a Ctrl+K command palette, and a 6-axis skill radar computed as min(100, max(25, Elo/25 + 7·CF_solved_T + 12·clash_wins_T)).

Boring-but-real engineering: pool recycling for Neon (max_inactive_connection_lifetime=180), sliding-window rate limits (5 queue requests/min, 15 verdict checks/min), and a /health endpoint that actually pings the DB.

The Ghost (the open-source AI part)

The Ghost is an agent, not a single prompt. It runs on an open-weight model served locally, and the model is a config value, so swapping it is a one-line change.

Agent loop: Read statement → plan approach → write solution → run it against the sample tests in a sandbox → read the failure → revise. The loop is bounded to a fixed number of attempts, so it can lose, and losing convincingly is the point.
Tools it can call: read_problem, run_code(lang, source, stdin) and submit_attempt.
Pacing: The Ghost's visible progress is paced to a target Elo, so a 1200-rated Ghost doesn't solve a 2000 problem in 8 seconds.
Integration: The Ghost joins the existing race room as a participant, emitting the same RACE_UPDATE events a human opponent would, so the arena needed almost no changes.

Why Does Open Innovation Matter?

Cost. Racing the Ghost costs nothing per match. A closed API charges per token on every attempt of every retry loop, and an agent that iterates several times per problem would burn through a free tier fast.
Swappable brains. Because the model is a config value, I can drop in a bigger or smaller open-weight model and feel the difficulty change. That is the difficulty slider, and it's impossible when the model behind an API can change or be deprecated underneath you.
No lock-in. A ghost that depends on a hosted service dies when the service does. Fitting for the theme, a ghost built on open weights can't be switched off by someone else.
Control of the agent loop. With open tooling I decide the sandbox, the attempt cap, the retry policy and the pacing. Those are product decisions here, not API parameters.

Mini Slack v2.0: Building a Real-Time Chat App That Doesn’t Broadcast Everything to Everyone

SHREYANSH GIRI — Sun, 25 Oct 2026 11:13:50 +0000

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

What I Built

Mini Slack v2.0 is a real-time team messaging platform with channels, private DMs, threaded replies, emoji reactions, typing indicators and unread badges, in a dark/light UI. It also has a "Summarize thread" button that uses a local open-source LLM (via Ollama) to turn a long thread into a short summary.

A naive chat app broadcasts every event to every connected user and re-renders the whole message list on each new message. That works with five users and falls apart as the workspace grows. So I took the slow and steady route and made the boring parts efficient:

Targeted WebSocket delivery. Clients send a SUBSCRIBE event when they switch channels, and the server keeps a channel_id → users registry. A channel message goes only to that channel's subscribers, and a DM goes to exactly two people.
Composite and partial Postgres indexes for the queries a chat app runs constantly: the channel feed, DM pairs, thread replies and unread counts.
A leaner React render path. React.memo on MessageItem plus stable useCallback handlers, so one incoming message re-renders one component instead of the whole visible list.
Local AI summaries. Nobody has to scroll through 40 replies to find out what a thread decided.

Anyone who keeps a team chat open all day gets to be a little lazier: no refreshing, no polling, and no reading every reply to catch up on a thread.

Demo

🌐 Live app: https://slack-r7df.vercel.app/
📖 API docs (FastAPI/OpenAPI): https://slack-7yia.onrender.com/docs

Code

ShreyanshGiri08 / Slack

Mini Slack v2.0 — Real-Time Team Messaging Platform

A production-grade, real-time team collaboration platform built with React, FastAPI, WebSockets, and Neon PostgreSQL — featuring channel-room targeted delivery, composite DB indexing, and an optimised React rendering pipeline.

🌐 Live Web Application: https://slack-r7df.vercel.app/
⚡ Backend REST & WS API: https://slack-7yia.onrender.com
📖 API Documentation: https://slack-7yia.onrender.com/docs

📸 Overview

Mini Slack is a full-stack Slack clone with isolated private DMs, emoji reactions, threaded replies, real-time WebSocket messaging, and a beautiful dark/light mode UI. Built with a clean separation of concerns across backend services, routers, schemas, and ORM models.

✨ Features

💬 Messaging

Feature	Details
Real-time Channel Messaging	Native FastAPI WebSockets — no polling
Isolated Private Direct Messages	DMs stored with `recipient_id`, never appear in channel streams
Threaded Message Replies	Sliding side drawer — replies stored as `parent_id` foreign keys
Soft Message Deletion	`is_deleted=True` flag preserves thread continuity
Emoji

…

View on GitHub

How I Built It

Backend: FastAPI (Python 3.13), SQLAlchemy 2.x, Pydantic v2, Uvicorn, and native FastAPI WebSockets. Data lives in serverless Neon PostgreSQL. The code is split into routers, services, schemas and ORM models, and the schema auto-migrates on startup. It also seeds 8 engineering channels (#general, #engineering, #web, #blockchain, #ai-ml, #devops, #design, #random).

Frontend: React 18 + Vite, TailwindCSS, Framer Motion, Axios, Lucide icons, emoji-picker-react, and DiceBear avatars.

Design decisions worth calling out:

Soft deletes. Deleting a message sets is_deleted=True instead of removing the row, so threads don't lose their parent.
DM isolation. DMs are stored with a recipient_id and filtered out of channel queries, so they can never leak into a channel feed.
Partial indexes. Each index only covers the rows its query touches, e.g. the channel feed index is restricted to parent_id IS NULL AND recipient_id IS NULL.

Open-source AI: Ollama. I added a "Summarize thread" button to the thread drawer. When you click it, the FastAPI backend collects the replies for that message, sends them to a locally running open-weight model through Ollama (I used [MODEL NAME]), and returns a short summary to the UI.

New endpoint: POST /api/v1/messages/{id}/summarize. It reuses the same reply query the thread drawer already uses.
Local inference: the backend calls Ollama's HTTP API on localhost:11434. No API key, no per-token billing, and nothing leaves the machine.
Failure handling: if Ollama isn't running, the endpoint returns a clear error and the button is disabled, so the rest of the chat is unaffected.

Why Does Open Innovation Matter?

Chat messages are some of the most private data an app handles. Because the model is open-weight and runs locally through Ollama, summarizing a thread doesn't mean shipping my users' conversations to a third-party API. I can pick the model, swap it for a smaller one on weak hardware, and run it with no usage costs. A closed API would have meant sending every thread off-machine, paying per call, and depending on someone else's pricing and uptime.

The rest of the stack is open source too: FastAPI, SQLAlchemy, PostgreSQL, React, Vite and Tailwind. As a first-year student I could read the source whenever something behaved strangely, and that's a big part of how a single person can build a real-time, multi-user app end to end.

The Lazy Payoff

Every feature in Mini Slack removes a small chore from a day of team chat:

No refreshing. Messages arrive over WebSockets, so there's no polling and no reload to see what's new.
No scanning for what's unread. Per-channel unread badges come from a message_reads table, so you can see which channels need you at a glance.
No hunting for old messages. Workspace-wide search covers channels and messages.
No losing context. Replies live in a sliding thread drawer, so side conversations stay out of the main feed.
No noisy channels. Events go only to people subscribed to that channel, so you aren't pulled into conversations that aren't yours. A DM from someone while you're in another channel shows up as a slide-in toast instead.
No rebuilding your place. The workspace persists across reloads, and the theme choice is saved in localStorage.
No reading 40 replies to catch up. The "Summarize thread" button gives you the gist from a local model, with nothing sent to a third party.

The same idea applies on the engineering side. Targeted fan-out and memoized components mean one new message re-renders one component instead of the whole visible list, so the app stays responsive however many messages are on screen.

Prize Categories

[OPTIONAL: list every partner category you're entering, from the challenge page. Otherwise delete this section.]