Runyard is a free hardware-aware AI model browser. You enter your CPU, GPU, and VRAM and it instantly shows every local LLM that will run on your machine, ranked by speed and quality.

How much VRAM do I need to run local LLMs?

8GB of VRAM runs 7B models like Llama 3.1 8B and Mistral 7B at Q4 quantization. 16GB unlocks 13B models. 24GB lets you run Mixtral 8x7B and Llama 3 70B at lower quantization.

What is the best local LLM for my GPU?

Use Runyard at www.runyard.dev — enter your GPU and VRAM and the Model Radar will rank every compatible LLM for your exact hardware, showing estimated tokens per second for each model.

Can I run Llama 3 locally?

Yes. Llama 3.1 8B at Q4 runs on any 8GB VRAM GPU. Llama 3.1 70B needs around 40GB VRAM at Q4, or an Apple Silicon Mac with 64GB+ unified memory.

Why does Fable 5.1 use up my Claude plan so fast?

Fable 5.1 costs $10 per million input tokens and $50 per million output, exactly twice Claude Opus 5's $5 and $25. Four documented behaviours multiply that: adaptive thinking is always on and cannot be disabled, effort defaults to high, the model often rewrites whole files instead of making targeted edits, and it batches tool calls less reliably than Fable 5 so agent loops take more turns. Reasoning tokens bill as output tokens.

How do I reduce Fable 5.1 token costs?

Lower the effort level from its default of high, and change it mid-conversation rather than holding one level. Keep conversations append-only so prompt caching keeps working, since cache reads cost $0.25 per million against $10 for fresh input. Add a prompt line asking for targeted edits rather than whole-file rewrites, and one asking it to batch independent tool calls. On a workload with 90% cached input, monthly cost falls from about $1,500 to roughly $620.

Can a local model replace Fable 5.1?

Not for frontier reasoning, but it replaces the volume work that empties a plan fastest. Renaming across files, boilerplate, format conversion, first-draft tests, summaries and codebase questions are handled acceptably by a 14B or 32B model running locally at zero cost per token. A practical split is to run everything locally by default and escalate by hand for architecture decisions and difficult debugging.

What model can I run locally on a 24GB GPU?

A 32B-class coding model at Q4_K_M fits 24 GB with usable context left over, which is the sweet spot for replacing most day-to-day API calls. At 16 GB a 14B model runs comfortably, at 12 GB a 14B fits tightly, and at 8 GB an 8B model runs with context to spare. A bigger model at Q4 generally beats a smaller one at Q8.

Do local AI models cost anything to run?

There is no per-token charge. Electricity and the hardware itself are real costs, but the hardware is already bought and there is no meter, so running a task a hundred times costs the same as running it once. That removes the five-hour usage window, the background credit accrual, and any dependency on a provider keeping the model available.

← Blog/Fable 5.1 Can Empty a Max Plan in 8 Minutes. Here's What to Run Locally Instead.

September 1, 2026deep-dive

Runyard Team

@runyard_dev

12 min read

Contents

▸Why Fable burns a plan faster than Opus ▸The subscription mechanics, briefly ▸What actually reduces the bill ▸The part nobody mentions: most of this work does not need a frontier model ▸Measure before you optimise ▸The dependency argument, which is not hypothetical ▸What to run instead, by what you own ▸A sensible split to start with

Fable 5.1 Can Empty a Max Plan in 8 Minutes. Here's What to Run Locally Instead.

When Fable 5 reached Claude subscriptions, developers started reporting the same thing: open a Claude Code session, come back a few minutes later, and the five-hour usage window is gone with usage credits quietly billing in the background. One account described burning just under $100 of tokens in a single agentic session on a $100-a-month Max plan — the same workload they had run on Opus repeatedly without trouble. Fable 5.1 does not change the economics that caused it. Here is why it happens, what actually reduces it, and what runs on your own machine for nothing per token.

Comparison card showing Fable 5.1 priced at $10 per million input and $50 per million output tokens — $50 per million output tokens is the number that empties a plan. Everything below follows from it.

Why Fable burns a plan faster than Opus

Start with the rate card, because most of the answer is there. Fable 5.1 costs $10 per million input tokens and $50 per million output. Claude Opus 5 costs $5 and $25. Fable is exactly twice the price in both directions, so identical work bills double before any behavioural difference enters the picture.

Then four behaviours multiply it, and all four are documented by Anthropic rather than inferred:

▸Adaptive thinking is always on. You cannot disable it. Sending <code>thinking: {"type": "disabled"}</code> returns a 400 error. Those reasoning tokens are output tokens, billed at $50 per million.
▸Effort defaults to high. Anthropic's own migration guidance is to re-tune effort from the default, which tells you the default is deeper than most tasks need.
▸It rewrites whole files for small edits. Fable 5.1 is more likely than Fable 5 to rewrite an entire file rather than make a targeted change. The result is usually the same and the output-token cost is not.
▸Parallel tool calling is more variable. Where Fable 5 batched several tool calls, 5.1 may issue one per turn. More turns means the conversation prefix is re-sent more often, and every turn re-bills.

There is a fifth multiplier that predates Fable entirely and catches people migrating from older models: the tokenizer introduced with Claude Opus 4.7 produces roughly 30% more tokens for the same text than models older than it. If your mental model of “how much is a thousand tokens” was formed on an earlier Claude, it is under-counting by about a third.

The subscription mechanics, briefly

On the API this is simply metered billing. On a Claude subscription it is less visible, which is why the reports read as surprise rather than complaint. Claude.ai plans do not expose raw token counts; limits are described as messages or usage and reset on rolling windows. When Fable 5 came to subscriptions, Pro, Max, Team and premium Enterprise seats could spend up to 50% of their weekly limit on it, and past that it moved to usage credits billed at standard API rates.

The practical consequence is that a long agentic run does not stop at a wall. It crosses from your included allowance into credits without much ceremony, and an agent that reasons at high effort, rewrites whole files and takes an extra turn per tool call crosses that line quickly.

What actually reduces the bill

Four things work, roughly in order of effect. None of them require giving up the model.

▸Drop the effort level. The default is high. Most routine turns do not need it, and on Fable 5.1 you can change effort mid-conversation without invalidating the prompt cache, so you can raise it for one hard step and lower it again.
▸Use the cache properly. This is where Fable 5.1's only real price change sits: cache reads cost $0.25 per million, down 75% from $1. Keep the conversation append-only so the cached prefix keeps matching.
▸Ask for targeted edits. A single prompt line telling it to make surgical changes rather than rewriting whole files removes a large slice of output tokens on any file-editing workload.
▸Batch tool calls. Anthropic publishes a one-line instruction for exactly this, because the model no longer batches as reliably on its own.

A worked example makes the caching point concrete. Take an agent consuming 100 million input and 10 million output tokens a month. At list rates that is $1,000 plus $500, so $1,500. If 90% of the input is served from cache, the input side falls to about $122 and the total to roughly $620. The single biggest lever on a Fable bill is how much of your context is cached rather than fresh.

The part nobody mentions: most of this work does not need a frontier model

Here is the uncomfortable arithmetic. The tasks that burn a plan fastest — renaming things across files, writing boilerplate, converting formats, first-draft tests, summarising a diff, answering questions about a codebase — are not frontier-reasoning tasks. They are volume tasks. You are paying $50 per million output tokens for work a 14B model does acceptably, and paying it on every single run.

A local model costs nothing per token. Not less: nothing. The electricity is real and the hardware is a sunk cost you have already paid, but there is no meter. That changes which tasks are worth automating, because the ones you currently avoid on cost grounds become free to run in a loop.

It also removes the failure mode entirely. There is no five-hour window to exhaust, no credits accruing in the background, and no export-control event that can take the model away — which is not hypothetical, since Fable 5 was suspended worldwide for 19 days in June 2026 before returning on 1 July.

Measure before you optimise

Most people guess at where their tokens go and guess wrong. Two numbers settle it. The first is your ratio of output to input tokens: output costs five times input on Fable 5.1, so a workload that looks input-heavy on token counts is usually output-heavy on cost. The second is your cache hit rate, because fresh input costs forty times what a cached read costs.

If you are on the API, both come back in the usage object on every response. If you are on a subscription, you cannot see raw counts, and the practical substitute is to watch which kinds of session move the needle: a long agentic run in Claude Code will dwarf dozens of ordinary chat turns, because it is the one generating reasoning tokens, tool-call turns and whole-file rewrites.

The dependency argument, which is not hypothetical

Cost is the obvious reason to move volume work off a hosted frontier model. Availability is the one people only appreciate after it bites. On 12 June 2026 the US applied export controls to Claude Fable 5 and Claude Mythos 5, and Anthropic suspended access worldwide rather than risk breaching an order that took effect immediately. Access returned on 1 July, after 19 days.

Nothing about that was Anthropic behaving badly, and nothing about it is likely to repeat soon. That is rather the point: a well-run provider with every incentive to keep the lights on still went dark for nineteen days for reasons entirely outside its control. A model sitting on your own disk has no such failure mode, which is worth something independent of the per-token maths.

What to run instead, by what you own

The honest framing is a split rather than a replacement. Local models do not match Fable 5.1 on the hardest reasoning. They comfortably handle the volume work that is emptying your plan. Run the volume locally, keep the frontier model for the handful of problems that genuinely need it, and the bill collapses without the quality falling where it matters.

▸8 GB card: an 8B-class model at Q4_K_M, with context to spare. Genuinely useful for summarising, rewriting, boilerplate and simple edits.
▸12 GB: a 14B-class model at Q4_K_M. This is the point where local coding assistance stops feeling like a compromise for everyday tasks.
▸16 GB: 14B comfortably with long context, or a 32B at tighter quantisation and shorter context.
▸24 GB: a 32B-class coding model at Q4_K_M with usable context. The sweet spot for replacing most day-to-day API calls.
▸32 GB and up: larger models, or a 32B with very long context for whole-repository work.

A rule that holds across all of them: a bigger model at Q4 generally beats a smaller model at Q8. Fit the largest model you can at Q4_K_M rather than running a small one at high precision.

Which specific model depends on your exact card, system RAM and runtime, which is what our <a href="/models">Model Explorer</a> exists to answer — you give it your hardware and it ranks what actually fits, rather than making you guess from parameter counts. The <a href="/gpu">GPU pages</a> cover what each card runs, and the <a href="/run">run guides</a> carry the commands with the right quantisation filled in.

A sensible split to start with

If you want a concrete policy rather than a principle: route everything to a local model first, and escalate by hand. Keep the frontier model for architecture decisions, gnarly debugging, and anything where being wrong is expensive. Send renaming, scaffolding, tests, documentation, commit messages and code questions to the local one.

Most people find the split lands somewhere near 80/20 by volume and near the inverse by value, which is exactly the shape that makes a subscription last the month. And if you are still paying for frontier calls, drop effort, cache aggressively and ask for targeted edits — those three together typically matter more than switching models.

Tell it your GPU, RAM and backend, and it ranks every open-weight model that actually fits your machine.

Open the Model Explorer → →

September 1, 2026

Try Runyard

Find AI models that fit your exact hardware. Enter your specs and get a ranked list instantly.

Newsletter