Every model in this ranking is available behind one haimaker.ai key, at about 5% below market rate. Point Hermes at one endpoint and switch tiers by editing a single string.
GET ONE KEY FOR EVERY HERMES MODEL
## What happened to the open-weight tier?
The open-weight tier stopped being a compromise this summer. Moonshot's Kimi K3, announced July 16, beat both Claude Fable and GPT-5.6 Sol on arena leaderboards, and its coding-tuned sibling Kimi K2.7 is already usable behind Hermes today. GLM-5.2 leads the open field on SWE-bench Pro at 62.1%, ahead of MiniMax M3 (59.0%) and Kimi K2.6 (58.6%).
Two practical implications for Hermes users:
- **Kimi K2.6 and later support agent-swarm coordination** — spawning specialized sub-agents that collaborate. If you push Hermes toward multi-agent patterns, the Kimi line is built for exactly that shape of work.
- **Open-weight pricing pressure is real.** The gap between "open budget model" and "closed mid-tier model" on agentic benchmarks is now a few points, while the price gap remains large. For most non-critical Hermes workloads, the open tier is the rational default.
## Can Hermes Agent run local models?
Yes. Hermes treats a local Ollama server as just another custom endpoint: base URL `http://localhost:11434/v1`, any placeholder API key, and whatever model you have pulled. The community consensus local pick is **Qwen3.6 27B** (77.2% on SWE-bench Verified from a single 24GB GPU), with **gpt-oss 20B** as the 16GB fallback.
The honest caveat: local models still trail cloud models on the hardest multi-file work, so the setup that holds up in practice is local for cheap private steps and a cloud model for escalation. Our [Ollama coding models guide](/blog/best-ollama-models-for-coding-agents/) covers the hardware tiers, and [cheapest APIs for coding agents](/blog/cheapest-api-coding-agents/) covers the cloud side of that hybrid.
## The bottom line
There is no single best model for Hermes Agent, but there is a clear default stack in July 2026:
- **Start:** Claude Sonnet 4.6 as the daily driver
- **Escalate:** Claude Opus 4.8 for production code
- **Economize:** MiniMax M3 or DeepSeek V4 Flash for always-on background agents
- **Experiment:** Kimi K2.7 and GLM-5.2 if you want frontier-adjacent results at open-weight prices
Because Hermes is endpoint-agnostic, none of these choices lock you in. Set up one key, then re-rank your stack when the next release lands. On current pace, that happens every few weeks.
Want the local-first, cloud-fallback setup without wiring two providers by hand? haimaker sends everyday coding work to your local model and escalates the hard tasks to a strong cloud model through one endpoint.
ROUTE LOCAL AND CLOUD MODELS WITH HAIMAKER
## The bottom line
Is Ollama good for coding? For autocomplete, private edits, offline work, and small well-scoped tasks on a 24GB-plus machine, yes, and it is genuinely good, not a consolation prize. For long agent loops, strict tool calling, and hard multi-file debugging, it is still a step behind, and the smart move is to keep a cloud model in reach for those moments. Match the tool to the task and local earns its place in the workflow. Force it to do everything and you will spend the afternoon watching a progress spinner.
---
### Cline Custom Provider Setup: Add Any OpenAI-Compatible API
**URL**: https://haimaker.ai/blog/cline-custom-provider-setup
**Date**: 2026-06-25
**Description**: Add Haimaker, Ollama, OpenRouter, or any OpenAI-compatible API to Cline using the OpenAI Compatible provider. Includes Base URL and API key setup, the Model Configuration fields that custom endpoints require, and fixes for the common errors.
**Keywords**: cline custom provider, cline openai compatible, cline add provider, cline model provider, cline custom api, cline haimaker, cline llm provider, cline base url, cline openrouter
Cline ships with first-class support for the big providers, and at ~64K GitHub stars it is one of the most-used coding agents in VS Code and JetBrains. But the built-in list is not the whole story. The "OpenAI Compatible" provider is how you point Cline at a gateway, a local runtime, an internal inference endpoint, or a model that has not landed in the directory yet.
The flow is short: choose the OpenAI Compatible provider, paste a Base URL and API key, name the model, set a couple of capability fields, and verify. The one step people skip is the Model Configuration block, which matters more for custom endpoints than it does for built-in providers.
> **Just want Haimaker in Cline?** Skip the manual settings — run `npx -y @haimaker/connect --cline` and the CLI writes Cline's OpenAI Compatible provider config (endpoint, key, and model) for you, then exits. The walkthrough below is the general method for *any* OpenAI-compatible endpoint — Ollama, LM Studio, an internal gateway, or a model not yet in the directory. See the [connect guide](/connect) for the one-command path.
## When to use a custom provider
Reach for the OpenAI Compatible provider when the model or endpoint is not already in Cline's built-in list, or when you want to route several model families through one key.
Good examples:
- **Haimaker** — one API key for multiple model families through an OpenAI-compatible gateway.
- **Ollama** — local models at `http://localhost:11434/v1`.
- **LM Studio** — local models at `http://127.0.0.1:1234/v1`.
- **Internal gateways** — company-hosted OpenAI-compatible endpoints.
- **New providers** — anything that speaks the OpenAI chat completions API before Cline's directory catches up.
If the provider already has a dedicated entry in Cline, start there. The OpenAI Compatible path is most useful when you need a custom Base URL, a gateway, or a model that the default options do not expose.
## Step 1: Open settings and pick the provider
Click the gear icon in the Cline panel to open settings. Under **API Provider**, select **OpenAI Compatible**.
This switches the form to the generic OpenAI-compatible fields: a Base URL, an API Key, a Model field, and a Model Configuration section. Everything else on this screen keys off those values.
## Step 2: Enter the Base URL and API key
Fill in the two connection fields:
- **Base URL** — the provider's API endpoint. For [Haimaker](https://haimaker.ai), that is `https://api.haimaker.ai/v1`. Cline accepts both the version-prefixed base (`https://api.provider.com/v1`) and, for some providers, the full chat-completions URL. When in doubt, use the `/v1` base.
- **API Key** — the secret key from your provider. Paste the raw key with no `Bearer` prefix.
There is also a **Use Azure Identity Authentication** checkbox. Leave it unchecked for standard API-key providers like Haimaker or Ollama. It only applies to Azure deployments where you authenticate with `az login` instead of a key.
## Step 3: Set the Model ID
In the **Model** field, enter the exact model identifier the provider expects in the `model` field of a request. Custom providers pass this string through unchanged, so it has to match the upstream API character for character.
For Haimaker, that looks like:
```text
anthropic/claude-sonnet-4-6
openai/gpt-5.4-mini
minimax/minimax-m2.5
qwen/qwen3-coder
```
If you are unsure of the exact string, list the provider's models first (see the verification step below).
## Step 4: Fill in Model Configuration
This is the step that trips people up. For built-in providers, Cline already knows each model's context window, output limit, and whether it supports tool calls. For an OpenAI Compatible provider it cannot detect any of that, so it falls back to conservative defaults that often do not match your model.
Open **Model Configuration** and set:
- **Context Window** — the model's real input limit. If this is too low, Cline truncates context early; too high and you get upstream errors on long sessions.
- **Max Output Tokens** — the per-response output cap.
- **Image Support** — turn on only if the model is multimodal.
- **Computer Use** — turn this **on** for any model you want to drive agentic edits, file operations, and tool calls. With it off, Cline treats the model as chat-only and agentic actions silently fail.
- **Input Price / Output Price** — the provider's per-million-token rates, used for Cline's running cost estimate. These are for display only and do not affect requests, so set them to whatever your provider currently charges.
Getting the Context Window and Computer Use fields right resolves most "the model is connected but acts broken" reports.
## Step 5: Verify and test
Click **Verify** to confirm the Base URL, key, and model resolve. Then send a small prompt in a throwaway task before pointing Cline at real code.
If Verify fails, the problem is almost always the Base URL, the key, or the Model ID, in that order. You can isolate it by hitting the API directly:
```bash
curl https://api.haimaker.ai/v1/models \
-H "Authorization: Bearer your-haimaker-api-key"
```
A clean JSON list back means your credentials and endpoint are good, and the issue is in the Cline form. Use the exact `id` values from that response in the Model field.
## Full example: Haimaker gateway
This is the setup to use when you want one OpenAI-compatible endpoint for several model families:
| Field | Value |
| --- | --- |
| API Provider | OpenAI Compatible |
| Base URL | `https://api.haimaker.ai/v1` |
| API Key | your Haimaker key |
| Model | `anthropic/claude-sonnet-4-6` |
| Context Window | match the model (for example 200000) |
| Max Output Tokens | a sane cap (for example 8192) |
| Computer Use | On |
Why this works well: Cline sees one provider, while Haimaker handles access to multiple upstream model families behind a single key. To switch models, you change the Model field (or save a second profile) instead of juggling separate provider credentials. The same key gives you a [wide range of models](https://haimaker.ai/models), so you can move from a budget model for routine edits to a premium model for hard refactors without re-authenticating.
## Full example: Ollama local provider
Ollama exposes an OpenAI-compatible endpoint on your machine, which makes it a clean fit for the same provider type:
| Field | Value |
| --- | --- |
| API Provider | OpenAI Compatible |
| Base URL | `http://localhost:11434/v1` |
| API Key | any non-empty string (Ollama does not validate it) |
| Model | `qwen3-coder:30b` |
| Computer Use | On |
Pull the model before you point Cline at it:
```bash
ollama pull qwen3-coder:30b
```
Confirm the exact tag with `ollama list` and use that string in the Model field. Local models are more sensitive to context limits and tool-call formatting, so start with one that handles agentic coding well, such as Qwen3 Coder, and keep the Context Window modest until tool calls behave.
## Common errors and fixes
#### Verify fails immediately
The Base URL or key is wrong. Confirm the URL ends at `/v1` (not `/v1/chat/completions` unless your provider requires the full path), and that you pasted the key with no `Bearer` prefix and no trailing whitespace. Test with the `curl` command above to isolate Cline from your credentials.
#### Model connects but every agentic action fails
**Computer Use** is off. Cline is treating the model as chat-only, so file edits and tool calls never fire. Turn it on in Model Configuration. If it is already on and tool calls still fail, the model itself may be weak at structured tool use; switch to a model known for agentic coding.
#### Output gets truncated or context errors appear on long tasks
The **Context Window** or **Max Output Tokens** value does not match the model. Cline used a default. Set both to the model's real limits.
#### Requests hit the wrong model or 404
The **Model ID** does not match what the upstream API expects. Custom providers pass it through verbatim, so `anthropic/claude-sonnet-4-6` and `claude-sonnet-4-6` are different strings to the API. Copy the exact `id` from the provider's `/models` response.
#### Cost estimate looks wrong
The **Input Price / Output Price** fields are display-only estimates you entered by hand. They never affect requests or billing. Update them to your provider's current rates if you want the in-session estimate to track reality.
## The practical setup
For most Cline users, a clean two-or-three provider setup covers everything:
1. **Haimaker** for cloud models and one-key routing across families.
2. **Ollama** for local, private work.
3. **One premium model** kept on hand for hard debugging and multi-file refactors.
That gives you local privacy when it matters, low-cost cloud models for routine work, and a stronger model when the task is expensive in attention, all from the same OpenAI Compatible provider type.
Even on a 5090, hard multi-file tasks are better handled by a frontier cloud model. haimaker gives you one endpoint to run Qwen3 Coder locally for the cheap work and escalate to cloud models when the task gets expensive in attention instead of tokens.
ROUTE LOCAL AND CLOUD MODELS WITH HAIMAKER
## 24GB: RTX 4090 and RTX 3090
Both 24GB cards run the same model: **Qwen3 Coder 30B-A3B** at Q4_K_M. At roughly 18GB it leaves about 6GB for KV cache and context, which is workable for real agent sessions.
```
ollama pull qwen3-coder:30b
```
The split between these two cards is speed and price, not capability. The 4090 generates tokens about 20 percent faster than the 3090 on a 30B model. The 3090, bought used, is the best VRAM-per-dollar value in local AI right now: it fits the exact same 30B coding model for a fraction of a new card's price, which makes it the smart pick for learning, light use, or a tight budget.
Q5_K_M (about 22GB) technically fits 24GB, but it leaves almost no room for context. Stick with Q4_K_M unless you are running short prompts and know why you need the extra precision.
## 16GB: RTX 5070 Ti, 4070 Ti Super, 4060 Ti 16GB
Sixteen gigabytes is the line where 30B models stop being practical. A 30B model at Q4 is about 18GB, so it spills out of a 16GB card into system RAM and the speed collapses. Stay in the **14B class** and you get a fast, fully-resident model with room for context.
```
ollama pull qwen3:14b
```
Qwen3 14B at Q8 fits comfortably and produces strong code. On an RTX 4060 Ti 16GB expect around 22-34 tokens per second; on a GDDR7 RTX 5060 Ti the same model runs closer to 50 tokens per second thanks to higher memory bandwidth. Other solid 16GB picks are `phi4:14b` and `deepseek-r1:14b`. This tier is genuinely useful for code explanation, small edits, test drafts, and config generation, and it is where most developers without a flagship GPU should land.
## 12GB: RTX 3060 12GB and similar
At 12GB the sweet spot is the **8B class**. Qwen3 8B runs at interactive speeds and handles the everyday agent work: explaining unfamiliar code, writing small functions, drafting tests, summarizing logs.
```
ollama pull qwen3:8b
```
You can squeeze a 14B model at Q4 (about 8GB) onto a 12GB card, but context space gets tight quickly. For a smooth agent loop, an 8B model that stays fully resident usually feels better than a 14B model fighting for memory.
## 8GB: entry-level cards
Eight gigabytes runs lightweight models only: **Gemma 4 E4B** or an 8B model at Q4.
```
ollama pull gemma4:e4b
```
Set expectations accordingly. This tier is good for code explanation, boilerplate, and small single-file edits. It is not the place to run a coding agent through a multi-file refactor. Smaller models lose the thread once the agent starts opening files, revising patches, and juggling tool output.
## The rule that beats every benchmark
Keep the model fully in VRAM. Everything else is secondary.
- A 32B model at ~60 t/s in VRAM becomes ~1-2 t/s the moment it spills to system RAM
- Quantization is how you make a model fit: Q4_K_M is the practical default, Q5/Q8 only when you have spare VRAM
- Prompt processing is fast on every card; token generation is the bottleneck, and it scales with memory bandwidth
- A smaller model that stays resident beats a bigger model that swaps, every time
When you are picking a quant, leave headroom for context. A model that fits at 0K context but overflows at 16K will swap mid-session, which is the worst case.
## When to use a cloud model instead
Local is best when privacy, cost, or offline work matters. It is not automatically better for every task, and no consumer GPU changes that. Reach for a cloud model when:
- The task spans many files
- The bug is subtle and needs strong reasoning
- You need reliable tool calling
- The change will touch production
- You do not have time to review every generated line
The practical setup is local-first, not local-only. Run Qwen3 Coder or a 14B model on your RTX card for cheap private work, then escalate to a stronger cloud model when the task gets hard.
## How to route local and cloud together
- **[haimaker.ai](https://haimaker.ai)** — one endpoint that lets you run your local Ollama model for simple coding-agent work and fall back to frontier cloud models for the hard tasks, without juggling separate API keys
- **Ollama** — runs the local model on your RTX card with an OpenAI-compatible API on localhost
- **Your coding agent** — point OpenCode, OpenClaw, or any OpenAI-compatible agent at the local endpoint for cheap work and the cloud endpoint for everything else