A lab built around development questions
We started with a practical question: could a local model work across several files, respond to test failures and improve its own solution? We set up a separate research environment on our DGX Spark to explore this without touching live client systems.
Its 128 GB of unified memory gave us room to run a model with roughly 27 billion parameters in BF16, without further quantising its weights. We also wanted to explore tasks that take longer than a quick chat response. What could an agent finish if we gave it time to work, test and revise?
Connecting the model to development tools
Our later setup paired Qwen 3.8 27B on the Spark with OpenCode as the coding agent. SGLang served the model through an API. OpenCode used its responses to edit files, run tests and return the results for the next step.
Codex helped us coordinate and review the experiments. We combined local inference with other development tools, including cloud tools for the surrounding work. The coding comparisons used synthetic data and a defined scope, with no access to live client systems.
Three coding agents, one local model
An early trial put OpenCode, Codex CLI and Claude Code against the same tasks using the same local Qwen 3.6 model and a 65,536-token context window. Three tasks, repeated three times, gave us nine runs per agent. They covered data normalisation, linked SQLite and API behaviour, and an import that had to leave no partial changes after a failure.
All 27 runs passed the visible tests; 19 also passed our independent checks. Those examined behaviour such as preserving the original data after a failed import. They helped us distinguish solutions that worked beyond the normal success path.
| Coding agent | Visible tests passed | Independent checks passed |
|---|---|---|
| OpenCode | 9 of 9 runs | 7 of 9 runs |
| Codex CLI | 9 of 9 runs | 7 of 9 runs |
| Claude Code | 9 of 9 runs | 5 of 9 runs |
This compares coding agents using one local model, not OpenAI models against Anthropic models. Results apply to this internal task set, its tests and its permitted scope of work.
The models we tried
Our first model comparison covered Qwen 3.6, Gemma 4 and GPT-OSS 120B across the same three agents and tasks. These results belong to the tested configurations. They do not describe everything each model family could achieve with different settings or workloads.
| Model configuration | Full passes |
|---|---|
| Qwen 3.6 · Q4_K_M | 19 of 27 runs |
| Gemma 4 26B A4B IT · Q4_K_M | 10 of 27 runs |
| GPT-OSS 120B · MXFP4 | 7 of 27 runs |
Internal coding tasks with visible tests and independent verification. Architecture, precision and agent compatibility all differ; these figures do not isolate any one of those factors.
- Qwen 3.6: comparing two precision levels
- With OpenCode, Q4 and Q8 both achieved seven full passes out of nine runs. Q8 took roughly 63% longer on average. The extra precision did not improve the results for these tasks.
- Qwen 3.8 27B: our choice for the next experiments
- Qwen 3.8 with BF16 weights became our preferred model for OpenCode trials. Seven of nine initial Ollama runs passed; two reached the time limit. An additional attempt without that limit completed the demanding import task and passed the independent checks.
From Ollama to controlled SGLang profiles
Ollama let us connect local models and start running coding tasks. SGLang then gave us more control over context length, memory allocation and the processing of large inputs. We ran the model server in Docker and kept separate configurations for different experiments.
This let us work with both the native 262,144-token context window and an experimental extension to one million tokens. Our focus was on individual, substantial tasks rather than throughput under concurrent load.
A 300,000-token input and a two-hour coding task
Given a synthetic input of 300,090 tokens, the model successfully retrieved information from the beginning, middle and end in roughly nine minutes. That demonstrated retrieval from this substantial input; comprehensive evaluation of the million-token context is still ahead of us.
On a demanding coding task involving data revisions and consistent API updates, the agent worked for just over two hours. It then passed all seven visible and six independent tests. An earlier run with a smaller output budget had not reached implementation. That gives us a useful direction for further experiments: allowing extended tasks enough room for analysis, tool use and revision.
Pocket Universe: a sentence becomes a world you can explore
Pocket Universe was a more open-ended experiment: describe a world in a sentence and explore it as an interactive particle landscape in the browser. Users can change time and gravity or influence movement with a mouse or touch. A verbal idea becomes something they can play with.
Qwen wrote the application through OpenCode; Codex helped coordinate and review the development work. In the resulting application, the language model has a narrower role: it returns a structured description of a world. The application validates that data and renders it through its own Canvas engine. It does not execute model responses as code.
The research prototype brings AI, interaction design and visualisation into one application. Automated tests and our review also identified areas that need further work. It gives us a practical way to explore how a language model can work within a purpose-built interface.
Next: connecting models to other systems
We plan to add a gateway for access to different models and a queue for longer jobs. These planned additions will let us investigate how applications can hand tasks to local models and process the results, for example when preparing documents or running background workflows. They extend our model trials into application integration.
How the research informs client work
Our August 2026 work ranged from model comparisons to an interactive prototype. We are continuing that R&D with our own tasks, different tools and independent checks of what they actually produce.
That experience informs the AI features we develop for websites, portals and business applications. We can evaluate models against relevant tasks, bring checked output into an interface and connect the processing to existing systems. Whether it runs locally, through a cloud service or across both depends on the project.
Our DGX Spark gives us a place to run extended experiments with local AI and check the results independently. That hands-on work informs the way we choose models, connect tools and develop AI features for applications.