How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Fallback chains — Ai Mastery

Day 18 · ~11 min●

When the primary model fails — outage, rate limit, parse error — you don't crash. You fall back. The pattern is a list of strategies tried in order:

python

def answer_with_fallback(query):
    for strategy in [primary, secondary, from_cache, refuse]:
        try:
            result = strategy(query)
            if result is not None:
                return result
        except Exception:
            continue
    raise RuntimeError("all fallback tiers exhausted")

4 tiers: primary model → secondary model → cached response → refusal message. Each tier knows how to fail (returns None or raises) so the next can take over.

And the order matters?

From most-preferred to least-preferred. Primary is best (cheapest, freshest). Secondary is good (different provider, expensive). Cache is fast but possibly stale. Refusal is last — better than a crash.

What's the trigger for falling back?

Anything that signals "this tier failed" — a raised exception, a None return, a low-quality output (e.g., parsing failure). The chain is defensive: each tier reports failure, the next takes over.

Fallback chains — graceful degradation

python

def try_chain(query, strategies):
    """Try each strategy in order. Return first successful (non-None, non-raising) result."""
    last_err = None
    for strategy in strategies:
        try:
            result = strategy(query)
            if result is not None:
                return strategy.__name__, result
        except Exception as e:
            last_err = e
            continue
    raise RuntimeError(f"all strategies failed; last error: {last_err}")

Tier design

Tier	Speed	Cost	Quality	Failure mode
Primary model	Slow	High	Best	Outage, rate limit
Secondary model	Slow	High	Good	Outage
Cached response	Instant	Free	Stale	Cache miss
Static refusal	Instant	Free	Generic	None — always works

A real chain has 3-4 tiers. More than that, you're papering over a deeper architectural issue.

What "failed" means per tier

Primary model: 5xx, 429 (with retry exhausted), parse error
Secondary model: same
Cached: cache miss → returns None, the chain advances
Refusal: never fails — last line of defense

Composing with retry

Retry is within a tier (retry the same strategy a few times before giving up). Fallback is between tiers (try a different strategy entirely). They compose:

python

def primary(query):
    return with_retry(lambda: call_primary_model(query), max_attempts=3)

primary retries 3 times. If all 3 fail with rate-limit errors, the exception bubbles, and the fallback chain advances to secondary.

When NOT to fall back

Auth errors — falling back masks the real problem. Crash loud.
Logic errors in your code — KeyError, TypeError aren't transient. Don't catch broadly.
Tier-1 says "refused due to safety" — falling back to a different model that also refuses is fine, but falling back to one that bypasses safety is a problem. Be intentional.

Day 18 · ~11 min●

When the primary model fails — outage, rate limit, parse error — you don't crash. You fall back. The pattern is a list of strategies tried in order:

python

def answer_with_fallback(query):
    for strategy in [primary, secondary, from_cache, refuse]:
        try:
            result = strategy(query)
            if result is not None:
                return result
        except Exception:
            continue
    raise RuntimeError("all fallback tiers exhausted")

4 tiers: primary model → secondary model → cached response → refusal message. Each tier knows how to fail (returns None or raises) so the next can take over.

And the order matters?

What's the trigger for falling back?

Fallback chains — graceful degradation

python

def try_chain(query, strategies):
    """Try each strategy in order. Return first successful (non-None, non-raising) result."""
    last_err = None
    for strategy in strategies:
        try:
            result = strategy(query)
            if result is not None:
                return strategy.__name__, result
        except Exception as e:
            last_err = e
            continue
    raise RuntimeError(f"all strategies failed; last error: {last_err}")

Tier design

Tier	Speed	Cost	Quality	Failure mode
Primary model	Slow	High	Best	Outage, rate limit
Secondary model	Slow	High	Good	Outage
Cached response	Instant	Free	Stale	Cache miss
Static refusal	Instant	Free	Generic	None — always works

A real chain has 3-4 tiers. More than that, you're papering over a deeper architectural issue.

What "failed" means per tier

Primary model: 5xx, 429 (with retry exhausted), parse error
Secondary model: same
Cached: cache miss → returns None, the chain advances
Refusal: never fails — last line of defense

Composing with retry

Retry is within a tier (retry the same strategy a few times before giving up). Fallback is between tiers (try a different strategy entirely). They compose:

python

def primary(query):
    return with_retry(lambda: call_primary_model(query), max_attempts=3)

primary retries 3 times. If all 3 fail with rate-limit errors, the exception bubbles, and the fallback chain advances to secondary.

When NOT to fall back

Auth errors — falling back masks the real problem. Crash loud.
Logic errors in your code — KeyError, TypeError aren't transient. Don't catch broadly.
Tier-1 says "refused due to safety" — falling back to a different model that also refuses is fine, but falling back to one that bypasses safety is a problem. Be intentional.

Fallback chains — graceful degradation

Tier design

What "failed" means per tier

Composing with retry

When NOT to fall back

Fallback chains — graceful degradation

Tier design

What "failed" means per tier

Composing with retry

When NOT to fall back

Fallback chains — graceful degradation

Tier design

What "failed" means per tier

Composing with retry

When NOT to fall back

Sign up to practice

Fallback chains — graceful degradation

Tier design

What "failed" means per tier

Composing with retry

When NOT to fall back

Sign up to practice