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.

Retry with exponential backoff — Automation Patterns

Day 9 · ~12 min●

A flaky function — fails the first two calls, succeeds on the third. Naive code crashes immediately. With retry, it succeeds.

python

import time

attempts = {"n": 0}
def flaky():
    attempts["n"] += 1
    if attempts["n"] < 3:
        raise RuntimeError("transient")
    return "ok"

last_error = None
for attempt in range(1, 4):
    try:
        result = flaky()
        break
    except Exception as e:
        last_error = e
        time.sleep(2 ** attempt)    # 2, 4, 8 seconds
else:
    raise last_error

print(result)    # 'ok'

The wrapper attempted 3 times, slept exponentially between attempts, returned the result.

Why exponential — 2, 4, 8 — instead of 1 second flat?

Backoff. If the service is overloaded, hammering it every second makes it worse. Doubling gives the service room to recover. The first retry is fast (most blips clear quickly); successive retries get patient.

And for/else — what's the else doing?

Python quirk: an else on a for loop runs only if the loop completed without a break. Inside the try, success calls break. If no attempt succeeds, no break — else fires and re-raises the last error. Idiomatic for retry loops.

What about real Composio calls — same shape?

Same shape. Wrap the toolset.execute_action(...) in the same retry pattern. We use a fake function today so we can guarantee failure on attempts 1-2 — real Gmail rarely flakes on demand. The pattern is identical.

Retry with exponential backoff

python

import time

last_error = None
for attempt in range(1, MAX_ATTEMPTS + 1):
    try:
        result = SOMETHING_FLAKY()
        break
    except Exception as e:
        last_error = e
        time.sleep(2 ** attempt)
else:
    raise last_error

use(result)

Components

for attempt in range(1, MAX+1) — bounded loop; never infinite.
try/except — catch the failure; don't re-raise inside the loop.
break on success — exit early when it works.
time.sleep(2 ** attempt) — exponential backoff: 2, 4, 8, 16 ...
for/else: raise last_error — if no attempt succeeded (no break), re-raise.

When to retry

Retry only on transient failures — failures that should clear up on their own.

Error	Retry?	Why
`ConnectionError`, `TimeoutError`	yes	Network blip — usually clears
429 / Too Many Requests	yes (with longer backoff)	Rate limited — wait and try
5xx server errors	yes	Service problem — usually clears
`KeyError`, `ValueError`	no	Bug in your code — won't fix itself
401 / 403	no	Credentials wrong — escalate, don't loop

Day 7's lesson on error classes is the foundation here. Catch specific transient classes and re-raise everything else immediately:

python

try:
    SOMETHING()
except (ConnectionError, TimeoutError) as e:
    last_error = e
    time.sleep(2 ** attempt)

For v1 lessons we use the broad except Exception so the lesson stays small. Production scripts narrow it.

Cap the attempts

Three is a sensible default. Beyond that, you're masking a real problem — escalate to a human alert (day 18) instead of looping forever.

Jitter — production polish

If 1000 clients all retry at exactly 2 ** attempt, they synchronize and overload the service in waves. Add a random offset:

python

import random
time.sleep(2 ** attempt + random.uniform(0, 1))

Not needed for one-script-on-one-machine. Useful when you have many automation scripts running simultaneously.

Day 9 · ~12 min●

A flaky function — fails the first two calls, succeeds on the third. Naive code crashes immediately. With retry, it succeeds.

python

import time

attempts = {"n": 0}
def flaky():
    attempts["n"] += 1
    if attempts["n"] < 3:
        raise RuntimeError("transient")
    return "ok"

last_error = None
for attempt in range(1, 4):
    try:
        result = flaky()
        break
    except Exception as e:
        last_error = e
        time.sleep(2 ** attempt)    # 2, 4, 8 seconds
else:
    raise last_error

print(result)    # 'ok'

The wrapper attempted 3 times, slept exponentially between attempts, returned the result.

Why exponential — 2, 4, 8 — instead of 1 second flat?

And for/else — what's the else doing?

What about real Composio calls — same shape?

Retry with exponential backoff

python

import time

last_error = None
for attempt in range(1, MAX_ATTEMPTS + 1):
    try:
        result = SOMETHING_FLAKY()
        break
    except Exception as e:
        last_error = e
        time.sleep(2 ** attempt)
else:
    raise last_error

use(result)

Components

for attempt in range(1, MAX+1) — bounded loop; never infinite.
try/except — catch the failure; don't re-raise inside the loop.
break on success — exit early when it works.
time.sleep(2 ** attempt) — exponential backoff: 2, 4, 8, 16 ...
for/else: raise last_error — if no attempt succeeded (no break), re-raise.

When to retry

Retry only on transient failures — failures that should clear up on their own.

Error	Retry?	Why
`ConnectionError`, `TimeoutError`	yes	Network blip — usually clears
429 / Too Many Requests	yes (with longer backoff)	Rate limited — wait and try
5xx server errors	yes	Service problem — usually clears
`KeyError`, `ValueError`	no	Bug in your code — won't fix itself
401 / 403	no	Credentials wrong — escalate, don't loop

Day 7's lesson on error classes is the foundation here. Catch specific transient classes and re-raise everything else immediately:

python

try:
    SOMETHING()
except (ConnectionError, TimeoutError) as e:
    last_error = e
    time.sleep(2 ** attempt)

For v1 lessons we use the broad except Exception so the lesson stays small. Production scripts narrow it.

Cap the attempts

Three is a sensible default. Beyond that, you're masking a real problem — escalate to a human alert (day 18) instead of looping forever.

Jitter — production polish

If 1000 clients all retry at exactly 2 ** attempt, they synchronize and overload the service in waves. Add a random offset:

python

import random
time.sleep(2 ** attempt + random.uniform(0, 1))

Not needed for one-script-on-one-machine. Useful when you have many automation scripts running simultaneously.

Retry with exponential backoff

Components

When to retry

Cap the attempts

Jitter — production polish

Retry with exponential backoff

Components

When to retry

Cap the attempts

Jitter — production polish

Retry with exponential backoff

Components

When to retry

Cap the attempts

Jitter — production polish

Sign up to practice

Retry with exponential backoff

Components

When to retry

Cap the attempts

Jitter — production polish

Sign up to practice