Teaching LLM application development has a cost problem that appears before anyone writes code. Students need an API key, a budget, and a deployment target, and the first blocker is usually a credit-card form, not a syntax error. A workshop removes that blocker by using free model access and a free server, then makes every exercise measurable so the skills transfer to paid infrastructure. This post is a complete 90-minute workshop outline with timing, exercises, and a worked example that students can rerun locally. The infrastructure is MonkeyCode's open-source project, which currently offers free model access and a free server option, plus a 10 million token allowance as of late August 2026.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Why a workshop beats a slide deck
Most LLM tutorials stop at a single API call, which teaches nothing about latency, token cost, or deployment failure modes. A workshop forces students to hit the three problems that matter in production: metering usage, enforcing a budget, and shipping to a reachable endpoint. The format also gives the instructor a natural checkpoint after every exercise, so a student who is stuck at minute ten does not silently fail at minute eighty.
What students need before minute zero
Keep the setup list short, or the workshop becomes a support session. Each student needs a laptop with Python 3.10 or newer, a code editor, and a MonkeyCode account to access the free model tier and the free server option. They also need the base URL and API key from their dashboard, stored in environment variables rather than in source code.
- Python 3.10+ and pip installed
- MonkeyCode account with free model access enabled
- Free server provisioned as the deploy target
- Starter folder with
requirements.txtand.env.example
The 90-minute outline
The outline below assumes one instructor and up to twelve students, and it is deliberately tight on time. Each exercise ends with a visible result, which keeps the pace honest and makes debugging a shared activity.
0:00–0:10 — Setup audit
Students verify their environment before writing any application code. Exercise one is a health check: a five-line script that calls the model endpoint with a trivial prompt and prints HTTP status, latency, and token usage. Anyone who cannot finish in ten minutes has an environment problem, and it is cheaper to fix it now than during the deploy exercise.
0:10–0:25 — First metered call
Exercise two turns the health check into a reusable client that records tokens and latency on every call. Students wrap the API request in a small function that returns content, token count, and elapsed milliseconds, then log all three to the console. This is the same instrumentation pattern used in the token-forensics workflow, and it gives the class a shared vocabulary for the rest of the session.
0:25–0:45 — Build the token gate
Exercise three adds a budget: if a single call exceeds a configured token limit, the client raises an error instead of returning text. Students wire the limit to an environment variable, then test both the happy path and the failure path with a deliberately long prompt. This is the moment where the workshop becomes about engineering judgment rather than API syntax.
0:45–1:00 — Deploy to the free server
Exercise four ships the client as a tiny web service and deploys it to the free server option. Students expose one endpoint that accepts text and returns the summary plus the token count, then verify it with curl from their own machines. The deployment step is where most workshops fail, so reserve the full fifteen minutes and expect network and permission issues.
curl -s -X POST http://localhost:8000/summarize -H "Content-Type: application/json" -d '{"text": "A short paragraph to summarize."}'
1:00–1:15 — Measure and break it
Exercise five is a mini load test: students fire twenty concurrent requests, record the p50 and p95 latency, and then send one oversized prompt to confirm the token gate rejects it. The goal is not a benchmark; it is a repeatable measurement ritual that students can reuse when a new model appears next week.
1:15–1:30 — Retrospective
The final exercise is a discussion with three questions: which failure took the longest to debug, what would break if the free tier disappeared, and what metric would justify moving to a paid tier. The answers give the instructor concrete material for a follow-up session and give students a decision framework instead of a demo.
Worked example: the metered summarizer
The snippet below is an illustrative client; the exact model name and response shape come from your dashboard, so treat the endpoint as a placeholder. Students can rerun this on their own machines after the workshop, and it is intentionally small enough to read in one pass.
# metered_client.py — illustrative example, adapt to your dashboard values
import os
import time
import requests
BASE_URL = os.environ.get("MC_BASE_URL", "https://api.example.com/v1")
API_KEY = os.environ.get("MC_API_KEY", "")
BUDGET = int(os.environ.get("TOKEN_BUDGET", "400"))
def metered_chat(prompt: str) -> dict:
started = time.perf_counter()
response = requests.post(
f"{BASE_URL}/chat/completions",
headers={"Authorization": f"Bearer {API_KEY}"},
json={
"model": "free-model",
"messages": [{"role": "user", "content": prompt}],
"max_tokens": BUDGET,
},
timeout=30,
)
response.raise_for_status()
data = response.json()
latency_ms = (time.perf_counter() - started) * 1000
usage = data.get("usage", {})
total_tokens = usage.get("total_tokens", 0)
if total_tokens > BUDGET:
raise RuntimeError(f"token budget exceeded: {total_tokens} > {BUDGET}")
return {
"content": data["choices"][0]["message"]["content"],
"tokens": total_tokens,
"latency_ms": round(latency_ms, 1),
}
if __name__ == "__main__":
result = metered_chat("Summarize this workshop in one sentence.")
print(result)
Students then wrap this client in a FastAPI route and deploy it; the route returns the same dictionary as JSON, which makes the token count visible to anyone who calls the service. A sample invocation is included in the workshop repo so the deployment check is identical for every student.
When this approach is the right call
Free infrastructure is the right call for learning and prototyping, but it is not a substitute for a paid tier with guarantees. Use the table below as a quick filter before you plan your own session.
| Scenario | Free model access + free server | Paid tier |
|---|---|---|
| Internal workshop or hackathon | Yes, ideal | Overkill |
| Demo-day prototype | Yes, good enough | Not yet |
| CI smoke test for a side project | Yes, cheap and disposable | Not yet |
| Production traffic with an SLA | No, missing guarantees | Yes |
| Batch processing of sensitive data | No, verify terms first | Yes |
Limitations and who should skip this workshop
Free tiers change, and the 10 million token allowance and the free server option are current as of late August 2026, not a permanent contract. Instructors should verify the dashboard before the session and keep a fallback exercise that works with any OpenAI-compatible endpoint. The workshop also assumes students can debug basic network issues, so absolute beginners may need a longer setup window. Teams that need an SLA, data-residency guarantees, or reproducible benchmark results should not build their core workflow on free infrastructure.
The takeaway
The 90-minute format works because it measures everything: tokens, latency, and deployment success are all visible by the end of the session. If you run it with a team, MonkeyCode's free model access and free server are enough to complete the whole outline, and the deployment exercise is usually where the real learning happens.
Top comments (0)