DEV Community: Kris Racette

Ollama Cloud Compute vs Capability: I Ranked Every Model by GPU Cost Per Task

Kris Racette — Thu, 09 Jul 2026 00:14:34 +0000

Ollama Cloud Compute vs Capability: I Ranked Every Model by GPU Cost Per Task

By Kris Racette · Originally published at executivemind.io · 12 min read

If you're an Ollama Cloud subscriber, you've probably noticed the weekly quota is a moving target. Hit the limit halfway through Wednesday, you're stuck for the rest of the week. Hit it on Saturday afternoon, you've been efficient. The difference is almost entirely about which models you route to — and almost no one is publishing the data on what actually burns the most compute per task.

Until now. I crunched the numbers on every major Ollama Cloud model — DeepSeek V4 Flash, DeepSeek V4 Pro, GLM 5.2, Kimi K2.7 Code, MiniMax M3, Qwen 3.7 Max, GPT-OSS 120B, and both Gemma 4 variants — and ranked them by GPU compute per task against their actual coding benchmark performance.

⚡ The Headline Finding: DeepSeek V4 Flash (13B active parameters) burns ~73% less compute than V4 Pro (49B active) — and lands within 1-3 points on virtually every coding benchmark. If you're paying for V4 Pro tier to do routine work, you're burning three quarters of your weekly quota for marginal quality gains.

Why Compute Is a Moving Target on Ollama Cloud

Most people read the Ollama Cloud pricing page and think they're paying per token. They're not. From Ollama's pricing page:

"Models consume a different amount of usage based on how difficult they are to run."

In practice, this means Ollama weights your usage by GPU compute difficulty, not raw tokens. A 1,000-token response from a 13B active MoE model costs a small fraction of the quota of the same 1,000 tokens from a 49B active MoE model. The two biggest drivers are:

Active parameters per token — the number of parameters that actually fire on each forward pass
Thinking token overhead — reasoning models emit hidden "thinking" tokens that count toward your quota but never appear in the output

Context window memory matters too, but the dominant variable is active params. That's why a 1T-parameter MoE with 32B active (Kimi K2.7 Code) costs less than a 744B-parameter model with 40B active (GLM 5.2). Total parameter count is a vanity metric on cloud subscriptions — what matters is what fires per token.

The Model Roster

Sorted by active parameters, because that's the primary compute driver:

Model	Total Params	Active Params	Context	Open Weights
Gemma 4 26B (A4B MoE)	26B	4B	1M	✅ Open
GPT-OSS 120B	117B	5.1B	128K	✅ Apache 2.0
DeepSeek V4 Flash	284B	13B	1M	✅ MIT
MiniMax M3	428B	23-26B	1M	✅ MIT
Gemma 4 27B (dense)	27B	27B	1M	✅ Open
Kimi K2.7 Code	1T	32B	256K	✅ Modified MIT
GLM 5.2	744B	40B	1M	✅ MIT
DeepSeek V4 Pro	1.6T	49B	1M	✅ MIT
Qwen 3.7 Max	Proprietary	N/A	1M	❌ API only

Note the wild spread: Gemma 4 26B (MoE) fires only 4B parameters per token, while DeepSeek V4 Pro fires 49B. That's a 12× difference in per-token compute — which is exactly what Ollama is charging you for.

Benchmark Performance Across the Field

Pulled from SWE-bench Verified, SWE-bench Pro, Terminal-Bench 2.1, LiveCodeBench, the Composio tool-use benchmark, and Design Arena. Estimated values are marked in italics — these are interpolation estimates from partial public data, not made up.

Model	SWE-bench Verified	SWE-bench Pro	Terminal-Bench	LiveCodeBench
GLM 5.2	82.8	62.1	81.0	—
DeepSeek V4 Pro	80.6	55.4	~76 (est.)	93.5
DeepSeek V4 Flash	79.0	~52 (est.)	~73 (est.)	91.6
Qwen 3.7 Max	—	60.6	69.7	91.6
Kimi K2.7 Code	~65 (est.)	~55-58 (est.)	~75 (est.)	~88 (est.)
MiniMax M3	—	59.0	66.0	—
Gemma 4 27B (dense)	61.2	—	—	—
GPT-OSS 120B	~54.9 (est.)	—	—	—
Gemma 4 26B (A4B)	17.4	—	—	—

GLM 5.2 is the capability leader for open-weight models — #1 on SWE-bench Pro (62.1), Terminal-Bench (81.0), and Design Arena for code. Qwen 3.7 Max and DeepSeek V4 Pro are tightly bunched behind. DeepSeek V4 Flash sits in the top tier at 79% SWE-bench Verified and 91.6 LiveCodeBench.

The Gemma 4 MoE variant (A4B) at 17.4% is essentially not a coding model. Google chose not to feature SWE-bench in their official Gemma 4 press materials for a reason.

Compute Per Token — The Real Number

If Ollama weights usage by GPU compute difficulty, and the dominant driver is active parameters, then the relative cost per token looks like this (V4 Pro = 1.0x as the reference):

Model	Active Params	Compute/Token	Notes
Gemma 4 26B (A4B)	4B	0.08x	Cheapest, but not a coding model
GPT-OSS 120B	5.1B	0.10x	Cheapest viable, weak coder
DeepSeek V4 Flash	13B	0.27x	Sweet spot: low compute + high capability
MiniMax M3	23-26B	0.53x	Mid-tier
Gemma 4 27B (dense)	27B	0.55x	Dense = all params active
Kimi K2.7 Code	32B	0.65x	+ 30% fewer thinking tokens
GLM 5.2	40B	0.82x	Can exceed on `max` thinking
Qwen 3.7 Max	N/A	~0.65-0.82x (est.)	Proprietary
DeepSeek V4 Pro	49B	1.00x	Heaviest per token

That 0.27x on V4 Flash versus 1.0x on V4 Pro isn't a typo. It's a 73% compute reduction for the same kind of work, on most tasks. If you're running a 10-agent operation on Ollama Cloud, the difference between routing everything to V4 Pro and routing routine work to V4 Flash could literally be the difference between hitting your quota on Wednesday and hitting it on Saturday.

Total Compute for the Same Coding Task

Per-token cost is half the story. The other half is thinking token overhead. For a moderate coding task (5,000 thinking + 2,000 output tokens), the total compute looks like this:

Model	Active (rel.)	Thinking (rel.)	Est. Total Compute	Tier
Gemma 4 26B (A4B)	0.08x	1.0x	~0.08x	❌ Not viable
GPT-OSS 120B	0.10x	1.0x	~0.10x	⚠️ Weak
DeepSeek V4 Flash	0.27x	1.0x	~0.27x	✅ Strong
Kimi K2.7 Code	0.65x	0.7x	~0.46x	✅ Strong
MiniMax M3	0.53x	1.0x	~0.53x	✅ Strong
Gemma 4 27B (dense)	0.55x	1.0x	~0.55x	⚠️ Mid
Qwen 3.7 Max	~0.65-0.82x	1.0x	~0.65-0.82x	✅ Top tier
GLM 5.2	0.82x	1.0-1.4x	~0.82-1.15x	✅ Best open
DeepSeek V4 Pro	1.0x	1.0x	~1.0x	✅ Top tier

Note Kimi K2.7 Code's trick: it uses 30% fewer thinking tokens than its peers. That single design choice moves it from a 0.65x per-token cost to a 0.46x total cost — a meaningful efficiency gain for IDE-bound coding work.

The Compute vs Capability Matrix

Each model plotted by total compute per task and coding capability tier:

                       Low Compute                High Compute
                 ┌───────────────────────┬───────────────────────┐
  Top-Tier       │                        │  GLM 5.2 (best open)  │
  Capability     │  DeepSeek V4 Flash     │  Qwen 3.7 Max (API)   │
                 │  (best value)          │  DeepSeek V4 Pro      │
                 ├───────────────────────┼───────────────────────┤
  Mid-Tier       │  MiniMax M3            │                        │
  Capability     │  Kimi K2.7 Code        │                        │
                 │  Gemma 4 27B (dense)   │                        │
                 ├───────────────────────┼───────────────────────┤
  Low            │  GPT-OSS 120B          │                        │
  Capability     │  Gemma 4 26B (A4B)     │                        │
                 └───────────────────────┴───────────────────────┘

The single most important cell: DeepSeek V4 Flash in the top-left quadrant. High capability, low compute. The closest competitor in that cell is Kimi K2.7 Code — but Kimi is purpose-built for agentic IDE coding, not for general-purpose reasoning at the Flash tier's quality.

What About GPT-OSS and Gemma?

Short answer: no, they're not in the same league for coding on Ollama Cloud.

GPT-OSS 120B has the cheapest compute profile on Ollama Cloud (5.1B active — barely a blip on the quota), but it ranks #78 out of 124 models on coding benchmarks with a score of 21.2. It's a reasoning model that can do tool use, but for real software engineering it's nowhere near the frontier.

Gemma 4 27B (dense) is more interesting. Google reports 61.2% on SWE-bench Verified, which is respectable. But independent testing of the MoE variant (A4B, 4B active) scored only 17.4% — and Google deliberately omitted SWE-bench from their official Gemma 4 benchmark press materials.

⚡ Key Insight: On Ollama Cloud, the compute cost difference between the cheapest viable coder (DeepSeek V4 Flash at 13B active) and GPT-OSS or Gemma is irrelevant compared to the capability gap. You're already on a subscription — use the model that actually solves the problem. GPT-OSS and Gemma are models for local hardware constraints, not cloud subscription optimization.

Final Ranking — All Nine Models, by Value

Rank	Model	Why
🥇	DeepSeek V4 Flash	13B active = ~73% less compute than V4 Pro. 79% SWE-bench Verified. The undisputed value king.
🥈	Kimi K2.7 Code	32B active + 30% fewer thinking tokens. Purpose-built for agentic coding.
🥉	MiniMax M3	23-26B active, 59% SWE-bench Pro, 1M context, native multimodal.
4	GLM 5.2	40B active, but #1 on SWE-bench Pro (62.1) and Terminal-Bench (81.0). Best open-weight coder.
5	Qwen 3.7 Max	60.6 SWE-bench Pro, 69.7 Terminal-Bench. Top-tier but proprietary + heavier.
6	DeepSeek V4 Pro	49B active — heaviest. V4 Flash covers ~96% of its capability at ~27% of compute. Use sparingly.
7	Gemma 4 27B (dense)	Decent coding (61.2 SWE-bench Verified) but outclassed by Flash/M3. For local, not cloud.
8	GPT-OSS 120B	Cheap compute (5.1B active) but coding score 21.2. Not viable for software engineering.
9	Gemma 4 26B (A4B)	17.4% SWE-bench Verified. Not a coding model.

Recommended Model Routing on Ollama Cloud

Here's the playbook I use across my 10-agent operation:

Task Type	Model	Why
Routine agent calls (heartbeats, monitoring)	DeepSeek V4 Flash	Barely dents quota, near-frontier quality
IDE execution (Cline/Codium)	Kimi K2.7 Code	30% fewer thinking tokens, purpose-built
Legal/financial analysis	DeepSeek V4 Flash	1M context, near-Pro quality, fraction of compute
Web/SEO content	MiniMax M3	Native multimodal, 1M context, strong coding
Architecture & planning	GLM 5.2 (high mode)	1M context, best coding benchmarks
Hard problems	GLM 5.2 (max mode)	Frontier quality, accept the compute cost
When Flash can't handle it	DeepSeek V4 Pro	Last resort — but Flash usually can
Local-only / no cloud	Qwen 3.6 27B (local)	Not on cloud, but your local fallback

The Bottom Line

If you're hitting Ollama Cloud Max limits at 55% through the week, the fix isn't to upgrade. The fix is to route better.

Move all routine/monitoring to DeepSeek V4 Flash — could cut 30-40% of compute usage overnight
Use Kimi K2.7 Code for IDE execution — purpose-built efficiency, minimal thinking overhead
Reserve GLM 5.2 for planning only — don't waste 40B active params on heartbeats
DeepSeek V4 Pro should almost never run — V4 Flash covers 96% of what Pro does at 27% of the cost
GPT-OSS and Gemma are not your friends here — built for local hardware constraints, not cloud subscription optimization

The Ollama Cloud pricing model is poorly understood because nobody has published the data in this format. I hope this analysis helps you route smarter.

Benchmark sources: DeepSeek V4 tech report, Z.ai GLM 5.2 release, Moonshot K2.7 Code release, MiniMax M3 release, Qwen 3.7 blog, OpenAI GPT-OSS release, Google Gemma 4 release, Composio benchmark, Artificial Analysis, SWE-bench leaderboard, BenchLM.ai, vals.ai. Compute weights estimated from active parameters and thinking token efficiency per the Ollama Cloud pricing model.

— Kris Racette, Founder of Executive Mind — https://executivemind.io | https://krisracette.me | https://github.com/Roughn3ck

Building an Open-Source Fitness Tracker with Flutter

Kris Racette — Wed, 01 Jul 2026 19:41:09 +0000

For the last year and a half, I've been lifting four days a week — alternating between hypertrophy blocks (~12 reps × 3 sets) and strength blocks (~6 reps × 5 sets) for the same lifts. I tried the popular subscription apps. I tried spreadsheets. I tried a notebook.

None of them fit. The subscription apps wanted me to start a "program" before they'd let me log a set. The spreadsheets didn't remember my last weight per lift per training style. The notebook was, predictably, terrible at search.

So I built Gym Tracker in Flutter, and this week I open-sourced it.

What it does

It's a small app with a clear job: log a session, remember my numbers, and get out of the way.

A Workout tab where I pick body parts, see only the relevant exercises, and tap my way through sets. Each exercise card pre-fills my last weight for the current training style — strength and hypertrophy records live as separate rows, so a 100kg × 5 strength entry doesn't bleed into a 80kg × 12 hypertrophy entry.
An Exercises tab grouped by body part (Legs, Chest, Arms, Back, Shoulders) with a many-to-many catalogue, weight history per exercise, and an "add new exercise" button.
A History tab with every session I've ever logged, in reverse chronological order.
A Profile tab for body stats (weight, waist, neck, notes) and a database export via the system share sheet.

The app ships with a pre-populated exercise catalogue and a blank SQLite database. No account. No telemetry. No cloud. It works on Android (APK) and Windows (portable .exe) from the same codebase. iOS and macOS build from source; I just don't have a Mac to sign releases with.

Why open source

I'm the Founder of Executive Mind, an AI consultancy where I spend most of my days building agent systems for clients. A pattern I keep returning to: good tools should be inspectable, portable, and free. Lock-in is the enemy.

Open-sourcing Gym Tracker means three things to me:

Anyone can read the code. The whole stack is small enough to navigate in an afternoon — sqflite for storage, sqflite_common_ffi to make it work on desktop, provider for state, one repository for all data access. If a Flutter dev wants to see a real-world app that ships to two platforms from one codebase, this is it.
Anyone can fork it. A coach can add their own exercises. A lifter can theme it. A developer can swap SQLite for Drift if they want reactive queries. The license lets you.
It forces me to keep it honest. Public code ages in the open. That's a feature, not a bug.

What's next

The roadmap is in the README. The big items: GPS run tracking (a placeholder toggle in Settings waiting for a real screen), Health Connect sync on Android, a session detail view with per-set editing, and an analytics dashboard with charts. I built the toggle in early so I'd remember the wiring.

If you want to contribute, the easiest first PR is adding exercises to the catalogue or building the session detail screen. The data layer is ready for it.

If you just want a fitness tracker that doesn't try to sell you a program, you can grab the APK or the Windows zip from the releases page.

Either way, the code is on GitHub. Go read it. Tell me what's wrong with it. That's the whole point.

🔗 github.com/Roughn3ck/gym_tracker
🌐 executivemind.io
👤 krisracette.me

— Kris Racette, Founder of Executive Mind | krisracette.me | GitHub

Why I Built ColdStack Instead of Using a Browser Extension for Crypto Key Management

Kris Racette — Thu, 25 Jun 2026 06:28:26 +0000

Why I Built ColdStack Instead of Using a Browser Extension for Crypto Key Management

The Problem

Browser extensions are convenient. They're also the single biggest attack vector in crypto. Every time you install a wallet extension, you're handing your private keys to a piece of JavaScript that runs inside the same browser you use for everything else — the one with 50+ extensions, 100+ tabs, and a decade of cached cookies.

The threat surface is staggering. Malicious updates can ship to a legitimate extension overnight. Supply chain attacks compromise the build pipeline before the code ever reaches your browser. Phishing extensions impersonate real wallets with near-identical branding. And browser zero-days? Those don't need an extension at all — they just need you to visit the wrong page.

Your keys live inside a browser that is actively under attack.

Between 2024 and 2026, hundreds of millions of dollars were drained through extension-based wallet compromises. Some were outright malicious extensions. Others were legitimate wallets that got compromised through their dependencies. A few were browser vulnerabilities that allowed attackers to read extension storage directly. The pattern is always the same — the keys were accessible from the browser, and the browser was accessible from the internet.

The Alternative

The answer isn't a better browser extension. The answer is no browser at all.

Offline key management has been the gold standard for institutional crypto custody for years. Hardware wallets, air-gapped signing machines, HSMs — these are the tools that custody billions of dollars professionally. The principle is simple: a key that never touches a network can't be stolen over a network.

I built ColdStack because I wanted that level of security without the $200 hardware wallet, without the proprietary firmware, and without the closed-source trust model. I wanted something I could run from a USB drive on any Windows machine, something I could audit myself, and something I could give away for free.

What ColdStack Does

ColdStack is a portable Windows application for offline crypto key management. It doesn't install. It doesn't phone home. It doesn't run in your browser. You drop it on a USB drive, plug it into any Windows machine, and double-click.

AES-256-GCM encryption protects your key vault at rest. The encryption key is derived using Argon2id — the same memory-hard KDF recommended by the IETF — which makes brute-force attacks computationally infeasible even with modern GPUs.

Version 3.0 ships with a built-in BIP39 derivation engine. That means you can generate a 24-word mnemonic and derive addresses for seven blockchain ecosystems directly inside the app:

EVM chains (Ethereum, Polygon, BSC, Arbitrum, Optimism, and others)
Bitcoin — with support for Taproot, SegWit, and Legacy address formats
Solana
Dash
Sui

No more jumping between five different tools to manage keys across chains. One mnemonic, one vault, seven ecosystems.

The app also includes auto-lock — if you step away from your computer, ColdStack locks itself after a configurable timeout. Zero telemetry means no analytics, no error reporting, no usage tracking. Nothing leaves your machine unless you explicitly send it.

Why Offline by Default Matters

"You can't hack what isn't connected" isn't a marketing tagline. It's the fundamental principle of air-gapped security.

ColdStack makes exactly zero network requests on startup. None. No update check, no license verification, no telemetry ping, no "phone home for feature flags." The app is completely silent until you do something that requires a network connection — and the only thing that does is the manual "Check for Updates" button.

Even then, ColdStack asks first. A dialog pops up: "ColdStack wants to check for updates. Allow this network request?" You click Yes or No. If you click No, no bytes leave your machine. If you click Yes, it hits one endpoint — the GitHub releases API — and shows you what's available. That's it.

This is what "offline by default" actually means. Not "offline most of the time." Not "offline unless we need to sync." Offline. Full stop.

Open Source Security

ColdStack is open source on GitHub. Every line of code is auditable. Every security claim is verifiable. You don't have to trust me — you can read the code yourself.

This matters because "trust us, it's secure" is exactly what the browser extension wallets said. Security through transparency beats security through assertion every time. The code is there. Fork it, audit it, build it yourself. If I've made a mistake, you'll find it. If I haven't, you'll know why.

Download

ColdStack v3.0 is available now:

GitHub: https://github.com/Roughn3ck/key_manager/releases/tag/v3.0
Product page: https://executivemind.io/key-manager

Free. No subscription, no premium tier, no upsell. Download it, put it on a USB drive, and take control of your keys.

— Kris Racette, Founder of Executive Mind — Key Manager | krisracette.me | GitHub

Kris Racette on the Future of Agentic Business Operations

Kris Racette — Mon, 22 Jun 2026 11:10:54 +0000

By Kris Racette | Executive Mind | Brisbane, Australia

The next evolution of business technology isn't just automation — it's agency. Agentic systems don't just follow rules; they make decisions, take actions, and learn from outcomes. For businesses in Brisbane and across Australia, this represents a fundamental shift in how operations work.

What Are Agentic Business Operations?

Traditional automation follows a script: when X happens, do Y. Agentic operations go further. An agentic system understands context, evaluates options, and takes the best available action — even when the situation wasn't explicitly programmed.

At Executive Mind, we define agentic business operations as: systems that can autonomously execute complex business processes while maintaining alignment with organisational goals and human oversight.

The Architecture of Agentic Operations

Building agentic systems requires a different architecture than traditional automation:

1. Perception Layer — The system must understand its environment. For financial operations, this means real-time access to transaction data, market conditions, and regulatory requirements.

2. Reasoning Layer — Given what it perceives, the system must evaluate options. This is where large language models and specialised AI models process context and generate potential actions.

3. Action Layer — The system must be able to execute. In financial operations, this might mean initiating transactions, generating reports, or flagging compliance issues.

4. Learning Layer — Every action produces feedback. The system must learn from outcomes to improve future decisions.

Why Brisbane Businesses Should Pay Attention

Brisbane's business ecosystem is uniquely positioned for agentic operations. The city has:

A growing fintech and AI startup scene
Strong connections to Asia-Pacific markets
A workforce that increasingly understands AI capabilities
Competitive costs compared to Sydney and Melbourne

The businesses that implement agentic operations first will have a structural advantage. They'll operate with lower overhead, faster decision cycles, and more consistent execution than competitors relying on traditional processes.

The Executive Mind Approach

At Executive Mind, Kris Racette has developed an approach to agentic operations that puts financial professionals at the centre. The AI handles the volume — monitoring, processing, flagging — while human expertise handles the judgement.

This isn't about replacing people. It's about giving financial professionals in Brisbane and beyond the tools to operate at a scale that wasn't previously possible.

Getting Started

For organisations considering agentic operations, the first step is identifying high-volume, rules-heavy processes where human time is being spent on tasks that don't require human judgement. These are the lowest-risk, highest-return entry points.

The future of business operations is agentic. The only question is timing.

Kris Racette is the Founder & CEO of Executive Mind, an AI-first operations company based in Brisbane, Queensland. Specialising in agentic business operations, financial AI strategy, and multi-agent architecture, Kris helps Australian enterprises navigate the future of work. Learn more at krisracette.me or executivemind.io. Follow on GitHub or LinkedIn.