Local model or Claude for vibe coding: what Qwen3.8-27B reaches on one RTX PRO card

How close local models come when you build apps

For building web apps and internal tools from prompts, Qwen3.8-27B, Qwen's newest dense model and one that fits a single workstation card, comes close to the Claude Opus models it is compared with on Qwen's own agentic coding benchmarks: ahead on some, behind on others. Anthropic has released newer models since, and no published table we found compares them with Qwen3.8 on the same setup. A local model is good enough for many apps if it is of the 27B class or larger and runs with 64K to 128K tokens of context; whether it is good enough for yours, a test with your own prompts shows in an afternoon.

This article is for the person who decides before buying hardware: the head of a studio or an agency, a product owner, an IT lead who wants app building without sending code and data to a cloud tool. The tools themselves are compared in our guide to self-hosted Lovable alternatives, and the hardware kits in our guide to the vibe coding workstation. For business answers rather than code, our comparison of local LLMs and ChatGPT covers the quality question.

The question matters because of what leaves the building. A cloud model processes each prompt, together with the files the tool sends along, on the provider's infrastructure; Lovable's documentation, for example, lists EU inference for AI model requests among its governance features. With a local model served by Ollama on your workstation, prompts, files and answers stay on that machine, provided Ollama's cloud models are switched off with OLLAMA_NO_CLOUD=1, as its FAQ describes; the open question is quality.

The published scores side by side

Two of Qwen's model cards compare its open models with a Claude model. The Qwen3.8-27B card of August 2026 uses Claude Opus 4.6 at its maximum setting.

Qwen3.8-27B model card on Hugging Face, read on 30 October 2026. SWE-bench Pro: Opus 4.6 Max "uses the officially reported score"; the other models were run in the Claude Code harness at temperature 1.0, top_p 0.95 and a 256K context, on a refined task set.

The Qwen3.6-27B card of April 2026 compares with Claude 4.5 Opus and adds QwenWebBench, Qwen's internal benchmark for front-end generation, which comes closest to what an app builder does.

Qwen3.6-27B model card on Hugging Face, read on 30 October 2026. SWE-bench on Qwen's internal agent scaffold with bash and file-edit tools and a 200K context; Terminal-Bench 2.0 in the Harbor/Terminus-2 harness, averaged over five runs; QwenWebBench rated by a multimodal judge on an Elo scale.

The benchmarks measure different work. SWE-bench, by its own site, uses "real GitHub issues from 12 Python repositories" and reports the percentage of tasks solved; Verified is "a human-filtered subset" of it. Terminal Bench runs agent tasks in a terminal environment, in Qwen's April runs with a three-hour timeout. QwenWebBench renders the generated front ends and has a multimodal model judge them, in English and Chinese; it is an internal Qwen benchmark. The tables also show that the setup matters: Qwen's own April run gives Claude 4.5 Opus 57.1 on SWE-bench Pro, while the officially reported score that Qwen quotes in August for the newer Opus 4.6 Max is 53.4.

The comparison models are no longer Anthropic's newest. Its model overview, read on 30 October 2026, lists Claude Opus 5.5, Claude Sonnet 5.5, Claude Haiku 5.5 and Claude Fable 5.1 as the current models and recommends to "start with Claude Opus 5.5 for most workloads". We found no published table that runs those models and Qwen3.8-27B on the same benchmark with the same harness.

A 1T-class open coding model gives a second reference. Moonshot's card for Kimi K2.7-Code, a model with 1T parameters and 32B active per token, compares it with Claude Opus 4.8, run in Claude Code, and GPT-5.5, run in Codex, both at the xhigh effort setting. On Kimi Code Bench v2, Moonshot's in-house benchmark for coding agents across backend, infrastructure, security and front-end tasks, Kimi K2.7-Code scores 62.0, Claude Opus 4.8 67.4 and GPT-5.5 69.0; on Program Bench, where agents rebuild a program from its compiled binary and documentation, 53.6, 63.8 and 69.1. On these two benchmarks of its maker's own table, the open model, which needs a server with eight GPUs, trails both cloud models.

Where local setups fail first

Most of the failures that the tools' own documentation describes come from configuration, and each has a known fix.

• Context too short. Ollama asks for "at least 64000 tokens" for coding tools in its announcement of 23 January 2026. The OpenHands guide warns that 4,096 tokens are too small for its system prompt and that the agent will not behave correctly; Ollama's own default is 4K only below 24 GiB of GPU memory and 32K or 256K above, so set the context explicitly.
• No tool calls. The OpenHands guide states that when the agent acts like a plain chatbot, refuses to use tools or files, or keeps failing tool calls, the model may be the cause, and that some local models struggle with reliable tool use even with a large context window.
• Small models. Dyad's guide of 4 February 2026 warns that "Smaller models (under 7B parameters) often struggle to follow structured output formats", which app builders depend on to write files.
• Sampling settings. Qwen's cards give their own values for thinking mode: temperature 1.0, top_p 0.95 and top_k 20 for general tasks, and temperature 0.6 for precise coding such as web development in the Qwen3.6 card. A tool that sends other values gets other results.
• Thinking time. Qwen3.8-27B reasons at its highest effort by default; the model card offers medium and low settings for faster answers.

Quantisation matters less than these points on NVIDIA's own figure: its card for the NVFP4 build of Qwen3.8-27B lists 74.02 on Terminal-Bench against 75.56 for BF16. That figure is for NVIDIA's format; we found no comparable published figure for the 4-bit files Ollama uses.

You can order the workstation alone, the setup of Ollama, Qwen3.8-27B and Dyad or OpenHands alone, with the context length and sampling values above, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Quality by memory step

More memory buys a larger or more precise model and more sessions, the agent conversations held at once. The table follows our users-per-card rule, 90 per cent of driver-visible memory less 3 GiB per card, as explained in our guide to how many users one RTX PRO 6000 serves, with Ollama's default 16-bit cache.

Our estimates by the users-per-card rule, not measurements; weights from Ollama's library and Hugging Face file lists, read on 30 October 2026; Kimi K2.7-Code from our eight-card guide (decode context parallelism, an upper bound by our estimate). The RTX PRO 6000 Workstation Edition has the same 96 GB as the Max-Q and gives the same counts.

The first tier is where a local model starts to make sense for agents. On a 24 GB card our rule leaves 18.5 GiB, too little for a 64K session beside Qwen3.8-27B at 4-bit; gpt-oss-20b, which Ollama names for coding tools, fits with three such sessions, but none of the vendor tables we opened compares it with Claude. On the second tier the same 27B model runs at 8-bit with room for several makers.

The third tier changes the model class, and a larger parameter count does not by itself mean higher scores. Qwen3-Coder-Next, a mixture-of-experts (MoE) model with 80B parameters and 3B active, and gpt-oss-120b, both under Apache 2.0, are older than Qwen3.8-27B, and we found no table that compares them with it. Qwen3.8-Flash-Next, published in August 2026 with 125B parameters and 6B active, is the exception: Qwen's own table puts it ahead of Qwen3.8-27B and Claude Opus 4.6 (Max) on SWE-bench Pro, 62.5 against 61.7 and 53.4, and NVIDIA's NVFP4 build fits two 96 GB cards by our rule with its 51B n-gram table in host memory, as our Qwen3.8-Flash-Next guide explains. NVIDIA has tested that build only on B200 and B300, and its Qwen Community License 1.0 asks companies that run a Model as a Service or AI Work Assistant business for a separate licence, internal use excepted. What the 96 GB card buys for certain is room: Qwen3.8-27B in 16-bit with three sessions of 128K, Qwen3-Coder-Next in FP8 with five of 64K, or both models side by side on two cards. The fourth tier is a server: Kimi K2.7-Code is 595.2 GB in INT4 and needs eight RTX PRO 6000 Server Edition cards, as our guide to Kimi K2.7-Code on eight Server Edition cards shows. Its Modified MIT licence asks commercial products or services with "more than 100 million monthly active users, or more than 20 million US dollars (or equivalent in other currencies) in monthly revenue" to display "Kimi K2.7 Code" prominently in the user interface. For 20 to 100 developers the server for coding agents is the sizing guide.

Tell us how many people build and which tools they use, and our team suggests the tier that fits your budget.

Speed against quality

A fast model gives more correction rounds per hour, and with vibe coding the rounds are the work. The 35B-A3B MoE model computes about 3B of its 35B parameters per token, so by our arithmetic it answers several times faster than a dense 27B model, which reads all of its weights for every token.

Set against the scores, the faster MoE model scores lower: 73.4 against 77.2 on SWE-bench Verified and 1,397 against 1,487 on QwenWebBench in Qwen's table. For changing a layout, a colour or a form field, the fast model keeps you in the loop; for a feature across several files or a bug that needs reasoning, the 27B dense model is the better choice. Thinking multiplies the tokens per answer, so the reasoning effort setting in Qwen3.8-27B is a speed control as well. Our article on speculative decoding explains how multi-token prediction and draft models raise speed for one user.

An afternoon test with your own app prompt

Published scores give a range; your own prompts decide. The test below takes an afternoon on one workstation.

1. Choose three real tasks: a small new app from a description (for example a form, a list and an export), a change to an existing project (a new field and a filter), and a bug from your backlog. Use only data your policy allows outside the company if you also run the tasks in a cloud tool.
2. Set up Ollama 0.35.0 or later with a context of 64K to 128K, Qwen3.8-27B and Qwen3.6-35B-A3B, Qwen's recommended sampling values and the builder you plan to use: Dyad or OpenHands, or bolt.diy for the trial only, since StackBlitz's WebContainers licence exempts prototypes but not daily use in a company.
3. Run each task with each model and note whether the app starts without manual edits, how many correction rounds it takes until it works, the time to a working preview, whether the project files build, and how many tool calls failed.
4. Run the same tasks in the cloud tool your team knows, where your policy allows it, and compare the same notes.
5. If the 27B model solves most tasks with a few corrections, a workstation covers your work. Tasks that only the cloud tool solves show where the gap is for you.

Keep the three tasks and the notes: they become the test set for the next model, as our guide to LLM evaluation before model upgrades describes. Terminal agents such as Claude Code with a local model are covered in our guide to Claude Code with a local model. Before an app built this way goes live, our security checks for vibe-coded apps list what to test.

For exactly this test, send us the kind of apps you build and we suggest the configuration for your team and budget.

FAQ