Can you share the model config? If you're getting bad results it might be due to missing thinking config.

👋🏼 I really appreciate the kind words about Coder and your feedback around our direction! This helps make the Coder project better and we've circulated the thread around internally a lot :)

I wanted to share some of our rationale for the Tasks-to-Agents migration and what this means for Coder. The TLDR here is we will never force users to use our harness (Agents) and we are actively working to make Coder work better with any harness (improved lifecycle, support for Cursor self-hosted workers in Cursor, etc). We just didn't believe Tasks was the answer and we also believe that we can do something unique with Agents.

We originally built Tasks because we originally didn't want to build with/compete with another harness and really enjoyed Claude Code, Codex, opencode, etc and were optimistic that over time they would become easier to integrate with. Because these harnesses lacked clear APIs at the time, we built https://github.com/coder/agentapi as a stopgap and a translation layer which basically scraped the stdout (and placed things in stdin) in order to provide a UI and API for communicating with Agents.

Needless to say for anybody who has used it, the UX and architecture of Tasks/AgentAPI was pretty bad and we were never able to fully iron out the bugs. The harnesses would (rightfully) release new features and they would either be unsupported, or break the Tasks integration altogether. It felt very similar to the early days of Coder v1 when we only had hardcoded support for Kubernetes and we had to change our product any time a user needed access to a new/different Kubernetes feature or any other type of compute (Windows, EC2, etc). After a couple of years of pain, we wrote Coder (v2, the Coder we know today) which uses Terraform to let users define their own infra requirements.

While there are cleaner protocols than AgentAPI (like ACP), we still decided that trying to be a "harness wrapping another harness" (which is what I effectively consider Tasks to be) means that we are still giving our users little control over which harness features they can use. For example, a new Claude Code feature (dynamic workflows) may not be available in our API (or in ACP) therefore limiting the benefits of running the harness in Tasks versus standalone. Even if the harnesses were different, because only a subset of features are supported, it'd often appear functionally the same.

It took us a few projects/experiments to land on this conclusion, including the likes of Tasks, Mux, and Blink, as well as the feedback we've gotten from our users and enterprise customers. Most of the feedback we got on Tasks is: "this is great, but the UI/lifecycle is buggy," or "API support and integrations is key for us," and the feedback we got on Mux was "the UI/UX is smooth, but we need it deeply integrated into Coder," which is where Agents came from. We also learned a lot around what it takes to build a harness, and helped us develop the belief that very little "magic" belongs in the harness layer.

Therefore, our strategy is threefold:

1. Support any CLI/IDE harness to run inside Coder (supported today, little work needed). You basically install claude-code in your workspace or use our (recently refactored) modules. That way, you get all of the support of the harness with no middle-layer. This may sound basic but I believe running Claude Code CLI inside Coder is way better than running it outside Coder on local laptops 🤓
2. [Coder Agents] Build a first-class harness into Coder: Agents. It may lack the full feature-set of the flagship harnesses (hooks, memory, etc) or be a month or two behind in that support but has a clean UI, API, avoids LLM provider lock-in, and most importantly, allows us (and our users) to demonstrate a full agentic workflow with Coder Workspaces as the infrastructure/background compute layer. For the longest time, we were "locked out" of being able to demo the power of Coder in agentic workflows due to the lack of harness support for background compute and self-hosted runners. We also believe a lot of the power of any given harness comes from the underlying LLM/model and Coder Agents can still be used as a powerful frontend or API for background workflows in Coder.
3. [New] Integrate/partner with existing harnesses (e.g. Claude Code Web, Codex, Cursor Cloud Agents) that are seperating the logic layer from the sandbox/runtime layer and ensure Coder Workspaces provides the best infrastructure layer for any harness. For example, Cursor Cloud Agents has support for Self-Hosted Workers and we're actively working on an integration to ensure this works well with Coder (and the corresponding workspace/session lifecycle).

The third one is new for us, but it is in progress and (frankly) the core lifecycle of Workspaces regardless of the harness does need to be revisited with agentic workflows in mind. I believe workspaces need to be faster to start up, context-aware of the agentic processes running in them, spin down when not in use, and preserve/replicate context on-demand, all regardless of the harness being used.

I'm personally optimistic we can find a "SSH" or "Terraform" of harness<>compute interactions so Coder can support any harness just like we support any IDE or any compute provider, but even without that we're working towards integrating with the harnesses that do support remote/self-hosted runners.