The problem
Music apps are good at recommending songs that already exist. None of them write one about your day: the weather where you are, the headlines you care about, what's on your calendar. That's a small, slightly silly gap, which is why I liked it as a hackathon idea. It also looked hard enough to be interesting, because it means generating a sung track, not just a playlist.
What I built
TuneTools makes you a new song of about 60 seconds every day, written from your own context. We built it as a team of two for Kiroween, the hackathon Kiro (AWS's agentic IDE) ran on Devpost from October 31 to December 5, 2025. We entered the "Frankenstein" category, whose brief was to stitch incompatible technologies into one app. I built the music pipeline, the spec and the production deploy; Sebastian took the spec and built most of the application (126 of the 163 commits are his, 35 are mine).
What it does
- Your day as input. It pulls the weather for your location, headlines from topics you pick and, if you connect it, your Google Calendar.
- Lyrics and music. An LLM writes a verse and a chorus about that day, and an open music model sings them over a generated track in the genres you chose.
- Settings that shape the song. Preferred topics make up 70% of the news pulled in, and your genres steer the style, instrument, mood and voice.
- Weekly albums. Each week's songs become an album with a generated cover, pressed into the shape of a vinyl record, with a share link.
Why these tools
YuE is the core: an open model that sings lyrics over generated music, which is exactly what a song about your day needs. It's actually three models (a 7B planner, a 1B audio stage and an upsampler), about 18.5 GB together.
RunPod serverless runs YuE, because nobody was going to pay for a GPU that sits idle 23 hours a day waiting for one song. The weights download once to a network volume on the first request instead of being baked into the container image, so later requests go straight to generating. That's about 12 minutes and ~$0.23 for a cold first song, about 7 minutes and ~$0.09 once the models are cached. Seven minutes is why TuneTools is a daily song and not a tap-for-a-song app.
OpenAI's gpt-4o-mini writes the lyrics, with Gemini 2.5 Flash as the fallback if it fails. Supabase stores users, songs and albums. FastAPI on Railway calls the news, weather, calendar and GPU services, and the React frontend runs on Vercel.
Kiro was the point of the hackathon, and it's how two people worked without constant syncing. I wrote a spec with it (requirements, a design doc and 34 numbered tasks), plus steering docs and the Supabase MCP server so the agent could create tables itself. Sebastian worked through the task list; his commits line up with it.
What was hard
For a while the songs stopped at about 25 seconds, somewhere in the chorus. There were two causes. The LLM kept adding a bridge or a second verse, and YuE only sings the first two sections, so the chorus never arrived. I rewrote the prompt to be blunt, with exact line counts and a "WRONG Examples" block in capitals. The other cause was that YuE generates tokens, not seconds, and our cap was too low. Raising --max_new_tokens from 2500 to 4000 made most of the difference, and also made every song cost more GPU time.
Cost was the other fight. Every song costs real money, and anyone can open a demo link on Devpost. The daily limit went from 2 to 5 and back to 2 within minutes, which sums up the project's economics: users want to press the button again, and every press costs money.
What it became
We submitted to Kiroween before the December 5 deadline, with the public repo, the .kiro folder, a demo video and the Devpost page. The landing page is still live on Vercel. The app works end to end: sign up, pick your topics and genres, connect Google Calendar or skip it, press one button, and several minutes later there's a song about your Tuesday on a record-shaped cover with a share link.
It was never used by anyone beyond us and the people we showed it to, and I'd rather say that than make up a number.