Claude Code, Codex, Kimi Work or an open architecture: how to choose

DECISION AID · CHOOSING A PLATFORM

Place the tool on the work, not on the demo

The map is a starting hypothesis, not a ranking. It separates speed of adoption from control and reversibility, and it has to be checked on representative work.

01Indicative positioning · check it with the same test pack

Control and reversibility ↑limits set by your companylimits set by the product

BUILD / CONTROLADOPT / GOVERNChatGPT EnterpriseworkspaceClaude Enterpriseknowledge workClaude Codesoftware developmentCodexcoding agentKimi Workdesktop agentKletronorchestrationOpen architectureyour own controlsThe choice

slower / more to buildSpeed of adoption →faster / more integrated

02Fit by type of work

A single winner is rarely the right answer. Choose a main architecture, then state where a second one adds real value.

Type of workWorkspaceCoding agentDesktop agentOpen architectureOrchestration

Broad knowledge workstronglowmediummediummedium

Software developmentmediumstronglowmediummedium

Desktop / local workmediumlowstronglowmedium

Differentiated productlowmediumlowstrongstrong

The unit of evaluation is a completed task, not a model answer.

"Which AI tool should we choose?" sounds like a product question. In a company, it is an architecture decision that commits your data, identities, processes, controls, costs and ability to change course.

The products do not do the same thing. Claude and ChatGPT Enterprise cover knowledge work in the broad sense; Claude Code and Codex work in code and change the way software is built; Kimi Work, from the Chinese company Moonshot AI, offers agents that work on local files, in the browser and on recurring tasks; Kletron, the agent product developed and run by Numezis, coordinates several agents on business tasks. Finally, open-weight models make self-hosting possible. The right answer depends on the work to be done, not on the feature table.

We configure and integrate these products every day: settings, connections to your software (notably through the MCP protocol), testing, access rights and controls in production. Knowing the products matters, but the architecture decision comes first.

Describe the work before choosing the product

First, draw the trust boundary around the work. What can the system read? What can it retain? Which tools can it call? What can it change? Where must a person confirm? What records must remain available once the work is done?

These questions immediately change the list of candidates. A company workspace suits drafting and analysis; a coding agent belongs in an isolated repository; an agent working on a computer's files should be tested within a very narrow scope; an open architecture is justified for a distinctive product, not because "open" is safer, but because the company needs control over things an online product does not expose.

Test every candidate with the same test pack

Sales demonstrations show polish; a common test pack shows what matters for the decision. Same tasks, same documents, same rights, same scoring grid and same cost assumptions for every candidate. Include the edge cases: incomplete documents, contradictory instructions, content in several languages, confidential fields, a malicious instruction hidden in a document, a tool failure, a request for an irreversible action.

The test pack produces six results:

1. Quality: accuracy, completeness, faithfulness to sources, review effort.
2. Reliability: reproducible results, behaviour when something fails or times out.
3. Controls: what the system refuses, what it asks to have confirmed, what it logs.
4. Integration effort: identities, connectors, interfaces, environments, support load.
5. Full cost: licences or usage, set-up, human review, running costs, exit.
6. Ability to switch: what can be exported, what would have to be rebuilt, what becomes a dependency.

Do not boil the results down to a single score. A candidate can win on quality and still lose the decision because it does not respect the required data boundary.

Data first: where is it processed?

For each candidate, check where content is processed and stored, how long it is kept, whether it can be used to improve the service, and on what legal basis a transfer outside Switzerland is possible (a country recognised as adequate, certification under the Swiss-US Data Privacy Framework, standard contractual clauses). This needs particular attention with Kimi Work: until processing in China, or anywhere outside Switzerland and the EU, is covered by sufficient safeguards, put neither customer data nor protected data into it. Our analysis of the nFADP, the AI Act and generative AI sets out these rules.

Four typical architectures

The managed workspace (ChatGPT Enterprise, Claude Enterprise, Copilot). The right default for broad internal use: identities, administration and access to models in one place. In return, you accept the product's limits and must check how data, connectors, retention and model changes are handled.

The managed API (a model provider's API). The right choice for a distinctive application or a controlled process: you control the experience, the orchestration, the document search and the rules. In return, building and running it is down to you: an API is not a complete service.

The coding or desktop agent (Claude Code, Codex, Kimi Work). The right choice when the work lives in files, a code repository, a terminal or a browser. In return, the range of possible actions is wider: isolation, local rights, secrets, browser sessions and human review become your responsibility.

The open or self-hosted architecture. The right choice when control, hosting location, cost structure or differentiation justify owning everything. In return, it is not just about servers: model testing, updates, capacity, security, incident response and support are all yours.

A combination is often the rational choice, provided the boundaries are written down: the workspace for everyday low-risk use, the coding agent for development, an API for a customer-facing process, an open model only where control demands it. A pile of tools without boundaries creates duplicate identities, inconsistent data rules and nobody in charge.

Compare the cost per completed case

The question is almost never "price per user versus price per request". Compare the full cost per case successfully completed: platform, usage, integration, data preparation, testing, human review, running costs, changes and exit. Then compare it with the current cost, including rework and delays. A tool that is cheap per request is expensive per case if users have to correct most of the results.

Work out three scenarios: the pilot, the expected volume and a difficult case (more volume, longer documents, a lower success rate, a model change, closer review). The aim is not a precise figure but to find the assumption that would overturn the decision.

Write down the decision and the exit route

A good decision record describes the context, the options, the test pack results, the option chosen, the risks accepted and the conditions for revisiting it. It also describes the exit in five lines: export format for the data, list of integrations, whether the tests can be reused, user dependencies and training, and the estimated time for a credible replacement. It is reviewed when the contract, the price, the model's behaviour or the importance of the process changes.

The right answer is not "we are vendor-neutral". It is "we know why this architecture wins for this work, what we are accepting and which options we have kept open".

How we can help

Choosing and configuring a workspace for your teams comes under AI Adoption Support. The test pack, integration with your software, agents and custom architectures come under AI Engineering: a scoping phase of one to three weeks, then a firm quote, or a subscription if several projects follow one another. For an SME weighing up ChatGPT, Claude, Gemini and Copilot, our analysis of which one an SME should choose is more direct.