In this second part, I want to take a hands-on approach and show how to get started with different options in the coding-agent ecosystem. I’ll begin with two practical decisions: how you want to interact with the coding agent and how you want to access the model behind it. I’ll present the available options in each case and then compare three different setups on the same task in terms of cost, quality, and speed.
You may already be familiar with some or all of the options presented here. But if you have only used tools such as OpenAI Codex or Claude Code, this article may still be useful in showing what other approaches are available.
1. Choosing the coding agent interface
First, let's talk about the coding agent interface or how we prefer to interact with the coding agent. These are the main interface styles available today, although many products now support more than one:
-
Terminal-first: coding agents that run from the command line. This is an environment many developers will feel at home with and is particularly well suited to automation, scripting, headless environments, and remote machines. Developers will usually rely on a separate editor or IDE for rich visual code inspection.

-
Integrated into the IDE/editor: agents that work directly inside a traditional development environment, either as a built-in feature or an extension. This approach works particularly well when you want the agent alongside the code you're actively inspecting and editing.
-
Standalone GUI: desktop applications organized primarily around agents, tasks, and sessions rather than files and an editor. They are particularly useful for delegating work and managing multiple tasks or agents in parallel.

-
Built into services: coding agents embedded into platforms such as GitHub for specific workflows, including code review and delegated coding tasks.
Above, I have presented the different interface styles available today, but choosing the interface is not the same as choosing a specific harness. The capabilities of different harnesses vary significantly. Some are tightly integrated with models from the same vendor and may be optimized to work particularly well together, while others are vendor-agnostic and allow you to switch between models from different providers.
The best choice depends on your priorities. A vendor-specific harness may offer a more integrated experience, while a vendor-agnostic one can provide more flexibility and reduce vendor lock-in. In the hands-on section, I will show examples of both vendor-specific and vendor-agnostic harnesses.
2. Choosing how to access the AI model
Once we choose our coding agent interface, we need to connect it to an AI model to actually use it. The harness sends our prompts and relevant context to the model, receives the model’s requested actions or tool calls, and executes them as part of the agentic loop.
These are the main choices we have when connecting an AI model to the harness:
- Vendor subscriptions: this is probably the simplest path for many users. AI providers commonly offer monthly or yearly plans that include access to their own chat products and agentic tools. For example, ChatGPT plans can include Codex usage, while Claude subscriptions can include access to Claude Code, subject to plan-specific usage limits. These subscriptions should not be confused with direct API access, which is usually billed separately.
- Agent/harness subscriptions: some coding-agent vendors bundle model usage into their own subscriptions. Cursor is a good example: its paid plans include usage pools for Cursor’s own models as well as third-party models from providers such as OpenAI, Anthropic, and Google.
- Direct API access: the coding agent is configured with credentials for the model provider’s API, and usage is generally billed according to the number and type of tokens consumed.
-
Router / multi-provider service: these services provide a single API through which models from multiple providers can be accessed. OpenRouter is a well-known example: a harness can use the same integration while switching between models from different providers through configuration. The main advantage is flexibility and reduced coupling to a single model provider.
- Some providers specialize in hosting open-weight models, offering API access to models that users could otherwise run locally themselves.
- Local models: we can also use local models in our harnesses. In this case, we download and run open-weight models ourselves on our own infrastructure, which can be as simple as a single consumer device. Once we expose the model through an API, we can connect coding agents in much the same way as commercial services.
3. Testing and comparing
Now it’s time for the hands-on section where I will test three different coding agent setups to perform the same task and compare their results in terms of quality, speed and cost. Please keep in mind that this is not a scientific test and evaluating quality can get quite subjective.
I chose the following three setups because I thought they would illustrate significantly different options available today:
- OpenAI Codex - this is probably the setup that, along with Claude Code, first comes to mind when people think about coding agents. Here, we will deal with a frontier-level AI model paired with the provider’s own harness.
- OpenCode with DeepSeek V4 Flash - this setup tests DeepSeek V4 Flash, which attracted considerable attention after its release because of its near-frontier capabilities and extremely aggressive pricing. As has increasingly been the case with Chinese models, it is open-weight, one aspect that clearly contrasts with American models. OpenCode was selected as the harness as the open-source alternative to closed-source harnesses.
- OpenCode with Qwen 3.8 27B running locally - Qwen 3.8 27B made headlines when it was released due to its good benchmark scores. This gives us another Chinese open-weight model, but this time one small enough that local inference on consumer hardware is much more realistic. This setup also illustrates OpenCode's flexibility in dealing with different AI models.
Since this is not a guide on how to run these tests, I won't provide detailed setup instructions; I'll only briefly describe the setup process.
Common prompt:
The three setups will be tested with the same prompt below:
Create the frontend for an e-commerce website specializing in products for babies and infants.
- For now, implement three fully working interfaces: a home page, a product details page, and a shopping cart page. Please also create the overall application structure, including elements such as the header, navigation, and footer, even if features outside these three interfaces are not functional.
- Create a realistic set of sample products, including names, descriptions, prices, images, and any other details you consider useful. There is no need to implement search, but please populate the website with enough content to give a good sense of what the finished product would look like. Include sections such as recommended products, products on sale, and any other sections you consider appropriate.
- You may choose the library or framework you consider most appropriate. Include clear and detailed instructions in
README.mdexplaining how to install dependencies and run the application locally. - Prioritize long-term maintainability, with a clear component structure, sensible separation of concerns, and reusable code where appropriate.
- Use a pastel color palette and aim for a polished, modern, family-friendly visual design.
- Make the interface responsive and suitable for both desktop and mobile devices.
Do not ask follow-up questions. Make reasonable assumptions where necessary and complete the implementation autonomously.
OpenAI Codex
I first tested the desktop app of OpenAI Codex. There wasn’t much to the setup process as it was a matter of installing the app and signing in to my account. Please note that I used my $20/month Plus plan for the tests.
I ran the task with GPT-5.6 Sol on High thinking effort and Codex took 29m 8s to complete it, and utilized 4% of my weekly quota. These were the generated home, product detail and shopping cart pages:



I thought the results were really good, with an aesthetic that matches the subject. I could not find any obvious issues in terms of the app layout and, although there were a couple of errors appearing in the web browser console, the navigation, "add to bag" logic and pricing calculation were all working as expected.
The screenshot below shows the technology stack used by Codex for the task. It's interesting that it even published the resulting app to OpenAI's infrastructure, so I can access it easily through the provided URL. Unfortunately, although the resulting app worked as expected when running locally, the published app had issues with page transitions not working.

OpenCode with DeepSeek V4 Flash
OpenCode's setup process was also very straightforward. In this case, I opted for the terminal version and it was just a matter of running the provided install script.
To test DeepSeek V4 Flash, I opted for OpenCode Go, its $10/month subscription-based service that gives access to different models, especially open-weight models, but some proprietary models such as GPT-5.6 Luna as well.
After opening the app, I ran /connect, selected "OpenCode Go" as the provider, and entered my API key. The model selection screen then appeared:

In my case, I chose the recently released experimental Vision version of DeepSeek V4 Flash, since it was announced that it retains the same performance as the original release. In the screenshot below, we can see OpenCode + DeepSeek working on the created Todo list:

I ran the task with High thinking effort and it took 20m 54s to complete. OpenCode shows that the task cost $0.05 (my subscription page shows 1% utilization of my weekly quota). These were the generated home, product detail and shopping cart pages:



In this case, there's no service to publish the resulting web site and, from my quick checks, I just found a small spacing issue in the product details page where there's no space between the product tags and the section below it. Otherwise, there were no errors in the console and the visual style suits the subject well. One noticeable difference between these two runs was that Codex appeared to generate its own vector graphics, while DeepSeek mostly relied on emojis for the product imagery.
This is subjective, but Codex's results seemed a bit more professional to me. That said, the navigation, "add to bag" logic and pricing calculation were all working as expected. The screenshot below shows the technology stack used by DeepSeek for the test, as well as OpenCode's statistics on token usage and cost.

OpenCode with Qwen 3.8 27B running locally
For the final test, I chose Qwen 3.8 27B, a recently released model that made the headlines for its excellent performance considering its size. Since it is an open-weight model, I decided to download and run it on my own PC.
The PC I used is far from being a powerhouse (it's quite old, actually), but it has a reasonable amount of VRAM due to its dual-GPU configuration: Radeon RX9060XT 16GB + GeForce RTX3060 12GB.
The first thing I did was to install LM Studio on my PC running Linux, then download and load the Qwen provided by LM Studio itself. I chose the Q4_K_M variant and set the context window to a little over 100K tokens, leaving enough VRAM available for inference.
The last step on my PC was to run the built-in API server that provides endpoints compatible with OpenAI and Anthropic APIs. I just configured it to serve my local network and to use an optional API key for authentication. Below is a screenshot showing the status of the API and the loaded model.
Then, in OpenCode on the device I was working on, I only needed to choose "LMStudio" as the provider and enter the API key I had configured previously. OpenCode can automatically discover models from a local LM Studio server on its default endpoint. Since I was connecting to LM Studio on another machine, I configured the target model manually in opencode.jsonc and also set the remote base URL. Please note that I also enabled websearch and webfetch, so models have access to these features (I also had to set an environment variable for this purpose: OPENCODE_ENABLE_EXA=1).
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"websearch": "allow",
"webfetch": "allow"
},
"provider": {
"lmstudio": {
"name": "LM Studio @ desktop",
"npm": "@ai-sdk/openai-compatible",
"options": {
"baseURL": "http://192.168.0.100:1234/v1",
"apiKey": "{env:LMSTUDIO_API_KEY}"
},
"models": {
"qwen/qwen3.8-27b": {
"name": "Qwen 3.8 27B @ desktop",
"modalities": {
"input": ["text", "image"],
"output": ["text"]
},
"variants": {
"none": {
"reasoningEffort": "none"
},
"low": {
"reasoningEffort": "low"
},
"medium": {
"reasoningEffort": "medium"
},
"xhigh": {
"reasoningEffort": "xhigh"
}
}
}
}
}
}
}
Having done so, I just prompted OpenCode the same way as the other tests and, below, is the todo list created by Qwen to achieve the given task.

I set the thinking level to Medium because I had read that Qwen tends to overthink at higher levels and OpenCode reported that the first run took around 6h 10m to complete. Since I had left it running overnight, I wasn’t completely confident that this value was representative, so I later ran a similar task with the same local setup. The second run completed in 1h 47m, suggesting that execution time can vary considerably between tasks and runs.
The second result was more in line with my expectations since the model had produced around 15-20 tokens per second in previous interactions. Even at the faster result, however, local inference was still substantially slower than the cloud-based setups in my tests. I would consider this speed impractical for interactive use, although it may still be acceptable for long-running agentic tasks.
These were the generated home, product detail and shopping cart pages:



I was pleasantly surprised by the generated results, which had a similar aesthetic to DeepSeek's output, with no obvious layout issues or errors in the browser console. It even generated SVG images for the products. One curious detail was that it chose the same site name as DeepSeek.
The screenshot below shows the token usage and also confirms that Qwen used React, just like the other models..

Summary of the results
| Setup | Time | Approx. cost/usage | Subjective quality |
|---|---|---|---|
| Codex | 29m 8s | 4% weekly quota | Best visual polish |
| OpenCode + DeepSeek V4 Flash | 20m 54s | $0.05 / 1% quota | Very good |
| OpenCode + local Qwen 3.8 27B | 1h 47m and 6h 10m in two different runs | Local compute | Surprisingly good |
These figures should be treated as observations from individual runs rather than benchmarks, especially since completion time can vary substantially between tasks and runs.
Conclusion
There is no single best way to get started with coding agents. The right setup depends on what you value most: convenience, model quality, flexibility, cost, privacy, or the ability to run everything locally.
In my small experiment, Codex provided the most polished overall experience and results, while OpenCode with DeepSeek V4 Flash showed how close a much cheaper alternative can get. The local Qwen setup was considerably slower on my hardware, but I was surprised by the quality it could achieve without relying on a cloud model at all.
More importantly, the tests reinforced one of the main ideas from Part 1: evaluating a coding agent is not just about evaluating the model. The harness, available tools, execution environment, model access method, and even hardware can significantly change the final experience.
The coding-agent ecosystem is evolving quickly, so the specific models, prices, and products discussed here will inevitably change. The broader choices, however—how we interact with the agent, which harness we use, and where the underlying model runs—are likely to remain useful ways of thinking about the available options.
References
OpenAI — Using Codex with your ChatGPT plan
https://help-lb.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
OpenCode — OpenCode Go
https://dev.opencode.ai/docs/go/
DeepSeek — DeepSeek-V4-Flash-Vision-Exp Release: Multimodal API Now Live
https://api-docs.deepseek.com/news/news260821/
HuggingFace — Qwen3.8-27B
https://huggingface.co/Qwen/Qwen3.8-27B
LM Studio — Run LM Studio as a local LLM API server
https://lmstudio.ai/docs/developer/core/server
OpenCode — Models / LM Studio integration
https://opencode.ai/v2/docs/models
OpenRouter — Quickstart / unified API
https://openrouter.ai/docs/quickstart
