---
title: ""
canonical: "https://studiomeyer.academy/en/playbooks/lokal-oder-cloud-die-ehrliche-rechnung"
language: en
publisher: "StudioMeyer Academy, https://studiomeyer.academy (llms.txt: https://studiomeyer.academy/llms.txt)"
---

[← Alle Playbooks](https://studiomeyer.academy/playbooks)

Playbook· lokal

# Local or cloud, the honest arithmetic

When your own hardware pays off and when it is an expensive hobby. Ten steps through a calculation that counts electricity, your working time and the quality gap, instead of just putting hardware price against token price.

The calculation everybody makes goes like this: the graphics card costs this much once, the cloud costs this much per month, after this many months the card has paid for itself. That calculation is almost always wrong, because it leaves out two items that are larger than the hardware price.

The first is your working time. The second is the quality gap, which shows up as longer rework. With both included the result looks different, and for some use cases it then tips the other way. This playbook does the arithmetic honestly, in both directions.

## 1\. Sort by the reason first, not by the price

There are three reasons for local, and only one of them is a maths problem.

If the reason is **privacy**, the arithmetic is secondary. Data that must not leave the building must not leave it even if the cloud were cheaper. Here the requirement decides, not the money.

If the reason is **independence**, you are buying insurance. No provider changing prices, no model suddenly switched off, no block because of a policy. That has a value you can put a number on, but not in token prices.

If the reason is **cost**, then do the maths. The next steps do exactly that.

**Tip:** If you notice that your actual reason is curiosity, that is entirely legitimate. Just do not do the maths then, set yourself a budget instead. That is more honest and ends better.

## 2\. Measure your real usage before you calculate

Almost everybody overestimates their usage. The impression of "we use AI constantly" comes from how often it is used, not from the volume of tokens.

Look up in your provider's billing what the last three months actually cost. That number is the starting point. Everything else is gut feeling, and gut feeling is unreliable with token prices because the amounts look so small.

**Tip:** Separate two things that get mixed up here. A flat-rate plan covers **interactive** use inside that app, with usage limits and fair-use rules, and it is not meant as a channel for automated bulk processing. For anything automated you pay API prices per token alongside it. Throw both into one pot and you either flatter or punish local hardware artificially.

## 3\. Count the full hardware, not just the graphics card

People buying for local models rarely buy only the card. A power supply that can carry it comes along, often a different case, sometimes more RAM, and for larger setups a machine that is allowed to run overnight.

With Apple machines it is easier to see, because the memory is fixed at purchase. On the other hand it cannot be upgraded, which makes the decision more final.

**Tip:** Calculate with three years of service life, not five. At the pace models and requirements move, a card is not broken after three years, but it is too small for what has become normal by then. There is a residual value, though, graphics cards sell on second-hand, and you can offset that.

So the full calculation looks like this: (hardware minus residual value) divided by the months of service life, plus electricity per month, plus your maintenance time times your hourly rate, plus the rework from step 6. That sum is what you hold against the monthly cloud bill, not the purchase price alone.

## 4\. Include electricity

A capable graphics card draws several hundred watts under full load. At German electricity prices that is not a rounding error, it is a line item.

The calculation is simple: power draw in kilowatts, times hours under load per month, times your price per kilowatt hour. The second number decides, and most people badly overestimate it, because the card only pulls full power under load. Count idle anyway if the machine runs continuously for the purpose: a waiting machine does not draw zero watts, and over a month that adds up.

**Tip:** If the machine is running anyway and you only ask something occasionally, the electricity item is small. If a machine runs permanently for bulk processing, it is large. Those two cases are economically completely different.

## 5\. Put in your working time, honestly

This is the item missing from most comparisons and the one that most often tips the result.

A local setup wants installing, updating and repairing when something breaks. Models get replaced, runtimes get updates, occasionally something stops working after an update. Count on a few hours at the start and recurring effort after that.

Use your own hourly rate. If you find that setting it up costs more than two years of cloud usage, that is a result and not an argument against doing it anyway. It just has to be a conscious choice.

**Tip:** Whoever wants to learn the subject anyway may put this item lower, because part of it books as training. Whoever just wants a tool may not.

## 6\. Put a number on the quality gap

A mid-range local model is close to the big providers on simple text tasks. On hard tasks it is not, and that difference costs time, because you rework more.

Take ten typical tasks and have both handle them. Do not measure quality in points, measure the minutes you still need after the answer until the result is usable. That difference times frequency is a real cost item.

**Tip:** This exact test decides the question better than any leaderboard. The procedure is in [Which local model fits your hardware](https://studiomeyer.academy/playbooks/welches-lokale-modell-passt-zu-deiner-hardware), step 7.

## 7\. Check whether the cloud side is even calculated correctly

Many people compare local hardware against the most expensive cloud model. That is unfair to the cloud.

If your task is simple enough that a local model with eight billion parameters manages it, then the budget model in the cloud manages it too. And that costs a fraction of the top model. The honest comparison is local against budget tier, not local against flagship.

**Tip:** A setup that routes simple requests to a cheap model and only passes the hard ones upward is the biggest cost lever there is, and it needs no hardware at all.

## 8\. Recognise the cases where local clearly wins

There are patterns where the arithmetic comes out unambiguously.

**Very high volume on a simple task.** Classifying tens of thousands of documents, sorting texts into categories, normalising masses of records. Here the cloud charges per item and your own machine simply runs through.

**Data that must not leave.** Already covered, here the requirement decides.

**No reliable connection.** Anyone who has to work offline has no choice.

**Constant load rather than spikes.** A machine that is continuously busy amortises. One that waits 95 percent of the time does not.

**Tip:** If none of these four patterns applies to you and privacy is not an issue, the cloud very probably wins the arithmetic.

## 9\. Recognise the cases where the cloud clearly wins

That belongs in an honest account too.

With **fluctuating usage** you only pay for what you consume in the cloud, whereas hardware depreciates in quiet months as well. On **hard reasoning tasks** the quality gap is large enough that the rework costs more than the token price. In **small teams without IT** the operating effort is the real cost driver. And whoever needs the **latest model generation** gets it in the cloud on release day and locally months later in a smaller form.

**Tip:** A flat-rate plan shifts this calculation further, because one more interactive request costs nothing extra as long as you stay inside the usage limits. Above them, throttling or an add-on tariff kicks in, and for automated runs the plan does not apply at all. So anyone on one should build locally mainly for the reasons in step 1, and for cost reasons only where real volume actually accumulates.

## 10\. Choose mixed if you are unsure

The two camps discuss this as though you had to pick a side. You do not, and most productive setups do not either.

A mixed setup sends everything with sensitive data and all bulk work to the local model, and everything hard to the cloud. You get privacy where you need it and quality where it counts.

There is one thing you must not economise on, or you undo exactly the privacy you are building for: **two separate environments, not one switch.** The sensitive tools, histories and knowledge stores belong solely in the local configuration, the cloud credentials solely in the other. The same interface with a model selector is not enough: whatever a read tool once pulled into the history travels out with you when you switch.

**Tip:** It being the same server software either way saves you the setup of the second environment, not the separation itself. Which servers you register in each remains a security decision. The detail is in [MCP with local models](https://studiomeyer.academy/playbooks/mcp-mit-lokalen-modellen), step 10.

## What next

If you have nothing running yet and want to do the arithmetic with your own experience first, [Your first local AI model in 30 minutes](https://studiomeyer.academy/playbooks/erstes-lokales-modell-in-30-minuten) takes exactly as long as it says. If privacy is your main reason, [Local AI and the GDPR](https://studiomeyer.academy/playbooks/lokale-ki-und-die-dsgvo) sorts out what local really solves. And if you stay in the cloud but want to push the bill down, [Cost controls for daily drivers](https://studiomeyer.academy/playbooks/claude-code-cost-controls-fuer-daily-driver) is the more direct lever.

## Sources

Prices and model line-ups change quickly. The method above stays valid, the numbers you have to plug in fresh each time.

- Anthropic, current pricing per model: https://www.anthropic.com/pricing
- OpenAI, pricing overview: https://openai.com/api/pricing
- Ollama, model library with size figures: https://ollama.com/library

[← MCP with local models, tools w](https://studiomeyer.academy/playbooks/mcp-mit-lokalen-modellen) [When a stranger's repo configu →](https://studiomeyer.academy/playbooks/agent-konfiguration-als-angriffsweg)

Alle Playbooks

[01. From ChatGPT to Claude, guide in 10 steps](https://studiomeyer.academy/playbooks/von-chatgpt-zu-claude) [02. From ChatGPT to Codex, guide in 10 steps](https://studiomeyer.academy/playbooks/von-chatgpt-zu-codex) [03. Your first MCP server in 90 minutes](https://studiomeyer.academy/playbooks/erster-mcp-server-in-90-minuten) [04. Using memory portably, same memory in Claude, Codex and Cursor](https://studiomeyer.academy/playbooks/memory-portabel-nutzen) [05. DACH legal. EU AI Act and GDPR for AI operators](https://studiomeyer.academy/playbooks/dach-legal-eu-ai-act-und-dsgvo) [06. Your first sub-agent in 30 minutes](https://studiomeyer.academy/playbooks/erster-sub-agent-in-30-min) [07. Publishing an MCP server step by step](https://studiomeyer.academy/playbooks/mcp-server-publishen) [08. Hooks against hallucinations](https://studiomeyer.academy/playbooks/hooks-gegen-halluzinationen) [09. Git for AI, 30-minute quickstart](https://studiomeyer.academy/playbooks/git-fuer-ki-quickstart) [10. Scheduled agents with Claude Code routines](https://studiomeyer.academy/playbooks/scheduled-agents-mit-routines) [11. Avoiding tool sprawl, from 530 to 30 MCP tools per session](https://studiomeyer.academy/playbooks/tool-sprawl-vermeiden) [12. Claude Code update strategy, without your workflow suddenly breaking](https://studiomeyer.academy/playbooks/claude-code-update-strategie) [12. Structuring your subagent team, the six roles you need in a daily driver](https://studiomeyer.academy/playbooks/subagent-team-strukturieren) [13. Claude Code cost controls for daily drivers, staying under 30 dollars a day in 10 steps](https://studiomeyer.academy/playbooks/claude-code-cost-controls-fuer-daily-driver) [14. Your own slash commands for Claude Code, productive in 30 minutes](https://studiomeyer.academy/playbooks/eigene-slash-commands-fuer-claude-code) [15. Claude Code headless in CI/CD, a setup that runs tomorrow](https://studiomeyer.academy/playbooks/claude-code-headless-in-ci-cd) [16. Agent eval in 60 minutes, how to find out if your agent is any good](https://studiomeyer.academy/playbooks/agent-eval-in-60-minuten) [17. Plan Mode in Claude Code, the invisible seatbelt, when you need it and how to keep it on](https://studiomeyer.academy/playbooks/plan-mode-richtig-nutzen) [18. Debugging MCP when nothing works, the 10 checks that solve 90 percent of cases](https://studiomeyer.academy/playbooks/mcp-debuggen-wenn-nichts-geht) [18. Mastering prompt caching, from cache miss to an 80 percent hit rate in 10 steps](https://studiomeyer.academy/playbooks/prompt-caching-meistern) [19. Repair memory drift, when your agent's memory starts contradicting itself](https://studiomeyer.academy/playbooks/memory-drift-reparieren) [20. MCP STDIO security, what the OX Security story means for you](https://studiomeyer.academy/playbooks/mcp-stdio-sicherheit) [21. Opus 4.7 migration, what changed for API builders](https://studiomeyer.academy/playbooks/opus-4-7-migration) [22. Your first Skill in 30 minutes, when slash commands aren't enough](https://studiomeyer.academy/playbooks/erste-eigene-skill-in-30-min) [23. Managing the context window in long Claude Code sessions](https://studiomeyer.academy/playbooks/context-window-managen-claude-code) [24. Advisor Tool, Opus as advisor and Sonnet as executor in one API call](https://studiomeyer.academy/playbooks/advisor-tool-opus-als-berater-sonnet-als-executor) [25. Secure your MCP server with OAuth 2.1 in 60 minutes](https://studiomeyer.academy/playbooks/mcp-server-auth-mit-oauth-2-1) [26. Distributing plugin bundles via URL, --plugin-url in 30 minutes](https://studiomeyer.academy/playbooks/plugin-bundle-via-url-distribution) [27. Claude Code in a Team, how to keep CLAUDE.md alive without turning it into a trash bin](https://studiomeyer.academy/playbooks/claude-code-im-team-claude-md-gemeinsam-pflegen) [27. Loading third-party Claude Code plugins from ZIP and URL, safely in 20 minutes](https://studiomeyer.academy/playbooks/claude-code-plugins-aus-zip-und-url-laden) [28. Confused deputy audit for Claude Code, done in 25 minutes](https://studiomeyer.academy/playbooks/confused-deputy-audit-fuer-claude-code) [28. Your first Claude Code plugin in 60 minutes, from empty folder to installable bundle](https://studiomeyer.academy/playbooks/dein-erstes-claude-code-plugin) [29. Pull request reviews with Claude Code, 10 steps for a PR workflow nobody blocks anymore](https://studiomeyer.academy/playbooks/pull-request-reviews-mit-claude-code) [30. Claude Projects for non-coders, a productive workspace in 30 minutes](https://studiomeyer.academy/playbooks/claude-projects-fuer-nicht-coder) [31. Build a prompt library, reuse your favourite prompts without copy-paste](https://studiomeyer.academy/playbooks/prompt-bibliothek-aufbauen) [32. Output Styles for Claude Code, your own tone in 20 minutes](https://studiomeyer.academy/playbooks/output-styles-fuer-claude-code) [33. Statusline for Claude Code, context at a glance in 15 minutes](https://studiomeyer.academy/playbooks/statusline-fuer-claude-code) [34. Claude Code checkpoints and /rewind: your safety net for risky edits](https://studiomeyer.academy/playbooks/claude-code-checkpoints-und-rewind) [34. Keeping discovery files consistent so AI crawlers do not quote old nonsense bios](https://studiomeyer.academy/playbooks/discovery-files-konsistent-halten) [34. Debugging hooks when nothing fires](https://studiomeyer.academy/playbooks/hooks-debuggen-wenn-nichts-feuert) [34. Parallel Claude Code sessions with git worktrees, two branches at once without conflict](https://studiomeyer.academy/playbooks/parallele-claude-sessions-mit-worktrees) [34. Skill does not trigger, what to check in 10 steps before you type /command again](https://studiomeyer.academy/playbooks/skill-trigger-debugging) [34. Sub-agent or skill or MCP tool, which one do you pick when](https://studiomeyer.academy/playbooks/sub-agent-oder-skill-oder-mcp-tool) [35. Running parallel Claude Code sessions with git worktrees](https://studiomeyer.academy/playbooks/claude-code-mit-git-worktrees) [35. Memory backup before an update, so you do not cry over a schema migration bug](https://studiomeyer.academy/playbooks/memory-backup-vor-update) [36. AGENTS.md alongside CLAUDE.md, one repo context for several AI tools](https://studiomeyer.academy/playbooks/agents-md-neben-claude-md) [47. Generative Engine Optimization for small sites, so Perplexity and ChatGPT-Search cite you](https://studiomeyer.academy/playbooks/geo-fuer-kleine-sites) [50. Opus 4.8 migration, the first Opus update with no breaking changes](https://studiomeyer.academy/playbooks/opus-4-8-migration) [51. Background sessions with Claude agents: run long tasks without blocking your terminal](https://studiomeyer.academy/playbooks/background-sessions-mit-claude-agents) [52. Set up the Claude Code bash sandbox: isolate commands instead of blindly allowing them](https://studiomeyer.academy/playbooks/claude-code-bash-sandbox-einrichten) [53. From script to your own agent: the Claude Agent SDK in 90 minutes](https://studiomeyer.academy/playbooks/claude-agent-sdk-erster-eigener-agent) [54. Build an MCP App: interactive UI in your MCP tool instead of a wall of text](https://studiomeyer.academy/playbooks/mcp-app-interaktive-ui-bauen) [55. The expensive-model myth: when the top AI model is really worth it](https://studiomeyer.academy/playbooks/mythos-klasse-wann-lohnt-sich-das) [56. Setting up fallback models so Claude Code doesn't stall on overload](https://studiomeyer.academy/playbooks/claude-code-fallback-modelle) [57. Dynamic workflows in Claude Code, your first orchestrated multi-agent script](https://studiomeyer.academy/playbooks/dynamic-workflows-in-claude-code) [58. Security-guidance plugin for Claude Code, automatic security review while you build](https://studiomeyer.academy/playbooks/claude-code-security-guidance-plugin) [59. Claude Code acting up after a config change, how to find the cause](https://studiomeyer.academy/playbooks/claude-code-safe-mode-diagnose) [60. MCP is stateless: what the 2026-07-28 spec changes and what you need to do now](https://studiomeyer.academy/playbooks/mcp-spec-2026-07-was-aendert-sich) [61. Your first real n8n flow: automation for people who don't code](https://studiomeyer.academy/playbooks/mein-erster-n8n-flow-fuer-nicht-coder) [62. Agentic payments with x402, what builders need to know about machine-paid APIs](https://studiomeyer.academy/playbooks/agentic-payments-x402) [63. GPT-5.6 or Opus 5, which model for which task](https://studiomeyer.academy/playbooks/gpt-5-oder-opus-4-8-welches-modell) [64. Subagents that spawn subagents, Claude Code's 5-level rule](https://studiomeyer.academy/playbooks/subagents-die-subagents-spawnen) [65. Setting up Claude Code agent teams, multiple sessions working together](https://studiomeyer.academy/playbooks/claude-code-agent-teams-einrichten) [66. Tracking model availability, when a model vanishes overnight](https://studiomeyer.academy/playbooks/modell-verfuegbarkeit-tracken) [67. Data protection when working with AI tools: ten habits that keep you safe](https://studiomeyer.academy/playbooks/datenschutz-mit-ki-tools) [68. Using Auto Mode in Claude Code safely, in 10 steps without suicide commands](https://studiomeyer.academy/playbooks/claude-code-auto-mode-sicher-nutzen) [69. AI for the job hunt: 10 steps through the ATS filter](https://studiomeyer.academy/playbooks/ki-fuer-jobsuche) [70. Build an AI portfolio that lands you a job, in 10 steps](https://studiomeyer.academy/playbooks/ai-portfolio-fuer-den-job) [71. Proving your AI skills credibly in CV and interview](https://studiomeyer.academy/playbooks/ai-skills-belegen-lebenslauf-interview) [72. Effort levels in Claude Code, when low is enough and when you need max](https://studiomeyer.academy/playbooks/effort-level-in-claude-code-einstellen) [73. From Academy skill to your first paid AI gig](https://studiomeyer.academy/playbooks/erster-bezahlter-ki-auftrag) [74. Fact-checking an AI answer: 10 steps against wrong information](https://studiomeyer.academy/playbooks/ki-antwort-faktenchecken) [75. AI images for your brand, from first prompt to finished set](https://studiomeyer.academy/playbooks/ki-bilder-fuer-deine-marke) [76. AI for freelancers, writing quotes and client emails in half the time](https://studiomeyer.academy/playbooks/ki-fuer-selbststaendige-angebote-und-mails) [77. Spotting and correctly labelling AI content](https://studiomeyer.academy/playbooks/ki-inhalte-erkennen-und-kennzeichnen) [78. AI meeting notes that are actually usable](https://studiomeyer.academy/playbooks/ki-notizen-fuer-meetings) [79. Local AI on your own machine, so your data never leaves the house](https://studiomeyer.academy/playbooks/lokale-ki-auf-dem-eigenen-rechner) [80. Understanding the three MCP primitives. Tools, Resources and Prompts](https://studiomeyer.academy/playbooks/mcp-primitives-tools-resources-prompts) [81. Reliable JSON from any AI, so your automation doesn't break](https://studiomeyer.academy/playbooks/verlaessliches-json-aus-ai) [82. What AI tools really cost, and where the hidden bills hide](https://studiomeyer.academy/playbooks/was-kostet-ki-wirklich) [83. Understanding prompt injection, the three traps when your AI assistant reads foreign text](https://studiomeyer.academy/playbooks/prompt-injection-erkennen) [84. Protecting yourself from AI fraud, fake calls, phishing and bogus job offers](https://studiomeyer.academy/playbooks/dich-vor-ki-betrug-schuetzen) [85. Opus 5 migration, when thinking becomes the default](https://studiomeyer.academy/playbooks/opus-5-migration) [86. The AI policy for small teams, on a single page](https://studiomeyer.academy/playbooks/ki-richtlinie-fuer-kleine-teams) [87. Stopping agents that drift off course](https://studiomeyer.academy/playbooks/agenten-die-abdriften-stoppen) [88. Seeing what your agent actually did, tracing in 10 steps with OpenTelemetry](https://studiomeyer.academy/playbooks/agent-tracing-mit-opentelemetry) [89. Having AI summarize long documents without it inventing things](https://studiomeyer.academy/playbooks/lange-dokumente-sicher-zusammenfassen) [90. Vetting third-party MCP servers safely before you install them](https://studiomeyer.academy/playbooks/fremde-mcp-server-sicher-pruefen) [91. AI as a learning coach: teaching yourself a new field for a career change](https://studiomeyer.academy/playbooks/ki-lern-coach-berufswechsel) [92. The AI operator job: what do you actually do?](https://studiomeyer.academy/playbooks/berufsbild-ai-operator) [93. Using AI without losing your own edge](https://studiomeyer.academy/playbooks/ki-nutzen-ohne-selbst-zu-verlernen) [94. Why your screenshot shrinks, and how to control it](https://studiomeyer.academy/playbooks/bilder-und-screenshots-an-die-ki-geben) [95. Framing a deep research brief so the report is actually worth something](https://studiomeyer.academy/playbooks/deep-research-auftrag-formulieren) [96. Analysing numbers and tables with AI without ending up with nonsense](https://studiomeyer.academy/playbooks/zahlen-und-tabellen-mit-ki-auswerten) [97. Reading AI benchmarks without being taken for a ride](https://studiomeyer.academy/playbooks/ki-benchmarks-richtig-lesen) [98. AI as a sparring partner, better decisions instead of polite agreement](https://studiomeyer.academy/playbooks/ki-als-sparringspartner-fuer-entscheidungen) [99. Learning a new skill with AI, the honest way](https://studiomeyer.academy/playbooks/mit-ki-neue-faehigkeit-lernen) [100. Changing your MCP server without breaking your users](https://studiomeyer.academy/playbooks/mcp-server-aendern-ohne-nutzer-zu-brechen) [101. Your first local AI model in 30 minutes](https://studiomeyer.academy/playbooks/erstes-lokales-modell-in-30-minuten) [102. Which local model fits your hardware](https://studiomeyer.academy/playbooks/welches-lokale-modell-passt-zu-deiner-hardware) [103. Local AI and the GDPR, what it really solves and what it does not](https://studiomeyer.academy/playbooks/lokale-ki-und-die-dsgvo) [104. MCP with local models, tools without the cloud](https://studiomeyer.academy/playbooks/mcp-mit-lokalen-modellen) [105. Local or cloud, the honest arithmetic](https://studiomeyer.academy/playbooks/lokal-oder-cloud-die-ehrliche-rechnung) [106. When a stranger's repo configures your AI. The ChainDrop case](https://studiomeyer.academy/playbooks/agent-konfiguration-als-angriffsweg) [107. Transcribing conversations offline, without them leaving the building](https://studiomeyer.academy/playbooks/gespraeche-offline-transkribieren) [108. Connecting n8n to a local model](https://studiomeyer.academy/playbooks/n8n-mit-lokalem-modell-verbinden) [109. Reading documents offline when the scan must not be uploaded](https://studiomeyer.academy/playbooks/dokumente-offline-auslesen) [→ Zur Academy](https://studiomeyer.academy/levels/1)

## Sitemap

Public pages of this site as Markdown: [sitemap](https://studiomeyer.academy/sitemap.md). Curated entry point: [llms.txt](https://studiomeyer.academy/llms.txt), full text: [llms-full.txt](https://studiomeyer.academy/llms-full.txt).