← All sessionsHomeSearch
AI Sprints (Live Weekend Programs)·The Open Source Playbook Sprint·2:30:53

AI Sprint: The Open Source Playbook — Day 2 (Weights 101, OpenCode, and the Subsidy Math)

Dileep Head of Generative AI Education at Outskill — the intermediate-to-advanced day: models 101 through a DJ-mixer analogy, a live open-source build with hot-swapped models, and deliberately contrarian commentary on the week's hype cycle · Sumedha Sprint host — certificates (Google Form, both days required), recordings navigation, and the Catalyst/Engineering program close (8 alumni seats, Calendly funnel)

Session map

THE MECHANICSTHE ECONOMICSTHE JUDGMENTWeights 101the DJ-mixer model of training, fine-tu…OpenCode + OpenRouterthe open-source coding lane with a visi…The subsidy mathyou are not the customerThe model-council buildspec handoffs and hot-swapped modelsLoop and graph engineering, h…
The mechanicsThe economicsThe judgment
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — the mechanics flow into the economics, then into the judgment. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. Weights explained without math: the mixer's KNOB is the parameter, its SETTING is the weight, training is the apprentice learning the settings by listening, fine-tuning is the Hans-Zimmer apprentice adapting to AR Rahman, quantization is 'low/medium/high' instead of 6.5/7.5 — compression for trillion-parameter scale.
  2. The three-tier recap in music: song only = closed; song + mixer snapshot = open weights; + the music sheets of every instrument = open source (Beethoven's symphonies are open source; a paid composition is not).
  3. The moment being taught: 'for the very first time, the open weights models have reached a level where they are beating closed source models' — Kimi K3 as planner, GLM 5.2 as executor, run through OpenCode + OpenRouter with full per-model cost visibility.
  4. The subsidy math nobody says out loud: the $20 Claude plan burns ~$400 of API-equivalent credits, $100 ≈ $2,000, $200 ≈ $4,000 — subsidized because 'you are not the customer'; Anthropic's revenue is B2B ('Lovable is one of the biggest customers of Anthropic').
  5. The live build is honest to a fault: a multi-model 'model council' app planned by Kimi K3, hot-swapped to Grok on server errors, executed by GLM 5.2, handed off via spec files ('day shift and night shift'), ~$1 spent — and left unfinished on camera with '2 to 2.5 hours of focused work' remaining.
  6. The hype check closes it: loop engineering can route you 'from New York to San Francisco via the moon' on your token bill; graph engineering is 'loops with proper handoffs' (≈LangGraph) — 'people tweeting about this work at OpenAI. They have unlimited tokens... don't try to kill a mosquito with a nuclear missile.'

The concepts

01

Weights 101: the DJ-mixer model of training, fine-tuning, and quantization

Hans Zimmer trains an apprentice sound-mixer. That one image carries parameters, weights, training, fine-tuning, and quantization without a single equation.

The mapping: each mixer KNOB is a PARAMETER (bass-guitar volume, vocal level); the knob's learned POSITION is the WEIGHT; TRAINING is the apprentice listening to many songs with the master until the settings come out right; different artists need different settings the way different models weight differently (Yanni's piano-hero mix vs The Corrs' violin-forward mix). FINE-TUNING is the trained apprentice moving from Hans Zimmer to AR Rahman — not relearning mixing, just re-tuning subtleties (Sufi vocals) to a new style. QUANTIZATION is compressing the snapshot: 'instead of giving the exact number, I'm just saying low' — necessary when the snapshot spans trillions of parameters.

He is explicit about the pedagogy: 'I'm purposefully skipping technical terms... these are extreme mathematical concepts' — the mixer image is a visual anchor, with Perplexity assigned for anyone wanting the formal versions. The hardware reality-check rides along: fine-tuning needs 'extreme hardware'; local open-weights work wants 128GB-class memory; 16GB RAM is the bare minimum for small local models.

Worked example · from the session

The three-scenario quiz run on the room: song only → closed; song + mixer settings → open weights; + music sheets per instrument → open source — with Beethoven as the standing open-source case.

Why it matters

Every open-weights decision downstream (which model, what license, what hardware, quantized or not) reads directly off this one analogy.

People get this wrong

Fine-tuning a model is a smaller version of training it.

It presupposes full training — you adjust an already-learned configuration to a style or domain. And it still needs serious hardware, unlike merely RUNNING a quantized snapshot.

Weights 101: the DJ-mixer model Training sets every knob Weights the mixer snapshot Fine-tuning nudges some knobs Quantization rounds them smaller Runs locally Ollama-class hardware Open weights give you the mixer, not the music sheets — enough to perform, not enough to recreate
The DJ-mixer: training sets the knobs, fine-tuning nudges, quantization rounds
The knob is the parameter. The setting is the weight.
For your projects

Best plain-language weights explainer in the KB to date — topic-page material for the models-101 concept cluster.

Go deeper

In one line: Parameter = adjustable control; weight = its learned value; training = learning the values from data; fine-tuning = adapting learned values to a new style/domain; quantization = low-precision compression of weights for shareability/size. Tier test: closed (output only) / open weights (snapshot) / open source (snapshot + training recipe).

'The knob is the parameter. The setting is the weight' ()

Fine-tuning ≠ retraining: the Zimmer→Rahman move keeps the craft, adjusts the subtleties ()

Quantization as phone-call compression: low/medium/high beats reciting 6.5/7.5/12 at trillion scale ()

Scale quoted: recent models named in the trillions of parameters ()

Hardware honesty: fine-tuning and serious local inference are hardware problems first ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Where do fine-tuning and quantization each act on the mixer?

Fine-tuning MOVES the knobs slightly for a new style; quantization ROUNDS the reported positions into coarse bands so the snapshot travels light. One changes values, the other changes precision.

02

OpenCode + OpenRouter: the open-source coding lane with a visible bill

'How many of you face these problems... suddenly it says you have hit the session limit. You are very, very confused as to why.' The open lane's answer: a bill you can read, per model, per task.

OpenCode is the open-source Claude Code analog: terminal AND desktop interfaces, free to use with your own keys, optional plans (Zen $20 — curated stronger models; Go $10 — Grok 4.5/GLM 5.2/Kimi K3 tier). His recommended wiring: attach an OpenRouter key (300+ models) and pick per task — Kimi K3 to think and plan, GLM 5.2 to execute — checking the OpenRouter activity page as the meter ('I have been using 1.8 dollars of GLM 5.2 and 0.19 of Kimi K3. I am in control').

Two ecosystem facts elevate it: SKILLS ARE PORTABLE — 'install this skill' + a GitHub link installed superpowers and OmniRoute inside OpenCode, the same skills used in Claude Code and Codex; and the tool field is CONVERGING — 'all of these tools have become more or less one and the same... it is just up to your taste' (Kilo Code, Cline, Antigravity all acknowledged). Known weakness, stated: parallel sub-agents are visible and smooth in Claude Code/Codex, murky in OpenCode — his workaround is parallel chat sessions on the same folder.

Worked example · from the session

The OmniRoute install: paste the repo link, 'install this,' sign in (default password 'change me') — an auto-router that sends each request to the best model, demonstrated then deliberately set aside ('not part of the session').

Why it matters

This is the practical lane for anyone whose subscription tokens expire or whose budget is small — most of the capability, all of the cost visibility.

People get this wrong

Leaving Claude Code means losing your workflow (skills, agents, habits).

Skills and folder-based workflows port across the converging tools — what changes is the bill's visibility and the model menu.

For your projects

Directly relevant to the usage-meter dance in this project — a BYOK lane exists when subscription opacity costs more than API transparency.

Go deeper

In one line: OpenCode: open-source coding agent (terminal/desktop), BYOK-first (OpenRouter recommended), optional $10/$20 plans; skills installable from GitHub repos; model-per-task switching (K3 plan / GLM execute); weakness: sub-agent parallelism opacity (workaround: parallel sessions per folder). Convergence thesis: pick by taste, keep the folder as the constant.

'OpenCode is free to use. I'm using my own API key. This is like a BYOK policy' ()

Control as the argument: choose the model per use case, see the spend per model ()

Skills transcend the tool — the same GitHub-installed skills run in Claude Code, Codex, and OpenCode (0:52:14... 1:14:34)

'The only thing common is my folder. I point Claude as well as Codex to the same folder' — his actual multi-tool workflow ()

His honest split: '50 percent Claude, 50 percent Codex' daily; open tools are the tinkering lane ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why does he route planning to Kimi K3 but execution to GLM 5.2?

K3 is the strongest open-weights reasoner (worth its higher price for decisions); GLM is cheap and capable for the long token-heavy execution stretch — spend follows the value of the tokens.

03

The subsidy math: you are not the customer

The $20 plan spends like $400 of API credit. The natural question — 'are they crazy?' — has a B2B answer.

Community measurements he cites: running identical tasks through API keys vs subscription plans shows the $20 Claude plan delivering ~$400 of API-equivalent usage before session limits, ~$2,000 on the $100 plan, ~$4,000 on the $200 plan. The subsidy works because only ~10% of subscribers are power users; the rest use a fraction. And it persists because consumer subscriptions aren't the business: 'Anthropic doesn't earn money on you... they earn money with B2B' — with Lovable named as 'one of the biggest customers of Anthropic' (every Lovable build runs Anthropic models underneath). His pointed corollaries: that's why the Fable-meme experience is tolerable to the vendor ('you are not the customer'), and why Anthropic skips images/video for coding.

The decision rule that falls out: HEAVY users should ride the subsidized subscriptions; LIGHT/casual users may do better on BYOK open-weights; and everyone should know which they are before believing either bill.

Worked example · from the session

The Fable meme as exhibit A: thinks 25 minutes, hits the session limit before answering — infuriating for consumers, irrelevant to the B2B revenue line.

Why it matters

It reframes every plan-vs-API decision from 'which is cheaper' to 'which side of the subsidy are you on' — and explains vendor behavior that otherwise looks like neglect.

People get this wrong

API pricing shows what subscribers 'really' consume — so subscriptions are a ripoff.

The opposite: subscriptions are heavily subsidized. The catch is opacity and session limits, not price.

It is Fable who is coming, thinking for 25 minutes... the context limit is hit, and therefore, Fable returns back without giving the answers.
For the 20 dollar plan, actually, you're using 400 dollar worth of credits.
Anthropic doesn't earn money on you... they earn money with B2B.
For your projects

Quantifies yesterday's advice: plan credits are ~20x cheaper than the usage-credit overflow — protect the plan meter, avoid the paid overflow.

Go deeper

In one line: Subscription plans are loss-leader subsidized (~20x API-equivalent at the $20 tier per community measurements) because consumer revenue is secondary to B2B API revenue (Lovable-class customers). Rule: heavy users exploit the subsidy; light users consider BYOK; vendor priorities follow the paying side.

The measured ratios: $20→~$400, $100→~$2,000, $200→~$4,000 (community-measured, as stated) ()

The 10%-power-user cross-subsidy makes the ratios sustainable ()

'Lovable is one of the biggest customers of Anthropic' — the B2B revenue anchor ()

'They don't get any revenue by making you happy' — the product-priority decoder ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Given the subsidy, when would BYOK ever win?

When usage is light or spiky (subsidy unused), when session opacity costs planning time, or when the task runs fine on open-weights models priced far below the closed models the subsidy covers.

04

The model-council build: spec handoffs and hot-swapped models

Kimi K3 plans, crashes under demand, Grok picks up mid-thought, GLM executes — and the context survives because the plan lives in FILES, not in any model's memory.

The build target: a 'model council' (multiple models answer a question blind, critique each other, a synthesis model finds agreements/disagreements and a recommendation — Perplexity's model-council feature rebuilt open). The workflow demonstrates the portable practices: superpowers skill drives brainstorm → clarifying questions (interaction mode, model source, debate structure, stack, key handling, no history); a design borrowed from superdesign.dev by pasting its prompt; plan mode writes DESIGN AND IMPLEMENTATION SPECS TO FILES — his 'day shift and night shift' doctrine: 'when somebody is working on day shift, they have logs... the night shift employee looks at the logs and takes the handover.' That file-based handoff is what makes the mid-build model swaps survivable (K3 → Grok on server errors → GLM for parallel execution).

The honesty is the lesson's second half: OpenCode's parallel sub-agents are less visible than Claude Code's; errors pile up; his stated intuition — 'it could not be as clean as when I built with Claude Code... same model, same harness, protected environment' — and the close: '2 to 2.5 hours of focused work' remain, shown unfinished. Total spend for the on-camera portion: ~$1. Model-choice philosophy stated twice: 'don't try to chase which model is good for what. Make it experiential.'"

Worked example · from the session

The swap moment: Kimi K3 dies mid-plan ('insane demand nowadays'), Grok resumes from the written specs without losing the thread — the day-shift log doing exactly its job.

Why it matters

The build teaches the transferable core (specs as handoff, model-per-phase, visible costs) precisely BECAUSE the tooling misbehaves — a clean demo would have hidden the practices that matter.

People get this wrong

Switching models mid-project means starting over.

With plan/spec files as the shared log, models are interchangeable shift workers — the folder is the memory.

It is like day shift and night shift... the night shift employee comes in, looks at the logs, and then takes the handover.
Don't try to chase which model is good for what. Make it experiential.
For your projects

His day-shift analogy is your pipeline's architecture: open-items.yaml is the shift log that lets any chat (or model) take the handover.

Go deeper

In one line: Build pattern: skill-driven brainstorm → clarifying questions → plan mode → design+implementation specs written to files → model-per-phase execution (planner strong, executor cheap) → swap models freely against the specs. Costs metered per model; polish honestly deferred when the tool underdelivers.

Specs-to-files as the handoff mechanism — the anti-amnesia move for multi-model work ()

'If one model is failing, I can always swap another model and continue the work from there' ()

Parallel sub-agents: Claude Code/Codex 'do this very well'; OpenCode's are opaque — parallel sessions per folder as the workaround ()

'Which model for which work? That is like asking which song should I listen to for which mood' ()

Cost discipline live: benchmark the balance before building, check after (~$1) ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why did the model swaps not lose the project?

The state lived in files (design doc, implementation plan, specs) that any model could read — the handoff was environmental, not conversational.

05

Loop and graph engineering, hype-checked by the token bill

'I can travel from New York to San Francisco via the moon also... the charge of this entire trip is 10,000 dollars.' That's a loop without controls, priced.

The definitions, fairly given: LOOP ENGINEERING (viral via the Claude Code creator's 'I stopped using prompts. I use loops') = listen/adjust/test/repeat against a satisfaction criterion — a feedback mechanism, excellent concept; GRAPH ENGINEERING (viral via the OpenClaw creator's 'we moved from loops to graphs') = 'a collection of loops with proper handoffs and controls' — the production-crew image, each specialist finishing before handing off; 'very, very similar' to LangGraph.

Then the check: without explicit controls a loop optimizes its way through arbitrary token expense ('you will easily incur thousand dollars of billing if you are going along with the loops without proper controls'); and the people evangelizing these patterns 'work in OpenAI. They have got unlimited tokens to experiment with.' The verdict is calibrated, not dismissive: 'excellent concepts... they are meant to solve different problems' — try them with cost awareness, drop them if they don't pay, and 'don't try to kill a mosquito with a nuclear missile.' A proper graph-engineering explainer is promised for Vibhav's YouTube."

Worked example · from the session

The perfectionist loop: a Hans Zimmer-grade checker runs the listen-adjust-test cycle a hundred times — magnificent output, and a bill that scales with the perfectionism.

Why it matters

This is the KB's second reading on loop/graph engineering (after Catalyst s15's enthusiastic one) — a deliberate counterweight from the same organization's education lead, priced in tokens.

People get this wrong

The newest orchestration pattern is the professional default.

Patterns are priced tools. The professionals evangelizing them often don't pay for tokens; you do — adopt with caps and evidence.

People who are tweeting about this work in OpenAI. They have got unlimited tokens to experiment with.
Don't try to kill a mosquito with a nuclear missile.
For your projects

Pair this with s15 on any loop-engineering topic page — the two sessions are the argument and its price tag.

Go deeper

In one line: Loop = goal-directed act/measure/adjust cycle with a stop criterion — powerful, token-unbounded without controls. Graph = loops composed with explicit handoffs/controls (≈LangGraph). Adoption rule: budget caps first, experiential testing second, hype discounting always (evangelists often have free tokens).

Origin stories as told: Claude Code's creator (loops), OpenClaw's creator (graphs) — 'this week's buzzword of the day' ()

The moon-route failure mode: loops satisfy goals by any affordable path — YOUR affordability, not theirs ()

'People who are tweeting about this work in OpenAI... unlimited tokens' — the incentive check ()

Balanced verdict: good frameworks, different problems, test-and-drop freely ()

Explainer promised on Vibhav's YouTube channel — watch for it ()

▶ Watch this taught:

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

How does this session's loop verdict differ from Catalyst session 15's?

S15 teaches loops as the core gift (checker-enforced quality); this session prices them — both are right: loops WITH controls are the tool, loops without controls are the bill. The synthesis is 'loops, capped.'

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01Weights 101: the DJ-mixer model of training, fine-tuning, and quantizationParameter = adjustable control;

Parameter = adjustable control; weight = its learned value; training = learning the values from data; fine-tuning = adapting learned values to a new style/domain; quantization = low-precision compression of weights for shareability/size. Tier test: closed (output only) / open weights (snapshot) / open source (snapshot + training recipe).

'The knob is the parameter. The setting is the weight' ()

Fine-tuning ≠ retraining: the Zimmer→Rahman move keeps the craft, adjusts the subtleties ()

Quantization as phone-call compression: low/medium/high beats reciting 6.5/7.5/12 at trillion scale ()

Scale quoted: recent models named in the trillions of parameters ()

Hardware honesty: fine-tuning and serious local inference are hardware problems first ()

02OpenCode + OpenRouter: the open-source coding lane with a visible billOpenCode: open-source coding agent (terminal/desktop), BYOK-first (OpenRouter recommended), optional $10/$2…

OpenCode: open-source coding agent (terminal/desktop), BYOK-first (OpenRouter recommended), optional $10/$20 plans; skills installable from GitHub repos; model-per-task switching (K3 plan / GLM execute); weakness: sub-agent parallelism opacity (workaround: parallel sessions per folder). Convergence thesis: pick by taste, keep the folder as the constant.

'OpenCode is free to use. I'm using my own API key. This is like a BYOK policy' ()

Control as the argument: choose the model per use case, see the spend per model ()

Skills transcend the tool — the same GitHub-installed skills run in Claude Code, Codex, and OpenCode (0:52:14... 1:14:34)

'The only thing common is my folder. I point Claude as well as Codex to the same folder' — his actual multi-tool workflow ()

His honest split: '50 percent Claude, 50 percent Codex' daily; open tools are the tinkering lane ()

03The subsidy math: you are not the customerSubscription plans are loss-leader subsidized (~20x API-equivalent at the $20 tier per community measuremen…

Subscription plans are loss-leader subsidized (~20x API-equivalent at the $20 tier per community measurements) because consumer revenue is secondary to B2B API revenue (Lovable-class customers). Rule: heavy users exploit the subsidy; light users consider BYOK; vendor priorities follow the paying side.

The measured ratios: $20→~$400, $100→~$2,000, $200→~$4,000 (community-measured, as stated) ()

The 10%-power-user cross-subsidy makes the ratios sustainable ()

'Lovable is one of the biggest customers of Anthropic' — the B2B revenue anchor ()

'They don't get any revenue by making you happy' — the product-priority decoder ()

04The model-council build: spec handoffs and hot-swapped modelsBuild pattern: skill-driven brainstorm → clarifying questions → plan mode → design+implementation specs wri…

Build pattern: skill-driven brainstorm → clarifying questions → plan mode → design+implementation specs written to files → model-per-phase execution (planner strong, executor cheap) → swap models freely against the specs. Costs metered per model; polish honestly deferred when the tool underdelivers.

Specs-to-files as the handoff mechanism — the anti-amnesia move for multi-model work ()

'If one model is failing, I can always swap another model and continue the work from there' ()

Parallel sub-agents: Claude Code/Codex 'do this very well'; OpenCode's are opaque — parallel sessions per folder as the workaround ()

'Which model for which work? That is like asking which song should I listen to for which mood' ()

Cost discipline live: benchmark the balance before building, check after (~$1) ()

05Loop and graph engineering, hype-checked by the token billLoop = goal-directed act/measure/adjust cycle with a stop criterion — powerful, token-unbounded without con…

Loop = goal-directed act/measure/adjust cycle with a stop criterion — powerful, token-unbounded without controls. Graph = loops composed with explicit handoffs/controls (≈LangGraph). Adoption rule: budget caps first, experiential testing second, hype discounting always (evangelists often have free tokens).

Origin stories as told: Claude Code's creator (loops), OpenClaw's creator (graphs) — 'this week's buzzword of the day' ()

The moon-route failure mode: loops satisfy goals by any affordable path — YOUR affordability, not theirs ()

'People who are tweeting about this work in OpenAI... unlimited tokens' — the incentive check ()

Balanced verdict: good frameworks, different problems, test-and-drop freely ()

Explainer promised on Vibhav's YouTube channel — watch for it ()

Tools referenced

ToolCoverageMomentContext
OpenRouterdemonstratedThe BYOK spine: provider config in OpenCode, per-model activity as the meter
PerplexitydemonstratedThe model-council feature being rebuilt; also the assigned lookup tool for technical terms
Claude CodementionedThe comparison baseline throughout — cleaner harness, better sub-agent visibility; 50% of his daily work
CodexmentionedThe other 50%; also 'does parallel sub-agents very well'
LovablementionedNamed as one of Anthropic's biggest B2B customers — the subsidy math's anchor
OllamamentionedLocal-model route attachable to OpenCode for capable hardware

Action items

Resources mentioned

Resources
  • docOpenCode (site + installers; Zen/Go plan pages)
  • docsuperpowers skill + OmniRoute (GitHub repos, installed live by link)
  • docsuperdesign.dev (design prompt gallery used for the council UI)
  • docSprint certificate Google Form (both days required; shipped next day) + LMS recordings path (AI Masterclasses & Sprints → Resources & Recordings)
  • docProgram close: Catalyst (8 alumni seats, learn/apply/scale phases, ~6 months, monetization focus) and GenAI Engineering Fellowship (coders; RAG-heavy phase 1) — Calendly funnel, cohorts start August

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
Dilip / Duleep / the lip / Delhi (name contexts)Dileep
craft engineeringgraph engineering
Landgraf / LandgraaffLangGraph
Climb (tool list)Cline (open-source coding agent)
kilo codeKilo Code
GROC 4.5 / Grok build / product build (one instance)Grok 4.5 / Grok's build tier
Kimmy k 3 / Kiwi / qme k 3 / Qmee / Kimmy KhetriKimi K3
Apertisapprentice
the Kars / the Cause / the course (band contexts)The Corrs
AR Rahman / Sufi vocals(correct as heard)
2800000000000 / 3000000000000 models2.8T / 3T parameters (trillion-parameter models)
5.5 / 5.6 / GPT Sol(frontier-model comparisons as heard — likely GPT-5.5/5.6 tiers; 'Sol' unverified)
zed dot aized.ai (as heard, in the Zen plan model list)
super pass / super power skillthe superpowers skill
omniroter / Omnipath / OmniRoots / omniroteOmniRoute
super design dot devsuperdesign.dev
change me (default password)(correct as heard — OmniRoute's default)
Winsev and Devon / Hermitage (recordings list)WindSurf and Devin / Hermes (prior sprint names)
Vibhav's YouTube(Outskill-affiliated channel — as heard; likely Vaibhav)
high at the rate Outskill dot comhi@outskill.com

True on recording day — verify before relying