In January 2026, the American Red Cross declared a severe blood shortage. National supply fell about 35 percent in a single month, and some hospitals were down to less than a two-day reserve.

That number is scary on its own. But the part that reframed the problem for me was this:

Sometimes, the right unit already exists somewhere in the network.

It just gets promised to two hospitals at once.

Nobody has to be careless for this to happen. A hospital can submit a request. Another hospital can submit a request seconds later. The inventory dashboard may look fresh enough. The unit may appear available in both workflows.

And then one physical bag of blood has two promises attached to it.

That is the coordination failure I wanted to build against.

So I built Sanguine, a shared reservation layer for blood centers, hospital supply teams, and regional coordinators. When two facilities request the same scarce unit at the same moment, Sanguine confirms one reservation, reroutes the other request to the next compatible unit, and records every decision in an audit-ready log.

Why I made it boring on purpose

The flashier version of this project would have been a swarm of agents doing a dozen impressive things.

I deliberately did the opposite.

The entire value of Sanguine is one promise:

A blood unit is never given to two hospitals at once.

Everything else exists to make that promise true, visible, and testable.

That is why the headline metric in the app is not an abstract performance score. It is one operational number:

Double-promised units: 0

If that number ever rises, the system has failed.

Watching the guarantee hold, and break

Sanguine ships with two allocation engines and a toggle.

I fire the exact same surge at both.

In the legacy engine, two hospitals can end up with a promise for the same unit. The counter climbs.

Switch to Sanguine, run the same surge again, and the counter stays at zero.

That contrast matters because correctness is hard to trust when it is only described in words.

It is one thing to say, “This system prevents double allocation.”

It is much stronger to show the unsafe version failing right next to the safe version holding under the same pressure.

That became the core of the demo.

The choice underneath

Sanguine runs on Amazon Aurora DSQL, a distributed SQL database with strong consistency.

That property is not a backend detail here. It is the product.

When two requests collide over the same scarce unit, the database ensures that exactly one write wins. The other request does not silently create a second promise. It is retried, rerouted, and recorded.

In other words, the dangerous thing is not handled by hope, timing, or application-layer optimism.

It is blocked by the infrastructure.

The front door is plain English

A clinician or coordinator should not have to fill out a complicated form during a shortage.

So the request interface accepts plain English.

Someone can type:

half a dozen units of the universal donor type, as soon as possible

Claude on Amazon Bedrock turns that into a structured request, and the allocation engine takes it from there.

The important part is that the AI is not the source of truth. It helps with intake. The database-backed reservation layer owns the guarantee.

What I took away

Every blood shortage is partly a supply problem.

But it is also a coordination problem.

You do not fix that with a prettier dashboard alone. You fix it by choosing infrastructure that makes the dangerous thing impossible, and then letting people see that guarantee hold under pressure.

The same pattern applies to any scarce, perishable resource that must never be double-allocated.

Blood is where it matters most.

Try it: https://sanguine-eight.vercel.app

Built for the H0 Hackathon with Amazon Aurora DSQL and Vercel. #H0Hackathon

Chapter Zero — the repetitive void

I graduated recently, and like a lot of people right now I’ve spent more hours than I’d like to admit inside the job-hunt loop: same PDF, same cover letter, tweak a bullet, hit Apply, refresh an inbox that doesn’t refresh back. The market is brutal and the feedback loop is mostly silence. It is, to use a technical term, a void.

Then I came across a hackathon whose entire premise made me laugh out loud, in a good way.

The pitch was basically: the pace of AI over the last year has been anxiety-inducing; let’s take things back to how they felt in 2021, when models were small enough to tinker with and the vibe was fun and hopeful. No giant LLM, no B2B SaaS. You get 32 billion parameters, total, and you either solve a real problem for someone you know or you build something whimsical.

I picked whimsical. Track 2 — An Adventure in Thousand Token Wood. The brief: build something delightful that wouldn’t exist without AI, where the AI is doing the fun thing, not just helping you build it. Joyful is the bar.

So I made the most unserious possible answer to the most serious problem in my life. If applying for jobs is a soul-flattening void, what if you applied like you were the main character of a Broadway musical?

The idea: Open to Work: The Musical

You drop in your résumé and a job description. You add your photo. Optionally you record ten seconds of your own voice. Then you drag one slider — the Sendability Slider — and the app writes you a custom parody song about wanting that exact job, composes the music, sings it (optionally in your voice), and lip-syncs the whole number to your headshot. Out comes a shareable music video.

The slider is the whole personality of the thing. It goes 1 to 10:

- 1 — Actually Sendable ✅: clever, polished, lightly funny. You could genuinely attach it.
- 5 — LinkedIn Risky ⚠️: funny, exaggerated, still makes sense.
- 10 — HR Has Left the Chat 🔥: full unhinged parody. Desperation as an art form.

Same résumé. One slider. The lyrics, the music, the vocal energy, and the on-screen drama all morph together as you drag it. The tagline I kept coming back to: from “here’s my résumé” to “here’s my application as a music video.”

The constraint that made it fun

Here’s the thing I didn’t expect: the 32B cap made the project better!

With a powerful API, the obvious instinct is to ask, “How do I write the best prompt?” But with a strict parameter budget, the question becomes much more interesting: what is the smallest model that can do each job, and how do you connect those pieces so the whole thing still feels magical?

And the timing felt real, not just like a hackathon theme. The industry has been shifting from chasing bigger parameter counts to chasing performance per watt: small, fast, local models that can actually run on everyday machines. NVIDIA researchers have even argued that small language models are the future of agentic AI, and MarketsandMarkets projects the small language model market to grow at around 29% CAGR through 2032.

So building under a hard parameter cap did not feel like building away from where AI is going. It felt like building toward it.

That gave me one rule: the entire experience should be able to run tiny. Not a tiny model bolted onto a big app, but tiny end to end.

How it actually works

Here’s the full pipeline. Every step runs inside the Hugging Face Space: ZeroGPU for the heavier stages, plain CPU for the tiny lyricist, and no external inference APIs. The final output is not stitched together from outside services. What you render is what the Space made.

Six models, each picked to be the smallest practical tool for its part of the pipeline:

🎼 Lyrics / Producer
gpt-oss-20b — 21B parameters

👀 Photo vibe read
moondream2–1.9B parameters

🎤 Music + sung vocals
ACE-Step 1.5 turbo — 2.0B parameters

🔊 Vocal isolation
demucs — 0.08B parameters

🎭 Lip-sync
SadTalker — ~0.2B parameters

🗣️ Your-voice conversion
seed-VC — ~0.1B parameters

That’s ~25B in Full Mode — comfortably under the 32B cap. But the part I’m proudest of is Tiny Mode, where the same résumé → song → video pipeline runs at ≈2.8B params, every single model ≤4B, with zero calls to the 20B model. More on how that’s possible in a second, because this was the most interesting constraint-solving part of the build.

The Agent: a writer that critiques its own drafts

The lyrics aren’t one-shotted. The “Producer” (gpt-oss-20b) runs a small reflection loop:

read the materials → set the sendability level → choose a genre → draft the lyrics → critique its own draft against the target tone → revise → pass style tags to the music model

The critique step is the interesting one.

The model reads its own draft back and scores it against the slider target using a strict rubric: SCORE, KEEP, and FIX. Then it rewrites accordingly. The critic and the writer are the same model, just running under different system prompts.

So the loop becomes: generate → evaluate → revise.

That loop made the outputs noticeably better. A level-2 draft that came out too zany gets pulled back. A level-9 draft that played it too safe gets pushed further off the rails.

A couple of unglamorous but essential details will be familiar to anyone who has built with LLMs:

Structured output, plus a forgiving parser.
The model is asked to return a clean GENRE / TITLE / LYRICS format, with [verse] and [chorus] tags. But small models drift. So the parser does not fail dramatically when the format wobbles. It tries to salvage the song, extract the useful parts, and keep the pipeline moving.

Reasoning-channel handling.
gpt-oss uses OpenAI’s Harmony format, where the model can produce internal reasoning before the final answer. For this project, I had to separate that from the actual output and keep only the performance. Otherwise, the model’s out-loud deliberation can leak into the lyrics, which is funny once and broken every time after.

Every loop is logged and shown inside the app under “Behind the scenes: the Producer’s trace.” I also published the full set of traces as a Hugging Face Hub dataset, so anyone can inspect how the model moves from draft to critique to revision.

The Understudy: how a 0.5B model learned to do the 20B’s job

This is the heart of Tiny Mode, and it is the trick I’d most want another builder to steal.

The 20B Producer writes great lyrics, but it needs a GPU. For instant previews, the kind where you drag the slider and the song rewrites in real time, I did not want to touch GPU quota at all. So I built an understudy: a model 40× smaller that learned to imitate the Producer.

The technique is knowledge distillation: training a small “student” model to reproduce the outputs of a larger “teacher” model. It has a great lineage. Stanford’s Alpaca used a related recipe in 2023, fine-tuning LLaMA 7B on synthetic instruction-following data generated by a much larger model. Distillation has since become one of the practical ways teams turn smaller models into high-performing, cost-effective systems, often alongside quantization.

My version, concretely:

1. Synthetic data generation.
   The training set did not exist, so I had the teacher invent it. gpt-oss-20b wrote around 1,500 parody songs across 60 fictional careers, every genre, and every sendability level: a fully self-bootstrapped corpus.
2. The student.
   Base model: MiniCPM4–0.5B from OpenBMB. Half a billion parameters, and not a GPT. People keep assuming the small model is also OpenAI’s. It is not. The OpenAI model is only the teacher whose homework it studied.
3. Parameter-efficient fine-tuning.
   Instead of retraining all 0.5B weights, I trained small LoRA adapter matrices, rank 16, on the linear layers and merged them back into the model. One A100, around 30 minutes, eval loss 0.718.
4. Quantization + a CPU runtime.
   I quantized the merged model down to a 4-bit Q4_K_M GGUF and serve it through llama.cpp on plain CPU. A few hundred megabytes, zero GPU.

The payoff: in Tiny Mode, the Understudy replaces the 20B headliner entirely. You drag the fader, and a half-billion-parameter model running on CPU rewrites your song instantly. The whole pipeline drops to about 2.8B parameters.

One small, very real gotcha worth sharing: a 0.5B model loves to repeat itself. Because mine was trained on the teacher’s calibration examples, it would sometimes parrot memorized lines instead of writing from your résumé. The fix was a mix of decoding controls, including temperature, top-p, repeat penalties, and presence penalties, plus an anchor-echo detector. If the output matches a known memorized phrase, the app regenerates with a hotter temperature.

Tiny models need babysitting. That is part of the craft.

The pit orchestra: turning words into a video

Once the lyrics exist, four more small models put on the show.

ACE-Step turns the lyrics into a full sung track using diffusion-based music generation. In simpler terms, it starts with noisy audio and gradually shapes it into music, guided by the lyrics and the style tags from the Producer. When the slider changes the tags, the music changes with the words.

demucs handles source separation. It splits the generated song into vocal and instrumental stems, so the lip-sync model can follow the voice alone instead of the entire track.

seed-VC is optional, but it is the part that makes the result feel personal. It performs zero-shot voice conversion, mapping the sung vocal onto your vocal timbre from a short sample, without training a new model for each user.

SadTalker animates your headshot using the vocal track, turning the song into a performance instead of just an audio file.

And off to the side, moondream2, a tiny vision-language model, reads your photo and produces the “your headshot radiates…” one-liner.

The war stories: because nothing small is actually easy

If you only look at the parameter table, the system looks tidy.

It was not tidy.

A few scars from the build:

ZeroGPU and ACE-Step did not get along.
ZeroGPU reports torch.cuda.is_available() == True in the main process. ACE-Step then runs real CUDA checks during startup, which triggered an NVML assert and broke the GPU workers. The fix was to hide CUDA during initialization, then re-initialize the model fresh inside each GPU call. Not elegant, but necessary.

transformers 5 builds models on the meta device.
ACE-Step’s quantizer calls .item() inside __init__, which the meta device does not allow. I had to patch that init path just to get the model to load cleanly.

Dependency Tetris was very real.
I originally wanted OpenBMB’s MiniCPM-V for the photo read, but it pins transformers ~4.44, which could not share an environment with the 4.57 version ACE-Step needed. That was a version conflict, not a model-quality problem. So the photo read moved to moondream2, and MiniCPM stayed where it mattered most: the Understudy.

This is the part of small-model building that does not fit neatly on a slide. Most of the weekend was not spent on the glamorous part. It was spent making older vision code, a diffusion music model, and a CPU-quantized LLM coexist inside one Gradio Space without setting each other on fire.

What I actually took away from it

I started this because the job hunt had me feeling like a cog feeding PDFs into a void. I finished it having distilled a 20-billion-parameter model down to something that runs on a laptop CPU and still makes me laugh.

The hackathon’s whole thesis, take it back to when models were small enough to tinker with and the vibe was hopeful, turned out to be right.

Working under a tight parameter budget did not feel like a limitation. It was the most fun I have had building in months. It forced sharper design decisions, kept the system inspectable, and produced something I would actually show a friend.

Also, I now have a level-10 drill song about my own résumé.

I am going to post it on LinkedIn, because the platform is the punchline.

🎬 Try it yourself: Open to Work: The Musical · 🐜 the Understudy model · 📡 the Producer’s trace dataset

Thank you

Thank you to Hugging Face and Gradio, the organizers of the Build Small Hackathon, for a prompt that made small models feel exciting again.

The theme, “take it back to when models were small enough to tinker with,” genuinely shaped the build. Spaces gave the project a home, ZeroGPU made the heavier stages possible without hiding everything behind external APIs, and Gradio made it easy to turn the whole pipeline into something people could actually touch, test, and play with.

Built over a weekend for the Build Small Hackathon, Track 2: Thousand Token Wood. Stack: gpt-oss-20b, MiniCPM4–0.5B, ACE-Step, demucs, SadTalker, seed-VC, and moondream2, all under 32B and running inside one Hugging Face Space.

Further reading

• Distilling the Knowledge in a Neural Network — Hinton, Vinyals, and Dean on knowledge distillation
• LoRA: Low-Rank Adaptation of Large Language Models — Hu et al. on parameter-efficient fine-tuning
• Small Language Models are the Future of Agentic AI — Belcak et al. on why SLMs fit agentic systems
• Stanford Alpaca — an early example of fine-tuning a smaller model on synthetic outputs from a larger model
• Project tools: llama.cpp, ACE-Step, SadTalker, and demucs