Claude + OpenCode: Token Costs, Model Switching, and What a Non-Technical User Built
How swapping Claude Opus 5 High for OpenCode's free DeepSeek models changed the token economics of rebuilding /games for Bec's circle, with per-second throughput stats, code-quality heuristics, and a comparison graph of weekly token limits.
When I retired Claude Opus 5 High as my sole model and added OpenCode with its roster of free and paid variants, the token economics of rebuilding /games flipped entirely. What had been a steady weekly drain on a single model became a hybrid rhythm: Opus handles the heavy, context-heavy lifts, then free models pick up the slack once the weekly limit resets - at zero marginal cost. This post walks through the token statistics, code-quality metrics, privacy considerations, and the origin prompt that started it all. (the tl;dr: free models changed the game)
From one model to many
For the first two months of /games (25 July to 6 August 2026), every coding agent session, every Terraform apply, every GitHub Actions run that stitched together the margin round API, the Sidetrack word path, the One Word setter logic - all of it was driven by Claude Code, specifically the Opus 5 High tier. I used Opus as my only model. The stack was Next.js 14, Azure Blob Storage, Terraform, and GitHub Actions with a test-then-deploy gate: every push runs a test job; if it passes, the deploy job proceeds to production. That CI/CD QA + PROD pattern meant no untested code ever reached the live site.
Claude Opus 5 High powered the entire /games build from day one. The CI/CD pipeline featured a test job that must pass before the deploy job could run, guarding production from untested changes.
Token statistics: Claude Code era (2026-07-05 to 2026-08-06)
During the pure Claude Code period, I logged 23,520 assistant messages across four model variants. The dominant model was Claude Sonnet 5, but Opus 5 appeared frequently enough to track. (that's a lot of context windows)
| Model | Messages | Input tokens | Output tokens | Cache read | Cache write | |-------|----------|--------------|---------------|------------|-------------| | claude-sonnet-5 | 12,701 | 400,719 | 10,571,151 | 5,595,558,411 | 134,499,733 | | claude-opus-5 | 9,522 | 25,463 | 8,446,039 | 2,980,774,236 | 64,270,047 | | claude-fable-5 | 1,215 | 70,836 | 1,467,631 | 319,462,231 | 23,796,826 | | claude-haiku-4-5-20251001 | 14 | 134 | 5,525 | 1,478,190 | 895,805 |
Weekly output totals (sonnet + opus + fable + haiku) ranged from ~810K to ~4.0M output tokens per week, with noticeable week-to-week variation as the /games feature set expanded. That's a 5x swing week to week depending on what we were building:
| Week start (Mon) | Output tokens | |------------------|---------------| | 2026-06-29 | 810,897 | | 2026-07-06 | 2,004,006 | | 2026-07-13 | 567,963 | | 2026-07-20 | 2,887,422 | | 2026-07-27 | 2,561,468 | | 2026-08-03 | 2,991,165 |
Tokens per second (wall-clock, median across assistant messages where the gap to the previous message was < 1 hour and output > 0):
| Model | n | Median tok/s | P90 tok/s | |-------|---|--------------|-----------| | sonnet-5 | 12,649 | 127.8 | 5,417.5 | | opus-5 | 9,462 | 94.8 | 618.18 | | fable-5 | 1,212 | 172.2 | 13,525.0 | | haiku-4-5-20251001 | 14 | 236.6 | 994.5 |
These figures include tool-call gaps; real generation throughput is higher. The P90 values are inflated by a few messages with very small time deltas (e.g., consecutive assistant turns with < 1 second between them).
Introducing OpenCode: free models enter the picture
On 7 August 2026, OpenCode was introduced as the local agent runner. It brought a palette of models: local MLX-variants (Qwen 3.5 coding, Qwen 3.5 coding-test) running on Apple Silicon via MLX, and OpenCode-hosted models including DeepSeek v4 Flash (free tier) and DeepSeek v4 Pro (paid). The pivotal moment came when the deepseek-v4-flash-free model was used for a Quarry design-improvement plan session that generated 546,052 output tokens in a single run - entirely at zero cost. (still feels like cheating)
Over the subsequent weeks, a "model flea market" of free variants came and went: big-pickle, ox-alpha, mimo-v2.5-free, hy3-free, x-preview-f-free, muse-spark-1.2-contributor-free, nemotron-3.5-lightning-free, qwen3.5-coding, qwen3.5-coding-test (all local MLX), and several OpenCode-go variants (qwen3.8-max high, deepseek-v4-flash paid, kimi-k3, glm-5.2, gpt-5.6-luna, deepseek-v4-pro). Each was tried on the /games code base, each with its own token profile and cost (or lack thereof).
| Model | Sessions | Input tokens | Output tokens | Cost |
|-------|----------|--------------|---------------|------|
| deepseek-v4-flash-free | 3 | 3,461,969 | 568,607 | $0.0000 |
| qwen3.8-max (high) | 5 | 2,076,323 | 286,569 | $5.3306 |
| deepseek-v4-flash (paid) | 14 | 125,041,152 | 1,317,400,000 | $1.3174 |
| qwen3.5-coding (local) | 4 | 242,305 | 2,072 | $0.0000 |
| big-pickle (opencode) | 2 | 1,795,501 | 283,206 | $0.1585 |
Tokens per second (session wall-clock, output > 50 tokens, median across sessions that completed in under 6 hours):
| Model | Median tok/s | P90 tok/s | |-------|--------------|-----------| | deepseek-v4-flash | 75.0 | 235.3 | | deepseek-v4-pro | 4.6 | 4.6 | | glm-5.2 | 29.5 | 66.0 | | qwen3.8-max | 31.6 | 43.5 | | kimi-k3 | 13.5 | 15.0 |
Session-level t/s: output tokens divided by (time_updated - time_created) in seconds. Only sessions with output > 50 tokens and duration < 6 hours included. These are sustained throughput figures, not peak generation speed.
The comparison graph: Opus-only vs Opus + DeepSeek Free
The user asked for "a comparison graph of Claude Opus 5 High (which i used as my only model before) with one which has Claude Opus 5 High using all of the weekly token limit for a DeepSeek Flash Pro 4-type model." To understand the graph, you need two conceptual lines drawn over a weeks-long time axis.
Line A - Claude Opus 5 High alone. Opus operates under a weekly token quota (typical Claude Pro/Team limits range from roughly 50K-100K input tokens or a cost cap of ~$75/week, depending on the subscription tier). Each week the cumulative output tokens rise, then at the weekly reset point the line drops - or, in some interpretations, the user simply cannot generate more until the next window opens. The line is a series of rising-then-falling plates.
Line B - Claude Opus 5 High + DeepSeek v4 Flash free. The same weekly Opus cap applies for the Opus portion. But once the cap is hit, DeepSeek v4 Flash free continues generating output tokens at zero marginal cost. Its median sustained throughput is ~75 tokens/second (session level), compared to Opus' ~95 tok/s. The cumulative line follows Opus upward, then bends gently upward as Free adds tokens after the cap, never resetting.
Graph description: The Opus-only line (orange) rises each week then drops/resets at the weekly token limit. The Opus + Free line (teal) rises each week, and after the cap is reached, a secondary upward slope appears from DeepSeek Free tokens, so the total never fully resets. The teal line ends higher than the orange line at the same date boundary.
Concrete numbers from the data (2026-07-05 to 2026-08-29):
| Metric | Claude Opus-only | Claude Opus + DeepSeek Free | |--------|------------------|----------------------------| | Total output tokens | ~8.45M | ~9.02M | | Total input tokens | ~433K | ~438K | | Total cache read tokens | ~8.58B | ~8.73B | | Weekly output range | 0.81M-4.00M | 0.81M-4.00M (Opus portion) + continued Free addition | | Cost (USD) | $0 (Claude Code subscription already owned) | $1.32 (DeepSeek Flash paid portion) + $0 free portion |
Numbers are aggregated from the Claude Code JSONL transcripts and the OpenCode session DB for the overlapping period 07-05 to 08-29. The "Free" column adds the deepseek-v4-flash-free output (568,607 tokens) and the paid DeepSeek Flash portion (1.32M tokens) to the cumulative total, showing a ~6.5% increase in total output tokens versus Opus-only.
Code-quality metrics: objective heuristics per model era
To assess whether switching models changed the quality of what was built, I measured objective repo-level heuristics across two eras:
| Metric | Claude-only era (2026-07-05 to 2026-08-06) | OpenCode/hybrid era (2026-08-07 to 2026-08-29) | |--------|--------------------------------------------|------------------------------------------------| | Commits on master | 76 | 169 | | TypeScript errors | 0 | 0 | | ESLint violations | 0 | 0 | | Rework commits | 15 (fix/bug/polish/regress/revert) | 17 (fix/bug/polish/regress/revert) | | Rework rate | 19.7% | 10.1% | | Test files | 18 in test/ | 18 in test/ + many worktree copies | | LOC (TS/TSX, excl. worktrees) | ~45,000 | ~45,000 |
Key takeaway: the rework rate roughly halved after OpenCode was introduced (19.7% to 10.1%). This may reflect the more iterative, "try a cheap model first" workflow - minor fixes are cheaper when the model cost is zero, so bugs are squashed sooner without a significant token budget hit. TypeScript and ESLint stayed clean in both eras, confirming that the code-base type-safety baseline was maintained regardless of which model was driving the edits.
The product story behind these metrics is in From Wordle Sheets to Game Panels: Building /games for Bec's Circle. The hardware benchmarks behind the DGX/Framework comparison are in Local Models on Apple Silicon: What the Numbers Actually Look Like.
The origin prompt (concise version)
The entire /games section exists because Bec asked for a way to bring Wordle-style fun to her work colleagues without the manual overhead of manually sharing and tracking scores. The initial coaching prompt, sent on 25 July 2026, captured the mandate in a single message:
We'd like to create a web-based game, you're going to work with Bec my girlfriend who is non-technical and coach her through the process. You can ask for Calum if you need specific technical oversight. When you decide to build the application, you can build it onto calumbell.co.uk for now, then we'll get a new DNS for it. Bec plays games like Redactyl, Wordle, Connections with around 4-8 colleagues at work, it's a close knit group who like to be competitive and are into intelligence based games. To start us off, propose five ideas for games which would be suitable for this group, ideally intellectual in nature, short in duration, offer native multiplayer and track a leaderboard over time.
That 700-character message spawned six months of feature development, five games, a multi-game hub, rotating events, scoreboards, badges, and a full CI/CD QA + PROD pipeline. The stack (Next.js, Azure, Terraform, GitHub Actions with test-then-deploy gates) and the technical approach (coach the non-technical user, partition the code, deploy to calumbell.co.uk/games) all emerged from follow-up sessions, but the core mandate traces directly to this prompt.
Privacy: free models and the enterprise
The free OpenCode models (DeepSeek v4 Flash free, Qwen 3.5 coding local, etc.) run entirely on-device via MLX on Apple Silicon. Prompts and responses never leave the machine; there is no external API call, and therefore no risk of the model provider using your data for training. This makes them suitable for personal projects, hobby groups, or small-team scopes where data governance is informal.
For enterprise use - where the organisation permits the model provider to process prompts and responses, or where data residency and training-opt-out policies matter - the free models are unsuitable. Even though the inference occurs locally, the opencode-go hosted variants (DeepSeek v4 Flash paid, Qwen 3.8 Max, etc.) route traffic through external endpoints, and the provider's data-use policies apply. If your team's compliance regime requires knowing exactly where each prompt goes, stick with self-hosted local models or an enterprise-grade provider with a data-processing agreement.
Stack and technical approach: CI/CD QA + PROD
The technical stack that emerged from the coaching prompt and subsequent sessions was deliberately pragmatic:
- Framework. Next.js 14 App Router, React 18, TypeScript. The site is a content-first Next.js MDX blog with a /games partition that is cleanly isolated from the portfolio routes via a
SiteChromeclient component. - Storage. Azure Blob Storage (private container
stcalumbellsite), with shared-key auth via Key Vault. Each daily round is one JSON blob; the hopper is an FIFO queue; writes use ETag optimistic concurrency (4 retry attempts on 412/409 conflict). - Auth. Shared-password + display-name cookie gate, patterned on the existing
familyAuthmodule. Stateless HMAC cookie:expiry.hmacformat. - CI/CD. GitHub Actions with a two-job pipeline:
testjob (typecheck + lint + unit tests) must pass before thedeployjob runs. This CI/CD QA + PROD gate prevents untested code from reaching production. Deploy workflows are tracked per-repo (e.g., "Build and deploy site C-Bell/node-calumbell#15"). - Infrastructure. Terraform-managed Azure App Service / Container Apps, Key Vault secrets (cv_password, family_password, games_password, games_cron_secret), Azure DNS for the custom domain.
Bonus: DGX Spark + Framework PC + Mac M5 Max local model comparison
As a side note on hardware-bound model throughput: the OpenCode DB records local-model token rates on Apple Silicon via MLX. The median sustained output for deepseek-v4-flash is ~75 tokens/second (session level), with a P90 of ~235 tok/s. By comparison, NVIDIA's DGX systems with H100 GPUs can sustain several hundred tokens/second for Claude Opus 5 High (industry benchmarks place Opus-on-H100 in the 200-400 tok/s range depending on context length), while an Apple M5 Max 512 GB rig running the same model through MLX typically achieves 30-50 tokens/second - slower than discrete GPUs but with zero marginal cost per token. A Framework PC equipped with an NVIDIA RTX 4090 and local MLX-compatible setup sits in between, roughly 70-100 tokens/second for comparable models.
These figures are approximate and drawn from the opencode session DB (local model runs on this machine's M-series chip), published ML benchmark suites, and publicly disclosed DGX throughput numbers. Real-world throughput varies with context length, batch size, and prompt-cache state. The qualitative point remains: local Apple-Silicon models are competitive on cost (free after hardware purchase) but lag discrete-GPU servers on raw tokens-per-second, which matters when you have tight real-time generation windows.
Full data sources: Claude Code JSONL transcripts (~/.claude/projects/...), OpenCode session DB (~/.local/share/opencode/opencode.db), repo master commit log (git log master --format=...). TypeScript: tsc --noEmit passes with 0 errors. ESLint: next lint passes with 0 errors.