Choosing a coding agent: Claude Code, Codex, Cursor, Antigravity, or Opencode
Your data situation decides the coding agent, not the benchmark. Does your code leave the building or not?
This translation was produced automatically using AI. The German version is the editorially reviewed original.
Which coding agent is right is decided by your data situation and your existing stack, not by the top spot on a SWE-Bench leaderboard. The differences between the leading models sit, for most real B2B work, in the noise.
Claude Code, Codex, Cursor, Antigravity, and Opencode solve the same task in very different ways. The one question that splits the field is simple: does your code have to be allowed to leave the building? Whoever can answer yes chooses by stack. Whoever cannot has exactly one serious option. This piece sorts the five along that question and ends with the decision I recommend to a German team.
01. FIVE TOOLS, ONE FIRST QUESTION
The five sit at different levels, and the form factor already says a lot about the use case.
- Claude Code is a terminal agent from Anthropic: strong at multi-file changes, large context, and an agentic loop in the terminal.
- Codex from OpenAI is available as a CLI, a cloud sandbox, and an IDE integration, all sharing one usage window.
- Cursor is the AI IDE with an agent mode and a background agent mode, plus free model choice.
- Antigravity is Google's agent-centric IDE, available since 20 November 2025, with a manager interface for launching and observing parallel agents (Google).
- Opencode is an open-source terminal agent under the MIT licence, model-agnostic across many providers and self-hosted endpoints (opencode.ai).
How these tools fit into a stack, from the API to the CLI, we laid out in API, MCP, or CLI. This piece is about the choice, and that starts with your data situation.
02. DOES YOUR CODE LEAVE THE BUILDING?
This one question sorts the field faster than any feature list, because it decides compliance and confidentiality before any feature counts.
Four of the five send code to someone else's cloud. Claude Code, Codex, Cursor, and Antigravity run against hosted models in the US. That is not automatically a disqualifier: for many projects it is fine, and on the enterprise tier you can negotiate zero-data-retention and no-train clauses. But the code goes out, and that has to be a conscious decision, not something overlooked.
Opencode is the exception. Because it is model-agnostic and can address a local endpoint, it can run entirely against a self-hosted model. Then the code never leaves the building. That is exactly the dividing line that decides everything else. Which open-weight model you put behind it is a separate decision, one we walk through in Open-weight model for German B2B.
03. IF THE CLOUD IS FINE: CHOOSE BY STACK
If you knowingly accept the hosted cloud, the stack decides, not the benchmark. A quick overview:
| Tool | Form factor | Model | Open source | Best for |
|---|---|---|---|---|
| Claude Code | Terminal CLI | Anthropic | no | deep multi-file work in the terminal |
| Codex | CLI + cloud + IDE | OpenAI | client partly open | ChatGPT teams, cloud sandboxes |
| Cursor | IDE | Multi-model | no | IDE-native flow, model switching |
| Antigravity | Agent IDE | Multi-model | no | agent orchestration with verification |
| Opencode | Terminal CLI | any / local | MIT | control, no lock-in, local model |
The pragmatic rule: an Anthropic house takes Claude Code, an OpenAI house takes Codex, an IDE-centric team takes Cursor or Antigravity. Benchmark numbers such as SWE-Bench scores around 85 percent circulate, but they are mostly vendor claims and rarely independently verified; I would not base a tool choice on them. What a coding agent delivers beyond pure development is shown in our piece Claude Code beyond engineering.
04. IF THE CODE MUST STAY IN-HOUSE: OPENCODE PLUS YOUR OWN MODEL
If the code must not leave, there remains a serious option, and it is a good one.
Opencode is open source under MIT, speaks to many providers and, crucially, can address a local endpoint. Paired with a self-hosted open-weight model, this produces a coding agent where neither source code nor prompts leave your own infrastructure. For regulated data, client confidentiality, or simply cautious customers, this is often the only viable setup. We took a dedicated look at an open coding model, Kimi K2.7, for exactly this case here.
The price of this control is doing the work yourself: you assemble the model, hardware, and operations on your own, there is no managed cloud agent fleet. In practice, it helps to give the agent structure, for example a codebase map, as we described in Graphify. The effort is real, but it buys something the hosted tools cannot offer.
05. HOW I DECIDE THIS
You do not need a single answer for the whole company, but the right one depending on your data situation. Here is how I approach it:
- Clarify the data situation. Is the code in question allowed into a US cloud? This answer comes from legal and the client, not from the development team.
- If yes, choose by stack. An Anthropic house goes to Claude Code, an OpenAI house goes to Codex, an IDE-centric team goes to Cursor or Antigravity, each with negotiated ZDR and no-train conditions.
- If no, Opencode plus your own model. The only option where the code never leaves the building.
- Keep an eye on lock-in. Every tool demands its own binding, so keep a path open back to a deeper level in case a provider changes its terms.
We ourselves work with several of these tools depending on the project, and that is exactly the point: the choice is project-bound, not ideological. The one small internal tool we built with an agent instead of commissioning it is covered in Building event-scout. Which of your repositories should not actually go into someone else's cloud today, and which tool do you use for it anyway?
