A blog post published on the n8n blog by Andrew Green on August 14, 2026, explains that the only way to ensure that token prices do not rise is to host your own large language models (LLMs). Currently, token prices are subsidized by major tech companies, and most AI providers are operating at a loss, which increases the likelihood of price hikes in the near future as funding decreases. The post provides an in-depth analysis of the benefits, challenges, and tools required for self-hosting models.
Why are Token Costs Expected to Rise?
According to the n8n post, the true cost of a token is not precisely known because it is subsidized by tech giants. Once funding is reduced and providers are forced to operate as normal businesses, token costs will highly likely rise, as has already begun to happen recently. Even Microsoft found the Claude Code tool to be too expensive and canceled its licenses, despite developers preferring it over GitHub Copilot.
Most organizations currently base their business logic on large language models. An organization will not decommission an active chat support agent in production just because of a 10% price increase. However, if the price increases by 10% several times, the organization will be forced to re-examine its financial data. Furthermore, agentic logic is becoming increasingly token-heavy due to the growing use of tool calls, retrievals, reasoning, and agents deciding to write an entire web page instead of responding with simple plain text.
Therefore, organizations are left with two options: optimizing token consumption in their existing frontier models, or switching to self-hosting models (Self-host LLMs). The author supports the second option, quoting Mitko Vasilev's motto: "Make sure you own your AI. AI in the cloud is not aligned with you; it's aligned with the company that owns it." n8n prepared for this trend in advance by launching its self-hosted AI starter kit over two years ago. The fact that swappable AI components are a core functionality of n8n’s workflow logic allows users to swap a model provider without rewriting the surrounding wrapping logic. The open-source community has also built several language models that allow for significant cost reductions.
The Advantages of Self-Hosting Models
Beyond preventing the outsourcing of an organization's budget decisions to third-party providers, self-hosting offers several other key advantages:
- Fewer points of failure: In 2026, the Claude model experienced multiple outages (with only 98.64% uptime at the time of writing) without users having any way to influence it. In contrast, industry-standard compute services offer "five nines" (99.999%) availability. Aside from dependency on the LLM provider's availability, there is an associated network dependency that can lead to timeouts or rate limits.
- Additional controls: When an organization owns the model endpoint, it decides what happens at every layer. The organization controls which model version runs, when it is updated, or if it is updated at all, and is not limited by the controls that LLM providers choose to expose via their APIs.
- Privacy: Input prompts and outputs do not leave the self-hosted environment unless explicitly exported. This eliminates concerns regarding data subprocessors or changes in data processing terms by third-party providers.
- Interpretability: Tools such as TransformerLens or SAEsto exist to help better understand the internal mechanics of an LLM—an option that is unavailable with closed cloud models.
- Model customization and finetuning: Technologies like QLora allow adapting a model to a specific task to such a degree that, in specific domains, a small model can achieve performance identical to state-of-the-art (SOTA) models at a fraction of the size and time. This advantage is even more prominent given that OpenAI has discontinued support for its fine-tuning APIs.
The Challenges and Complexities of Self-Hosting
Alongside the benefits, self-hosting brings full responsibility for the model's infrastructure; OpenAI or Anthropic cannot be blamed when services fail. The main challenges include:
- Supply chain security: It is the organization's responsibility to select, deploy, and manage the models, exposing it to the risk of deploying backdoored models. Runtimes also come with their own security vulnerabilities.
- Setup and configuration: This infrastructure cannot be set up based solely on quick, intuitive coding ("vibe coding"). While the AI starter pack makes initial deployment easy, transitioning to Ollama or exposing the LLM to non-n8n services requires establishing proper infrastructure. This varies depending on whether you self-host on a local machine, organization hardware, or use a cloud provider.
- Managing breaking changes: Updating any component in the system could cause the entire system to stop functioning.
- Performance: Frontier models in the cloud remain the highest-performing models today, and new releases continue to outperform older models on benchmarks.
- Resource utilization: Large language models consume substantial memory for both the model and the cache, which can cause out-of-memory (OOM) errors that might crash agents and other processes sharing the compute layer without proper isolation.
Hardware Infrastructure for Running Models
Self-hosting does not necessarily require running on a user's local machine, waiting for H100 processors, or finding rack space in the office. You can lease compute and storage resources and deploy LLMs on cloud infrastructure on your own terms. For GPU-based Infrastructure-as-a-Service (IaaS), the following options are available:
- RunPod: Offers both dedicated GPU servers (GPU Pods), which are persistent virtual machines, and Serverless options with pay-per-second pricing, covering everything from development to production.
- Lambda Labs: Considered the preferred choice for stable, dedicated servers with no data egress fees—a significant advantage when workflows push large volumes of text completions back to a local n8n installation.
- CoreWeave: Provides enterprise-grade infrastructure optimized for large multi-node clusters. H100 processors run there at approximately $4.76 per hour on-demand, with volume discounts for committed capacity.
- Vast.ai: Offers the lowest base prices, starting at around $0.17 per hour for older GPUs, through a peer-to-peer cooperative marketplace.
Additionally, hyperscalers are an excellent option. If the organization already runs n8n in such a cloud, hosting an LLM within that existing environment can be explored. AWS, for example, offers CPU and GPU-based options within EC2 services. While this essentially shifts the budget from one provider to another and introduces operational overhead, token prices are arbitrary and lack fixed market value, meaning they could easily skyrocket, whereas Infrastructure-as-a-Service (IaaS) is a highly competitive and mature market. If the rising cost of renting GPUs poses too great a risk, the option to run models on CPUs is always available.
Leading Inference Runtimes for Local Models
Different runtimes have different mechanisms for serving models, primarily centering around whether they run on CPU or GPU. Other considerations include model format (such as GGUF or safetensor) and support for new models. The primary runtimes mentioned in the post are:
- llama.cpp: Supports both CPU and GPU-based architectures and is considered the preferred option for CPU-based use cases. It is a highly portable reference runtime with zero GPU dependencies, supporting AVX2, AVX-512, and ARM NEON instruction sets. It serves as the engine behind Ollama and is suitable for development environments and low-traffic deployments.
- vLLM: A production-grade, GPU-optimized server. It implements continuous batching and PagedAttention mechanisms, making it an excellent choice when multiple n8n developers run AI agents simultaneously, requiring the GPU to handle concurrent requests efficiently rather than processing them one after another.
- Ollama: A developer-friendly entry point. It wraps llama.cpp with a clean API, manages the model's lifecycle, and serves as the default in n8n's self-hosted AI starter kit. It trades a slight sacrifice in peak performance for operational simplicity.
- LM Studio: Provides a desktop graphical user interface (GUI) for running local models. It is useful for internal teams wishing to experiment without a terminal, but is not designed for headless server deployments.
- SGLang: Optimized for structured and constrained generation. It is particularly relevant for n8n tool-calling nodes that require receiving valid JSON files from the model—an area with a high failure rate in general-purpose runtimes.
- ExLlamaV3: Pushes quantization efficiency a step further on NVIDIA hardware. Its main value lies in its ability to run larger models under limited video memory (VRAM) constraints.
- Intel IPEX-LLM: A runtime supporting CPU and partially GPU, designed specifically for Intel's Xeon or Arc hardware.
Model Selection: Finding the Right Size and Performance
Models with a large number of parameters will behave more like the leading cloud models of Anthropic and OpenAI, but they require substantial resources. Most organizations can achieve a good balance between performance and resource consumption by running models in the 3B to 13B parameter range with Q4 quantization on general-purpose hardware. Models in this range can run on a single consumer GPU or a powerful CPU server, providing sufficient output quality for most business automation tasks. Below is the variety of models available to choose from:
- Llama (Meta): The reference open-source model family (ranging from 1B to 70B parameters). Llama 3.x models are an excellent general-purpose choice, well-supported across all runtimes, and available under a license that allows commercial use for most organizations. The 8B and 70B variants are the most commonly deployed.
- Qwen (Alibaba): Models in the 0.8B to 72B parameter range, particularly strong in code generation and multilingual tasks. The Qwen2.5-Coder variants deliver competitive performance against much larger general models for tool-calling agents. The Qwen3.5 series extends the range down to sub-1B models suitable for routing and classification tasks.
- Mistral: Offers efficient mid-size models in the 7B to 22B parameter range. Mistral Nemo and Mixtral (which utilize a mixture-of-experts (MoE) architecture) are excellent defaults when video memory (VRAM) is constrained and a strong general-purpose model is required without reaching the 70B size.
- Google Gemma 3 / Gemma 4: Models in the 2B to 27B parameter range. The smallest variants of Gemma 4 (at 2B and 4B effective parameters) run with only about 5 GB of RAM under 4-bit quantization on modern hardware. The Apache 2.0 license makes commercial deployment straightforward.
- Qwen 3.5 Small: A series featuring models in the 0.8B to 9B parameter range with a 256K context window and support for 201 languages. It offers thinking and non-thinking modes, which is useful when wanting to suppress the chain-of-thought process in simple tasks to save tokens. The model is particularly strong for multilingual n8n deployments.
- Meta Llama 3.2: Models in the 1B and 3B size, designed explicitly for edge devices and CPU-based deployments. The 1B version fits in under 1 GB of memory under Q4 quantization, making it suitable for lightweight classification and routing tasks within n8n workflows.
- SmolLM3-3B (HuggingFace): At the 3B parameter scale, this model outperforms Llama 3.2 3B and Qwen 2.5 3B, remaining competitive against 4B-class alternatives across a broad range of benchmarks. HuggingFace has published its full engineering blueprint, including architectural decisions, data mixture, and post-training methodology.