I will write more about this at some point in the future.
Projects
Differential vision encoding for computer-use agents. Instead of sending full screenshots each frame, encode only the visual diff between consecutive frames. Reduces token cost and latency for CUA inference.
Sudo generated the page for whatever URL you visited — no route table, a typed HTML object streamed and rendered as it arrived. It's written up as the origin of WikWok, which is the same generator pointed at a feed.
Mac computer-use agent that paired a small grounding VLM with GPT-5's reasoning over screen captures. It clicked, typed, and ran through RPA workflows; the interesting part was using the CLI directly whenever possible instead of pretending every computer action had to be pixel-level grounding.
I also used it to test how far strong computer-use models could get one-shot on games. Claude Opus could play League of Legends badly but coherently from a plain prompt.
Built a workspace for spreadsheets, code, and docs for a multi-billion dollar company. I killed it because it felt mediocre relative to where AI tools were heading.
WebGPU inference for DeepSeek-R1 — runs entirely in your browser, no downloads, no server. Open source, made in America, run on American servers.
Later extended to run Qwen3 0.6B with thinking locally via WebGPU, including experimental mobile support. Uses transformers.js with ONNX conversion under the hood.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
Live video and audio interview agent for screening blue-collar workers on a $2B government contract. It ran the interview, scored responses, and produced candidate notes without a human interviewer.
OSINT agent system that tracked 350k+ geopolitical signals a day. The useful artifact was not a dashboard; it was catching anomalous clusters early enough to matter.
One run flagged signals around the 2024 Amsterdam riots roughly 6 hours before they became mainstream.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
Bountylist started as a marketplace for small bounties aimed at serial hackers — post a problem, set a reward, let developers compete to solve it. It has since grown into Spread, a generalized marketplace where the same homepage feed shows roles, résumés, and small jobs side by side.
The interface decision
The site is a deliberate Craigslist clone. Black text on a white page, 13px Helvetica, purple links, dotted section underlines, no rounded corners, no cards, no hero. The whole homepage is three columns of directory entries arranged taxonomically: community, blog, events on the left; for-sale, services, research in the middle; jobs, résumés, receipts, discussion forums on the right. Each column item is a plain text link.
This was the early product decision, and it's load-bearing. A marketplace with three users feels like a ghost town if it shapes itself like Stripe or Lever, because the chrome implies a scale the data doesn't have. A directory page shaped like Craigslist reads as populated even when most of the rows are static taxonomy — the eye can't immediately tell which links go to live listings and which go to static category pages. The site feels useful before it is useful. The cost of this choice is that the interface looks like 1998 to people who weren't raised on it; the benefit is that it onboards bounty posters and recruiters without any explanation of what the product is.
The /jobs view
Jobs and bounties share one listing format: a date, a one-line title, a price, and an open/closed state. Prices range from $50 for a Spotify email scrape to $10k for an eval leaderboard to $$$ for "build AGI." The interface refuses to distinguish between serious requests and joke requests, because the people who post on a Craigslist-shaped board enjoy that ambiguity. Real listings get answered; joke listings turn into recruiting copy.
Single-blind contact
The interesting machinery is the messaging layer. When you reply to a listing the system mints a tagged forwarding address — apply+<listingId>@spread.xyz — and routes mail through it. Both sides write back without ever seeing the other's real address.

The Cloudflare Worker email handler accepts inbound mail at that tagged address, looks up the listing's Durable Object, and fans the message out to whichever real address is on the other side of the thread. Single-blind is preserved end-to-end: neither party sees the other's real email until both opt in. The aliasing also means recruiters can keep applicants warm without leaking either side's address into a CRM.
How state lives on both sides
The same conversation has to look right in Gmail and in /inbox, and replies typed in either surface have to land in the same thread. That works because every thread is one Durable Object, with a small SQLite schema inside it: a message table (one row per send/receive — direction, from, to, subject, body, the Cloudflare message id, the In-Reply-To header, a timestamp) and a meta table that pins the real poster email, the real recruiter email, and the canonical subject. The DO is named by the thread id (in v1 that's just the listing id, so each listing has at most one open conversation).

When the recruiter hits Send the first time, the worker creates the ThreadDO, persists the outbound row, then sends from apply+<listingId>@spread.xyz with the poster's real address as the recipient — so the poster's Gmail thread is anchored to the proxy address forever. When mail comes back in, Cloudflare Email Routing delivers it to the worker; the worker parses the apply+<id>@ tag, opens the DO by name, appends an inbound row, and sends the canonical-subject copy out to whichever real address is not the sender. The In-Reply-To and cf_message_id are stored so threading stays intact across both surfaces.
The /inbox view is just the DO's own log. Because the only authenticated viewer is one of the two participants, the worker is the only place that ever knows both real addresses — they live in the meta table and never leave it. The other side's emails always show the proxy address as the From, and any reply they type lands on the worker first.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
Ran GPT-2 inference entirely inside ChatGPT's Code Interpreter using GGML. An LLM running inside an LLM.
Vector DB in pure NumPy — no dependencies, no server. Stores embeddings in a custom .ctx format with binary embeddings for speed. vlite 2 shipped lighter and faster than v1.
Dead simple, portable, and extremely lightweight by design.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I built the #1 ChatGPT plugin that lets you ask questions about any PDF you upload -- this was made before you could just upload a PDF to ChatGPT which is why it was so popular. To monetize I prompt-injected across the various plugins I made with Stripe links (that conveniently rendered as markdown) to use the users context to try and sell them why they should pay for the plugin.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
I will write more about this at some point in the future.
Simple proxy that redirects to a random Art Blocks generative art piece on each request. A lightweight way to discover new on-chain generative art.
Semantic search over your Twitter timeline using GPT-3. Search, sort, and summarize tweets by meaning rather than keywords. Built during the early GPT-3 API days.
CLI tool that analyzes Wireguard config files and prints latency diagnostics for each peer. Useful for debugging VPN performance across distributed tunnel configurations.
Real-time DeFi liquidation tracker. Monitors on-chain liquidation events and posts them to Twitter as they happen. Built during the DeFi summer era.
VC dealflow engine that aggregated and ranked startup deals from multiple sources. Automated the discovery and evaluation pipeline for venture capital.
Website analytics platform running entirely on Cloudflare Workers. Fast, lightweight, and privacy-friendly — no cookies, no tracking scripts, just edge-computed pageview data.
SMS bridge for Twitter DMs. Send and receive Twitter direct messages via text message — useful when you want to stay connected without opening the app.
Networking and clustering system built on top of Docker Swarm. Handled service discovery and load balancing across distributed nodes.
LLM-powered text summarizer. Part of the Wordflow content platform — paste long-form content and get concise summaries.
AI-generated content media network. The platform that spawned Wordflow Summarizer and Wordflow Ads — exploring what happens when you let LLMs generate and distribute content at scale.
Turn regular 2D photos into 3D parallax effects using AI depth estimation. Upload a photo, get a Facebook-style 3D photo with convincing depth.
Stripe-inspired multicolor gradient generator. Renders smooth animated WebGL gradients with configurable color palettes — the kind of background that makes marketing pages feel premium.
Fine-tuned GPT-2 on hundreds of thousands of news articles to generate news articles, running GPT-2 124M inference on a cluster of Google Colab notebooks running on 8 Google accounts that sent the generations to a cluster of 4 Raspberry Pis that were running Ghost. This was one of the first projects I did that really made me think about how to scale and deploy models in a way that was efficient and cost effective.
The idea was think about AI-safety in a realistic scenario -- could a small LLM spread fake news cheaply and easily? Over the course of 7 months the blog network started backlinking to each other and eventually got 12 million impressions across Facebook, Reddit, and Hacker News.
From my understanding of interviewing many users (and almost signing a loi with the Washington Post in 2019) it was clear AI-safety, governance, and red-teaming was important to understand implications of models regardless if they were small. In this scenario many users simply reposted and shared articles purely based on headlines and the OG image they saw to continue narratives they believed in -- for instance some articles BigBird(the whole AI/serving stack I made) made were around local politics -- these articles were more widely shared in Facebook groups and despite them getting many likes and share, very few (if any) actually read to the bottom of the page. Even in 2019 124m paremeter models were barely coherent enough to pass it off as human written. Shortly after due to AI-safety concerns I made the effort to de-index all NotRealNews related pages from the internet.
Fine-tuning scripts for GPT-2 774M and 1.5B parameter models using Google's S3 optimizer. One of the early open-source efforts to make large language model fine-tuning accessible.
PPO reinforcement learning agent trained to walk in a simulated environment. One of my first RL projects — watching a policy learn to coordinate limbs from random noise.
I grew up taught that I could do anything, so every chance I had I wanted to see the extreme limit of what I could do. Sometime during my sophomore year of high school I was frustrated the robotics team wasn’t doing anything really that novel or interesting. Why did it take a team of 30 to put together mostly off the shelf parts to ultimately face against other teams in an effectively zero sum game?
I wanted to challenge what I could do with a stripped down RC car, Google, a few Raspberry Pis and an Arduino. I spent most of this summer learning how to properly interface compute, microcontrollers, cameras, sensors, CAD, and budgeting.
By the end of the summer I built a sensor-fusion system for a RC car to be able to navigate a track with a neural network trained end-to-end. This was probably the most transformational period in my life, realizing that if I wanted to do anything I could with enough intensity, with no funding or serious mentors.
In elementary and middle school I had a bunch of balsa, bass, and pine wood to try and build projects with. One such project was building a life-size model of a trojan horse and despite stroling it on a dolley in middle school my teacher(now fired) gave me a C for the supporting writeup.
The ability to go from nothing into something was an extremely motivating force -- when I was part of the SciOly team I started on the team focused on building bridges or structured that could withstand a lot of weight.
And to get this done I needed how to get my fingers stuck with Gorrila Glue a lot. I didn't trust anyone to get it right and didn't think anyone could do it as I could -- I learned how to bend wood by moisterizing the balsa wood over steaming pans and how to properly think about tension and build the entire bridge or structure.
In the end this was one of a few wood bridges and structures I made that probably won some prize I can't fully remember. But it did weigh 15 grams and supported well over 15 kilograms of weight.