DEV Community: john lee

Three hackathon agents, one card-free API key: what I learned building on Qwen Cloud

john lee — Tue, 07 Jul 2026 12:11:44 +0000

Over the past month I shipped three entries to the Global AI Hackathon Series with Qwen Cloud — an autonomous bounty-hunting agent, a GitLab CI diagnosis agent, and an AI "showrunner" that turns one line of premise into a finished, subtitled vertical short-drama episode. All three run on the same card-free Qwen Cloud free-tier API key.

That last part matters. I'm in Malaysia, I don't put credit cards into cloud consoles for hackathons, and Qwen Cloud turned out to be one of the few platforms where a genuinely free, no-payment-method tier covers LLM, video, image and speech generation. This post is the map of the gotchas I hit so you don't have to.

Getting the key (the card-free path)

There are two signup flows and they look confusingly similar:

✅ Model Studio "Free Quota" via home.qwencloud.com/benefits — email/phone signup, ~1M tokens per model across 200+ models, no payment method required.
❌ The broader Alibaba Cloud free trial ("Activate full account", ECS etc.) — this one is card-gated.

If any screen asks for a card, you're in the wrong flow — back out.

The endpoint maze

The free-tier sk-… key works on the international endpoint only:

https://dashscope-intl.aliyuncs.com/compatible-mode/v1      # OpenAI-compatible chat
https://dashscope-intl.aliyuncs.com/api/v1/services/aigc/…  # video / image / speech

Three things that cost me hours:

Beijing-region model names don't exist on intl. Docs and blog posts written for the China region will point you at wanx2.1-* or qwen-tts — on dashscope-intl the working IDs are wan2.2-t2v-plus / wan2.1-t2v-turbo (video), wan2.2-t2i-flash (image) and qwen3-tts-flash (speech). When in doubt, probe the endpoint: an auth-valid request with a wrong model returns InvalidParameter: "Model not exist" with a request ID, which tells you your key is fine and only the name is wrong.
TTS must be called synchronously. Sending the X-DashScope-Async header to qwen3-tts-flash gets you AccessDenied: does not support asynchronous calls. Video and image are the opposite — async submit + poll.
The token-plan/MaaS endpoint 401s the free-tier key. Don't mix them up; compatible-mode/v1 is the one you want for chat.

Project 1: AutoPR — an agent that hunts open-source bounties

AutoPR scans bounty platforms every 15 minutes, triages issues with Qwen-Max (structured JSON out: {score, reason, approach, skip}), then hands tractable ones to a Qwen-Plus tool loop — six tools (list_files, read_file, search_code, write_file, run_command, finish) against a cloned repo until the tests pass, then opens the PR.

What I learned: Qwen-Max's structured output is reliable enough to be a gate (skip anything scoring < 0.45), and Qwen-Plus handles well-scoped bugs — null checks, missing coverage, small API changes — while the triage layer correctly filters out the architectural stuff it would flounder on.

Repo: https://github.com/64johnlee/autopr

Project 2: QwenPipelineGuard — CI failure diagnosis over MCP

A GitLab CI watcher that pulls failed pipeline logs and has Qwen produce a root-cause diagnosis and a suggested fix, exposed as an MCP server so any MCP-capable client can call it. The interesting part was how little glue code is needed once the chat endpoint is OpenAI-compatible — the same client library talks to Qwen with one base-URL swap.

Repo: https://github.com/64johnlee/qwen-pipelineguard

Project 3: Qwen Showrunner — premise in, episode out

The fun one. Give it "a KL hawker discovers his rival stole his recipe" and it:

writes a shot-by-shot screenplay with Qwen-Max (validated JSON: title, characters, assigned voices),
films every shot with Wan text-to-video,
voices every character with Qwen3-TTS in the spoken language,
translates subtitles into a different language (spoken 中文, subtitled English — the SEA localization angle),
cuts it all with ffmpeg into a vertical 9:16 episode.mp4 with burned subtitles.

Wan-specific lessons:

Free-tier clips are fixed at ~5 seconds. The duration parameter is accepted at submit time and then rejected at execution ("duration customization is not supported"). Episode length is therefore controlled by shot count.
Submit all shots up front, then await. Wan tasks are async; a 10-shot episode submitted in parallel renders in roughly the wall-clock time of one shot.
Video quota is metered in seconds, not tokens — and "stop-on-exhaust" means the service just stops with a 403 instead of billing you. Exactly what you want on a card-free account.
ffmpeg on Windows with CJK subtitles: one -filter_complex only, and the font path needs single quotes plus escaped colon: fontfile='C\:/Windows/Fonts/msyh.ttc'.

Repo: https://github.com/64johnlee/qwen-showrunner

Proof of deployment

The hackathon requires evidence your project actually ran on Alibaba Cloud. The Qwen Cloud console's Analytics → Usage/Logs pages are perfect for this: per-request logs with request IDs, timestamps, models and status codes. Screenshot those rather than your billing page — "running resources", not "quota remaining".

The economics

36.8K tokens and 435 requests across a week of building and demos, all inside the free tier. For the bounty agent the math is fun: at fractions of a cent per triage call and $20–$250 bounties, a low single-digit merge rate breaks even.

If you've been putting off trying the Qwen/Wan stack because you assumed it needed an Alibaba Cloud account with a card on file — it doesn't. One email signup, one key, all four modalities.

Built solo in Kuala Lumpur with an agentic coding setup (Claude Code driving the builds, Qwen models doing the runtime work). Questions welcome.

"Building an HSK Speaking Test AI: Real-time Tone Grading with Gemini

john lee — Sun, 28 Jun 2026 09:57:22 +0000

Building an HSK Speaking Test AI: Real-time Tone Grading with Gemini

I built a free Mandarin speaking assessment tool that grades tone + grammar in real time. Here's the engineering behind it.

The Problem

HSK (Chinese proficiency test) has a speaking component (HSKK), but most learners can't self-assess their level. Online tutors are expensive. Generic AI conversation tools don't grade tones.

So I built ToneTutor: a 3-minute spoken-HSK test that estimates your speaking level and identifies weak points.

The Tech Stack

Frontend:

Web Audio API (record user voice → PCM → LINEAR16)
React + TypeScript (real-time transcript display)

Backend:

FastAPI (Python) on Google Cloud Run
Gemini 2.5 Flash (real-time conversation + transcript grading)
Firestore (user sessions + results)

The Challenge:

Web Audio API records as WebM. Gemini expects LINEAR16 (WAV). iOS Safari doesn't support WebM. So:

Transcode WebM → PCM in browser (Web Audio context)
Send raw PCM bytes to backend
Backend wraps PCM in WAV header → sends to Gemini Speech-to-Text
Gemini analyzes transcript + provides HSK level estimate

The Grading Loop


python
async def grade_session(transcript: str):
    prompt = """
    Rate this Mandarin response on HSK 1-6 scale.
    Assess: tone accuracy, grammar, vocabulary range.
    Provide: level estimate + weak points.
    """
    response = await gemini.generate_content(prompt, stream=True)
    return parse_hsk_level(response)

Results

- 3-min test
- Real-time feedback
- Shareable HSK score card
- Free (limited sessions)

Open source coming soon. Built because I'm a native speaker + voice actor frustrated with generic tools.

Try it: tonetutor.tefusiang.com (free for 3 sessions)

Curious about the speech-to-text pipeline or tone grading logic? Ask below.

I built a million-scale World Cup prediction game on DynamoDB + v0 in a weekend

john lee — Wed, 24 Jun 2026 07:32:26 +0000

I created this project and this post for the **H0: Hack the Zero Stack* hackathon
(Vercel v0 + AWS Databases). #H0Hackathon*

Live demo: https://world-cup-prediction-game-psi.vercel.app
60-second walkthrough: https://youtube.com/shorts/tTPotTmi4fE

A World Cup is one of the few events where you genuinely might get hundreds of millions
of people doing the same thing at the same time. So when I set out to build a prediction
game for it, the question wasn't "can I make a CRUD app" — it was "would the data layer
survive matchday?" That's exactly the bet H0 asks you to make: prototype on the same
Amazon DynamoDB foundation real products run on, with a v0-scaffolded Next.js
frontend on Vercel.

Here's how it came together — and the one design decision the whole thing hinges on.

The app

Every match shows a 10,000-run Monte-Carlo forecast (win/draw/loss + a likely
scoreline) next to what the crowd actually picked. You call the result, earn points
(+5 exact score, +3 right outcome), and climb a global leaderboard that settles
against real results pulled from ESPN. No login — an anonymous cookie makes every visitor
a player instantly.

v0 did the frontend; I owned the data layer

v0 scaffolded a genuinely good Next.js App Router app — match cards, a pick sheet, three
tabs, SWR data fetching against /api/* — in minutes. It even left placeholder route
handlers with a literal TODO: "wire to DynamoDB." My job was to make that real without
fighting the contract v0 generated. I dropped in the sim engine + a DynamoDB data layer
and rewrote the four routes to return the exact shapes v0's TypeScript types expected.
The UI never knew the difference — it just started showing real fixtures.

The decision the whole thing hinges on: the leaderboard

Single-table DynamoDB is the easy part. The trap is the leaderboard. The naive design —
"put every user in one partition, sort by points" — is a hot partition waiting to
happen: on matchday every score update hammers one partition key.

So the leaderboard is write-sharded. A user's profile is indexed under
LB#<season>#<hash(uid) % 10> with their (zero-padded) points as the sort key. Writes
spread across 10 partitions; to read the global top-N I scatter-gather — query the
top-N of each shard in parallel and merge. A user's rank is COUNT(points > mine) summed
across shards. It's the pattern AWS literally recommends, and it means the board scales
horizontally instead of melting.

One GSI does triple duty (all-string keys):

LB#<season>#<shard> → leaderboard
DATE#<yyyymmdd> → today's slate
MPICK#<matchId> → every pick on a match (so settling fans out cheaply)

Picks bump an atomic counter on the match (that's the "crowd picked" split) inside a
transaction. On-demand capacity means I never pre-provision — matchday spikes just work.

Shippable, not a demo

The thing that makes me happiest: it's actually deployed and serving real data —
real 2026 fixtures, real sim odds, a real sharded leaderboard on real AWS — and it plugs
into a daily-content funnel I already run that sends real fans to it. The whole point of
the "zero stack" is that the weekend prototype is the production foundation. This one is.

Try it: https://world-cup-prediction-game-psi.vercel.app · built with v0 + Vercel +
Amazon DynamoDB for #H0Hackathon.