Qwen3.8-27B and Pi: A Local LLM Agent at Work

Local AI has been interesting for years. It is private, controllable, independent from APIs and technically fascinating. Until recently, however, that was mostly what it remained, at least in my experience: interesting.

You could talk to a model, ask it for a function, have it analyze a document or generate a piece of code. But when you tried to give it real work — read a repository, understand its conventions, change multiple files, run tests, correct errors and produce a coherent patch — the distance from frontier models became obvious.

With Qwen3.8-27B, I started to perceive something different. Not parity with the best commercial models, because that gap still exists. What changed was the threshold: for the first time, I could assign an important task to a local model and let it implement the substantial part of the solution.

The test was not a benchmark. It was our own website, www.xseven.it.

The hardware: ASUS Ascent GX10

We ran Qwen3.8-27B on an ASUS Ascent GX10, a compact workstation based on NVIDIA's GB10 Grace Blackwell Superchip with 128 GB of unified memory. It is not a traditional server GPU and does not compete with a cluster of accelerators, but it puts enough memory on a desk to run models that, until recently, would have required much less accessible infrastructure.

ASUS positions it as a platform for local inference, fine-tuning and agents, built around a coherent CPU-GPU memory architecture. Its declared specifications are available on the official ASUS Ascent GX10 page.

For inference, I used LM Studio, which makes it easy to download models, manage quantizations and expose a local endpoint compatible with APIs commonly used by AI tools. The llama.cpp ecosystem sits beneath that convenience, but the everyday experience is much closer to using a ready-made service.

LM Studio was the engine. The agent, however, made the real difference.

The model had not changed. Its body had

To use Qwen3.8-27B as a coding agent, I chose Pi. Pi can connect to local models served through LM Studio, vLLM, SGLang and other compatible endpoints. It can read a repository, search files, edit code, execute commands, observe errors and continue working from the result.

That shift radically changed my perception of the model. In a chat, an LLM is confined to the quality of a single answer. As an agent, it can build a sequence: read the project's instructions, explore the code, form a hypothesis, apply a patch, run the tests, inspect the error and try again.

Qwen had not suddenly become more intelligent. It had gained an environment in which its intelligence could turn into work.

This distinction matters. When we evaluate a model, we tend to separate it from the system around it. A coding agent, however, is the result of at least three elements: the model, the context it receives and the operational loop through which it can act and receive feedback. Changing the agent can therefore radically change the usefulness of the same LLM.

Real work on xseven.it

The task assigned to Qwen concerned some residual issues in our website migration toward Astro and a Git-based CMS, together with accessibility fixes. This was not an isolated page generation exercise. The model had to understand a hybrid codebase where Astro pages, collection-driven content and some legacy HTML pages coexist. It also had to preserve indexed public URLs, Italian and English versions, the sitemap, build rules and accessibility requirements.

Qwen worked mainly on three problems.

The first was an insufficient focus ring that remained on the Terms page. A minified CSS variant, rgba(65,208,52,.85), had survived earlier checks because the scans were looking for a slightly different syntax. The model found the residual value, replaced it with a double white-and-black ring and extended the checks so that both forms would be detected.

The second change concerned the CMS page translation field. Qwen created an explicit contract: its value must be a local path shaped as /it|en/<slug>.html. External URLs, protocols, query strings, fragments, path traversal and non-conforming values are rejected.

It did not stop at syntax. It added validation across content entries: a translation must target the opposite language, the destination must exist and the relationship must be reciprocal. If an Italian page points to an English page that does not exist, or if the English page does not point back, the build fails. It also wrote 38 test cases, including a range of invalid inputs.

The third change involved mobile keyboard navigation. Menu behavior was duplicated between Astro pages and CMS-generated pages, creating a risk that the two implementations would diverge. Qwen extracted the script into a single shared source.

The new behavior moves focus to the close button when the menu opens, contains Tab and Shift+Tab inside the panel, closes the menu with Escape, returns focus to the hamburger button and keeps aria-expanded and aria-hidden synchronized. Qwen accompanied the implementation with 18 jsdom-based DOM tests.

This is the most significant point for me: the substantial implementation was produced by Qwen3.8-27B running locally. It was not a carefully prepared example designed to flatter the model, but a cross-cutting change to a real repository.

Where Codex stepped in

Once the work was complete, I submitted it to Codex for a second review. Codex did not rewrite Qwen's implementation. It found subtler issues, mostly around reproducibility and what it means to close the task properly.

Qwen had written the jsdom tests, but their dependencies were not declared in the project. The tests worked in the development environment where they had been created, but they would not necessarily work after a clean installation or inside the build container.

The test scripts were also excluded from the main TypeScript check, and the normal npm run build command did not run them. Good tests existed, but they were not yet a real pipeline gate.

Codex declared jsdom and its types as development dependencies, added a dedicated TypeScript configuration for the scripts and integrated type-checking and tests into the build command. It then validated the complete process from a clean installation.

It also found a nuance in focus management. The original implementation brought focus back inside the menu when a new Tab event arrived. That covered ordinary keyboard navigation, but it did not prevent a script or another action from temporarily moving focus behind the overlay. Codex added a focusin listener that remains active while the menu is open. Focus is now returned to the panel immediately, without waiting for another key press.

The final result went through 56 tests, the Astro build, a Docker build with Node 22 and Nginx, generated-output audits, hash comparisons between the local build and the pods, real Chrome testing, and validation in both testing and production.

Qwen versus Codex: more than "strong" and "weak"

This experiment does not prove that Qwen3.8-27B is equivalent to Codex or other frontier models. That would be too convenient a conclusion. It does show an interesting division of labor.

Qwen solved the main problem. It understood the repository, designed a shared solution, modified multiple components, built translation validation and wrote a meaningful test suite.

Codex focused more heavily on the boundary between "it works here" and "it is reproducible everywhere." It examined the pipeline, the clean installation, type-checking and a focus edge case that the initial implementation did not close completely.

Qwen built the feature. Codex made it harder to declare the feature complete before it truly was.

This is also a concrete demonstration of cross-review between models. Not because one model should be the absolute judge of another, but because different systems tend to leave different errors uncovered.

In this case, the main credit remains with the local model. The frontier model supervised, challenged and completed the work. The implementation itself was born on the GX10, without sending the repository to an external provider. For me, that deserves real recognition.

Why Qwen3.8-27B is so slow

Now we reach its most obvious limitation: Qwen3.8-27B is slow.

According to the official model card, it is a dense 27-billion-parameter model with 64 layers and a native context window of up to 262,144 tokens.

In simplified terms, "dense" means that the whole model is involved in producing every token. A Mixture of Experts model may contain many more total parameters while activating only a subset for each token. A 35-billion-parameter model with 3 billion active parameters can therefore require much less work per token than a dense 27B model.

Qwen3.8-27B has to move through all its parameters, token after token. During interactive generation, the limit is not only the GPU's advertised mathematical capacity. The speed at which the weights can be read from memory and delivered to the compute units matters enormously.

Quantization reduces the model's footprint and memory traffic, but it does not remove the problem. A coding agent also amplifies perceived slowness. Every task contains several cycles: the model reads context, chooses a tool, receives its output, updates its reasoning and generates the next action. One task may therefore require many consecutive inference calls.

Reasoning also has a very concrete cost. The more the model reasons and produces intermediate tokens, the longer we wait. It is not merely time spent "thinking." Those tokens must actually be computed. The result is a capable agent, but one that requires patience.

Could SGLang and vLLM improve it?

LM Studio is extremely convenient and remains one of my preferred ways to experiment. Convenience and maximum efficiency, however, are not necessarily the same thing.

Runtimes such as vLLM and SGLang are specifically designed to serve models while using GPU and memory resources more efficiently. vLLM uses techniques such as PagedAttention to manage token caches in blocks, reducing fragmentation and waste. It also supports continuous batching and prefix caching. SGLang uses RadixAttention to reuse previously processed sections of context and combines scheduling, caching and inference-oriented kernels.

These optimizations are particularly relevant to a coding agent. The system prompt, repository instructions and part of the conversation are repeated between steps. If the runtime can effectively reuse the KV cache for that prefix, it can avoid processing the complete previous context every time.

This does not mean that moving to vLLM or SGLang will automatically make the model two or three times faster. In a single-user session, optimizations designed for many concurrent requests have less impact. Generating every new token remains constrained by the cost of the dense model and available memory bandwidth.

A real benchmark on the GX10 is therefore necessary. I believe this is the next step: keep Pi as the agent, replace the inference engine and separately measure prefill time, tokens per second, cache hits, tool-call latency and total task duration.

The meaning of local AI is changing

For years, we have said that local models offer privacy, independence and control. That was true, but it often meant accepting capabilities too limited for important work. The gap is now starting to narrow.

It has not disappeared. Frontier models remain substantially stronger in many scenarios. They preserve context more reliably, find adjacent problems more often, run faster, are easier to steer and are generally more dependable across long workflows. But "inferior" no longer necessarily means "useless for serious work."

With Qwen3.8-27B, we assigned a real change to a local agent, had a second model review it and took the result to production. That changes the nature of the discussion. We are no longer talking only about theoretical privacy or digital sovereignty as an aspiration. We are starting to talk about work that can actually be performed locally.

China and the open-weight window

The contribution of Chinese laboratories to this shift is difficult to ignore. Qwen and DeepSeek have released increasingly competitive open-weight models, often under licenses suitable for commercial contexts. Qwen3.8-27B, for example, is distributed under the Apache 2.0 license.

They are not the only contributors. Meta, Mistral, Google, NVIDIA and other Western organizations have released important weights and technologies. It would therefore be inaccurate to claim that the entire open-weight ecosystem exists only because of China.

Today, however, Chinese competition is one of the strongest forces preventing advanced AI from becoming exclusively a closed service available under the rules of a few large US providers. The pressure created by Qwen and DeepSeek forces the whole market to contend with models that can be downloaded, modified and executed on privately controlled infrastructure.

We do not know how long this window will remain open. Export rules, geopolitical tensions, training costs, license restrictions or ordinary commercial decisions could change the picture quickly. A model available today may not receive an equally open successor tomorrow.

That is precisely why I believe this is the time to experiment seriously, build internal knowledge and learn how to govern these systems while the opportunity exists.

Conclusion: not independent yet, but no longer standing still

Qwen3.8-27B does not replace frontier models. It is slower, it makes mistakes and it still needs supervision. In this experiment, Codex found problems that the local model had not closed on its own.

But that is not a failure. It is the normal operation of an engineering process. Code written by a person is also reviewed, tested and corrected. The right question is not whether Qwen produces the same result as the best commercial model on its first attempt. The question is whether it can take responsibility for a substantial part of the work, produce something valid and reach production through a controlled process.

In this case, the answer is yes.

We remain far from complete independence from big tech. Hardware, frameworks, toolchains and research are still part of a global network of dependencies. But running an open-weight model locally, giving it access to our repository and obtaining a real implementation is already a concrete form of technical freedom.

We do not know how long this opportunity will last. For now, however, it has become serious enough to deserve more than a weekend experiment. It has become part of how we work.