senn-tech
AI & Development
AI & Development2026-07-25· By Franz Senn

Coding Tools for Windows: Claude Code, OpenCode, Codex, Cursor, and Orca Put to the Test

Anyone writing code today no longer does so alone. Claude Code, OpenCode, Codex, Cursor, and Orca all promise the same thing—faster, better development with less effort. After a year of daily use of all five on a Windows-on-ARM64 machine (Snapdragon X2, Win11 24H2), here’s my honest comparison: What really works, what’s annoying, and which tool should I use for what?

A Coding Agent’s Toolchain on WindowsTerminalPowerShell / WSLAgentModel + ToolsFile SystemRepo AccessGitCommit, Branch
The bottleneck on Windows is almost always at the shell level, not the model. (Quelle: senn-tech, in-house use)

The Candidates at a Glance

ToolTypeLicenseGitHub StarsNative ARM64?
Claude CodeTerminal agentApache 2.0139kNo
OpenCodeTerminal / Desktop / VS CodeMIT190kNo (workaround)
CodexTerminal / Desktop / VS CodeApache 2.0101kYes
CursorIDE (VS Code fork)Commercial~190kYes
OrcaMulti-agent orchestratorProprietary28.7kYes

Then there’s Z.AI Coder (formerly ZCode), which I used to use—it’s now legacy and serves only as a central configuration source for MCP servers and skills. I’m leaving it out of this comparison.

Windows in Particular: ARM64 Is the Bottleneck

The Snapdragon X2 is fast, but the toolchain isn’t fully mature yet. Node.js runs natively on ARM64, but as soon as a tool relies on Bun with TinyCC-FFI, it crashes. This primarily affects OpenCode: The ARM64 build fails due to bun:ffi—the TUI doesn’t render, and the terminal remains black.

The workaround: Download the x64 build, check the PE headers (byte at offset e_lfanew+4 = 0x8664 for x64, 0xAA64 for ARM64) and overwrite the binaries in %APPDATA%\npm\node_modules\opencode-ai\ with the x64 version. This must be repeated after every npm update—the updater pulls the broken ARM64 build.

Claude Code, on the other hand, runs without issues under x64 emulation because it doesn’t use Bun. Codex is the only option that ships natively as an ARM64 binary (Rust codebase, codex-rs) — you can tell by its startup time and memory usage. Orca and Cursor come with their own installers and also run natively.

The Models — What’s Behind Them?

It’s not just the shell that matters, but the model that writes the code:

  • Claude Code uses exclusively Anthropic’s Claude models (Opus, Sonnet)—no “bring-your-own-provider” option. In return, the code quality is consistently high, and its understanding of tools (shell, Git, file system) is the most mature in the test.
  • OpenCode is provider-agnostic: 75+ providers via Models.dev, including local models. The “Zen” models are free and validated. I use it via OmniRoute (local gateway at localhost:20128) with the auto/best-free model—it works without an API key.
  • Codex is tied to OpenAI but is included in the ChatGPT Plus/Pro subscription. Alternatively, you can integrate your own API key or a self-hosted provider—this also runs via OmniRoute with wire_api="responses" (the old "chat" mode has been removed).
  • Cursor offers a model router: Auto, GPT-5.6, Opus 5, Gemini 3.1, Grok 4.5 — select automatically or manually. Bring-your-own-key is possible, but the full feature set (Cloud Agents, Automations) requires the Pro subscription ($20/month).
  • Orca is not an agent, but an orchestrator—it runs Claude Code, Codex, OpenCode, and 20+ others as subprocesses. Which model is used depends on the specific agent.

Terminal vs. IDE: Where Do You Actually Write Code?

That’s the real dividing line—and it depends on the use case.

Terminal-first: Claude Code, OpenCode, Codex. All three launch in the PowerShell or WSL terminal. The advantage: They’re available everywhere, even via SSH on remote servers. Claude Code is installed on 24 internal Homelab targets—if I need to tweak a config on a Proxmox host, I type claude and it understands the context immediately. Codex starts up faster, while OpenCode is more flexible when it comes to models.

IDE-first: Cursor. Cursor completely replaces VS Code—it’s a fork with deeply integrated AI. Composer 2.5 schedules tasks, breaks features down into subtasks, and executes them in parallel. Cloud Agents run autonomously for hours on end. That’s impressive, but it’s overkill for my day-to-day work (homelab ops, shell scripting, quick web edits). Anyone who works all day on a large codebase will love Cursor. Anyone who jumps between 20 SSH targets probably won’t.

The Hybrid: VS Code + Extensions. In practice, I use VS Code with the OpenCode extension and the Claude Code extension. This gives me the familiar interface with agent support right in the editor. No switching tools, no loss of context.

Orca: The Hidden Gem for Parallel Work

Orca breaks the mold because it’s not a coding agent, but an Agent Development Environment. Imagine having four branches open at the same time, each with its own agent—and all working in isolation within Git worktrees, without messing up each other’s files.

That’s the killer feature. I launch Orca in the morning and open three worktrees: one for a blog feature (Claude Code), one for a NIS2 compliance refactoring (OpenCode), and one for a bug fix (Codex). All three run in parallel. Orca’s terminal emulation is Ghostty-inspired and smooth, the built-in file editor replaces VS Code for quick changes, and the mobile app shows me the agent status when I’m on the go.

The downside: another layer of complexity. Orca occasionally crashes (agent daemon “session not found” error—harmless but annoying), and window management on Windows isn’t yet up to macOS standards. For multi-agent workflows, however, there’s nothing better.

Specific Recommendation: Which Tool for What?

After a year of practical use, the following breakdown has proven effective:

ScenarioBest ToolWhy
Quick code changes in VS CodeOpenCodeFree, good enough, runs right in the editor
In-depth understanding of the codebaseClaude CodeBest context recognition and tool utilization
Remote SSH home lab opsClaude CodeDeployed on all 24 machines, reliable
Parallel BranchesOrca + any agentIsolated worktrees, no risk of merge conflicts
Native ARM64 PerformanceCodexOnly native ARM64 build, fastest startup
Zero-Cost OperationOpenCode (Zen)Free plans, no subscription required
All-Day IDE WorkCursorFully integrated, cloud agents, Slack bot
Mobile MonitoringOrca Companion AppAgent status, terminal access from your phone

My daily stack: VS Code + OpenCode extension (OmniRoute auto/best-free) as my primary combination. For complex remote work, I switch to Claude Code in the terminal. Orca comes into play when multiple features are running in parallel. Codex is the backup solution when Claude or OpenCode quotas are exhausted.

The Elephant in the Room: OpenCode vs. ARM64

OpenCode is the best tool in the test—open source, provider-agnostic, huge community. But it doesn’t run natively on ARM64 Windows. The workaround involving swapping x64 binaries works, but it requires constant maintenance. Every npm update overwrites the fix. Eventually, this will either be fixed, or Codex will catch up.

Until then: Use OpenCode for anything that isn’t time-sensitive. Use Codex when speed is essential. Use Claude Code when things get complex.

Conclusion

There isn’t one tool that does it all. The landscape is fragmenting into specialists: Claude Code for depth, OpenCode for flexibility, Codex for speed, Cursor for integration, Orca for orchestration. On a Windows ARM64 machine, native support is still the limiting factor—Codex wins here, OpenCode loses (for now).

If you only want to install one: OpenCode (because it’s free, open-source, and the ARM64 fix is doable). If you’re willing to pay: Claude Code (because it just works and causes the least hassle). If you want the full package: Orca, which includes all three agents.

One thing is certain: No one seriously writes code without an AI agent these days. The only question is, which one.

Questions?
Which coding agent runs natively on Windows ARM64?+

Claude Code, Codex and Cursor run natively. OpenCode needs the x64 build under emulation — and its self-update reverts that, which makes the workaround permanent rather than one-off. On an ARM64 machine, check this before choosing a tool, not after.

Terminal or IDE — which is the better place for an agent?+

The terminal wins for long unsupervised tool chains, because the agent uses the same commands you do and nothing sits between it and the system. The IDE wins for pinpoint edits, because context and preview are already there. In practice both run side by side.

Is a second tool alongside your main one worth it?+

Yes, but not as a replacement. A second agent earns its place when it does something the first cannot — parallel worktrees, for instance. Two tools for the same job only cost switching time.

How much supervision does a coding agent need day to day?+

More than the marketing suggests and less than sceptics assume. On bounded tasks with clear verification — tests, types, linters — it largely runs alone. On architectural changes or in code without test coverage, reading every line is mandatory.