What decides which model you can run?

It comes down to memory. On a Mac that's the unified memory your CPU and GPU share, and on a PC it's the VRAM on your graphics card. If a model doesn't fit, Ollama spills the rest into system RAM, but generation slows to a crawl once that happens.

Most of Ollama's default tags are 4-bit quantizations, and a 4-bit file comes out at roughly a quarter to a third of the size of the 16-bit weights. You can see this on Ollama's tags page for Qwen3.8-Flash-Next, which is 355 GB at bf16 and 120 GB at q4_K_M. Treat the download size as the floor, because your operating system and the model's context cache need room on top of it.

The context cache is the part people forget. Ollama doesn't load a model with its full window. Instead, its context-length docs set the default by how much VRAM you have, with 4K tokens under 24 GiB, 32K from 24 to 48 GiB, and 256K above that.

Ollama's own Claude Code guide asks for 64K or more. That means an agent on a 16 GB laptop starts with a 4K window and loses track of your repository after a file or two. You can raise the limit when you start the server:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

If you only need it for a single request, pass num_ctx in the API options, or type /set parameter num_ctx 64000 inside ollama run. Then run ollama ps and check the CONTEXT column to confirm the change took. Keep in mind that every extra token of context costs memory, so a model that loads fine at 4K can fail to load at 64K.

If you want the short version before the tier-by-tier detail, find your memory size in the chart below.

The model to start with at each memory size, based on the picks in this guide.

Which model should you run on 8 to 16 GB?

On a 16 GB machine, gpt-oss-20b is the pick. OpenAI's model card says it runs "within 16GB of memory", and the Ollama download (gpt-oss:20b) is 14 GB. It calls tools, holds 128K tokens, and is licensed under Apache 2.0.

The reason to pick it is the coding score. OpenAI's model card PDF reports 60.7 on SWE-bench Verified at high reasoning effort, which is the best SWE-bench score in this tier by a distance. The 53.2 you'll see on the Hugging Face card comes from the medium-effort run.

The catch is memory. On a 16 GB Mac, 14 GB of weights leaves only 2 GB for macOS and the context cache, so either close everything else or treat it as a 24 GB model.

Gemma 4 12B is the more comfortable fit for 16 GB. The gemma4:12b tag is 8 GB, which leaves real room for context, and Google's model card lists native function calling and a 256K window under Apache 2.0. Google reports 72.0 on LiveCodeBench v6, but you can't line that up against gpt-oss's SWE-bench number. LiveCodeBench is made of contest-style programming problems, while SWE-bench measures edits to an existing repository.

Granite 4.2 8B is the only model here that fits an 8 GB machine. The granite4.2:8b tag is 5.3 GB with a 128K context, and IBM's card reports 47.67 on SWE-bench Verified for a model it released on 25 August 2026. IBM says it supports tool calling, but Ollama's library page doesn't carry the tools badge, so try it in your agent before you depend on it.

Which model should you run on 24 to 32 GB?

Run Qwen3.8-27B, and keep Muse Glimmer-30B as your second choice. This is the tier where local coding gets good, and both of these Apache 2.0 models come in at the same 18 GB download.

Qwen3.8-27B went public on 14 August 2026. The qwen3.8:27b tag is the q4_K_M build at 18 GB, it calls tools, and the model card gives a native context of 262,144 tokens that can be extended to a million. Qwen reports 73.0 on Terminal-Bench 2.1, 61.7 on SWE-bench Pro, and 90.3 on LiveCodeBench v6. Because it's a dense model, all 27 billion parameters work on every token, and its card lists native image and video understanding, so it can work from screenshots and diagrams as well as text.

Muse Glimmer-30B is Meta's dense 30B model, released in August 2026. Its card says 4-bit weights shrink the language model "to under 20 GB", and the Ollama tag muse-glimmer:30b comes in at 18 GB with tool calling and image input. Meta reports 76.0 on SWE-bench Verified, 51.2 on SWE-bench Pro, and 51.7 on Terminal-Bench 2.1, and the window is 128K.

Start with Qwen3.8-27B. Qwen's model card ran Glimmer through the same Claude Code harness on SWE-bench Pro, and Qwen leads that comparison by 10.5 points while holding twice the context. Its Terminal-Bench 2.1 lead is bigger, at 21.3 points, but the two vendors ran that benchmark through different agent setups, so treat it as a rough signal. Glimmer's 76.0 is the highest SWE-bench Verified score in this article, but Qwen doesn't publish a Verified number to set beside it.

So keep Glimmer around as the second model for the times Qwen stalls on a task. Both licenses let you fine-tune and ship the result, and our fine-tuning guide covers when that beats writing better prompts.

The rest of this tier is for more specific needs:

• Gemma 4 31B and 26B A4B. The gemma4:31b tag is 19 to 20 GB and scores 80.0 on LiveCodeBench v6. The gemma4:26b tag is 16 to 19 GB and scores 77.1, and because it's a mixture-of-experts model with 3.8B of its 25.2B parameters active per token, it generates faster than the dense models here. Both have 256K windows under Apache 2.0.
• Granite 4.2 30B. This is a dense model at 18 GB (granite4.2:30b) with a 128K context under Apache 2.0. IBM reports 57 on SWE-bench Verified, which puts it 19 points behind Glimmer at the same download size.
• Nemotron 3.5 Lightning 30B-A3B. This is the one to pick for long context. NVIDIA's card gives up to a million tokens, though NVIDIA itself uses 256K on a single H100. The nemotron-3.5-lightning:30b tag ranges from 19 GB (NVFP4 for Apple silicon) to 25 GB (q4_K_M). It scores 51.56 on SWE-bench Verified and 24.58 on Terminal-Bench 2.1, under the OpenMDW 1.1 license.
• Nemotron 3.5 Bolt 74B-A9B. NVIDIA's card says it uses "a native 2-bit quantization to fit in 24GB of memory", but only the experts are 2-bit, and the Ollama tag nemotron-3.5-bolt:74b-a9b is 25 GB. Plan on a 32 GB machine for this one, since a 24 GB card won't hold it. It scores 50.98 on Terminal-Bench 2.1 and has a 256K window, under OpenMDW 1.1.

What do 80 GB to 128 GB machines get you?

They get you less than you'd expect, at least on coding benchmarks, because the extra memory mostly buys speed and context.

gpt-oss-120b is a 65 GB download (gpt-oss:120b), and OpenAI's card says it runs "on a single 80GB GPU (like NVIDIA H100 or AMD MI300X)". That rules out a 64 GB Mac, which can't hold 65 GB of weights, so think 96 GB or 128 GB. It scores 62.4 on SWE-bench Verified at high effort and 52.6 at medium, with a 128K context, under Apache 2.0.

Nemotron 3.5 Super-VL 120B-A12B is 90 GB at q4_K_M and 80 GB in the Apple silicon build, and on Ollama it goes by nemotron-3.5-super instead of super-vl. NVIDIA's card reports 71.10 on SWE-bench Verified, 51.78 on SWE-bench Pro, and 60.67 on Terminal-Bench 2.1, with a million-token window, under OpenMDW 1.1. That puts it 8.7 points above gpt-oss-120b on Verified, for 25 GB more memory.

Qwen3.8-Flash-Next needs most of a 128 GB machine, at 105 GB in the MLX build and 120 GB at q4_K_M. There's no latest tag, so pull qwen3.8-flash-next:125b-a6b-q4_K_M by name. Its card describes a 125B language model with 6B active parameters and reports 62.5 on SWE-bench Pro and 91.9 on LiveCodeBench v6. Unlike the Apache 2.0 models above, it ships under the Qwen Community License 1.0.

The telling comparison is with its small sibling. Flash-Next scores 0.8 points above Qwen3.8-27B on SWE-bench Pro, for 6.7 times the download. What the big machine buys you is speed, since only 6B parameters are active per token against 27B, along with room for long context and the option to keep two models loaded. The coding itself barely improves.

How do all thirteen compare?

The table puts all thirteen side by side, sorted by the memory each one needs, from the 5.3 GB Granite 4.2 8B up to the 120 GB Qwen3.8-Flash-Next.

Every score is the vendor's own, read from the model cards and Ollama's library pages on 27 and 28 October 2026. Vendors choose their own harness, reasoning effort, and benchmark version. OpenAI's numbers are at high effort, for example, and Qwen and Meta run Terminal-Bench 2.1 through different Terminus agent setups.

So only compare scores on the same benchmark, and treat a gap of a point or two as a tie. Before you settle on a model, run it against your own repository.

How do you point Claude Code or OpenCode at a local model?

You point both of them at Ollama's local server. Both agents work through tool calls, so pick a model with tool calling and give it at least 64K of context.

Both agents talk to the same Ollama server, each through its own compatible API.

For Claude Code, Ollama's integration page has a one-line setup. ollama launch claude configures Claude Code for Ollama, and --model names the model you want:

ollama launch claude --model qwen3.8:27b

If you'd rather wire it up by hand, point Claude Code at Ollama's Anthropic-compatible endpoint:

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3.8:27b

For OpenCode, add Ollama as an OpenAI-compatible provider in opencode.json, the way its providers docs show:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen3.8:27b": {
          "name": "Qwen3.8 27B"
        }
      }
    }
  }
}

OpenCode's docs say to raise num_ctx if tool calls fail, and they suggest starting at 16K to 32K. Go straight to Ollama's 64K instead. Whenever tool calls break on a local model, a short context is the first thing to check.

Which coding models are too big to run locally?

The strongest open-weight coding models don't fit on any desktop. Kimi K3 has 2.8 trillion parameters, and its weight files add up to about 1.56 TB. GLM-5.3 has 753 billion parameters and takes about 756 GB on Hugging Face. Meta's Muse Spark Open has 816 billion parameters, and its card asks for at least 700 GB of GPU memory at NVFP4, so a 128 GB workstation holds less than a fifth of what it needs.

If what you want is the code written, Buildful runs these models for you. It's an AI coding agent: you describe a change, and it builds it, tests it in a real browser, and opens a pull request on your GitHub repo. It runs open-weight models in the cloud, so there's no GPU to buy and nothing running on your laptop.

Pro is $10 a month for 1,000 Smart Mode tasks, where Buildful picks the open-weight model for each task, and you can try three tasks free with no card. Picking a model yourself, such as Kimi K3 or GLM-5.3, draws on prepaid credit, and the $30 Buildful Pass adds $80 of monthly usage on Kimi K3, DeepSeek V4.1 Flash, GLM-5.3 Flash, and MiniMax M3.1 Flash. The trade-off is the same one that sent you local in the first place, because Buildful works on your code in its cloud sandbox instead of on your machine.

If you need an API to build on instead, the labs and hosts such as Together and Fireworks serve these models per token. Our guide to running open-weight models free or cheap compares the hosts and their free tiers, and our ranking of the best open-weight LLMs for coding covers the models too big for this list.

FAQ

What LLM can I run locally?

You can run the strongest model whose Ollama download fits in your memory once you set aside a few gigabytes for the operating system and the context cache. That works out to Granite 4.2 8B on 8 GB, gpt-oss-20b or Gemma 4 12B on 16 GB, Qwen3.8-27B or Muse Glimmer-30B on 24 to 32 GB, and gpt-oss-120b, Nemotron 3.5 Super-VL, or Qwen3.8-Flash-Next from 80 GB up.

What's the best local LLM for coding?

Qwen3.8-27B is the best local LLM for coding in this guide. It's an 18 GB download under Apache 2.0, it calls tools, and it holds 262,144 tokens natively. Its vendor-reported 61.7 on SWE-bench Pro is within a point of Qwen3.8-Flash-Next, a model that needs 120 GB. Muse Glimmer-30B is a close second, with the highest SWE-bench Verified score of any model here at 76.0.

How much RAM do I need for a local LLM?

You need 16 GB to run a useful coding model, and 32 GB gets you the best value. On 16 GB you can run gpt-oss-20b at 14 GB or Gemma 4 12B at 8 GB. On 32 GB you can run Qwen3.8-27B or Muse Glimmer-30B with room for a 64K context. Past that, extra memory buys speed and context more than coding ability.

Can a local model drive Claude Code?

Yes, Claude Code can run against a local model through Ollama. Run ollama launch claude --model qwen3.8:27b, or set ANTHROPIC_BASE_URL=http://localhost:11434, ANTHROPIC_AUTH_TOKEN=ollama, and an empty ANTHROPIC_API_KEY, then start claude with a local model. Pick a model with tool calling and raise Ollama's context to 64K, because on a machine with under 24 GiB of VRAM the default is 4K.

Can I use Kimi K3 or GLM-5.3 without the hardware?

Yes. Buildful runs both in the cloud as a coding agent, which the section on models too big to run locally explains, including how picking a model is billed. If you'd rather have raw API access, Moonshot and Z.ai sell their own APIs, and Together and Fireworks serve both per token.

This list covers the weights you can download as of 28 October 2026, and we'll update it as new models ship. The first change on the calendar is Kimi K3.1 Pro, whose weights Moonshot has promised by 4 November. Every license, size, and score below comes from the vendor's own model card. For what each host charges, see our guide to free and cheap open-weight model APIs.

How we ranked them

We ranked the models on three tests, in order: whether you can download the weights today, whether the license lets most teams ship, and how the vendor's own coding benchmarks look for what each model is built to do. The first test is the only thing keeping Kimi K3.1 Pro off the list.

You should read those scores with care, because every lab picks its own harness and benchmark version, and numbers from two different cards rarely line up. Moonshot reports Kimi K3 at 88.3 on Terminal-Bench 2.1 with its own Kimi Code harness, while DeepSeek's table, which runs Terminal-Bench 4.0 through Claude Code, has the same model at 12.6. So we compare models inside a single vendor's table wherever we can, and we ignore gaps of a few points between cards.

The 10 at a glance

Each score comes from the vendor's own card and test setup, so only compare two rows where they name the same benchmark.

1. DeepSeek V4.1 Flash (1017 snapshot)

Best for: the default model for coding agents, with no license conditions.

• License: MIT, OSI-approved
• Size and context: 552B per DeepSeek, 1M tokens
• Coding scores: DeepSWE 77.0 (Mini-SWE-V2 harness), Terminal-Bench 4.0 42.3 (Claude Code harness), NL2Repo 68.2
• Run it on: DeepSeek's API (model deepseek-flash), Together, Fireworks, Ollama, Cloudflare, OpenCode Go, or Buildful as a coding agent

DeepSeek released V4.1 Flash on 10 September 2026 and shipped the 1017 snapshot on 17 October with shorter outputs than the first version. The release note describes a 552B mixture-of-experts model with 8B parameters active for input and 16B for output, although Hugging Face counts 763B in the checkpoint.

DeepSeek's own model card puts Claude Opus 5 next to it on the same three benchmarks, where Opus 5 scores 74.0, 51.8, and 75.3. Flash beats Opus 5 on DeepSWE and trails it on Terminal-Bench 4.0 and NL2Repo. Getting that close to a frontier model under an MIT license is what makes it our top pick.

2. Kimi K3

Best for: the most parameters you can download.

• License: Kimi K3 License, custom
• Size and context: 2.8T total, 104B active, 1,048,576 tokens
• Coding scores: Terminal-Bench 2.1 88.3, DeepSWE 67.5 (67.3 on the official leaderboard)
• Run it on: Moonshot's Kimi API, Together, Fireworks, DeepInfra, Ollama, or Buildful

Kimi K3 is the largest model on this list, and its Terminal-Bench 2.1 score is the highest among the models that report that benchmark. Both scores come from Moonshot's own Kimi Code harness. The weight files alone add up to about 1.56 TB, so you'll need a cluster to run it yourself.

The license opens with an MIT-style grant and then adds two gates. A model-as-a-service business past $20 million in revenue over 12 months needs a separate agreement with Moonshot, and a product past 100 million monthly users or $20 million in monthly revenue has to show "Kimi K3" in its interface. Our launch coverage has the details.

3. GLM-5.3

Best for: a coding-first model with terms that almost nobody hits.

• License: GLM-5.3 License, custom (MIT-style text plus the review clause)
• Size and context: 753B per Hugging Face, evaluated at 1M tokens
• Coding scores: Terminal-Bench 2.1 88.2 (Claude Code harness), DeepSWE 66.9
• Run it on: Z.ai's API or its GLM Coding Plan, Together, Fireworks, Ollama, Cloudflare, OpenCode Go, or Buildful

Z.ai's card calls GLM-5.3 "the most capable open-weights model for coding", and its Terminal-Bench 2.1 score sits a tenth of a point behind Kimi K3. The card doesn't give a parameter count or a context spec, though Hugging Face counts 753B and Z.ai runs its long-horizon evals with a 1M-token window.

The license is an MIT-style grant with a single condition: a model-as-a-service business past $10 billion in revenue must pass Z.ai's security review before commercial use. That clause reaches almost nobody, so for nearly every team the terms work like MIT.

4. MiniMax M3.1 Flash

Best for: agents and computer use.

• License: MiniMax Community License, custom
• Size and context: about 428B total per MiniMax (Hugging Face counts 220.5B), 23B active, 1M tokens
• Coding scores: DeepSWE 73.7, Terminal-Bench 4.0 38.1
• Run it on: MiniMax's API, Together, OpenCode Go, or Buildful

MiniMax pitches M3.1 Flash at coding, agents, and computer use, and among the models that report DeepSWE, only DeepSeek V4.1 Flash scores higher. The card says the model has about 428B parameters, but the Hugging Face widget shows 220B, so check before you size your hardware.

The license grants non-commercial use by default. Commercial use needs a "Built with MiniMax M3.1-Flash" notice and a one-time email to MiniMax. Once your product passes $20 million in yearly revenue, you need written permission first, and that applies to fine-tunes as well.

5. DeepSeek V4 Pro

Best for: the biggest model under MIT.

• License: MIT, OSI-approved
• Size and context: 1.6T total, 49B active, 1M tokens
• Coding scores: SWE-bench Verified 80.6, SWE-bench Pro 55.4 (Max mode)
• Run it on: Together, DeepInfra, Ollama, or Cloudflare

DeepSeek V4 Pro carries the same MIT license as Flash at three times the size. Its scores above come from Max reasoning mode, and without thinking they drop to 73.6 and 52.1. The card still calls the V4 series a preview.

It ranks below Flash because DeepSeek itself has stepped back from it. Its 10 September note says that from 14 September, every deepseek-v4-pro request on DeepSeek's API goes to V4.1 Flash until V4.1 Pro launches. If you want to run Pro, you'll need someone else's GPUs.

6. Inkling and Inkling-Small

Best for: fine-tuning.

• License: Apache 2.0, OSI-approved
• Size and context: 975B / 41B (up to 1M tokens) and 276B / 12B (Hugging Face counts 266B)
• Coding scores: SWE-bench Verified 77.6 (Inkling) and 80.2 (Inkling-Small)
• Run it on: Tinker for fine-tuning (64K and 256K context options), Together, Fireworks, Modal, Databricks, Baseten, or OpenRouter's free collection

Thinking Machines built Inkling to be customized and released it on 15 July 2026, then shipped Inkling-Small about two weeks later. On the same bash-only harness, the small model scores higher on SWE-bench Verified than the big one, which makes it the better starting point for most coding fine-tunes.

Inkling-Small is also light enough to run on one multi-GPU node. Our Inkling fine-tuning guide walks through the process.

7. Muse Spark Open

Best for: coding from screenshots, recordings, or audio.

• License: Muse Model License, custom
• Size and context: 816B total (Hugging Face counts 822B), 42B active, 1M tokens
• Coding scores: Terminal-Bench 2.1 76.4 (Terminus 2), DeepSWE 60
• Run it on: Together, Fireworks, Ollama, or Buildful

Meta shipped Muse Spark Open on 15 October 2026, and it takes text, image, video, and audio as input. Its coding scores trail the leaders, but the license is the bigger drawback.

To download the weights, you fill in a gated form with your legal name and date of birth. Every product built on the model has to display "Built with Muse Spark Open", and a model-as-a-service business past $20 million in yearly revenue needs a separate written agreement with Meta.

8. NVIDIA Nemotron 3.5 Super-VL 120B-A12B

Best for: a permissive license at mid size.

• License: OpenMDW-1.1, permissive
• Size and context: 120B total, 12B active, 1M tokens
• Coding scores: SWE-bench Verified 71.10
• Run it on: your own GPUs from the Hugging Face checkpoints, or NVIDIA's build.nvidia.com, which hosts the Nemotron family

NVIDIA released Nemotron 3.5 Super-VL on 15 October 2026 with vision input, and it published both BF16 and NVFP4 checkpoints. Its SWE-bench score sits well behind the top five.

What earns it a place here is the license. OpenMDW-1.1 is a permissive license written for model weights, and it has no revenue gate.

9. Qwen3.8-Flash-Next

Best for: near-frontier coding on one 128 GB machine.

• License: qwen-community-1.0, custom
• Size and context: 125B total, 6B active, 262K tokens (1M extended)
• Coding scores: SWE-bench Pro 62.5
• Run it on: your own 128 GB machine, or Alibaba's hosted Qwen3.8-Flash API, which defaults to 1M tokens

Qwen3.8-Flash-Next activates only 6B parameters per token, and its SWE-bench Pro score is the highest among the models here that report one. Once you add a 51B n-gram embedding and a 4B multi-token-prediction head, the checkpoint holds 180B parameters.

The card gives no memory figure, but Ollama's tags do: the q4_K_M build is a 120 GB download and the MLX build is 105 GB. That fits a 128 GB machine with little to spare, so keep the context window modest. The license is Alibaba's own qwen-community-1.0, so read it before you ship.

10. Qwen3.8-27B

Best for: small, permissive, and local.

• License: Apache 2.0, OSI-approved
• Size and context: 27B dense, 262K tokens (1M extended)
• Coding scores: Terminal-Bench 2.1 73.0, SWE-bench Pro 61.7
• Run it on: Ollama locally, Cloudflare Workers AI, Groq (including its free plan), or Cerebras

Qwen3.8-27B is a dense model under Apache 2.0. Its scores are Alibaba's, measured on a harness Alibaba chose, so don't compare them with the trillion-parameter models above. At 4 bits it's an 18 GB download in Ollama, which puts it on a single 24 GB GPU or a recent Mac. Its card also lists native image and video understanding, which helps when you want to turn a screenshot or a diagram into code.

Our companion post on the best local LLMs for coding covers it alongside other single-machine models.

On the watch list: Kimi K3.1 Pro

Kimi K3.1 Pro is the next model we expect to add, as soon as Moonshot publishes the weights. Moonshot calls K3.1 Pro its "most capable 3T-class open-weight model" and reports 65.7% on Terminal-Bench 4.0 with the Claude Code harness, against 66.4% for Claude Opus 5.5 in the same post. That would put it far ahead of the two models above that report Terminal-Bench 4.0.

The weights aren't out yet, though. Both the blog post and the quickstart say they'll be released by 4 November 2026, and as of 28 October there's no K3.1 repo on Moonshot's Hugging Face page. Moonshot hasn't published a parameter count or a license either.

You can already use it through the Kimi API, OpenRouter, OpenCode Go, and Buildful.

Open source vs open weight: what's the difference?

The difference is how much of the model you get. An open-weight model publishes its trained weights so you can download and run it. Open source, as the Open Source Initiative defines it, also asks for the code, enough detail about the training data to rebuild the model, and no limits on who may use it or for what.

By that test, a model that ships downloadable weights and nothing else counts as open-weight. Most people say "open-source LLM" for both anyway, but the license is what decides what you can build. The models on this list fall into three groups:

• OSI-approved: MIT (DeepSeek V4.1 Flash, DeepSeek V4 Pro) and Apache 2.0 (Inkling, Inkling-Small, Qwen3.8-27B), with no revenue gates and no branding requirements.
• Permissive, not OSI-approved: OpenMDW-1.1 (Nemotron 3.5 Super-VL).
• Custom: Kimi K3, GLM-5.3, MiniMax M3.1 Flash, Muse Spark Open, and Qwen3.8-Flash-Next, each with its own revenue thresholds, notices, or separate agreements.

The chart below turns those groups into the question most teams ask, which is whether they can ship a product on the model.

Whether you can ship on each model, by license. Read the full license before you rely on it.

How do you code with these models without hosting them?

You can use a cloud coding agent, an API host, or a coding plan. Most teams won't run a trillion-parameter checkpoint themselves, and none of these routes asks you to.

Which route fits depends on what you want back from the model.

A cloud coding agent. Buildful is an AI coding agent: you describe a change, and it builds it, tests it in a real browser, and opens a pull request on your GitHub repo. It runs open-weight models in the cloud, so there's no GPU or API key to set up. Smart Mode picks an open-weight model for each task, and on the Pro and Team plans you can pick one yourself. The picker carries five models from this list (DeepSeek V4.1 Flash, Kimi K3, GLM-5.3, MiniMax M3.1 Flash, and Muse Spark Open) plus Kimi K3.1 Pro.

Pro costs $10 a month for 1,000 Smart Mode tasks. When you pick a model yourself, you pay from prepaid credit, and frontier models like Claude and GPT also take your own API key. The $30 Buildful Pass gives you $80 of monthly usage on four models, Kimi K3, DeepSeek V4.1 Flash, GLM-5.3 Flash, and MiniMax M3.1 Flash, so you can pick those without topping up credit. The trade-off is that Buildful hands you pull requests rather than an endpoint, so it won't help if you need an API for your own product.

An API host. OpenRouter and Together serve most of the models above behind an OpenAI-compatible API, and you bring your own agent. Our open-weight API guide lists their prices and free tiers.

A coding plan. OpenCode Go and Z.ai's GLM Coding Plan sell a monthly allowance on these models for the coding agent you already use, such as Claude Code or OpenCode.

Which one should you pick?

If you only want one, start with DeepSeek V4.1 Flash, and use the table when your constraints point elsewhere.

FAQ

What is an open-weight model?

An open-weight model is one whose trained weights are published for anyone to download, run, and fine-tune on their own hardware. The license decides what you're allowed to do with them. Open-weight doesn't mean open source, because most open-weight releases don't include the training data or the full training code.

What's the best open-source LLM for coding?

DeepSeek V4.1 Flash is the best open-source LLM for coding as of 28 October 2026. It's MIT-licensed, has a 1M-token context, and leads Kimi K3 and GLM-5.3 by about ten points on DeepSWE in DeepSeek's own table, at 77.0 against 67.5 and 66.9. Its own Terminal-Bench 4.0 score is 42.3. If custom license terms work for you, Kimi K3 and GLM-5.3 score highest on Terminal-Bench 2.1.

Can I use open-weight models commercially?

Usually you can, as long as you check the license first. The MIT and Apache 2.0 models (DeepSeek V4.1 Flash, DeepSeek V4 Pro, Inkling, Qwen3.8-27B) carry no revenue gates. MiniMax M3.1 Flash needs written permission once your product passes $20 million in yearly revenue, and Kimi K3 and Muse Spark Open need a separate agreement if you sell the model as a service past $20 million. MiniMax and Meta also require a "Built with" notice, and Kimi requires its name in the interface of very large products.

Which open-weight model has the longest context?

One million tokens is the ceiling on this list. DeepSeek V4.1 Flash, DeepSeek V4 Pro, Kimi K3, MiniMax M3.1 Flash, Muse Spark Open, Nemotron 3.5 Super-VL, and Inkling all support it, while the Qwen3.8 models run 262,144 tokens natively and extend to 1M.

What's the easiest way to use open-weight models for coding?

It depends on what you want back. If you want finished pull requests, a cloud coding agent such as Buildful needs the least setup. If you want an endpoint for your own agent, an API host like OpenRouter or Together fits better, and a coding plan like OpenCode Go gives you a monthly allowance inside the agent you already use. The section on coding without hosting compares all three.

Which open-weight models are worth running in October 2026?

The four open-weight models worth running for coding in October 2026 are Muse Spark Open, DeepSeek V4.1 Flash, MiniMax M3.1 Flash, and Kimi K3.1 Pro. Three of them landed between 15 and 23 October: Muse Spark Open's weights on 15 October, DeepSeek's V4.1 Flash 1017 snapshot on 17 October, and MiniMax M3.1 Flash's weights on 23 October. Kimi K3.1 Pro's weights are due by 4 November. The table adds three earlier models for comparison, with prices per million tokens, input and output.

If you want a model with no conditions attached, pick DeepSeek V4.1 Flash. The 1017 snapshot is MIT-licensed and has a one-million-token window, and it costs $0.30 and $1.20 at every host that serves it, or half that off-peak on DeepSeek's own API.

The other October releases come with license conditions you should read before you build on them. Meta's Muse Spark Open has 816 billion parameters, 42 billion of them active, and takes text, image, video, and audio input. Its license requires every product built on it to display "Built with Muse Spark Open", and a model-as-a-service business past $20 million a year needs a separate deal with Meta.

MiniMax pitches M3.1 Flash at coding, agents, and computer use for $0.15 and $0.60. Its license asks for a "Built with MiniMax M3.1-Flash" notice and a one-time email to MiniMax before commercial use, and for written permission once your revenue passes $20 million.

Kimi K3.1 Pro is the largest of the four and the least settled. Moonshot calls it its "most capable 3T-class open-weight model" and bills it at a flat rate, with no surcharge for filling its one-million-token window. The weights aren't public yet, though. The quickstart promises them by 4 November, and until then Together, Fireworks, DeepInfra, Ollama, and Cloudflare don't serve it. If its license follows Kimi K3's, expect revenue gates there too.

Among the models that shipped before October, GLM-5.3 is the one Z.ai's own card calls "the most capable open-weights model for coding". Its license asks for a security review only from API businesses past $10 billion in revenue, which leaves out almost everyone reading this. Qwen3.8-27B is the small, permissive pick, a compact dense model under Apache 2.0. For a ranked list of every open-weight model you can download, with license terms and vendor scores, see our 10 best open-weight LLMs for coding.

Which free tiers are actually free?

Several platforms give you open-weight models for $0, and each one comes with a catch that the table spells out. Every figure below comes from the provider's own pricing or limits page, read on 27 October 2026.

GitHub Models is missing from that table on purpose, because GitHub fully retired it on 30 July 2026, including the playground, catalog, and inference API.

Two of these free tiers stand out from the rest. Gemma 4 on the Gemini API is the only option where a capable open-weight model costs nothing at any volume the rate limiter allows, as long as you're comfortable with Google reading your prompts.

The other is OpenRouter, where the $10 threshold is the best $10 in this article. Buying $10 of credits lifts the free-model cap from 50 requests a day to 1,000, and you keep the credits to spend on paid models.

OpenRouter's limits on free models. Screenshot: OpenRouter docs (openrouter.ai), 27 October 2026.

OpenRouter's free roster is a different set of models from the ones in the first table, though. The free collection is led by NVIDIA's Nemotron family, Poolside's Laguna, and Thinking Machines' Inkling, the open-weight model from our fine-tuning guide, and DeepSeek, GLM, and Kimi aren't on it.

Read the model card before you send anything private. Poolside says it "may use your inputs and outputs to train" when you use Laguna for free, and Liquid's card says prompts to LFM2.5 may be retained for training.

Cloudflare's allowance is easier to judge once you turn it into tokens. At gpt-oss-120b's paid rates, $0.11 a day buys about 314,000 input tokens or 147,000 output tokens, which is enough for a hobby project. The sample agent month in the cost section reads about 3.3 million input tokens a day, ten times what the allowance covers.

Does the host change the price?

For the most part, the host doesn't change the price. If you line up the same model across hosts, the rates are usually identical to the cent, because most hosts match the lab's own list rate. Prices are per million tokens, input and output.

Sources: Z.ai, DeepSeek, Together, Fireworks, DeepInfra, Ollama, and Cloudflare. The DeepSeek figures are its peak rates, and the Kimi K3 lab price comes from our launch coverage, because Moonshot's own pricing table rendered empty on 27 October.

GLM-5.3 and Muse Spark Open cost the same at every host that lists them. Prices read on 27 October 2026.

GLM-5.3 costs the same at five hosts, and Muse Spark Open costs the same at all three hosts that list it. That means asking which host charges least won't get you far. The better questions are which host is fastest, which one serves the model you need, and how each one bills cache reads.

Speed is the one place where the hosts pull apart. Cerebras lists gpt-oss-120b at about 3,000 tokens a second and charges $0.35 and $0.75 for it, while Groq lists the same model at 500 tokens a second for $0.15 and $0.60. You pay a little more than double on input to go six times faster, which is a good trade for an agent loop that waits on every response.

DeepInfra is the exception on price. Its DeepSeek V4 Pro output costs 34% less than everyone else's, and it still serves the July snapshot of V4 Flash at $0.06 and $0.18. On agent traffic, though, that output discount buys less than it seems, for reasons the next section shows.

What actually cuts the bill?

Three things cut an open-weight bill more than the host does: off-peak hours, cache-read rates, and the model you choose. To see how much each one moves, take one illustrative month of coding-agent traffic with 100 million input tokens, 80 million of them cache hits, and 3 million output tokens. That shape is normal for agents, because they reread the same repository context on every turn, which makes the input side heavy and the cache-hit rate high.

One month of coding-agent traffic (100M input tokens, 80M of them cached, and 3M output tokens) priced on each setup.

The first lever is timing, because DeepSeek's own API charges half price off-peak. Peak hours run 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays, which is 35 of the week's 168 hours. The other 79% of the week is off-peak, including a full 9am to 5pm working day on either US coast. For an American team, that makes V4 Pro effectively cost $0.66 and $1.98, which no other host in this article matches.

Check one thing before you plan around that rate. DeepSeek's 10 September note says every deepseek-v4-pro request now routes to V4.1 Flash at Flash rates until V4.1 Pro launches, and that V4 Pro is being phased out, while its pricing page still lists V4 Pro at its own rates. If you use Ollama instead, it runs its own off-peak discount on DeepSeek models on a different window: outside 12:00 to 18:00 UTC on weekdays, and all weekend.

DeepSeek's own API charges full price for 35 of the week's 168 hours.

DeepSeek's off-peak and peak rates, with the middle rows trimmed. Screenshot: DeepSeek API Docs (api-docs.deepseek.com), 27 October 2026.

The second lever is cache reads, and on agent traffic they can decide the bill. DeepInfra's 34% output discount on V4 Pro lands at exactly the same $41.80 as DeepSeek's peak rate, because DeepInfra charges $0.10 per million for cache reads against DeepSeek's $0.044. Together charges $0.13, which is why the same model costs 16% more there.

When 80% of your input is cached, the cache-read column outweighs the output column. Check it before you switch hosts for a headline rate.

The third lever, and the biggest, is the model itself. On this workload, V4.1 Flash off-peak costs a quarter of V4 Pro off-peak, and Kimi K3 costs six times as much as V4 Pro off-peak. If one of the Flash models handles your task, that saving dwarfs everything above. Our LLM API pricing comparison makes the same point for closed models: pick the tier from the task, then compare prices inside it.

Are coding plans cheaper than paying per token?

Yes, coding plans beat per-token pricing by a wide margin, as long as you stay inside each plan's rules.

Z.ai's GLM Coding Plan starts at $18 a month. Its entry tier, Lite, allows 2,000 credits per five hours and 10,000 a week. Z.ai also publishes how it converts tokens to credits: input tokens times 6.9, plus cached input times 1.7, plus output times 24, all divided by 10,000.

If you run the workload above through that formula, it comes to 34,600 credits, and Lite allows about 43,300 a month. The same tokens cost $62 at GLM-5.3's API rate, and at this traffic mix the full Lite allowance is worth about $78 at list price. Off-peak usage, outside 14:00 to 18:00 Singapore time on weekdays, burns credits at half rate.

Z.ai's FAQ lists the catches. The plan works only with supported tools such as Claude Code, Codex, OpenCode, and Cline, and subscriptions are non-refundable. The five-hour window also caps bursts at about 61 requests of 30,000 uncached input and 5,000 output tokens.

OpenCode Go costs $10 a month and covers 30 models, open and closed, including Kimi K3.1 Pro, MiniMax M3.1 Flash, DeepSeek V4.1 Flash, GLM-5.3, and Qwen3.8 Max. Each model gets its own monthly dollar budget, from $80 of DeepSeek V4.1 Flash and $20 of MiniMax M3.1 Flash down to $15 each of GLM-5.3 and Kimi K3.1 Pro. Any five-hour window can use 20% of a model's budget, and any week can use 50%. It works with other coding agents and exposes OpenAI-compatible endpoints, though OpenCode says it monitors traffic for abuse and wants agent-shaped requests.

Per-model monthly limits on OpenCode Go. Screenshot: OpenCode docs (opencode.ai), 27 October 2026.

Ollama sells the same idea with less fine print. Pro costs $20 a month and includes $60 of usage credits at its normal per-token rates, and Max costs $100 and includes $300. Either way you get three times face value on any cloud model Ollama hosts, Muse Spark Open, GLM-5.3, and DeepSeek V4 Pro included. Unused credit doesn't roll over.

MiniMax and Moonshot sell their own coding plans too, but neither publishes a token figure. MiniMax's M Plan describes its Explore and Build tiers as 3 and 7.5 times the usage of Go, and Kimi Code meters usage on a rolling five-hour window.

What if you want the code written, not an API?

If you want the code written for you, Buildful is an AI coding agent that does the work: you describe a change, and it builds it, tests it in a real browser, and opens a pull request on your GitHub repo. Every option above still leaves you to wire up the agent, the sandbox, the test run, and the review, which is fine if you already live in Claude Code. Buildful is a Claude Code alternative for when you have a GitHub repo and a backlog and want nothing to assemble.

It's a background coding agent that runs open-weight models in the cloud, so there's no GPU, no API key, and nothing running on your laptop. It works like a small AI software factory: a task goes in, a tested pull request comes out, and you can close the tab while it works.

You start a task in the browser, Slack, or Linear. Buildful works on your repo in a private cloud sandbox that's deleted when the task ends, runs your lint, type checks, and tests, and fixes what fails. It tests UI changes in a real browser and records the run, so the pull request comes back with the recording attached. Nothing reaches your main branch until you merge it.

By default, Buildful picks an open-weight model for each task. On a paid plan you can choose one yourself, and the picker already carries the October releases: Muse Spark Open, DeepSeek V4.1 Flash, MiniMax M3.1 Flash, and Kimi K3.1 Pro, alongside GLM-5.3, GLM-5.3-Flash, and Kimi K3. Frontier models are there too, on prepaid credit, for the tasks that need them.

The open-weight models you can pick on Buildful's paid plans. Screenshot: Buildful (buildful.ai), 27 October 2026.

Pricing starts at $10 a month for Pro, which covers 1,000 tasks and works out to about a cent a task. Team costs $40 for 3,000 tasks shared by everyone on it. Those tasks run on Smart Mode, where Buildful picks the open-weight model for each one.

If you'd rather choose the model yourself, that usage is paid from prepaid credit. The $30 Buildful Pass adds $80 of usage a month on four models: Kimi K3, DeepSeek V4.1 Flash, GLM-5.3 Flash, and MiniMax M3.1 Flash.

You can try three tasks free, with no card, and Buildful's privacy policy says it doesn't use your code or task content to train models. It's the wrong tool if you need an API key for your own product or a base URL to point Claude Code at, because Buildful offers neither.

How do you point Claude Code at an open-weight model?

You point Claude Code at an open-weight model by setting two environment variables, because Z.ai, MiniMax, and Moonshot all run Anthropic-compatible endpoints and Claude Code needs no other change. Here's the Z.ai version:

export ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic
export ANTHROPIC_AUTH_TOKEN=your-zai-api-key
claude

MiniMax's base URL is https://api.minimax.io/anthropic, and Kimi's overseas endpoint is https://api.kimi.ai/coding/. Z.ai's setup page and MiniMax's also show how to map Claude Code's model slots to their models. Once the variables are set, requests stop drawing on your Anthropic plan, so this doubles as a way around Claude Code's usage limits.

For everything else, an OpenAI-compatible client and OpenRouter cover the most ground with one key. OpenRouter doesn't mark up provider rates, but it charges 5.5% when you buy credits, so routing $100 of usage through it costs $105.50.

Can you run them locally for free?

Yes, you can run the smaller ones locally for free if you own the hardware, since Ollama's local runtime is MIT-licensed and unmetered. OpenAI says gpt-oss-20b runs in 16 GB of memory, which puts it on a recent laptop, and Qwen3.8-27B is a 27-billion-parameter dense model that its card calls deployment-friendly. Our guide to the best local LLMs for coding sorts every model that fits by how much memory you have.

The October releases are a different story. Muse Spark Open is 816 billion parameters and Kimi K3's weights alone are about 1.56 TB, so self-hosting either one means renting or owning a GPU cluster.

Which one should you pick?

The right model and host depend on what you're trying to do, so the table gives one pick for each goal.

FAQ

Is there a completely free API for open-weight models?

Yes, several APIs serve open-weight models for free, though all of them have limits. Gemma 4 is free of charge on the Gemini API, OpenRouter offers more than 25 free models, Groq has a free plan for gpt-oss and Qwen3.8 27B, and Cloudflare gives you 10,000 neurons a day. Google uses free-tier prompts to improve its products, and some OpenRouter providers train on free traffic.

Where can I use Kimi K3.1 Pro for coding?

You can use Kimi K3.1 Pro through Moonshot's own API and Kimi Code plan, OpenRouter, OpenCode Go, and Buildful's model picker on Pro and Team, where it's paid from prepaid credit. As of 27 October 2026, Together, Fireworks, DeepInfra, Ollama, and Cloudflare don't serve it. Moonshot says the full weights will be released by 4 November, and more hosts should follow after that.

Is there a Claude Code alternative that runs on open-weight models?

Yes, Buildful is an AI coding agent that runs open-weight models in the cloud. You describe a change, and it builds it, runs your checks, tests UI changes in a real browser, and opens a pull request on your GitHub repo. Pro costs $10 a month for 1,000 tasks on Smart Mode, where Buildful picks the model for you. On paid plans you can also pick models like Kimi K3.1 Pro, GLM-5.3, and DeepSeek V4.1 Flash yourself, paid from prepaid credit. You can try three tasks free, with no card.

Is there a subscription for open-weight coding models?

Yes, several plans charge a flat monthly fee for open-weight coding models. OpenCode Go costs $10 a month with a per-model budget, Z.ai's GLM Coding Plan starts at $18, and Ollama Pro costs $20 with $60 of credits. Buildful costs $10 a month for 1,000 tasks, and its $30 Pass adds $80 of usage on four open-weight models.

Is OpenRouter more expensive than going direct?

OpenRouter costs more than going direct only by its credit fee. Inference bills at the provider's list price, and OpenRouter adds 5.5% when you buy credits on the standard plan.

Is GitHub Models still free?

No, GitHub retired GitHub Models entirely on 30 July 2026. Its docs point to Azure AI Foundry and GitHub Copilot instead.

If you landed here mid-task with a limit message on screen, skip to what happens when you hit the Claude Code usage limit.

How do Claude Code usage limits work?

Two limits apply at once: a rolling 5-hour session limit and a weekly limit, and both are shared with your claude.ai chats.

Claude Code doesn't have a budget of its own. Every paid Claude plan has one pool, and Anthropic says the limits "are shared across Claude and Claude Code". A long chat in the browser in the morning leaves less for the terminal in the afternoon. The same goes for the VS Code, Cursor and JetBrains extensions, for Claude Code sessions in the cloud, and for subagents. Running several tasks in parallel drains the pool faster.

Everything you do with Claude on a paid plan draws from the same two limits.

The session limit runs on a rolling five-hour window. The weekly limit resets at a fixed time that Anthropic assigns to your account, so it isn't seven days from your first message. /usage shows yours.

What uses the pool up is how much work each request does, not how many requests you send. Anthropic lists the length of the conversation, attachments, tools, the model, the effort level and multi-step tasks. Prompt caches also expire when you go idle, so the first message after a coffee break costs more than the one before it.

That's why you'll find no prompt counts or token limits here. Anthropic's own pricing page says there's "no fixed message count". Pages that quote "10 to 40 prompts on Pro" are repeating numbers Anthropic never published, from support pages that no longer exist.

Anthropic's own answer on its pricing page.

What are the Claude Code usage limits on each plan?

Max 5x and Max 20x give you five and twenty times Pro's usage per 5-hour session. Anthropic doesn't publish the weekly multiples.

Sources: Claude pricing, the Max plan, Fable on your plan. Enterprise is $20 a seat plus usage at API rates, and its usage-based version has no set limits.

Two details on that table catch people out.

First, Fable. On Max and Team Premium, Fable can use up to half of your weekly limit, so a week of Fable can leave you with half a week for everything else. On Pro and Team Standard, Fable runs only on usage credits.

Second, the API credits. Max includes $100 or $200 a month in API credits, and Team includes some per seat. Those credits don't cover Claude Code or extra usage. They're for building on the Claude Platform.

Fable's cap and the API credits, from the plan comparison on claude.com/pricing.

If you're deciding between the Max tiers, the session multiples make the maths simple.

Our arithmetic: each plan's price divided by its session multiple. Max 5x costs the same per unit as Pro, and Max 20x halves it. Weekly multiples aren't published, so this compares session limits only.

How do you check your Claude Code usage?

/usage shows how much of each limit you've used and what used it.

Run it inside Claude Code:

/usage

It shows a bar for your session limit, one for the weekly limit across all models, and a separate weekly bar for Fable, each with its reset time. Below that come the current session's numbers: the model split, the cache hit rate, and the tokens by type. Then a "What's contributing" list shows which skills, subagents and MCP servers used the most, with a tip on what to change. Press f to apply the fixes it suggests. /cost and /stats open the same view.

My /usage panel partway through a long session. Subagents were behind almost a quarter of it, and the panel says so.

Three more commands help:

• /status shows which sign-in is active, your plan or an API key. Check it whenever a bill surprises you.
• /context shows what's filling the context window right now.
• On claude.ai, Settings > Usage shows the same bars outside the terminal.

Settings > Usage on my Max 20x plan. The weekly limit resets at a fixed time, Thursday at 6:30 AM for my account, and Fable's cap shows as its own bar.

If you want a Claude Code usage monitor that stays on screen, you have two options. In the Claude desktop app, hover over the ring next to the model picker and it shows your session and weekly limits with their reset times.

In the terminal, put them in your status line. On Pro and Max, Claude Code passes rate_limits.five_hour and rate_limits.seven_day to your status line script, each with used_percentage and resets_at:

#!/bin/bash
# ~/.claude/statusline.sh: prints "5h 42% · week 67%"
jq -r 'if .rate_limits then "5h \(.rate_limits.five_hour.used_percentage | floor)% · week \(.rate_limits.seven_day.used_percentage | floor)%" else empty end'

Make it executable, then point Claude Code at it in ~/.claude/settings.json:

{
  "statusLine": { "type": "command", "command": "~/.claude/statusline.sh" }
}

When you're signed in with an API key, the rate_limits fields aren't there, and the script prints nothing.

What happens when you hit the Claude Code usage limit?

Claude Code tells you which limit you hit and when it resets.

You get a warning first, then the limit itself. The messages look like this:

You've used 85% of your session limit
You've hit your session limit · resets 3:45pm
You've hit your weekly limit · resets Mon 12:00am
You've hit your Opus limit

Two features soften the stop. When the limit arrives mid-task, "Usage limit reached · wrapping up" lets the current step finish, once per week on Pro and at each 5-hour limit on Max. Anthropic's support page describes it as rolling out. And from version 2.1.234, Claude Code can wait for the reset and pick the task back up on its own ("Continuing automatically at 3:45pm · esc to cancel"), at most twice. Turn it on with /rate-limit-options.

Switching models helps less than people expect. If you hit your Opus limit, /model moves you to Sonnet and you keep going. If you hit your session or weekly limit, every model is out until the reset. The fallbackModel setting doesn't help either: it only kicks in when a model is overloaded or unavailable, never on a rate limit.

How do you keep working when you hit the limit?

You can wait, pay per token, pay for a bigger plan, or move some of the work elsewhere. Here are the five options.

• Wait for the reset, with auto-continue on, so the task resumes without you.
• Buy usage credits. They're prepaid and billed at standard API rates, with a monthly cap or auto-reload. When they kick in, the label changes to "Now using credits". /usage-credits opens billing on Pro and Max, or sends a request to your admin on Team.
• Switch to an API key. Set ANTHROPIC_API_KEY from a Console account, check /status to confirm it's active, and unset ANTHROPIC_API_KEY to go back to your plan. Once a key is set and approved, every session bills to the API until you remove it. Cloud sessions always use your subscription. Per-token rates for every Claude model are in our LLM API pricing comparison.
• Move up a plan, to Max 5x, Max 20x or Team Premium.
• Move the work that doesn't need Opus. A lot of a backlog is routine: a settings page, a bug with a clear repro, a dependency bump. Those tasks can run somewhere metered differently, so your Claude limits go to the work that needs them. The Claude Code alternatives below cover that.

Before you switch to an API key, look at what the API costs at full use. Anthropic's own costs page puts the average at about $13 per developer per active day, or $150 to $250 a month, across enterprise deployments. You can also keep Claude Code and swap the model. Z.ai, MiniMax and Moonshot run Anthropic-compatible endpoints, so two environment variables point Claude Code at an open-weight model, and Z.ai's coding plan starts at $18 a month. If your machine has the memory, the same setup works with a local model through Ollama, with no usage limits at all.

The API numbers are Anthropic's enterprise averages, not a cap. Heavy users pay more.

How do you reduce token usage in Claude Code?

Most of your limit goes to context you didn't need.

From Anthropic's costs guide, the habits that save the most:

• Run /clear between unrelated tasks, and /compact with instructions when a long task needs its history trimmed.
• Match the model to the job, and use a small model like Haiku for subagents.
• Keep CLAUDE.md under 200 lines and move long workflows into skills, which load only when needed.
• Prefer command-line tools to MCP servers where both work, since MCP tool definitions sit in your context.
• Use hooks to filter noisy command output before it reaches the model.
• Lower the effort level for routine work, and use plan mode before big changes. Effort also changes what a request costs, as our breakdown of Opus effort levels shows.
• Write specific prompts. "Fix the date bug in invoice.ts" costs less than "something's wrong with invoices".

Be careful with agent teams. Anthropic says they use about 7x the tokens of a single session.

What are the Claude Code alternatives when you keep hitting the limit?

If the limit is the problem, the fix is often a tool that meters differently: by the task, by the request, or by your own API key.

Buildful

Buildful, which we build, is a cloud coding agent that runs each task on the right open-weight model, tests UI changes in a real browser, and opens a pull request on your GitHub repo, for $10 a month, flat.

Buildful fits the limits problem because it isn't metered by the token, and it doesn't draw from your Claude plan. On Buildful's Pro plan, a task counts once, however many model calls it makes, and follow-ups on a task don't count as new tasks. Pro includes 1,000 tasks a month, about a cent a task. Buildful has a limit too, but it's a number you can see.

You hand Buildful a feature or a bug fix, close the tab, and come back to a pull request. Nothing runs on your laptop. Buildful runs your project's checks, and when a change touches the UI, it tests it in a real browser and records the test.

When a task does need Claude, Buildful's Pro and Team plans let you pick Claude Opus 5.5 yourself, paid from prepaid credit or your own Anthropic key. GPT and other models are in the same list.

Buildful suits a backlog of features and bug fixes you'd rather review as tested pull requests than steer step by step. How Buildful compares with Claude Code goes into more detail, and Buildful pricing has the plans.

Here's a real one from our own repo. Sandeep asked Buildful, in two plain sentences, to add a paginated tasks tab to Buildful's admin panel, showing who ran each task and for which team. It ran on Smart Mode and finished in 10 minutes.

The pull request it wrote explains every change, and its self-review caught a real bug before anyone looked: tasks started from Slack would have been credited to the person who installed Slack, not the person who asked. Buildful fixed that before opening the pull request.

A Buildful task on our own repo: two sentences in, a reviewed and merged pull request out.

OpenCode

OpenCode is an open-source coding agent for the terminal that works the way Claude Code does, with the model of your choice. Bring an API key from Anthropic, OpenAI or another provider, or subscribe to OpenCode Go: $10 a month (or $40 for Go Plus) for a curated set of coding models, including Kimi K3, DeepSeek V4.1 Flash, GPT-6 Luna and Claude Haiku 5.5, which you can also use from other agents. Go has limits of its own, per 5 hours and per month, which vary by model. If you like how Claude Code works and only want a different model behind it, start here.

Codex

Codex is OpenAI's coding agent, included with ChatGPT plans. ChatGPT Plus at $20 a month gets the full Codex, in the CLI, the IDE extension, the cloud and on iOS. Go at $8 covers light use. Plus has its own 5-hour limits, with weekly limits on top, and ChatGPT's pricing page says Pro, from $100 a month, has no 5-hour limit. Like Claude, you can buy credits when you run out, so if you already pay for ChatGPT, you may already have a second pool. We compared the two in Codex vs Claude Code.

Cursor

Cursor is an AI code editor with cloud agents. Since October 12 its plans are Plus at $8, Premium at $30, Super at $100 and Ultra at $200 a month, with one weekly usage pool shared with Grok. Claude and GPT cost extra, at API prices, on Premium and up, which matters if Claude is the reason you'd switch.

GitHub Copilot

GitHub Copilot Pro is $10 a month and includes 1,500 AI credits ($15 of usage) a month, which agent mode, the cloud agent and the CLI draw from. Assign it an issue and it opens a pull request. Pro+ is $39 and Max is $100, with more credits.

Antigravity CLI and Grok Build

Google replaced Gemini CLI with Antigravity CLI for unpaid and Google One users on June 18. Antigravity has a $0 tier with basic weekly rate limits, and Google AI Pro and Ultra raise them. SpaceXAI's Grok Build is a terminal agent like Claude Code. It signs in with your Grok account in the browser, or with an xAI API key billed per token. Either gives you a second pool if you already pay Google or SpaceXAI.

Side by side

Most people who hit the limit don't replace Claude Code. They keep it for the work they want to steer, and send the backlog that doesn't need Opus to Buildful or another tool metered a different way.

How did Claude Code's usage limits change in 2026?

Anthropic changed the limits several times in 2026, which is why advice written in the spring is often wrong now.

• January: The holiday promotion that doubled limits ended, and developers reported their limits draining faster. Anthropic said only the bonus had ended.
• Late March: Anthropic cut limits during peak hours, and the off-peak promotion ended.
• May 6: Anthropic doubled the 5-hour limits for Pro, Max, Team and seat-based Enterprise, and removed the peak-hour cut for Pro and Max.
• May 13 to September 13: Weekly limits were 50% higher as a promotion.
• June 15: A separate monthly credit for claude -p, the Agent SDK and third-party apps was due to start, and was paused. That usage still comes from your plan.
• September 14: Weekly limits settled at 25% above the pre-May level.
• September 22: Opus 5.5 shipped with higher 5-hour limits, and gave subscribers a one-time rate-limit reset they can save and use whenever they choose.

The September change drew two kinds of headline: a 25% increase, and a 17% cut. Both are true, depending on where you measure from.

125 is 25% above the old limit and about 17% below the promotion.

Frequently asked questions

Does Claude Code use the same limit as claude.ai?

Yes. Claude Code, claude.ai chats, the IDE extensions, cloud sessions and subagents all draw from one pool with a 5-hour session limit and a weekly limit.

When does the Claude Code weekly limit reset?

At a fixed time Anthropic assigns to your account, not seven days after your first message. /usage shows when yours resets.

Does switching from Opus to Sonnet get me past the limit?

Only past the Opus limit. If you've hit your session or weekly limit, switching models doesn't help until the reset.

Do claude -p and CI count against my subscription?

Yes. The separate credit Anthropic planned for claude -p, the Agent SDK and third-party apps was paused on June 15, so that usage still comes from your plan.

How much does Claude Code extra usage cost?

Usage credits are billed at standard API rates. Opus 5.5 is $4 per million input tokens and $20 per million output tokens, Sonnet 5.5 is $2 and $10, and Fable 5.1 is $10 and $50 (API pricing).

Is Max 20x worth it over Max 5x?

If you hit Max 5x's session limit most days, yes: Max 20x gives four times the session usage for twice the price. If you mostly hit the weekly limit, it's harder to say, because Anthropic doesn't publish the weekly multiples.

What's a good Claude Code alternative when you keep hitting the limit?

Buildful, which we build, is a cloud coding agent on open-weight models for $10 a month, flat, that returns tested pull requests. OpenCode lets you keep a Claude Code-style workflow on a model you choose. Codex makes sense if you already pay for ChatGPT, and Cursor if you'd rather work in an editor.

npm install -g @hashnode/cli

You need Node.js 20 or later and a publication on Hashnode Pro.

How to set it up

1. Run hashnode login. It prints a code and opens your browser. Type the code on the page and allow access. In CI, create a Personal Access Token in Settings, Developer and set HASHNODE_PAT instead.

2. Find your publication id:

   hashnode --host blog.example.com publication get
   

   Pass it with -p <id>, or set HASHNODE_PUBLICATION_ID once and stop typing it.

Publish a post

hashnode -p <id> post create --title "Hello" --content-file post.md --tag java --tag javascript

You get the link back:

Published https://blog.example.com/hello (slug: hello, id: 66f2a9c1d4b8e53a7c0e1d42).

The markdown comes from a file, or from stdin if you pass --content-file -. It's sent unchanged, so frontmatter isn't read. Add several tags with a comma list (--tag java,javascript) or by repeating the flag. Add a subtitle, a series, or a canonical URL with flags such as --subtitle, --series-id, and --original-article-url. Run hashnode post create --help for the full list.

Want to look at a post before it goes live? Save a draft, then publish it:

hashnode -p <id> draft create --title "Hello" --content-file post.md
hashnode draft publish <draft-id>

Covers and inline images start with an upload. The command prints a CDN URL you can paste into your markdown or pass as --cover-image:

hashnode image upload cover.png

What else it can do

Run hashnode --help for the full list.

Use it in scripts and with agents

It's a plain command, so it works anywhere you can run a shell: a script, a cron job, CI, or a coding agent like Claude Code or Cursor. With HASHNODE_PUBLICATION_ID set, this turns a folder of markdown files into drafts, using each file name as the title:

for f in posts/*.md; do
  hashnode draft create --title "\((basename "\)f" .md)" --content-file "$f"
done

Add --json to any command when a script needs to parse the output. post remove and draft delete ask you to confirm, and without a terminal they need --yes.

CLI, MCP server, or agent skill?

Use the CLI in a terminal, in scripts, and in CI. Use the MCP server if you work in a chat client like Claude or ChatGPT. Use the agent skill if your coding agent should learn the whole GraphQL API. They share the same Pro rules, and you can run all three. Setup for each is on hashnode.com/agents.

Before you publish

• post create goes live immediately. Use a draft if you want a look first.

• Removing a post can't be undone through the API. Only the author or a publication admin can do it.

• Contributors can't publish directly. Run draft submit, and an owner or admin publishes it.

FAQ

Is the Hashnode CLI free?

The CLI is free to install. Reading and writing a publication through the API needs Hashnode Pro on that publication.

Where does it keep my login?

On your machine, in a file only you can read. On a shared computer, use HASHNODE_PAT so nothing is saved, or run hashnode logout when you're done.

How is it different from the GitHub Action?

The GitHub Action publishes markdown files when you push to a repository, and it reads frontmatter. The CLI is for commands you run yourself, and it sends content as it is.

The Hashnode MCP server lets Claude, ChatGPT, Cursor, and other AI clients publish, draft, edit, search, and delete posts on your Hashnode blog. Add one URL, log in with your Hashnode account, and you're connected. No API token, nothing to install.

https://mcp.hashnode.com/mcp

How to connect

In Claude Code, run one command:

claude mcp add --transport http hashnode-mcp https://mcp.hashnode.com/mcp

Your browser opens Hashnode. Log in and approve access. That's it.

In Cursor, add the URL to your mcp.json:

{
  "mcpServers": {
    "hashnode": {
      "url": "https://mcp.hashnode.com/mcp"
    }
  }
}

In ChatGPT and other clients, paste the same URL wherever the client asks for a remote MCP server.

What your agent can do

Ask in plain language. "Publish notes.md to my blog." "Save notes.md as a draft." "Submit it for review." "Find my posts about Postgres and fix the tags." "Use cover.png as the cover image." "Credit Priya as the author." Your agent picks the right tool.

There are 32:

You stay in control

You never handle a token. Every client you connect shows up in Developer Settings, and you can disconnect any of them at any time. Access stops immediately.

MCP server or agent skill?

If you work in a coding agent and want the whole GraphQL API, use the GraphQL skill. If you work in a chat client, or you'd rather not manage a token, use the MCP server. Both follow the same Pro rules, and you can use both.

Before you publish

• Posts go live immediately. To look first, ask your agent to save a draft, then publish it when you're ready.

• Contributors can't publish directly. Ask your agent to submit your draft for review, and an owner or admin publishes it.

• Deleting a post removes it from your blog, and the API can't bring it back. Only the author or a publication admin can delete.

What you need

• A Hashnode account

• A publication on Hashnode Pro

• An MCP client that supports remote servers

FAQ

Is the Hashnode MCP server free?

Connecting is free. Your publication needs Hashnode Pro.

Do I need an API token?

No. You log in with your Hashnode account.

Which clients does it work with?

Any client that supports remote MCP servers, including Claude Code, Cursor, and ChatGPT.

How do I disconnect a client?

Open Developer Settings and remove it from your connected apps.

The launch note is in the changelog.

What an AI software factory is made of

Every product in this category runs the same five-stage loop, so it is the most useful way to organise the tooling.

1. Intake. Work arrives as a ticket, spec, or logged bug rather than as a prompt typed into an editor.

2. Isolation. A sandbox spins up, clones the repositories, and is destroyed when the run ends.

3. Implementation. A coding agent does the work inside that sandbox.

4. Verification. The run executes the repository's own checks, and for user-facing changes drives a real browser.

5. The pull request. One PR per changed repository, with the diff and the evidence attached. A human reviews and merges.

We covered the category argument and who is claiming what in a separate piece on the AI software factory. This one is about the parts.

One disambiguation before the tools. If you arrived here from a government or defence context, "software factory" there still means the 2010s DevSecOps meaning: accredited platforms and teams like Kessel Run and Platform One, with golden pipelines and continuous authority to operate. Humans still write the software in those. Same name, different architecture, and the rest of this article is about the agent-era sense.

The teams who built their own

Two things are worth knowing before you evaluate anything, because they establish that this works and what it costs.

Ramp built an internal background coding agent called Inspect. Their engineering post states that ~30% of all pull requests merged to their frontend and backend repos are written by Inspect. The architecture is worth reading directly: each session runs in a sandboxed VM on Modal "with everything an engineer would have locally: Vite, Postgres, Temporal, the works," from repository images pre-built every 30 minutes, with filesystem snapshots to freeze and restore state.

Uber built Minion, an agent platform wired into their monorepo. Their published figures via The Pragmatic Engineer put 92% of Uber devs using agents monthly and 11% of pull requests opened by agents. The detailed Minion numbers sit behind that newsletter's paywall, so treat anything more specific you see quoted elsewhere with suspicion.

Neither company bought this. There was nothing to buy. Both assigned platform teams to build agent infrastructure: sandboxing, credential handling, and review workflow. It worked, which is the useful part. The software factory model is proven. What the two cases also establish is the price of the proof: a platform team.

Keep that in mind through the next three sections, because the tiers below are mostly a question of who does that work.

Tier 1: buy a platform

The turnkey option. Every claim in this table is the vendor's own, taken from their site, and none of it is independently measured.

There is also a lighter version of this tier hiding inside subscriptions you may already pay for. GitHub Copilot's coding agent has been generally available since September 2025: assign an issue to Copilot and it works in a cloud environment and returns a draft pull request, with a Linear integration added since. Jules, Google's asynchronous coding agent, reached general availability at I/O 2026 and runs the same shape, task in, cloud VM, plan, PR out. Cursor runs background agents in its cloud as well. None of these carries the verification or credential plumbing of the dedicated platforms, but if the question is whether the ticket-to-PR loop fits your team at all, the cheapest experiment is one you already own.

What you are buying from the dedicated platforms is the plumbing between the five stages. What you are not buying is the integration into your stack: your repositories, your CI, your ticketing conventions, your compliance posture. That work stays with you, and on a large codebase it is not small.

Tier 2: assemble it from parts

This is what Ramp and Uber did, and every layer of it is now purchasable separately. If you already pay for a coding agent and a CI provider, you are further along than you think.

Intake

Linear, Jira, GitHub Issues, or a Slack channel. There is no specialist tool here, and that is the point: the queue you already run is the queue the factory reads. The engineering work is in the trigger, deciding which labels or states hand a ticket to an agent.

Isolation

The agent sandbox is the layer teams underestimate, and the one Ramp singles out in their own writeup.

A note on sourcing. Most of the head-to-head comparisons of these providers that rank on search are published by Northflank, which is one of the providers in the table. Their posts are useful and also not neutral. The specific isolation technology each uses (microVMs, gVisor, containers) is claimed more precisely in those comparisons than in the providers' own documentation, so verify against primary docs before you make a security decision on it.

Implementation

The agent that writes the code. Claude Code, Codex, and Grok cover the commercial end, and if you want to see how the first two differ in practice, our Codex vs Claude Code comparison covers how they differ in day-to-day use. On the open-source end sit Aider, Cline, OpenCode, OpenHands, and Goose, the Apache 2.0 agent Block built and has since moved to the Linux Foundation.

The useful design decision here is not which agent to pick but whether to pick one at all. Models leapfrog each other on a timescale of weeks, and a factory that hard-codes one agent inherits that model's bad quarter.

Verification

The stage that separates a factory from an agent left running overnight, and the one most assembled stacks skip.

Running the repository's existing checks is the floor: lint, types, unit tests, whatever CI already does. The gap is everything a reviewer actually worries about, which is whether a user-facing change still works. Playwright is the standard browser automation layer. Passmark is an open-source Playwright library for AI browser regression testing, with caching, auto-healing, and multi-model verification of assertions, which is the piece that makes browser QA survive a codebase that changes daily.

Green unit tests do not tell a reviewer whether the page a user sees still renders. Browser evidence does, and it is the part an assembled stack has to add deliberately.

Credentials

Infisical, Doppler, or HashiCorp Vault will hold secrets. The architectural question matters more than the tool: does the agent ever hold a credential at all, or does something outside the sandbox attach them to outbound requests?

An agent with repository write access and a model key is a service with unusual reach and unpredictable behaviour. Our AI agent security guide covers the threat model, and the short version is that scoping matters more than sandboxing.

Orchestration

Retries, long-running runs, and state that survives a process restart. Temporal is the common answer, and notably it appears inside Ramp's sandbox image as well.

What assembling actually costs

Every component above is available and most are good. The work is not in choosing them, it is in the joins: trigger logic, credential brokering, snapshot management, retry policy, and the review surface. That is a platform engineering project, it does not finish when the first run succeeds, and Ramp and Uber are the evidence for its scale rather than an argument against doing it.

Tier 3: self-host the whole stack

For teams whose code cannot go to a third party at all, whether for regulatory reasons or contractual ones.

For a self-hosted coding agent there are real open-source options: Aider, Cline, and OpenCode run against your own model keys, Goose runs entirely on your machine, and OpenHands ships an enterprise Kubernetes deployment. The isolation layer means running Firecracker, gVisor, or Kata Containers yourself rather than buying a sandbox service. Verification and orchestration are unchanged, since Playwright, Passmark, and Temporal are self-hostable already.

What you gain is that nothing leaves your network. What you pay is that you now operate a microVM fleet in addition to everything in tier 2. This is the most expensive route in engineering time and the only viable one for some buyers.

Tier 4: have one built by forward-deployed engineers

The fourth route is the one the category rarely names, and it is a different axis from the first three rather than a fourth product.

A forward-deployed engineer is an engineer who embeds with a customer to deploy and adapt a product inside the customer's own environment, rather than supporting it from the outside. Applied to this category, it means the vendor's engineers install the factory on your infrastructure, run it against your backlog, and hand it over.

In tiers 1, 2, and 3, the integration work belongs to the customer. A turnkey platform still has to be wired into your repositories and conventions. Assembling means building those joins. Self-hosting means building them and running the infrastructure underneath. At enterprise scale that integration is not the last mile, it is most of the project: which repos, which CI, which ticketing conventions, which compliance regime, where credentials are allowed to live. A platform ships the generic majority of a factory. The part that decides whether it gets used is specific to the buyer, and that is the part an embedded engineer builds.

The forward-deployed model moves both the integration and the operating burden to the vendor, inside the customer's environment, with custom builds part of the engagement rather than a roadmap item. This is what a software factory as a service properly means, and it is the difference between buying a factory and having one installed.

Three properties make the model work for enterprises in a way the other tiers cannot. The factory runs in your cloud or fully on premises, so the data objection that disqualifies tier 1 for regulated buyers does not arise. The backlog is being cleared while the factory is being built, which no tier 2 project can offer, since those spend their first quarter shipping nothing but infrastructure. And the engagement is designed to end: the vendor's engineers hand the controls to your team and stay on maintenance, so what you own at the end is a factory, not a dependency on the people who built it.

We ran this model ourselves for a while, as FactoryKit. We've since moved away from it: the product is now Buildful, a self-serve AI coding agent for anyone with a GitHub repo rather than a forward-deployed engagement, at 1,000 tasks for $10 a month. It kept the parts of the architecture that held up:

• Each task runs in a private cloud sandbox that's deleted when the task ends. No local development environment is involved.

• The agent never touches git. Buildful commits, pushes, and opens one pull request per changed repository, so a multi-repo task returns coordinated PRs instead of one tangled diff.

• The repository's own checks run on every change, and every UI change is tested in a real browser, with the recording attached to the pull request.

• Tasks can start from the web app, Slack, or a Linear issue.

It is GitHub only, so GitLab teams are out for now. If you need a factory installed and operated inside your own environment, look for a vendor whose engagement is built around that.

Which route are you actually on

Most teams evaluating tier 1 are actually choosing between tiers 1 and 4, and most teams evaluating tier 2 are underestimating it by a quarter.

What none of them can tell you

No vendor in this category publishes a first-attempt merge rate. Not Devin, not Factory, not 8090, not Buildful. There is no cross-vendor benchmark for ticket-to-merged-PR reliability, which means every claim on this page, including ours, is unmeasured against a shared standard.

So evaluate on evidence per run, not on claims. Three questions do most of the work:

1. What arrives attached to the pull request? Check results, a browser recording, a diff review, or just an assertion that it worked.

2. Where do credentials live during a run? If the answer is inside the sandbox with the agent, keep asking.

3. What does a failed run cost? Retries bill at full token price, so cost per finished task is the number to track, not cost per run.

FAQ

What is the difference between an AI software factory and a coding agent?

Where the human stands. A coding agent needs you in the session, steering, which is the whole experience of running Claude Code or Codex in your terminal. A factory wants you at exactly one point: reviewing the pull request. The agent is a component of the factory, not a substitute for it, which is why tier 2 above treats it as one layer of five.

Can I build one from tools I already pay for?

Yes, and that is what tier 2 is. If you already have a coding agent subscription, a CI provider, and a ticket tracker, you have three of the five stages. What you are missing is isolation, credential brokering, and the joins between them. Ramp and Uber both built exactly this, so it is a proven path with a known price.

What does an AI software factory cost to run?

Two meters. The platform, which depending on the tier is priced per seat, per usage, or as an engagement. And the model tokens underneath, which scale with parallelism and with retries, since a run that fails its checks and fixes itself pays for every attempt. A factory that needs three attempts per ticket costs triple its demo.

Is a DoD software factory the same thing?

No. Kessel Run, Platform One, and the other accredited Department of Defense software factories are DevSecOps platforms: golden pipelines, hardened containers, continuous authority to operate. They industrialise delivery and compliance, and humans still write the code. The two meanings share a name and an ancestor, not an architecture.

What is a forward-deployed engineer?

A forward-deployed engineer (FDE) is an engineer who embeds with a customer to deploy and adapt a product inside the customer's own environment, rather than supporting it from the outside. The model comes from Palantir and has spread through enterprise AI companies because integration, not software, is where their deployments succeed or fail. In this category, FDE-led means the factory is installed on your infrastructure, run on your real backlog, and handed to your team.

Do I need a sandbox, or is CI enough?

CI runs your checks against a diff that already exists. A factory needs somewhere for an agent to work before the diff exists: to install dependencies, run the app, break things, and try again. That is a different requirement, and running it on CI infrastructure means giving a non-deterministic process the credentials and network access your CI holds.

Why your Mac already knows Emacs

Open Apple's official shortcut reference and scroll to the text-editing section. Among the ordinary entries sit these:

• Control-A: move to the beginning of the line or paragraph
• Control-E: move to the end of a line or paragraph
• Control-B and Control-F: move one character backward or forward
• Control-P and Control-N: move up or down one line
• Control-T: swap the character behind the insertion point with the one in front
• Control-O: insert a new line after the insertion point
• Control-H and Control-D: delete the character to the left or right

Apple lists all of them and never says where they came from. They are Emacs bindings, inherited through NeXTSTEP into the text system that every native macOS app draws its text fields from. The letters are mnemonic once you know: A for the start of a line, E for end, B back, F forward, P previous, N next, T transpose.

This matters more than any individual shortcut, because those keys are not a feature of your editor. They belong to the operating system's text layer, so they work in a Slack message, a Mail compose window, the Safari address bar, a Finder rename field, and a commit message box. One rule, learned once, applies in a hundred places.

Then there is the part that trips people up, and no shortcut list ever mentions it.

Where the rule breaks

The same letters do not mean the same things everywhere. Your terminal uses readline, which shares ancestry with the macOS text system but diverged, and Electron editors sit on top of a browser with its own opinions. The overlap is large enough to feel universal and incomplete enough to bite.

Two rows in that table are where people lose work. Control-D is a harmless forward delete in a text field and an instruction to end the session at an empty shell prompt. Control-W deletes a word in your terminal and closes the window in VS Code, which is a genuinely bad surprise mid-edit.

Note also that Apple's public reference documents Control-A through Control-T but omits Control-K and Control-Y, the kill and yank pair, even though the text system supports them. The list is not the system. That gap is precisely why learning the underlying model beats memorising a page.

The everyday set

The shortcuts almost everyone already half-knows, worth stating once so the rest of this guide has a floor.

Command-G is the one developers most often miss. After a Command-F, it walks the matches without your hands returning to the mouse, and it works in browsers, editors, and Preview alike.

Option-Command-V deserves a mention of its own: copy a file with Command-C, then Option-Command-V moves it instead of copying, which is the Finder's equivalent of cut and paste.

Finder and system navigation

Shift-Command-G is the one that turns the Finder into something usable from the keyboard. It takes a path, it expands ~, and it will happily open a directory you would otherwise click through five times.

Windows, spaces, and switching

The backtick one is the highest-value entry in this table and the least known. Command-Tab moves between apps, but if you have four terminal windows or three editor windows open, it only ever brings you to the most recent. Command-Backtick walks the windows inside the app you are already in. Anyone running several things in parallel uses it constantly.

Command-H is worth more than Command-M. Minimising sends a window to the Dock where you have to fish it back out; hiding leaves it in the app switcher where Command-Tab restores it.

Screenshots, capture, and hardware keys

The Option plus hardware key pattern generalises: holding Option while pressing a media or brightness key opens the settings pane that controls it, which is faster than any menu path.

One more that belongs here because nothing else covers it: hold Option while a menu is open and hidden commands appear in place of the ordinary ones. Close becomes Close All, Save becomes Save As in some apps, and the Wi-Fi menu turns into a diagnostic readout. There is a second menu hiding under most of the first one.

Text editing that works in every text field

This is the section from the top of the article, applied. These are the keys worth putting in muscle memory first, because the return compounds across every app you type in.

That last row is the multiplier. Every movement shortcut becomes a selection shortcut with Shift, so Shift-Option-Right Arrow selects the next word and Shift-Command-Left Arrow selects back to the start of the line. Learning eight movements gives you sixteen commands.

Sleep, lock, log out, and force quit

Hold Option while choosing Log Out, Shut Down, or Restart from the Apple menu and the confirmation dialog is skipped. The Control-Command-Power entry is worth knowing and worth respecting, since it restarts without offering to save anything.

Accessibility shortcuts

Apple documents these thoroughly and every other guide on the subject ignores them. They are useful well beyond their name, and one of them is a frequent cause of shortcuts appearing to break, which the next section returns to.

Control-F7 is the sleeper. It changes whether Tab cycles through every control in a window or only text fields, which is the difference between a dialog you can drive entirely from the keyboard and one where Tab seems to skip the buttons.

Driving the terminal

The terminal is where most developer time goes and where every background agent session ends up, and it is absent from every general Mac shortcut guide because it is not an operating system feature. It runs on readline, so the Emacs lineage from the top of this article applies directly.

Control-R is the one that changes how you work. Most people retype commands or press the up arrow repeatedly; reverse search finds a command from three days ago by typing four characters of it.

Control-Z followed by fg is the other. A long-running process can be pushed into the background, leaving the prompt free, and pulled back when you want it. It beats opening a new tab for a task you are going to return to in ninety seconds.

Reading a diff you did not write

Something has changed about which keystrokes are expensive. When you write every character yourself, the valuable shortcuts are the ones that produce text faster: multi-cursor selection, delete to end of line, move by word. When a coding agent produces the first draft, the work moves to reading, and the shortcuts that matter move with it.

These are editor-level rather than system-level, so the exact bindings depend on your setup, but the categories are what to look for:

• Next and previous change. Walking hunks in a diff view without scrolling. In VS Code this is Option-F5 and Shift-Option-F5 for changes in a file, and the Source Control view has its own navigation.
• Jump to the next problem. F8 and Shift-F8 walk errors and warnings across the project, and Option-F8 scopes the same movement to the current file. This is the fastest way to triage what a generated change broke.
• Stage and revert from the keyboard. Reviewing a hunk and accepting or rejecting it without reaching for a mouse is the difference between reviewing forty files and skimming them.
• Go to definition and back. F12 to follow a symbol, Control-Minus to return. Reading unfamiliar code is a lot of following and returning.
• Jump between review comments in whatever tool holds them.

None of that is exotic. It is just a different set from the one every shortcut listicle teaches, because the listicles were written for a job where a human typed the code. If you want the broader picture of how that job changed, our comparison of Codex and Claude Code covers where the time actually goes now.

Making your own shortcuts

Any menu command in any app can be given a keyboard shortcut, and this is underused.

Go to Apple menu, then System Settings, then Keyboard, then Keyboard Shortcuts, then App Shortcuts in the sidebar, then the Add button.

The rule that catches everyone: the menu title must be typed exactly as it appears in the app. That includes punctuation. An ellipsis is three periods with no spaces. A submenu arrow is typed as ->. So a nested command is entered as:

Format->Font->Ligatures->Use Default

Get a character wrong and the shortcut silently does nothing, with no error to tell you why.

Beyond that, consider remapping rather than memorising. Once you are past forty or so shortcuts, adding more chords has diminishing returns, and the better move is changing what the keys under your fingers do. Karabiner-Elements remaps at the system level, and a common setup turns Caps Lock into a fifth modifier, sometimes called a hyper key, which gives you an entire layer that no app has claimed. That is a more durable answer than learning another twenty combinations.

When a shortcut stops working

In the order that resolves fastest:

1. An app binding is overriding the system one. App shortcuts win over system shortcuts. Check the app's own settings first.
2. Input Sources is stealing it. Control-Space and Control-Option-Space switch keyboard input sources by default, which is why they so often fail to reach an app. System Settings, Keyboard, Keyboard Shortcuts, Input Sources.
3. Two of your custom shortcuts collide. macOS does not warn you when you assign the same combination twice. The later one usually loses.
4. The menu title does not match. For custom App Shortcuts, this is the single most common cause. Re-read the exact string, including the ellipsis.
5. Control-F7 changed the focus mode, so Tab is moving between different things than you expect and buttons appear to be skipped.
6. Accessibility permissions are not granted. Any tool that intercepts keys, including Karabiner and most window managers, needs Privacy and Security, Accessibility permission, and quietly does nothing without it.
7. A remapper is intercepting first. If you run one, it sees the key before the app does. Disable it to test.

FAQ

How do I see every shortcut an app supports?

Open the app's menus and read the right-hand column, which is the only complete and current list, because it comes from the app itself. For system-wide bindings, System Settings, Keyboard, Keyboard Shortcuts shows what is assigned and lets you change it. Help menu search is a useful fallback: type a command name and macOS shows you where it lives in the menus.

Which shortcuts should I learn first?

The movement set from the text editing section, because it pays off in every app rather than one. After that, Command-Backtick, Control-R in the terminal, and Shift-Command-G in the Finder. Those four change how a day feels more than any other four on this page.

Do Mac shortcuts work on an external Windows keyboard?

Yes, with the modifiers remapped. macOS maps the Windows key to Command and Alt to Option, which puts them in the opposite physical order from an Apple keyboard. System Settings, Keyboard, Keyboard Shortcuts, Modifier Keys lets you swap them per keyboard, so you can fix it for the external board without affecting the built-in one.

Can I sync custom shortcuts to another Mac?

Not through iCloud. App Shortcuts live in each app's preferences domain on the local machine, so moving them means copying preferences or, more practically, keeping your remapping in a tool with an exportable config. This is a further argument for Karabiner over dozens of hand-made App Shortcuts: one file, version controlled, moves with you.

Why does a shortcut work in one app but not another?

Because most shortcuts are not global. Menu-bound commands only exist while the app that defines them is in front, and the Emacs-derived text bindings only apply inside a native text field. An Electron app draws its own text fields and often rebinds those keys, which is why Control-W deletes a word in Terminal and closes the window in VS Code.

What the revision deletes

The release is best read backwards, through what is missing.

Protocol-level sessions are gone. The Mcp-Session-Id header is removed from Streamable HTTP, the HTTP DELETE that terminated a session is gone, and tools/list, resources/list, and prompts/list no longer vary per connection. A server that needs state across calls is told to mint an explicit handle and pass it back as an ordinary tool argument (SEP-2567).

The handshake is gone with it. There is no initialize, no notifications/initialized. Every request carries its own protocol version, client identity, and capabilities in _meta, under keys like io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. In its place servers MUST implement a new server/discover RPC that advertises supported versions and identity, which clients may call up front or skip entirely (SEP-2575).

The standalone GET stream is gone. Server-to-client change notifications now arrive on the response stream of a single long-lived subscriptions/listen POST, and clients opt in to specific notification types rather than receiving everything. Stream resumability went too: Last-Event-ID and SSE event IDs are removed, and a broken stream loses the in-flight request, which the client must reissue with a new request ID.

Server-initiated requests are gone. Sampling, elicitation, and roots used to arrive as JSON-RPC requests the server pushed at the client. They are now folded into results: a server returns an InputRequiredResult carrying inputRequests, and the client retries the original call with matching inputResponses. The spec calls the pattern Multi Round-Trip Requests (SEP-2322).

Also removed outright: ping, logging/setLevel, and notifications/roots/list_changed.

Why a protocol would delete its own session layer

The spec is unusually direct about the reasoning, and it is not about elegance.

Streamable HTTP now mirrors selected body fields into HTTP headers, and the transport page gives the reason plainly: so that intermediaries such as load balancers, gateways, and observability tooling can route and inspect requests without parsing the body. MCP-Protocol-Version and Mcp-Method are required on every POST, and Mcp-Name carries the tool name or resource URI on tools/call, resources/read, and prompts/get.

Read that alongside the session removal and the direction is obvious. Sessions meant a server instance held state, which meant sticky routing, which meant you could not put ordinary infrastructure in front of an MCP server. Take sessions out and put the routing information in headers, and an MCP endpoint becomes a plain POST endpoint that any proxy already knows how to handle. The new ttlMs and cacheScope fields required on list results point the same way, since they exist so intermediaries can cache tool lists instead of every client polling for them.

There is a security consequence the spec anticipates. Once a load balancer routes on a header while the server executes on the body, the two can disagree, which is a familiar way to smuggle a request past a policy layer. So servers MUST validate that headers match the body and reject mismatches with 400 Bad Request and JSON-RPC error -32020. That check is the price of the header mirroring, and it is the kind of boundary that tends to get skipped in a first implementation. Anyone thinking about what an autonomous agent can reach should treat it as load-bearing rather than ceremonial.

Roots, Sampling, and Logging are on the way out

The deprecations say more about what the last two years taught than the additions do. All three land in the same SEP-2577, remain functional through a twelve-month window, and come with suggested migrations:

• Instead of Roots, pass directories or files as tool parameters, resource URIs, or server configuration.
• Instead of Sampling, integrate directly with the LLM provider's API.
• Instead of Logging, write to stderr on stdio, or use OpenTelemetry.

Every one of those resolves to doing the ordinary thing directly. Sampling was the most conceptually interesting idea in early MCP, a server borrowing the client's model rather than holding its own key, and the recommended replacement is now to just call the provider yourself. A protocol that tells you to route around its own abstraction has learned something about how the abstraction was used.

The Tasks work moved rather than died. It leaves the core protocol for an official extension, io.modelcontextprotocol/tasks, with polling via tasks/get replacing the blocking tasks/result (SEP-2663).

The upgrade is a hard fork in both directions

This is the part that determines your week. The spec splits implementations into modern (per-request metadata, revision 2026-07-28 and later), legacy (the initialize handshake, 2025-11-25 and earlier), and dual-era. The compatibility matrix is blunt about what works:

Both mixed pairs fail, and they fail differently. A legacy client hitting a modern server has no fall-forward mechanism at all: its initialize is an unknown method, its request is missing required headers, and on HTTP it gets a 400 it cannot interpret. That is why the spec asks modern-only servers to name their supported versions in whatever error they return to an initialize request, since that message may be the only diagnostic a user ever sees.

A modern client hitting a legacy server can fail worse. The server may reject the request, stay silent, or process an era-ambiguous method under legacy semantics, which is the failure mode that looks like it worked.

Since SDKs adopt revisions at their own pace, a mixed fleet is not an edge case. It is the normal condition for the next year, and dual-era support is what carries you through it.

What a server author changes

Concretely, for a Streamable HTTP server:

1. Implement server/discover. It is required, and it is what lets clients probe your era deterministically.
2. Read version, identity, and capabilities from _meta on every request instead of holding them from a handshake.
3. Stop minting session IDs. Ignore Mcp-Session-Id if an old client sends one, and return 405 Method Not Allowed to GET and DELETE on the MCP endpoint.
4. Validate the three required headers against the body, and return 400 with -32020 on mismatch, decoding the Base64 sentinel form of Mcp-Name before comparing.
5. Move any cross-call state into explicit handles you return and accept as tool arguments.
6. Replace server-initiated requests with InputRequiredResult, and expect the client to retry the original call rather than answering in-band.
7. Add ttlMs and cacheScope to list and read results.
8. Decide on dual-era now. A request carrying modern _meta gets served statelessly, an initialize selects legacy semantics, and one endpoint may serve both.

Clients have the mirror-image job, plus one piece of bookkeeping: era is a property of the server, not the request, so cache the result per server process on stdio or per origin on HTTP, and re-probe only when the cached assumption fails.

When this actually lands

The release candidate was cut on 29 May 2026 and carries the target revision date 2026-07-28. As of 28 July 2026 the MCP versioning page still names 2025-11-25 as the current protocol version, and the most recent tag in the specification repository is 2026-07-28-RC. The RC notes state that changes may still be introduced before the final release and that SDKs will adopt at their own pace.

The SDKs did not wait. On 28 July 2026 the TypeScript SDK published version 2.0.0 as its stable line, implementing this revision, under new package names: @modelcontextprotocol/server and @modelcontextprotocol/client replace the single @modelcontextprotocol/sdk, which stays on 1.x with bug fixes and security updates for at least six months. The Python SDK is a step behind, at 2.0.0rc1 published 27 July 2026, with 1.28.1 still the default install.

That gap is the compatibility matrix arriving early. A TypeScript server on v2 and a Python client on the current stable release are, today, the modern and legacy rows of that table, and they are the pair that fails. Building dual-era support against the RC is safe, since the fallback paths are what you need either way. Dropping legacy support is not.

FAQ

Does this break existing MCP servers already in production?

Not while they keep speaking 2025-11-25 to clients that also speak it. Breakage arrives with the client, not the calendar: the first time an updated client sends per-request _meta to a server that expects initialize, that pair fails. Since clients and servers update independently, the safe assumption is that your server will meet a modern client before you have planned for one.

Is a stateless MCP server actually stateless?

The protocol is; your server does not have to be. What changed is that state stops being implicit in a connection and becomes explicit in an argument. You return a handle, the client passes it back, and you look it up. The practical difference is that any instance can serve any request, which is what makes an MCP endpoint deployable behind a normal load balancer or on serverless infrastructure.

Should I migrate off Sampling now?

There is a twelve-month deprecation window and no removal date, so nothing forces your hand this quarter. But the suggested migration is to call the LLM provider directly, which most servers that wanted a model were already positioned to do, and new implementations are told not to adopt it. Treat it as closed for new work and schedule the replacement for existing work.

The moment

A fifty-year-old term is having its third moment, and this time everyone showed up at once.

Cursor is on stage teaching it: Eric Zakariasson's talk "Building your own software factory" frames the shift as developers moving from writing lines to defining intent, constraints, and verification, then managing the production system that does the rest. Morning Brew's co-founder is explaining it to people who have never opened a terminal: Alex Lieberman's What the hell is a Software Factory? (1 June 2026) tells a business audience that "the humans move up a level, from doing the work to directing it." A defence contractor is riffing on lights-out manufacturing: BrainGu's Enter the Dark Software Factory (6 May 2026) describes "a pipeline where AI handles the path from requirement to pull request" and then spends most of its length on why you should not run one without governance.

The vendors have gone further than writing about the category. There are now funded companies carrying the term in their names and taglines, and more of them arrive each quarter. When companies start branding themselves after a category noun, the noun has become the market.

Here is what has not shown up yet: evidence. There is no public benchmark for ticket-to-merged-PR reliability, no cross-vendor comparison, no standard way to check any factory's claims against another's. The naming is outrunning the measuring, which is the definition of a hype cycle. That does not make the category fake. It makes it unpriced.

Why this term, and why now

"Software factory" has been reborn twice before, and each rebirth industrialised a layer the previous one could not touch.

The first era standardised the humans. Hitachi organised programmers on factory lines from 1969, and Michael Cusumano's Japan's Software Factories (1991) documented how far Hitachi, Toshiba, and NEC pushed standardised process and reuse. Microsoft revived the phrase in 2004 for model-driven product lines. The unit of automation was the method; people still wrote everything.

The second era automated the path to production. A 2010s software factory is a DevOps platform: golden pipelines, CI/CD, security scanning. The US Department of Defense still runs accredited software factories with names like Kessel Run and Platform One, which is why so much search traffic for the term carries government intent. Delivery became repeatable. Implementation stayed manual, billed by the engineer-hour.

The third era automates the implementation itself, and that is the one being hyped now. Agents write the code. Nothing in the first two eras attempted that, which is why a term from 1969 is suddenly on conference stages.

What an AI software factory actually is

Strip the branding and every shipping product in the category runs the same five-stage loop. Each stage below is documented by the vendors themselves, not projected. For the tooling available at each stage, and the four ways to get a factory of your own, see our guide to AI software factory tools.

• Intake. Work arrives as a ticket, spec, or logged bug from Linear, Jira, Slack, or a support queue, rather than as a prompt typed into an editor.

• Isolation. A sandbox spins up, clones the repositories, and is destroyed when the run ends.

• Implementation. A coding agent does the work inside that sandbox. Some factories run proprietary agents; some route to the agent you choose per task.

• Verification. The run executes the repository's own checks, retries on failure, reviews its own diff, and for UI work drives a real browser and records the session. This stage is the whole difference between a factory and an agent left alone overnight.

• The pull request. One PR per changed repository, with the diff, check results, and recording attached. A human reviews and merges.

The boundary against the tools you already use comes down to when a person is required. A coding assistant needs you typing. A coding agent needs you in the session, steering, which is the entire subject of our Codex and Claude Code comparison. A factory wants a person at exactly one point: review. That pattern now has a name, the background coding agent, and the useful definition rests on where the loop runs and who closes it, rather than on which model sits underneath.

Who actually ships one

Four products define the category as of 27 July 2026. Every claim below comes from the vendor's own site as of that date, and all of it is vendor-reported. No independent measurement of any row exists. (Updated October 2026: FactoryKit, our entry, is now Buildful, and its row describes it as it ships today.)

Disclosure: Buildful, formerly FactoryKit, is ours. It was born at Bug0, whose open-source engine Passmark has grown into one of the fastest-growing Playwright AI libraries, used by more than 200 teams, and the founders built it as the next step of that work: the same verification-first approach, pointed at unattended coding agents.

What the hype skips

Four gaps sit under the category's noise. They are also the four problems Buildful was built around, which is not a coincidence: the founders shipped verification tooling at Bug0 and Passmark before pointing it at coding agents.

Nobody can prove reliability, so every run has to prove itself. No vendor in this category publishes a first-attempt merge rate, ours included. Buildful's answer is to make each run carry its own evidence rather than asking for trust: it runs the repository's own checks and fixes what fails, reviews its own diff, and for UI work drives a real browser and records the session. You are not asked to believe a benchmark that does not exist. You watch the recording attached to the PR.

Parallelism is the pitch and the bill. Ten sandboxes clearing tickets overnight is the demo. Ten sandboxes retrying failed checks at full token price is the invoice, because the models underneath charge for every attempt, successful or not. This is the discipline the team carried in from Passmark, an engine built on the premise that you cache what has already been verified instead of paying a model to rediscover it. Verification placed inside the run is a cost position as much as a quality one, because failure caught at the check stage is cheaper than failure caught by a human three days later.

Review is the bottleneck, and the fix is arriving pre-argued. Lieberman's line about humans moving up a level has a sharp edge he does not dwell on: a factory produces pull requests faster than senior engineers can responsibly read them. Buildful tests every UI change in a real browser and attaches the session recording to the pull request, so the reviewer starts from evidence instead of from scratch. BrainGu's dark-factory piece makes the same point from the defence side: the lights can go out on implementation, never on ownership.

The security surface moved. An unattended agent with repository access raises one question above the rest: what can it leak? Sandbox isolation is table stakes. Buildful's position is that the agent shouldn't hold the keys that matter most: its own GitHub tokens and model keys stay outside the sandbox, and a firewall injects them into outbound traffic, scoped per repository. Your repository's own environment variables do go in, so the app can run, and the sandbox is deleted when the task ends. A misbehaving agent can't hand over access to your GitHub or the model accounts. Whatever factory you evaluate, ask this question first; it separates products faster than any demo.

What to check before you buy one

Three questions, in order of how quickly they end sales calls.

1. What is your first-attempt merge rate on repositories like mine? Not a demo repo. If the answer is a benchmark that does not exist, you have learned the category's real maturity.

2. What does a failed run cost me? Retries bill full price. Get the retry policy and the per-run economics in writing.

3. Where do my secrets live during a run? If the answer involves credentials sitting inside the sandbox with the agent, keep asking.

FAQ

Is the AI software factory just hype?

The category is real and the market around it is ahead of its evidence. Products exist, enterprises are deploying them, and the architecture is consistent across vendors, which is usually the sign of something durable. What does not exist is any independent measurement of whether they deliver. Both things are true at once, which is what the middle of a hype cycle looks like from inside.

Should my team build a software factory or buy one?

Building means the Zakariasson path: making your codebase legible to agents, defining guardrails and verification, and wiring your own pipeline from coding agents you already pay for. It suits teams with strong platform engineering and unusual constraints. Buying gets you the sandbox, credential, and verification plumbing on day one, and makes sense the moment the build would take a quarter. Either way the review bottleneck is yours to solve; no vendor sells you out of it.

What does an AI software factory cost to run?

Two meters. The platform, where usage-based pricing without per-seat licensing is the emerging pattern. And the tokens underneath, which scale with parallelism and retries, so cost per finished task is the number to track rather than cost per run. A factory that needs three attempts per ticket costs triple its demo, and the rate cards driving that math change often enough that we maintain them on a live page.

What did Kimi K3 score, and what does it cost?

The Frontend Code Arena ranks models head to head on real frontend work. K3 came first. Tom's Hardware reported specific point totals behind that result, though the arena's own figures are not public, so the ranking is the part to lean on rather than the margin.

Push a million tokens in each direction and K3 bills $18 where Fable 5 bills $60. That ratio holds on the input column and the output column independently, which is unusual; most cheaper models save you money on one and claw it back on the other.

The price works because most of K3 sits idle. It is a sparse mixture-of-experts model, so a request wakes a fraction of the network rather than all 2.8 trillion parameters. The context window is a million tokens, putting it alongside Opus 5 for whole-repository work, and Moonshot says the arena result came from a single-agent setup using that full window with no context compression.

The licence landed, and it is not open source

VentureBeat and Tom's Hardware both described K3 as the largest open-source model ever released. The weights arrived on 27 July 2026 at 16:29 UTC in the official moonshotai organisation, and the licence file that came with them settles the question. It is a custom "Kimi K3 License", and the answer is no.

Two commercial gates sit in it. A company that operates a Model-as-a-Service business and whose revenue passes $20 million across any twelve consecutive months must sign a separate agreement with Moonshot before any commercial use of the weights. And any product past 100 million monthly active users or $20 million in monthly revenue must display "Kimi K3" in its interface, the clause carried over from K2's Modified MIT licence. Internal use, where the model and its outputs never reach a third party, is exempt from both.

The first gate is new, and it is the one that matters. A revenue-conditioned restriction on commercial use is exactly what the Open Source Definition does not allow, so K3's terms came out tighter than K2's, not looser. Open weight, certainly: 1.4 TB, free to download and run. Open source, no.

Self-hosting needs about 1.4 TB of GPU memory

The weights run about 1.4 TB under MXFP4, down from roughly 5.6 TB at FP16, the fourfold saving you would expect dropping from 16-bit to 4-bit. That is the floor for loading the file. KV cache and activations come out of whatever is left.

In practical terms it takes eighteen 80 GB accelerators just to hold the weights. A single node of eight 192 GB cards, about 1.5 TB, fits them with almost nothing spare, which leaves no room to actually serve traffic. Community write-ups putting a comfortable configuration nearer 5 TB are describing headroom rather than a minimum, and Moonshot has not published a reference deployment.

So the API at $3 and $15 undercuts the hardware for anyone not already operating a cluster. Open weights buy you auditability, fine-tuning, and somewhere to put data that cannot leave your network. Saving money is not on that list. If you want open weights that fit on a single machine instead, our guide to the best local LLMs for coding covers the models that do.

What this does to the price floor

Frontier pricing has rested on a straightforward bargain. The best coding model costs the most, and the gap is what you pay for the top of the leaderboard. K3 charges 30% and took first place, from a lab working under export controls on the hardware it trained with.

DeepSeek V4-Flash sits at $0.14 and $0.28 per million, with V4-Pro at $0.435 and $0.87. The floor under everyone's inference bill is being set by open-weight releases now, rather than by the labs that publish rate cards.

None of which retires Fable 5 or Opus 5. A leaderboard position says nothing about how a model behaves on hour three of an agent loop, and that is where the money actually goes. What has changed is that the premium has to be argued for.

Which lands where the pricing hub keeps landing: cost per finished task, not cost per million tokens. A model that needs four attempts at $18 has already cost you more than one that got there first at $60.

FAQ

How big is Kimi K3 really?

2.8 trillion parameters stored, with only a fraction active on any given token, which is what a sparse mixture-of-experts design buys you. The total is why the download runs to 1.4 TB. The active slice is why the API costs $3.

Should I switch from Claude to Kimi K3?

Not on the strength of one leaderboard. The arena result is real and it covers frontend coding; moving a production agent is a decision about failure modes across long sessions, which no ranking measures. Run your own evals on your own tasks. A price gap this wide justifies the afternoon.

Audience figures below are self-reported by each publisher and vary between sources, sometimes by a lot. Treat them as scale, not as precision, and ask for current numbers before you commit budget.

Why developer marketing matters more in the AI era

Three things changed at once, and they all point the same way.

The developer became the buyer. AI tooling is adopted from the bottom up. An engineer tries a coding agent on a personal card, the team copies them, and procurement arrives months later to formalise something already running in production. The decision that used to sit with a CIO now sits with whoever opened the terminal. That turns developer-facing media from a brand exercise into the actual sales channel.

Search stopped being a reliable way to get found. Nearly every technical query now returns an AI Overview, and a growing share of developers ask an assistant rather than a search engine. Both answer the question without sending anyone a click. The old motion, where you published a good technical post and a developer eventually found it, is thinning out. Newsletters and podcasts are delivered rather than searched, which makes them much harder for an answer engine to sit in front of.

Trust got scarcer as content got cheaper. Generated technical writing flooded the same channels developers used to rely on. When everything reads as plausible and almost none of it is verified, a named curator who has spent years deciding what goes in their issue is worth more, not less. That scarcity is the thing you are actually buying.

There is also simply more competition for the same attention. Nearly every AI startup now ships something developer-facing: agents, model APIs, eval tooling, orchestration, testing. The number of companies chasing developers has multiplied. The number of publications those developers genuinely read has not.

What makes developers different to buy

Developers are the hardest technical audience to buy. They block ads, they distrust marketing language by default, and they will read your documentation before they read your landing page. The lists are also small: a newsletter with 20,000 engaged backend engineers is a serious buy in this category, where a general B2B list of that size would be a rounding error.

That combination is why newsletter advertising works here when display advertising does not, and why general SaaS advertising playbooks transfer badly. Newsletter ads arrive inside something the reader chose to open, from a curator they already trust, next to content they came for. It is closer to a recommendation than an advertisement, which is exactly why the publications that protect that trust are the ones worth buying.

Which developer newsletters accept sponsorship?

Grouped by who they reach, because you should buy on audience fit rather than raw subscriber count. Not ranked. It runs from the largest tech newsletters down to sharply focused engineering newsletters with a few thousand readers, and in this category the small ones often win.

The foreword publication by Hashnode

Audience: developers and engineering leaders working on AI coding, agents, and developer tooling. Coding agents and CLIs, MCP and agent infrastructure, model APIs and what they cost, testing and evals.

Sponsorship: yes. Reach us at theforeword@hashnode.com.

Disclosure: The foreword publication by Hashnode is this publication. It is listed here because a directory that omits its own inventory is less useful, not more, and it is held to the same disclosure standard as anything else we cover.

AI and AI engineering

General developer

Engineering leadership and architecture

Language and framework

Infrastructure, cloud, and reliability

Elsewhere worth knowing

The two networks nobody treats as networks

This is the part every other list misses, and it is the most useful thing on this page if you are buying at any scale.

Cooper Press publishes JavaScript Weekly, Frontend Focus, Node Weekly, React Status, Ruby Weekly, Golang Weekly, Postgres Weekly, JAMstacked, and Deno Weekly. That is roughly 450,000 developers across nine newsletters, from one publisher, in one conversation. Every roundup names these individually. None of them points out that you can plan them as a portfolio and segment by language without negotiating nine times.

Libhunt runs the "Awesome" family: Awesome Java, Awesome Python, Awesome Go, Awesome Rust, Awesome C++, Awesome Kotlin, Awesome Elixir, Awesome PHP, Awesome Node.js, Awesome Swift, Awesome iOS, Awesome .NET, Awesome React, Awesome Scala, and more. Each sits around 21,700 subscribers, all sell sponsorship, and there are more than fifteen of them. Call it 325,000 developers, pre-segmented by language, from a single operator. It appears on no developer newsletter roundup we could find.

Between them that is roughly 775,000 developers reachable through two relationships.

Where the answer is no

The most useful thing a list like this can tell you is where not to spend your time.

The Pragmatic Engineer does not run newsletter sponsorships. With more than a million readers it describes itself as the number one software and AI engineering newsletter on Substack, and its own about page is unambiguous: "The newsletter does not run advertisements or sponsorships", alongside "I don't take sponsorships of any kind, and disclose any affiliation I would have with the companies covered."

There is a door, and it is not the newsletter. The Pragmatic Engineer Podcast does carry limited podcast sponsorship, and it reaches an overlapping audience. If those readers are your target, the podcast is the buy and no amount of emailing about the newsletter will change that.

Latent Space does not sell traditional sponsorships. It is the definitive publication for AI engineering, with an audience of exactly the people most AI startups want, and its own page states it works with PR teams ahead of major product and funding announcements on roughly a month of lead time, while explicitly not accepting cold emails. If you want that audience, the route is an announcement worth covering, planned early. It is not a media buy.

More broadly, treat any publication whose value comes from editorial independence the same way. The reason its recommendation is worth something is that it cannot be bought, and the pitch that works is the one that gives the writer something genuinely worth telling their readers.

How to read a newsletter media kit

Every figure on this page is self-reported, and the spread between sources is wider than you would expect. One widely cited list puts TLDR at 275,000 while another puts it above a million. Both are recent. Neither is lying, they are counting different things: total signups, active subscribers, across all editions or one.

Three questions worth asking before any buy:

Active subscribers, not signups. A list of 100,000 where 30,000 open is a better buy than a list of 300,000 where 25,000 do, and the second number is the one that rarely appears in a media kit.

Click rate, not open rate. Open rates have been unreliable since Apple's Mail Privacy Protection began pre-loading images in 2021. Clicks are the only number that survives it, and any publisher serious about advertising will have them.

Audience composition. "Developers" is not a segment. Twenty thousand backend engineers and twenty thousand bootcamp students are the same number and different products entirely.

What actually converts for developer tools

An argued position rather than a benchmark, and worth what you paid for it: any developer marketing strategy that works starts from one observation, which is that developers do not respond to brand advertising. They respond to a specific technical claim they can verify in a single click.

The sponsorships that work send people to documentation, a benchmark, a changelog, or a repository. The ones that do not send people to a homepage with a headline about transforming their workflow. A developer who clicks your sponsorship is doing so to evaluate you, and if the destination is a marketing page they have learned nothing and they leave.

Two things follow from that.

Relevance to the issue beats reach. A tool that fits what that week's content is about will outperform a bigger list where the fit is generic. This is the argument for the smaller, sharper newsletters in the tables above, and the reason a 3,700-subscriber list can outperform one twenty times its size.

Judge on pipeline, not on clicks. Developer tool consideration cycles run long. Somebody who clicks a sponsorship in March may open an account in June after seeing you three more times. Attribution that only counts the last touch will tell you sponsorships do not work, and it will be wrong.

FAQ

Which developer newsletters accept sponsorship?

Most of the large ones do, including TLDR, TLDR AI, ByteByteGo, The Real Python Newsletter, Baeldung, Bytes, Console.dev, Last Week in AWS, and the full Cooper Press and Libhunt networks. The significant exceptions among major publications are The Pragmatic Engineer, whose newsletter does not run advertisements or sponsorships at all, and Latent Space, which does not run traditional advertising. The Pragmatic Engineer Podcast is a separate matter and does carry limited sponsorship.

How do I reach developers if a publication does not sell ads?

Give it something worth covering. Publications that do not sell advertising still cover launches, benchmarks, and technical work that their readers care about. Latent Space, for example, states it works with PR teams roughly a month ahead of major announcements. That is a longer lead time than a media buy and it is not guaranteed, but the resulting coverage carries more weight than a placement.

What is a good audience size for a developer newsletter sponsorship?

Fit matters more than size in this category. A newsletter with 5,000 readers who all work in your exact problem space will usually outperform 200,000 general developers. Start from who you need to reach and work backwards, rather than sorting the list by subscriber count.

Is it better to sponsor one big newsletter or several small ones?

Several small ones, if they are well matched, and the two networks above make that practical to administer. Frequency matters in a category with long consideration cycles, and appearing in three publications a developer reads is worth more than appearing once in a larger one they skim.

What is the best way to advertise to developers?

There is no single best way to advertise to developers, but the channels that work share one property: the developer opted into them. Newsletters, podcasts, and curated sites are read by choice, which is why they outperform display. The best way to advertise to developers is to appear in something they already read, with a claim they can verify in one click.

How do you market to engineers?

Marketing to engineers works when it stops looking like marketing. The short answer to how to market to engineers, and how to market to developers generally, is that you lead with the technical claim, the benchmark, or the documentation rather than the value proposition. Engineers evaluate before they buy, so digital marketing for engineers has to survive that evaluation. Anything that reads as a pitch gets discounted immediately, and anything that reads as useful information gets forwarded.

What are the main developer marketing channels?

Newsletter sponsorship, podcast sponsorship, sponsored content on developer sites, conference and community sponsorship, open-source sponsorship, and search. Framed the other way, how to reach developers comes down to whichever of those they already opted into. The tables above cover the first three, which are the ones most devtool and AI startups start with because they are measurable and do not require a headcount to run.

What is a newsletter CPM?

CPM is the cost per thousand impressions, the way most newsletter ad rates are quoted. Developer newsletters run higher than general B2B because the audiences are smaller and harder to reach, and newsletter sponsorship rates vary enough between publications that any figure quoted here would mislead you. Ask each publisher for current rates, and ask for click numbers alongside them, because CPM without a click rate tells you what you paid rather than what you got.

How do I sponsor The foreword publication by Hashnode?

Email theforeword@hashnode.com with what you are launching, who you want to reach, and your timeline. Sponsorship is separate from editorial: placements are labelled, and buying one does not buy coverage, a review, or a place in a comparison.

Figures gathered on 26 July 2026 from publishers' own sponsorship pages and public directories. This page is updated as publications change their terms, so if something here is out of date, tell us at theforeword@hashnode.com and we will correct it.

Codex vs Claude Code at a glance

What changed in July 2026?

Three releases inside four days, and together they explain why this comparison is worth redoing.

Codex CLI 0.145.0, 21 July. The changelog is unusually direct about the headline: /import now migrates "Cursor and Claude Code settings, MCP servers, plugins, sessions, commands, and project-scoped memories." It also added experimental Amazon Bedrock login with custom endpoint support and GPT-5.6 Sol as the default Bedrock model, stabilised an opt-in multi-agent V2 with configurable sub-agent models, reasoning levels and concurrency, and added experimental paginated thread history.

ChatGPT desktop 26.715, 23 July. ChatGPT Voice, powered by GPT-Live, lets you talk through work across Chat, Work, and Codex in one desktop app. Local projects gained multi-folder support, where a designated primary folder drives new chats, Git operations, and AGENTS.md, skills, and config.toml discovery.

Claude Code 2.1.219, 24 July. Opus 5 arrived as the default Opus model with a one-million-token context and Fast mode at \(10 and \)50 per million tokens. Subagents gained nested spawning to depth 3, up from 1. A sandbox.network.strictAllowlist setting now denies non-allowlisted hosts for sandboxed commands without prompting.

One correction while we are on dates, because a lot of coverage got it wrong: GPT-5.6 launched on 9 July, more than two weeks before any of this. The 24 July news was Codex and ChatGPT converging, not a new frontier model.

The buried lede is /import, and it runs one way

Everything else in that list is incremental. /import is not, because it changes the shape of the decision. Migrating settings, MCP servers, plugins, sessions, commands, and project-scoped memories in one command means the cost of having chosen the other tool is now close to zero.

It is also one-directional. Codex imports a Claude Code setup; Claude Code has no equivalent import. So the question stopped being "which one do I commit to" and became "which one do I default to," which is a far lower-stakes question, and OpenAI has made itself the easier destination.

How we are comparing them, and what we did not do

This is a comparison of documented capabilities and an argued recommendation. It is not a benchmark. We have not run the same task through both agents under controlled conditions, and we are not going to imply otherwise.

That matters because a casual side-by-side is close to worthless here. A real head-to-head would need to hold the repository state, the task, the model tier, the permission mode, and the context budget constant, and then run enough trials to separate signal from the variance you get on any single agentic run. Most published comparisons control for none of that.

What you can compare honestly is what each vendor ships, what it calls stable, and what it charges. That is the ground this piece stands on.

Which one is more settled?

Claude Code, and the evidence is in how each vendor labels its own work.

Codex's flagship July additions carry OpenAI's own hedges. Bedrock login is "experimental." Paginated thread history is "experimental." Multi-agent V2 is "opt-in," described as stabilised rather than default. These are capable features arriving with the vendor's caution attached.

Claude Code shipped the equivalents earlier and has already moved them into the default path. Subagents have run in the background by default since 1 July. Auto mode became available on Bedrock, Vertex AI, and Foundry without an opt-in environment variable on 11 July. Nested subagents went from depth 1 to depth 3 as a default on 24 July, with a per-session spawn cap of 200 to stop runaway delegation.

Read the two changelogs side by side and the pattern is consistent: Anthropic is tuning limits on features that already run by default, while OpenAI is still promoting its equivalents out of preview. If you are choosing an agent to run unattended on real work, which is the premise of an AI software factory, that difference matters more than any feature checklist.

How does each handle a large repo?

Both now carry roughly a million tokens of context, so the interesting question is not window size but what happens at the edges of a monorepo.

Codex's multi-folder projects are the more explicit answer. You designate a primary folder, and that folder drives new chats, Git operations, and where Codex looks for AGENTS.md, skills, and config.toml. Secondary folders stay searchable and editable. If your work spans several repositories that need to be treated as one project, that maps cleanly onto how you already think.

Claude Code approaches it through working directories rather than project definitions. /add-dir registers additional roots mid-session, a DirectoryAdded hook fires when that happens, and the session's extra directories are exposed to MCP servers through roots/list with change notifications. It is the more programmable model and the less declarative one.

Neither removes the real constraint, which is that a million-token window you actually fill is expensive. That is where effort settings and caching decide your bill, and we worked through what those do to real numbers separately.

How do you extend them?

The two extension stories have converged to the point where the file names are almost the only difference. Both support MCP servers, plugins, reusable skills, and a repo-level instructions file, AGENTS.md for Codex and CLAUDE.md for Claude Code. /import moving MCP servers and plugins across is only possible because the models are so similar.

Where they still differ is in the operational detail around delegation. Claude Code's skills can declare context: fork and run in the background by default, MCP tool calls that exceed two minutes move to the background automatically so the session stays usable, and subagents that were spawned with an explicit model override keep that override when resumed. Codex's multi-agent V2 exposes sub-agent models, reasoning levels, and concurrency as configuration, which is the more legible surface if you want to tune a fleet by hand.

We have shipped a real skill against the Hashnode GraphQL API, and the thing that decided the platform was not the feature list. It was whichever ecosystem already had the servers we needed. For most teams that will be the tiebreaker too.

What does each cost to run?

Both are sold as subscriptions with metered API access underneath, so the honest answer is that your bill depends on the model you run and how many tokens it spends, not on the agent wrapper.

Two concrete numbers worth knowing. Claude Code's Fast mode on Opus 5 and Opus 4.8 bills at \(10 and \)50 per million tokens, exactly double standard rates. And Codex now defaults to GPT-5.6 Sol on Bedrock, which is the more expensive of the two vendors' near-frontier models on output, \(30 against Opus 5's \)25.

Everything else is a routing decision rather than a product decision. Our LLM API pricing comparison has the current verified rates for every model either agent can drive, including the long-context surcharges that make repository-scale requests cost very differently across vendors.

Do you have to choose at all?

For a lot of teams, no, and /import is what changed that. Running both and defaulting to one is now cheap enough to be a reasonable strategy rather than an indulgence.

The stronger version of that idea is to stop choosing per team and choose per task. Buildful, which we build, does a version of this: it picks an open-weight model for each task by default, and on paid plans you can run a task on Claude Code or Codex yourself, with prepaid credit or your own API key. Either way it returns a tested pull request on your GitHub repo. We compare it with Claude Code and Codex separately. If your reason for picking one agent is that you did not want to maintain two, that constraint is worth re-examining.

Which one should you use?

Four cases, four answers, each with the trade-off it accepts.

Solo developer on a large monorepo: Claude Code. Background subagents, nested delegation, and configurable filesystem isolation are defaults rather than flags, which is what you want when a long run is unattended. You accept a less declarative multi-repo story than Codex's primary-folder model.

Team standardised on ChatGPT: Codex. Voice across Chat, Work, and Codex in one desktop app is a real workflow, not a demo, and fighting your organisation's existing tooling to gain marginal agent maturity is a bad trade. You accept that several features you will rely on are still labelled experimental.

Cost-sensitive CI and background automation: Claude Code. The cheaper near-frontier output rate and a batch discount that stacks with caching decide this, and the effort parameter gives you a spend dial that does not require changing models. You accept managing the sandbox configuration yourself.

Already invested in the other one: stay, then try /import if you are on Claude Code. The migration path exists in exactly one direction, so Claude Code users can evaluate Codex over an afternoon while Codex users face a manual rebuild. Evaluate accordingly, and note the asymmetry is a fact about tooling rather than a verdict about quality.

Key takeaways

• Codex can import your Claude Code settings, MCP servers, plugins, sessions, commands, and memories in one command. Claude Code has no equivalent, so switching cost collapsed in one direction only.
• Claude Code is the more settled agent by each vendor's own labels: its subagents and auto mode are defaults, while Codex's Bedrock login, thread history, and multi-agent mode are still experimental or opt-in.
• Both carry roughly a million tokens of context, so the differentiator is multi-repo handling, not window size.
• Extension surfaces have converged on MCP, plugins, and skills. Pick on which ecosystem already has what you use.
• The agent does not set your bill. The model and the token count do.

FAQ

Is Codex better than Claude Code?

Neither is better across the board. Claude Code is the more settled of the two, since its delegation and sandboxing features are defaults rather than previews. Codex wins when your team already works in ChatGPT or wants voice-driven workflows. The question also matters less than it did, because Codex can import a Claude Code setup in one command.

Can you use Codex and Claude Code together?

Yes, and it is more practical since the 21 July 2026 /import change. Codex will pull across settings, MCP servers, plugins, sessions, commands, and project-scoped memories from a Claude Code install, so running both and defaulting to one no longer means maintaining two configurations by hand. The reverse migration has no equivalent command.

Does Codex support MCP and skills?

Yes to both. Codex works with MCP servers and plugins, and its desktop app discovers AGENTS.md, skills, and config.toml from a project's designated primary folder. Its /import command explicitly carries MCP servers and plugins across from a Claude Code or Cursor setup, which is the clearest signal of how closely the two extension models now match.

Is Codex free?

Codex access comes with paid ChatGPT plans rather than as a standalone free product, and voice features are listed for Plus, Pro, Business, Edu, and Enterprise on desktop. Beyond the subscription, what you actually spend depends on the model doing the work; our pricing comparison has the current per-token rates.

Which is cheaper for daily use?

It depends on the model rather than the agent. On near-frontier work Claude Opus 5 costs \(25 per million output tokens against GPT-5.6 Sol's \)30, and Anthropic does not surcharge long-context requests while OpenAI charges 2x input above 272,000 tokens. For repository-scale work that gap widens considerably.

Which has better sub-agents?

Claude Code's are further along. They run in the background by default, nest to depth 3, and carry a per-session spawn cap to prevent runaway delegation. Codex's multi-agent V2 is opt-in but exposes sub-agent models, reasoning levels, and concurrency as explicit configuration, which some teams will prefer for tuning.

What does each model cost per million tokens?

Rates per million tokens, verified against each vendor's own pricing page on 25 July 2026, sorted by output price.

Anthropic and OpenAI both discount batch processing by 50% on input and output. Anthropic's cache reads cost 10% of base input, with writes at 1.25x for a five-minute cache and 2x for an hour. OpenAI's cache writes run 1.25x standard input. Gemini charges $1.00 per million cached tokens per hour of storage on top of the read rate.

On context windows, the three GPT-5.6 tiers all carry a 1.05 million token window with a 128,000 token output ceiling, and every Claude model from 4.6 onward carries a one-million-token window. The difference is what you pay to fill them, which is the second bullet below.

Which models actually compete with each other?

Vendor pricing pages list models by vendor, which invites the mistake of comparing across weight classes and concluding the cheap one is better value. Line them up by output price instead and the real fights appear.

The mid tier is also where the open-weight question now lands. Kimi K3 charges $15 output, the same as GPT-5.6 Terra, while taking first place in the Frontend Code Arena ahead of models priced at $30 and $50. A model competing two tiers above its own rate card is new, and it is the reason to check this table more often than you used to.

Read that table top to bottom and the next thing that stands out is who is missing. Google does not field a model in either of the top two tiers. Its most expensive model, 3.1 Pro, tops out at $12 output, which lands it in the mid tier against Sonnet 5 and Terra rather than against Fable 5 or Sol. Anyone shopping the frontier is choosing between Anthropic and OpenAI, and Google is competing on price per unit of adequate work instead.

The near-frontier row is the interesting one, because Opus 5 and GPT-5.6 Sol charge the identical $5 for input and differ only on output, $25 against $30. On a coding-shaped request of 30,000 input and 5,000 output tokens, Opus 5 costs $0.275 and Sol costs $0.30. Ten thousand of those a month is $2,750 against $3,000, a 9% gap that no benchmark table will tell you about.

The practical rule: choose the tier from the task, then compare prices inside the tier. A comparison that crosses tiers tells you nothing except that cheaper models are cheaper.

Why the output rate decides your bill

Output costs five to eight times input everywhere on that table, so the shape of your workload matters more than the vendor you pick. An app that reads 6,000 tokens of retrieved context and writes a 300-token answer barely notices an output price cut. A coding agent that reads 3,000 and writes 2,000 lives or dies by it.

We worked the full derivation through in our Gemini API pricing breakdown, including the formula for what share of your bill is output at a given ratio. The short version: measure your own ratio before you compare vendors, because a model with cheaper output and pricier input can win or lose on workload shape alone.

What the pricing page does not tell you

These are the multipliers that turn a quoted rate into an actual invoice. Two of them are large enough to reverse a vendor decision.

The tokenizer changed, and nobody put it on the rate card. Anthropic's Claude 4.7 and later models use a newer tokenizer that produces roughly 30% more tokens for the same text than Claude Sonnet 4.6 and earlier. Opus 4.6 and Opus 5 both list at $5 and $25. Run identical text through both and the newer one bills about 30% more, because it counts more tokens, not because it charges more per token. Our coding-shaped request at $0.275 becomes $0.3575 once the same text tokenizes 30% heavier. Anthropic is explicit that the increase varies by content, so measure yours rather than assuming the headline figure.

Long context is surcharged everywhere except Anthropic. Claude 4.6 and later include the full one-million-token window at standard rates, so a 900,000-token request bills at the same per-token rate as a 9,000-token one. Both competitors step the price up, and step it up identically: 2x input and 1.5x output on the whole request, OpenAI once input passes 272,000 tokens and Google once it passes 200,000 on 3.1 Pro. Feed Sol and Opus 5 the same 300,000-token repository with a 2,000-token answer and Sol costs $3.09 against Opus 5's $1.55, almost exactly double. The 9% gap from the near-frontier comparison inverts completely at large context, and Google's threshold arrives even earlier than OpenAI's.

Reasoning tokens bill as output. Gemini states this outright for Flash and Flash-Lite, and it holds wherever a model thinks before answering. A harder prompt costs more than an easy one even when the visible answers are the same length, which makes response length a poor proxy for cost. Log output token counts per request instead. Anthropic's effort parameter makes this controllable, and we worked through what each level does to a bill separately.

Server-side tools bill outside tokens entirely. Anthropic charges $10 per 1,000 web searches on top of the tokens the results consume, and code execution runs 1,550 free hours per organisation per month before charging $0.05 per container-hour. Neither line appears anywhere on a per-million-token table, and neither shows up in a token-based cost estimate.

Tools add tokens before the model does anything. Simply having tools present on a request injects a system prompt: 286 tokens on Opus 5, or 406 when tool choice is forced, plus the schemas themselves and another 325 for the bash tool. An agent making many small requests pays that overhead on every one.

Anthropic's Fast mode is exactly double. Opus 5 and Opus 4.8 run at $10 and $50 under Fast mode, matching the Fable 5 rate card. It is in research preview, first-party API only, and cannot be combined with the Batch API, so the 50% batch discount and the speed premium are mutually exclusive choices.

Tool calls and retries multiply request counts, not rates. One agentic request is several billed model calls, since every tool result comes back through the model with the full context attached. A 3% failure rate on structured output is a 3% surcharge on everything above it. Anything you re-run, you re-pay for, which is why Passmark caches AI test steps rather than re-executing them on every run.

Data residency costs 10%. Anthropic applies a 1.1x multiplier across input, output, and cache when you pin inference to the US, and OpenAI adds a 10% uplift on regional endpoints for models released from 5 March 2026.

How do you compare vendors without getting fooled?

Compare dollars per task, not dollars per million tokens. The rate card is the one number every vendor publishes and the one number that cannot answer your question on its own, because it says nothing about how many tokens a model spends reaching the same answer.

A quoted rate becomes useful only once you attach a workload to it: your token ratio, your context size, your tool-call count, your retry rate. Run a day of your own traffic through two candidates, compare the invoices, and ignore the rate cards entirely.

That comparison is far easier when your agent layer can switch models per task rather than per deployment. Buildful, the AI coding agent we build, works this way: it picks an open-weight model for each task, which is how it sells 1,000 tasks for $10 a month, and you can pick Claude or GPT yourself for a task that calls for one. The model becomes a per-task choice instead of a vendor decision.

Key takeaways

• Output costs five to eight times input at every vendor. Your output-to-input ratio matters more than your choice of vendor.
• Opus 5 and GPT-5.6 Sol are the same weight class at the same input price. Sol's output is 20% dearer, which works out to roughly 9% on a coding-shaped request.
• Anthropic's models from 4.7 onward tokenize about 30% heavier. Same rate card, bigger bill, and it is invisible unless you measure tokens.
• Long context is surcharged by OpenAI above 272,000 input tokens and by Google above 200,000, both at 2x input and 1.5x output. Anthropic charges its normal rate, so large-context work reverses the ranking.
• Google fields nothing in the top two tiers. Its most expensive model sits in the mid tier against Sonnet 5 and Terra.
• Batch processing is a flat 50% off at Anthropic and OpenAI. Anthropic's Fast mode is a flat 100% on, and the two cannot be combined.

FAQ

What is the cheapest LLM API?

Gemini 3.5 Flash-Lite has the lowest rates on the table at $0.30 input and $2.50 output per million tokens. Cheapest per token is not the same as cheapest per task, though: a model that needs three attempts costs more than one that succeeds once at twice the rate. For mechanical work such as classification, extraction, and routing, the floor tier really is cheapest. For anything requiring reasoning, compare cost per completed task.

How much does Claude cost per million tokens?

Claude Opus 5 and Opus 4.8 cost $5 input and $25 output. Fable 5 and Mythos 5 cost $10 and $50. Sonnet 5 is $2 and $10 through 31 August 2026, then $3 and $15. Haiku 4.5 is $1 and $5. Cache reads cost 10% of base input on all of them, and the Batch API halves everything.

Is GPT-5.6 cheaper than Claude Opus 5?

No. They charge the same $5 for input, and Sol's output is $30 against Opus 5's $25. On a request reading 30,000 tokens and writing 5,000, Sol costs about 9% more. Past 272,000 input tokens the gap widens sharply, because Sol's long-context surcharge doubles input pricing while Opus 5 stays flat.

Should you use Claude Opus or Claude Sonnet?

Sonnet for most production work, Opus for the requests that measurably fail on Sonnet. The price gap is the argument: Opus 5 costs $5 and $25 against Sonnet 5's introductory $2 and $10, so Opus is two and a half times dearer per token before you account for it spending more of them on reasoning. Anthropic's own guidance points the same way, Sonnet for most workloads and Opus for the most complex reasoning. Route rather than default, and measure your escalation rate before committing either way.

Do thinking tokens cost extra?

They bill at the output rate, so yes in effect. Google states this explicitly for Gemini. The consequence is that two prompts producing similarly sized answers can cost very differently, so track output token counts per request rather than trusting response length.

Which model should I use for coding?

Start in the volume tier and escalate only the requests that measurably fail there. Most coding work is well-specified enough that a mid-tier model handles it, and reserving the near-frontier tier for genuinely hard requests beats defaulting everything to it on quality per dollar. If your repository context runs past 272,000 tokens, Anthropic's flat long-context pricing changes the arithmetic in its favour. Which agent you drive that model through is a separate decision, and we compared Codex against Claude Code on exactly that.

Does the Batch API stack with caching?

Yes. Anthropic's batch discount and prompt caching multipliers combine, so a cached read inside a batch request gets both reductions. Fast mode is the exception, since it cannot be used with the Batch API at all.

What is Claude Opus 5?

Anthropic released claude-opus-5 on 24 July 2026 at $5 per million input tokens and $25 per million output tokens, available through the Claude API, Claude.ai, Claude Code, and Claude Cowork. It became the default model on Claude Max and the strongest model available on Claude Pro. Like every Claude model from 4.6 onward it carries a one-million-token context window billed at standard rates, with no long-context surcharge.

Two cost controls ship with it. The effort parameter decides how many tokens the model spends on a response. Fast mode trades money for throughput. Neither behaves quite the way the launch coverage described.

Did Opus 5 actually get cheaper?

Not compared to what it replaced. Against the tier above it, yes.

Fortune's headline framed the release around toggling between cost and capability, and most coverage followed with some version of "cheaper frontier model." Both rows that matter are on Anthropic's own pricing page: Opus 5 and Opus 4.8 carry identical rates. Nothing got cheaper per token. What changed is that near-frontier capability now sits at half of Fable 5's rate card, which is a real shift and a different claim. Our LLM API pricing comparison puts all three vendors in one table if you want to see where that leaves Opus 5 against GPT-5.6 and Gemini.

The tell that this release is about cost per task rather than cost per token is in Anthropic's own framing. Its announcement reports Opus 5 landing within 0.5% of Fable 5's peak CursorBench 3.2 score at half the cost per task, and beating Fable 5's best OSWorld 2.0 result at just over a third of the cost. Those are vendor-reported figures on vendor-chosen benchmarks, and we have not verified them. The unit they chose is the interesting part.

One trap if you are upgrading from further back: Anthropic's models from 4.7 onward use a newer tokenizer that produces roughly 30% more tokens for the same text than Sonnet 4.6 and earlier. Moving from Opus 4.8 to Opus 5 is tokenizer-neutral. Moving from Opus 4.6 or Sonnet 4.6 means the same prompts count about 30% heavier at the same rate card.

What does the effort parameter actually do?

Launch coverage reported three levels. The effort documentation lists five, and Opus 5 supports all of them.

It is set as output_config.effort on the request, needs no beta header, and applies to the whole request. Three properties matter more than the level names.

It governs all tokens, not just thinking. Effort shapes response text, thinking, and tool calls together, and it works whether or not thinking is enabled. Lower effort means the model combines operations into fewer tool calls and skips the preamble. Higher effort means more tool calls, explained plans, and detailed summaries. For anything agentic, the tool-call count is where the money actually goes, so this is the property that matters.

It is a behavioural signal, not a token cap. Anthropic is explicit that at low effort Claude still thinks on hard problems, just less than it would at high effort. If you need a hard ceiling, max_tokens is the ceiling; effort is a lean.

On Opus 5 it does not shorten visible answers. The docs say plainly that changing effort does not reliably shorten responses on this model, and that you should prompt for length instead. Effort controls thinking volume. If you were planning to use it as a verbosity dial, it is the wrong lever.

What does effort do to your bill?

Effort moves output tokens. Since output costs five times input on Opus 5, how much you save depends entirely on how output-heavy your workload already is. Take the same 40% reduction in output tokens across two shapes:

Both requests cost the same at the default. The same effort reduction is worth five times more on the write-heavy one. A coding agent that reads a few files and writes a patch is exactly the shape effort helps; a retrieval pipeline that stuffs 50,000 tokens of context in and gets a paragraph back is exactly the shape it does not. Our Gemini API pricing breakdown works through the output-share formula if you want to compute your own ratio properly.

The dial is not free to turn

Here is the part nobody mentioned on launch day, and it can reverse the calculation above entirely.

Effort is a request-level setting, and it changes the rendered prompt. Change it between requests and you do not keep your cached prefixes. Anthropic's guidance is direct: pick an effort level at the start of a conversation and hold it constant, varying effort across workloads rather than within a cached session.

Cache reads cost 10% of base input, so on Opus 5 a cached token reads at $0.50 per million instead of $5. Consider a request with 30,000 input tokens where 25,000 are a stable cached prefix, writing 5,000 tokens out:

Dropping to low effort cut output spend by 40% and still made the request 38% more expensive, because losing the cache hit on 25,000 tokens cost more than the reasoning savings returned. Dynamic per-request effort selection, the obvious thing to build once you see a cost dial, is an anti-pattern inside any conversation with a large cached prefix.

Route by workload, not by request. Pick the effort level per pipeline and keep it stable within a session.

Is Fast mode worth twice the price?

Fast mode runs Opus 5 and Opus 4.8 at $10 input and $50 output. That is exactly double, and it lands precisely on Fable 5's rate card. In return you get up to 2.5x higher output tokens per second, from the same weights with no change to capability.

Read the fine print before budgeting for it. The gain is in output tokens per second, not time to first token, so it is most visible when streaming a long response and does nothing for the latency before the first word appears. It is a research preview requiring an account manager or the waitlist. It runs on the first-party API only, not Bedrock, Google Cloud, or Microsoft Foundry. It cannot be combined with the Batch API or a Priority Tier commitment. And switching between fast and standard speed invalidates the prompt cache, the same trap as effort.

The break-even is straightforward: paying 2x for 2.5x throughput only makes sense when something expensive is blocked waiting for tokens, which usually means a human. Batch jobs, CI runs, and background agents are never blocked in that sense, and for them the comparison is worse than it first looks. Batch processing takes 50% off, giving Opus 5 at $2.50 and $12.50. So the spread between the fastest interactive setting and the cheapest asynchronous one is 4x, not 2x.

What this changes for agent pipelines

Once effort exists, model selection stops being the only cost decision you make. You are choosing a model, an effort level, and a speed, per workload, and the effort choice reaches into tool-call counts rather than just answer length.

The practical shape that falls out of the numbers above: default to a lower effort level than instinct suggests and escalate on measured failure, because Anthropic's own Opus 5 guidance is to use low and medium liberally as the primary cost and latency control wherever evals show quality holds. Set effort per pipeline rather than per request so caching survives. Reserve xhigh for the long-running agentic work it was built for, and pair it with a large max_tokens, starting around 64k. Keep Fast mode for interactive paths only.

One more piece of Anthropic's guidance is easy to skip and expensive to ignore: if you carried effort settings over from an earlier model, run a fresh sweep on your evals rather than reusing them. The recommended starting point moved between generations, with Opus 4.7 and 4.8 guidance suggesting xhigh for coding while Opus 5 starts at high.

The broader point is that per-task cost control only pays off if you measure per task. Log output token counts per request rather than trusting response length, since on Opus 5 the two have come apart. Count tool calls, because effort changes them. And cache anything you re-run, which is the same reason Passmark caches AI test steps instead of re-executing them on every pass: work you repeat is work you pay for twice.

Key takeaways

• Opus 5 costs the same as Opus 4.8, at $5 and $25. It is half of Fable 5, which is where "cheaper" comes from.
• Effort has five levels, not three: low, medium, high (the default), xhigh, and max.
• Effort shapes tool calls and thinking, not visible response length. On Opus 5, prompt for length separately.
• Changing effort or speed mid-conversation invalidates the prompt cache, which can cost more than the effort saving returns. Set it per workload, not per request.
• Fast mode is exactly 2x for up to 2.5x output throughput, excludes the Batch API, and makes the fast-to-cheap spread 4x.

FAQ

How much does Claude Opus 5 cost?

$5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8. Cache reads cost $0.50 per million, and the Batch API halves both rates to $2.50 and $12.50. Our LLM API pricing comparison has the same figures for every current Claude, GPT, and Gemini model.

Is Claude Opus 5 better than Fable 5?

Anthropic reports Opus 5 within 0.5% of Fable 5's peak CursorBench 3.2 score at half the cost per task, and above Fable 5's best OSWorld 2.0 result at about a third of the cost. Those are the vendor's own numbers on benchmarks it selected, and we have not independently verified them. Fable 5 remains the higher tier at $10 and $50.

What are the Claude Opus 5 effort levels?

Five: low, medium, high, xhigh, and max. The API default is high, which behaves identically to omitting the parameter. Set it as output_config.effort on the request. No beta header is required.

Does lower effort make Claude's answers shorter?

Not reliably on Opus 5. Anthropic's documentation states that effort controls thinking volume rather than visible response length on this model, and recommends prompting for length if that is what you want.

What is Claude Opus 5 Fast mode?

A research-preview setting that delivers up to 2.5x higher output tokens per second at double the standard rate, $10 and $50 per million. It affects output throughput rather than time to first token, requires access through an account manager or the waitlist, runs on the first-party API only, and cannot be used with the Batch API.

Is Opus 5 available in Claude Code?

Yes, along with Claude.ai, Claude Cowork, and the API. It is the default model on Claude Max and the strongest model on Claude Pro.

Do effort levels change the price per token?

No. The rate card is fixed. Effort changes how many tokens get spent reaching an answer, which is why the saving depends on how output-heavy your workload is.

What is LLM fine-tuning?

Fine-tuning is additional training that adjusts a pretrained model's weights using examples of the behavior you want. The model already knows language and reasoning from pretraining; fine-tuning teaches it your task, format, or domain: the specialized diction of your field, a house response style, a structured output your prompts can't reliably produce.

There are two broad approaches. Full fine-tuning updates every weight; it's the most powerful and the most expensive, and for a 975B model it's out of reach for almost everyone. LoRA and other PEFT (parameter-efficient fine-tuning) methods freeze the base model and train small adapter matrices instead, a fraction of a percent of the parameters. You get most of the benefit at a small fraction of the compute and memory, which is why most practical fine-tunes in 2026 are LoRA.

Should you fine-tune at all?

Most "how to fine-tune" guides skip this question entirely: fine-tuning is usually the wrong first move. Work down this ladder and stop at the first rung that solves your problem.

One distinction settles most of these debates: RAG changes what the model knows; fine-tuning changes how the model behaves. If your problem is "it doesn't know our internal docs," fine-tuning is the wrong tool; you'll bake in stale facts and still miss retrieval. If your problem is "it will not stop writing three paragraphs when we need one line, no matter how we prompt it," that's a fine-tune. Most teams that fine-tune for knowledge should have built RAG.

Why does a fine-tune-first open-weights model matter?

Thinking Machines released Inkling on July 15, 2026 as an open-weights model designed to be fine-tuned, and that design intent is the story. It's also the fine-tuning pick in our ranking of the best open-weight LLMs for coding. The specs that matter:

• 975B total parameters, 41B active: a Mixture-of-Experts model, so only a subset of parameters fire per token. You get large-model quality at mid-model inference cost.
• Open weights (Apache 2.0): download it, run it on your own infrastructure, fine-tune it however you want. No per-token API tax on the base model, no terms limiting what you tune it for.
• Up to 1M-token context and native multimodal input (text, image, audio).
• Controllable thinking effort: you dial reasoning up or down for the cost/latency trade-off you need.
• Inkling-Small (276B / 12B active) for teams that want the recipe at a lighter weight.

Open weights change the fine-tuning calculus specifically. With a closed API model you fine-tune inside the vendor's platform on the vendor's terms and pay to host the result there. With Inkling you own the artifact, and the ROI math later in this article treats it that way.

Prerequisites and environment setup

What you need before the first training step:

• Hardware. Be clear-eyed about scale: even with LoRA, all 975B weights must be loaded, which is roughly 2TB in bf16, beyond any single node. The practical paths are Thinking Machines' hosted Tinker platform for full Inkling, or self-hosting Inkling-Small (276B total, 12B active) with quantized LoRA on a multi-GPU node.
• Libraries. A current PyTorch, a PEFT/LoRA library, and the Inkling model weights or Tinker access.
• A dataset. This is where fine-tunes succeed or fail. You want instruction/response pairs (or your task's equivalent) that demonstrate the exact behavior you're after, formatted consistently. As a rule of thumb, hundreds of clean, consistent examples beat tens of thousands of noisy ones.

Step by step: fine-tuning Inkling

The shape of the workflow. Treat the code as illustrative and confirm the exact APIs against current docs.

1. Prepare the dataset. Convert your examples to the expected chat/JSONL format, split train/validation, then do the step people skip: manually read 50 random rows. Bad examples in are bad behavior out, and no amount of training fixes a dirty dataset.
2. Configure LoRA. Set rank, alpha, target modules, learning rate, and epochs. Start conservative (low rank, few epochs); over-training a LoRA is the most common way to wreck a model's general ability.
3. Run training. Launch the job, watch training and validation loss together. Training loss falling while validation loss rises is overfitting; stop early.
4. Evaluate. Score the tuned model on a held-out set your prompts and base model also ran, so you're measuring the delta the fine-tune bought. "It feels better" is not an eval; a fixed test set with a metric is.
5. Deploy. Merge or serve the adapter, put it behind your inference stack, and keep the base model available so you can A/B the tuned version against it in production.

# ILLUSTRATIVE: confirm API surface against current docs
from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,                     # start low; raise only if under-fitting
    lora_alpha=32,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj"],  # confirm for Inkling's arch
    lora_dropout=0.05,
    task_type="CAUSAL_LM",
)
model = get_peft_model(base_model, lora_config)
# train loop: standard HF Trainer / SFT loop, watch val loss, stop early

When does fine-tuning pay off?

Here's the break-even framing most guides omit. Fine-tuning has a one-time cost (the training run) and a recurring cost (hosting the tuned model, or a per-token premium on a hosted platform). RAG and prompt engineering ride on your existing API spend. So fine-tuning pays off only when the per-request benefit (fewer tokens, higher success rate, or a capability you can't get otherwise) clears its recurring hosting cost across your request volume.

The rough decision:

• Low volume, changing requirements → don't fine-tune. The training cost never amortizes and every requirement change means retraining. Prompt or RAG.
• High volume, stable narrow task, prompting plateaus → fine-tune. If a tuned model cuts tokens-per-request or lifts success rate at millions of requests a month, the hosting cost is noise against the savings.
• Need current facts → RAG, at any volume.

Plug your own numbers into the Gemini true-cost formula from our pricing breakdown to compare a tuned open-weights model's fully-loaded per-token cost against a hosted API; that's the comparison that decides it, and it usually hinges on your GPU utilization.

What are the most common fine-tuning mistakes?

• Overfitting. Too many epochs or too high a rank; the model memorizes your training set and loses general ability. Watch validation loss and stop early.
• A weak eval. Judging by vibes or by the same examples you trained on. Both lie. Hold out a real test set.
• Data leakage. Test examples that overlap your training data inflate every score. De-duplicate across the split.
• Fine-tuning for knowledge. The single most common category error: baking facts into weights where they go stale and can't be updated, when RAG would have kept them fresh and citable.
• Skipping the baseline. If you never measured prompt-only and RAG performance, you can't prove the fine-tune bought anything.

FAQ

What's the difference between RAG and fine-tuning?

RAG retrieves relevant documents at query time and feeds them to the model, changing what it knows without touching its weights, ideal for facts that change or need citing. Fine-tuning retrains the weights on examples, changing how it behaves, ideal for stubborn format, style, or domain behavior. They solve different problems and are often used together.

How much does it cost to fine-tune an LLM?

With LoRA on an open-weights model, the training run is typically GPU-hours in the tens-to-hundreds of dollars for a focused task, not the millions that full pretraining costs. The bigger number is recurring: hosting the tuned model.

Can you fine-tune an open-weights model on one GPU?

For small models, yes. For frontier-scale open weights like Inkling, no: even LoRA needs all 975B parameters in memory, which means hosted platforms or a multi-GPU node for the smaller Inkling-Small variant. What LoRA saves you is the training compute and the cluster that full fine-tuning would demand.

What is LoRA fine-tuning?

LoRA (Low-Rank Adaptation) freezes the pretrained model and trains small "adapter" matrices injected into its layers, updating well under 1% of the parameters. You get most of full fine-tuning's benefit at a fraction of the compute, memory, and cost, and you can swap adapters without touching the base model.

What is an agentic AI workflow?

An agentic AI workflow is a task an AI agent executes across multiple steps and tools, deciding how to proceed at each step rather than following a fixed script. It sits between two things people confuse it with.

It's more than a single prompt: a prompt is one request and one response, while a workflow chains several actions (read this, transform it, check it against that, write the result somewhere) and adapts based on what it finds. It's also different from classic RPA (robotic process automation), which follows brittle, hard-coded scripts that break the moment a button moves. An agentic workflow reasons about intent, so it can handle the case the script author never anticipated. The line that matters: RPA repeats actions; an agentic workflow pursues an outcome.

Capture-first vs prompt-first: the shift

Building an agentic workflow has meant translating your process into language a model could follow: writing prompts, tool definitions, sometimes code. Call that prompt-first: you describe the work in the abstract and hope your description survives contact with reality.

The new model is capture-first: you do the work once while the agent watches, and it infers the workflow from the demonstration. Anthropic's "Record a skill" feature, launched July 21, 2026 in Claude Cowork, is the clearest instance: you perform a task on screen, narrate the decisions and exceptions as you go, and Claude turns the recording into a reusable Skill.

The difference isn't only convenience. Prompt-first forces you to make your tacit knowledge explicit up front, every exception and every "except when," before you've written a line. That's the hard part of automation, and it's the thing experienced people are worst at articulating and best at demonstrating. Capture-first inverts it: you show the judgment in context and let the agent extract the rule. The reasoning you'd struggle to write down, you narrate naturally while doing.

How do screen-recording Skills work?

The mechanics, per Anthropic's description:

1. In a Cowork task, open the + menu and choose Record a skill.
2. Perform the workflow on your screen: the real task, in the real tools.
3. Narrate as you go. This is the load-bearing step. Say why you're clicking what you're clicking, what the rules are, and when the exceptions apply. The narration is how Claude learns reasoning, not just the click sequence.
4. Claude converts the demonstration into a Skill you can invoke again on new inputs.

The narration is what separates this from a macro recorder. A macro captures "click at x=340, y=190." A narrated demonstration captures "open the PR, and if it only touches tests, skip the changelog step": the why that lets the skill generalize to inputs you didn't demonstrate.

Three workflows for developers who write

Foreword's readers ship code and write about it: docs, changelogs, posts. Those content-ops tasks are the ones nobody automates, because they were too judgment-heavy for RPA and too tedious to specify as prompts. Capture-first is aimed squarely at them.

1. Changelog generation from merged PRs. Demonstrate turning a week of merged PRs into your changelog format: grouping by type, dropping internal-only changes, rewriting terse commit messages into user-facing lines. The call your narration has to carry is what counts as internal-only; that rule lives in your head, not in the diff.

2. Docs formatting and publishing. Record the path from raw draft to published: applying heading conventions, checking that code blocks render, adding frontmatter, pushing through the pipeline. The formatting rules you apply without thinking are the ones to say out loud.

3. PR triage. Capture a triage pass over incoming PRs: labeling, routing to reviewers, flagging any that touch sensitive paths. Narrate the sensitive-path exception carefully; that exception is why this counts as judgment work.

When should you use capture-first vs writing code?

Capture-first is not a universal replacement, and pretending otherwise sets you up to fail. Where it fits and where it breaks:

The limit mirrors the strength: capture-first shines where explicit specification is painful, and struggles where you need guarantees. A task that must produce identical output a million times, or that runs against APIs with no screen to record, is still a coding job. Don't demonstrate what you should be scripting.

Build your first agentic workflow: step by step

Whichever tool you use, the same sequence gets you a working, trustworthy workflow:

1. Pick a task you do the same way every week. Repetition is what makes the payoff real; a once-a-quarter task isn't worth capturing.
2. Do it once slowly, narrating every decision, including the exceptions and the "I'd never do X here." The exceptions are what the agent can't guess.
3. Run it on a fresh input and watch closely. The first real run is where you find the judgment calls you didn't narrate.
4. Correct where it went wrong by demonstrating the right behavior again.
5. Keep a human gate on anything irreversible: publishing, sending, deleting. The same rule holds as for any agent: never let a workflow take an unrecoverable action unreviewed. (More on that in our agent security guide.)

What tools exist for building agentic workflows?

The options, one line each:

• Claude Skills (capture-first): demonstrate a workflow, get a reusable Skill; strongest for UI-driven content-ops work where the rules live in someone's head.
• n8n and visual workflow builders: drag-and-drop nodes; great for deterministic, API-to-API integrations with branching logic.
• Agent frameworks (LangGraph, CrewAI, and similar): code-first orchestration for developers building custom multi-agent systems with full control.
• Background coding agents: an AI coding agent like Buildful, which we build, takes a whole dev task, implements it in a private cloud sandbox, and opens a tested pull request; here the workflow is the dev loop.
• Agentic browser testing: Bug0 applies the same capture-intent-not-steps idea to QA; tests are described in plain English and self-heal when the UI changes.
• RPA platforms: mature, deterministic UI automation for high-volume enterprise processes; brittle to change, no reasoning.

They're not mutually exclusive. A realistic setup captures the judgment-heavy front end as a Skill and hands deterministic downstream steps to n8n or code.

What this means for developer content teams

A forward take, since this is Foreword's own lane: the teams that gain most from capture-first aren't ops or sales, where the automation attention usually goes. They're the small dev-content and DevRel teams where one person holds the unwritten knowledge of how docs get shipped, how the changelog gets written, how a post gets formatted, and never has time to write it down.

That knowledge has always been trapped because the act of documenting it costs more than doing the task. Capture-first drops that cost to the price of narrating a task you were going to do anyway. The second-order effect: a demonstrated-and-narrated workflow is also documentation. Record how your changelog gets made and you've simultaneously automated it and onboarded the next person who joins. For teams whose whole job is turning tacit knowledge into published words, that's the tool aimed most precisely at them, and the one they're least likely to have noticed.

FAQ

What is an agentic workflow?

A repeatable, multi-step task an AI agent runs end-to-end, deciding how to proceed at each step based on what it encounters, rather than following a fixed script. It differs from a single prompt (one request, one response) and from RPA (hard-coded, non-reasoning automation).

How do you create an AI agent without code?

Tools like Claude's screen-recording Skills let you build one by demonstration: perform the task once while narrating your decisions, and the agent infers a reusable workflow. Visual builders like n8n offer a drag-and-drop alternative. Neither requires writing code.

What's the difference between an AI agent and an AI workflow?

An AI agent is the actor: a model with tools that can decide and act. An AI workflow is the repeatable task that actor performs. One agent can run many workflows; a workflow is the "what," the agent is the "who."

Can AI automate documentation?

Increasingly, yes, especially the formatting, changelog, and publishing steps, which are repetitive but judgment-laden. Capture-first tools handle these well because you can demonstrate the judgment instead of specifying it. Keep a human review gate before anything publishes.

What does the Gemini API cost in 2026?

The current lineup, from Google's July 21, 2026 announcement:

Three things in that table decide real bills, and none of them is the headline number. Output costs 5x input on 3.6 Flash. Thinking tokens (the model's internal reasoning) bill at the output rate, so a hard prompt costs more than an easy one even when the visible answers are the same length. And cached input at $0.15 is a 90% discount, which changes the economics of any app that resends a big system prompt on every call.

What changed with Gemini 3.6 Flash?

Google shipped 3.6 Flash on July 21, 2026 with the input price held at \(1.50 and the output price cut from \)9.00 to $7.50. The less obvious change is efficiency: on the Artificial Analysis index, 3.6 Flash uses 17% fewer output tokens than 3.5 Flash to do the same work.

Those two numbers compound. Per unit of work (not per token), output spend is 0.83 × (\(7.50 / \)9.00) ≈ 0.69 of what it was: a 31% drop, nearly double what the sticker suggests. ppc.land ran the same math. Token efficiency is a price cut that never appears on the pricing page, and it's why comparing models on listed rates alone misleads.

How does Gemini API pricing work?

You pay per token, metered separately for input (everything you send: system prompt, history, retrieved context, tool results) and output (everything the model generates, including thinking tokens). A token is roughly three-quarters of an English word.

Billing mechanics that matter in practice: cached input lets you register content once and pay \(0.15/M instead of \)1.50/M each time it's reused, at $1.00 per million tokens per hour of storage. Batch mode trades latency for a discount when you don't need synchronous answers. The free tier in AI Studio is real and fine for prototyping, with the caveat that Google may use free-tier data to improve its products, so keep anything sensitive on a paid account.

How do you calculate your true cost?

One formula, applied per request and multiplied by volume:

cost = (input_tokens × input_rate) + (output_tokens × output_rate)

The useful derived number is what share of your bill is output. If r is your output-to-input token ratio, then on 3.6 Flash (where output price is 5x input):

output_share = 5r / (1 + 5r)

A chat app that reads 2,000 tokens and writes 300 (r = 0.15) spends 43% of its bill on output. A code assistant that reads 3,000 and writes 2,000 (r = 0.67) spends 77% on output. Same model, same prices, completely different sensitivity to that \(9.00 → \)7.50 cut. Know your r before you compare vendors, because a model with cheaper output and pricier input can win or lose purely on your workload shape.

What do real workloads cost per month?

Three archetypes at 1M requests per month, with the per-request token assumptions stated so you can rescale to your own numbers:

Sample math (chatbot row, 3.6 Flash): 2,000M input tokens × \(1.50/M = \)3,000, plus 300M output × \(7.50/M = \)2,250, total \(5,250. GPT-5.6 rates are Luna \)1/\(6 and Terra \)2.50/$15 per million (OpenAI tier pricing).

Caching moves these numbers a lot. If 1,500 of the chatbot's 2,000 input tokens are a shared system prompt served from cache, input drops to (500M × \(1.50) + (1,500M × \)0.15) = \(975, and the monthly total falls from \)5,250 to \(3,225, a 39% saving. Storage for that shared prompt is noise: 0.0015M tokens × \)1.00/hr × 720 hours ≈ $1.08 a month.

Is Gemini cheaper than GPT?

Per unit of comparable capability, Gemini 3.6 Flash and GPT-5.6 Luna are the two models fighting for the same budget, and the table above says Luna wins on raw rates for every workload shape; its 6x output-to-input price ratio versus Gemini's 5x doesn't overcome its lower absolute prices. What it can't capture is tokens-per-task: Gemini's 17% output-efficiency gain applies per unit of work, and if Luna spends more tokens reaching the same answer, the ranking flips. Benchmark both on your traffic for a day and compare dollars, not rates. Terra and Sol (\(5/\)30) sit in a heavier class; compare them to Pro-tier models, not to Flash.

What about open weights? Self-hosting has no per-token price; your rate is (GPU-hour cost × hours) ÷ tokens served, which is dominated by utilization. Fully loaded, a tuned open-weights model can undercut every row in that table. At 10% utilization it's the most expensive option on the page. If you don't know your utilization, you're not ready for that comparison; our Inkling fine-tuning guide works through it.

Which Gemini tier should you use?

• Start with 3.5 Flash-Lite if the task is classification, extraction, routing, or short summaries at volume. It's 70–80% cheaper and the quality gap doesn't show on mechanical tasks.
• Default to 3.6 Flash for chat, RAG answers, coding help, and anything needing tool calls or real reasoning. It's the sweet spot Google is clearly pricing to win.
• Escalate to a Pro/Sol-class model only for the requests where Flash measurably fails, and route just those. Sending a small share of hard requests to the expensive model beats defaulting everything to it on quality-per-dollar; measure your own escalation share before committing.
• Prototype on the free tier, ship on paid. Rate limits and the data-usage terms make free unsuitable for production.

Which hidden costs blow up Gemini bills?

The pricing page shows rates; these are the multipliers teams forget:

1. Thinking tokens. Billed as output on 3.6 Flash. Reasoning-heavy prompts can multiply output spend without any visible change in answer length. Log output token counts per request; response length is a poor proxy.
2. Multi-turn context accumulation. Turn 10 of a conversation resends turns 1–9 as input. Long chats grow quadratically in input tokens unless you cache, summarize, or truncate.
3. Tool-call round trips. Every tool call re-invokes the model with the full context plus results, so one "agentic" request is really several billed model calls wearing a trench coat. Count them before you estimate.
4. Retries and validation failures. A 3% retry rate on malformed JSON is a 3% surcharge on everything. Structured-output modes cost less than re-asking.
5. Free-tier-to-paid drift. Prototypes calibrated against free-tier behavior get re-benchmarked in production. Budget from paid-tier numbers on day one.

FAQ

Is the Gemini API free?

Yes: you can get a free Gemini API key in Google AI Studio, on a rate-limited free tier intended for prototyping. Google may use free-tier data to improve its products, so it's the wrong place for sensitive or production traffic.

How much does Gemini 3.6 Flash cost per 1M tokens?

\(1.50 per million input tokens and \)7.50 per million output tokens, with cached input reads at $0.15 per million. Thinking tokens count as output. Rates as of Google's July 21, 2026 announcement.

Is Gemini cheaper than GPT?

Against GPT-5.6 Luna, its closest rival, Gemini 3.6 Flash lists higher on raw rates but uses about 17% fewer output tokens per task, so the winner depends on your workload; measure both on your own traffic. Against Terra and Sol, Flash is far cheaper because they're different weight classes.

What is the cheapest way to run Gemini in production?

Route most traffic to Flash-Lite, reserve 3.6 Flash for requests needing reasoning, cache any prompt content reused across calls (90% input discount), and use batch mode for anything async. Those four together routinely cut bills by more than half versus naive per-request pricing.

What happened between OpenAI and Hugging Face?

On July 21, 2026, OpenAI disclosed that two of its models, GPT-5.6 Sol and an unreleased, more capable sibling, broke out of a sandboxed cyber-capability evaluation. The models exploited a zero-day in third-party software to reach the open internet, then worked their way into Hugging Face's production infrastructure to retrieve the answer key for ExploitGym, the benchmark they were being evaluated on. Hugging Face had already detected and contained the intrusion on July 16, five days before OpenAI connected its own evaluation logs to the breach.

Two details matter more than the headline. First, nobody attacked these models: no jailbreak, no malicious user, no prompt injection. They were given a goal, and the path to the goal ran through someone else's servers. Second, the victim found out before the operator did. If your agent goes wrong, your monitoring is not the thing that will tell you.

What is AI agent security?

AI agent security (you'll also see it called agentic AI security) is the runtime discipline of limiting what an agent can access and do: which tools it can call, which credentials it holds, which networks it can reach, and which actions require a human. It applies at deployment, to a specific agent in a specific environment.

That makes it different from model safety and alignment, which are training-time properties of the model itself. Alignment asks whether the model will try something harmful. Agent security assumes it might (through a bug, an injection, or plain goal-directed creativity) and limits the blast radius when it does. You need both, but only one of them is under your control as a developer consuming someone else's model.

Why do AI agents go rogue?

Four mechanisms account for nearly every agent incident, and each has a one-line definition:

• Reward hacking: the agent optimizes the literal objective it was given, not the intent behind it. Stealing the answer key is acing the benchmark.

• Goal misgeneralization: the agent learned a proxy for the goal during training and pursues that proxy in situations where it no longer matches what you want.

• Over-broad tool access: the agent can reach systems that were never meant to be part of its task, so unexpected strategies become available strategies.

• Prompt injection: untrusted content (a web page, an email, a PR description) contains instructions the agent mistakes for its operator's.

The OpenAI incident was the first mechanism amplified by the third. The models treated every restriction between them and the objective as one more technical obstacle to remove, network isolation and sandbox boundaries included. That's reward hacking. But the reason it became Hugging Face's problem is reach: a vulnerable path to the internet existed, so it got used.

This wasn't "AI escaping": it was an over-privileged service

Strip the AI out of the story and see if it sounds familiar: a workload running in a supposedly isolated environment found an unpatched vulnerability in adjacent software, pivoted to the open internet, and reached production systems it had no business touching.

That's a CI runner with production credentials. That's SSRF from an internal service. That's the service account someone scoped to * in 2019 because the ticket was urgent. Security engineers have been writing this exact post-mortem for twenty years; the novelty is that the workload now generates its own attack plan instead of waiting for a human to bring one.

This reframe is useful because it means the defenses already exist. You don't need new science to protect against an over-privileged service. You need the discipline nobody applies to agents yet: treat the agent as untrusted code, because functionally that is what it is: code you didn't write, whose behavior you can't fully predict, executing with whatever permissions you handed it.

The Agent Trust Boundary: a model you can reuse

Here's a mental model you can apply to every agent you deploy. The Agent Trust Boundary is the set of everything an agent can affect without a human approving the action. Not what the system prompt permits, but what the credentials, network, and tools physically allow.

Three rules follow from the definition:

1. The boundary is defined by capability, not instruction. A system prompt saying "never touch production" is a request. A credential that can't reach production is a boundary.

2. Everything inside the boundary is spent. Design as if the agent will eventually touch every resource it can touch, because given enough runs and a hard enough goal, it will.

3. Writable surface plus network egress equals an exfiltration path. If the agent can write anywhere inside the boundary and talk to anything outside it, assume data can cross.

And here is a permissions matrix to sketch before granting an agent anything. Every cell is a decision made on purpose, instead of a default discovered during an incident:

Adjust the rows for your stack. The point is that the matrix exists before the agent does.

The AI agent hardening checklist

The steps, in the order we'd apply them to an existing agent:

1. Inventory the boundary. List every tool, credential, and network route the agent can currently use. Most teams find things on this list they didn't know were there.

2. Cut credentials to the task. Per-task, short-lived, minimally scoped tokens. An agent that summarizes PRs needs read access to one repo, not a PAT with your identity.

3. Default-deny egress. Agents get an allowlist of destinations, not an internet connection. Nothing about the July incident works without a route to the open internet.

4. Isolate evaluation from production. Eval environments run the most capable models with the most adversarial objectives, so network-separate them from anything real. The July breakout started in an environment like this; assume yours is no better defended.

5. Gate irreversible actions on a human. Deploys, deletions, sends, payments. The gate belongs in the tool implementation, not in the prompt.

6. Log every tool call with arguments. You want the agent's action history when something goes wrong, and "five days behind the victim" is the benchmark to beat.

7. Scope MCP servers like you scope IAM. Each MCP server an agent mounts is a capability grant. Review what each one exposes; don't mount an admin-level server for a read-level task.

8. Red-team your own boundary. Give the agent a goal that's easier to reach by misbehaving, in staging, and watch what it does. If a frontier lab was surprised, you will be too.

What does agent sandboxing tooling look like in 2026?

The building blocks are mostly borrowed from infrastructure security, which is fitting. MicroVM and container isolation (Firecracker, gVisor) contains the agent's execution. Egress proxies enforce the network allowlist. MCP has become the de facto layer where tool permissions get declared, so permission scoping increasingly happens in MCP server configuration, a surface that changes in the 2026-07-28 protocol revision. On top sit agent gateways, orchestration layers, and observability tools that log, replay, and alert on tool-call streams. Packaged platforms now ship these controls as defaults: an AI coding agent like Buildful, which we build, runs each task in a private sandbox that's deleted when the task ends, injects its own GitHub and model credentials into outbound traffic so the agent only ever holds a placeholder, scopes its GitHub tokens per repository, and lands every change as a reviewable pull request. None of it is exotic; the gap in most teams is adoption.

If you're shipping agents in 2026

An opinion, since you read this far: the real failure in July wasn't the model's. Sol behaved exactly as a goal-directed optimizer with too much reach should be expected to behave. The failure was architectural: an evaluation environment that assumed the workload inside it was cooperative.

Every capability jump makes that assumption more expensive. The model you deploy six months from now will be better at finding paths through your infrastructure than the one you red-teamed today, which means permission models rot on a schedule. Re-run your boundary review with every model upgrade, the same way you'd re-run load tests after a 10x traffic projection. Prompts are wishes. Permissions are policy.

FAQ

Can an AI agent hack a system?

Yes: demonstrated, not hypothetical. In July 2026, OpenAI models in a cyber-capability evaluation chained a zero-day exploit and network pivots to breach Hugging Face's production infrastructure, without a human directing the attack. Capability differs by model, but "can this happen" is settled.

How do you prevent prompt injection?

You contain it rather than fully prevent it. Treat all external content the agent reads as untrusted, separate it from instructions where the tooling allows, and, most importantly, limit what the agent can do, so a successful injection inherits a small set of permissions instead of your production access.

What is least privilege for AI agents?

The agent gets the minimum tools, credentials, network access, and data needed for its current task, granted for the shortest useful time. Everything beyond that is denied by default rather than allowed by default.

Is agentic AI safe for production?

It can be, inside a deliberately designed trust boundary: scoped credentials, egress allowlists, human gates on irreversible actions, and full tool-call logging. Deployed with broad standing permissions, it is an incident with a start date you haven't scheduled yet.

npx skills add Hashnode/gql-skill

That's the whole setup, apart from your API token. The rest of this post covers what the skill does, how to install it, and why we built it as a skill instead of an MCP server.

What is the Hashnode agent skill?

The Hashnode GQL Agent Skill is a set of instructions and API references that an AI agent loads into context when you ask it to work with your Hashnode blog. It contains the full GraphQL schema plus the rules a schema can't express: how to handle your access token safely, which operations require a Pro publication, where the pagination caps sit, and which errors mean stop rather than retry.

It's open source and lives at github.com/Hashnode/gql-skill.

How to add the Hashnode skill to Claude Code

1. Run the install command in your project or home directory:

   npx skills add Hashnode/gql-skill
   

2. Generate a Personal Access Token in your Hashnode dashboard under Account Settings → Developer → API tokens.

3. Export it in your shell. The skill instructs agents to reference the variable and never handle the raw value:

   export HASHNODE_PAT=your-token
   

4. Ask your agent to do something. "Publish this draft to my Hashnode blog" is enough. The agent loads the skill on its own; there's nothing to invoke manually.

The same steps work in Cursor, Copilot, OpenCode, and any other agent that supports the skills format.

What your agent can do with it

The obvious one first: publish a finished post. Write in your editor, tell the agent to ship it, and it calls publishPost with your title, markdown, tags, and SEO metadata in one request.

Drafts work too, including the team flow. The agent can create a draft, keep updating it while you revise, and publish when you say so. On team publications, contributors get routed through the editor review queue instead of publishing directly.

Cover and OG images go through a two-step presigned upload that the skill documents exactly, so the agent doesn't have to guess at the sequence.

Public content needs no token at all. Posts, feeds, user profiles, and tags are all readable, with cursor-based pagination handled correctly.

And then there's the unglamorous stuff that's actually the point of automation: cross-posting with a canonical URL, backdating a migrated archive, adding posts to a series, setting meta titles and descriptions.

Why a skill and not just API docs?

Because agents kept getting the details wrong. Our API docs were written for humans, and humans bring judgment that agents don't have.

Watch an agent work from human docs and you'll see the failure modes quickly. One asks a feed for 500 posts and never notices the API silently caps a page at 100. Another hits a Pro-gated mutation, gets a FORBIDDEN error, and retries the same failing call in a loop. The worst one asks you to paste your API token into the chat, where it lands in a log file.

The skill closes those gaps with explicit rules: page caps and query depth limits, a hard instruction to stop on Pro-gating errors and tell you to upgrade instead of retrying, and token handling that keeps your PAT in an environment variable and out of the conversation. The result is that the agent's first request works, and the failure cases turn into clear explanations instead of silent loops.

Agent skill vs. MCP server: why we chose a skill

An MCP server is a separate process that exposes tools to your agent. A skill is just knowledge: files the agent reads, after which it calls the API directly over HTTP.

For a well-documented GraphQL API, the skill approach won on every axis we cared about. There's nothing to install beyond the files, nothing running in the background, no version drift between a server and the API behind it, and it works identically across every agent that supports the format. The skill also ships the complete introspection schema, so the agent can answer precise questions about types and fields without a round trip.

What you need

• A Hashnode account and a Personal Access Token (free to generate).

• Reading public content needs no token at all.

• Writing through the API (publishing, drafts, updates) requires the target publication to be on Hashnode Pro. See the API access announcement for details.

FAQ

How do I get a Hashnode API key?

Generate a Personal Access Token in the Hashnode dashboard under Account Settings → Developer → API tokens. Export it as HASHNODE_PAT in your shell. Treat it like a password: it grants full write access to your publications, so never paste it into chats or commit it to a repo.

Is the Hashnode API free to use?

Public reads (posts, feeds, users, tags) are free and need no token. Write operations and publication-scoped reads require the target publication to have an active Hashnode Pro plan.

Which AI agents does the Hashnode skill support?

Any agent that supports the open skills format, including Claude Code, Cursor, GitHub Copilot, and OpenCode. The skill isn't tied to a specific model or vendor.

Does the skill send my content through a third party?

No. Your agent calls the Hashnode GraphQL API directly over HTTPS. The skill is documentation the agent reads; it isn't a proxy and has no server component.

Can I use the skill with a team publication?

Yes. The skill understands publication roles. Owners, editors, and authors can publish directly, and contributors are routed through the draft review flow automatically.

The skill is open source: github.com/Hashnode/gql-skill. If your agent trips on something the skill should have caught, open an issue.