I have been working a lot with Orchistra as it evolves from a control surface into something closer to an operating system for agentic work.

That has forced me to look quite carefully at where the work should actually run.

Could I move everything onto my own server and call the models directly through their APIs?

Technically, yes.

Operationally, I have discovered two things.

First, the result is often not as good as working inside a mature harness such as Codex, Claude Cowork, Claude Code, or Kimi Code.

Second, direct API use can become expensive surprisingly quickly when an agent is carrying large contexts, making repeated calls, retrying work, and continuing through a long loop.

It can feel a little like watching the price of a cup of coffee leave the account every few seconds.

My recommendation is not to abandon the harness.

Use the harness. Take the leverage. But keep an escape route.

The model is not the whole worker

It is easy to compare a model in a harness with the same model through an API and assume they should behave in roughly the same way.

They often do not.

The harness is doing a great deal of work around the model. It may manage context, files, tools, terminals, permissions, skills, memory, subagents, approvals, retries, checkpoints, and the conversation with the human.

OpenAI describes Codex as the environment for working with repositories, terminals, local files, tests, and longer technical tasks. Anthropic describes Cowork as a system that can work across files and applications to return a finished deliverable. Kimi Code can read and edit files, run commands, use MCP servers, dispatch subagents, and react to what happens next.

That is not a decorative wrapper around an LLM call.

It is the machinery that turns a model into a useful worker.

When I strip that machinery away and make a direct API call, I have not simply moved the same worker to my server. I have kept the model and taken responsibility for the rest of the job.

The economic pull is real

The pricing also creates a pull back towards the provider's environment.

Subscriptions, included allowances, shared credits, prompt caching, and product-specific optimisations can make a harness feel much easier to use than a raw metered API. Anthropic also separates Claude subscription usage from its API Console billing, while OpenAI now publishes a Codex rate card that maps usage more directly to token consumption and credits.

The detail changes quickly, but the architectural point remains.

Pricing is not separate from system design. It shapes which model you use, how much context you send, how often an agent loops, when you cache, and whether a task is commercially sensible at all.

Direct APIs are not automatically expensive. DeepSeek's current API pricing, for example, is dramatically lower than some frontier alternatives, and both OpenAI and DeepSeek offer discounts for cached input. Local open-weight models may replace a variable token bill with hardware, power, engineering, and support costs.

The problem is uncontrolled consumption.

A long-running agent can repeatedly resend context, call the wrong model, produce far more output than the task needs, retry without a useful stopping rule, or keep several workers busy when one would do.

If you cannot see the cost of a job, you do not yet have an operating system. You have a meter.

The gentle lock-in

I do not think this needs a conspiracy theory.

Of course providers want their models to work best inside their own products. They can tune the model, interface, tools, context handling, and commercial package together. That is rational product design.

It also creates a gentle form of lock-in.

The lock-in is not only the model name or API format. It is the growing collection of scheduled tasks, hidden context, skills, permissions, connectors, histories, approvals, and habits that only make sense inside one harness.

One scheduled task is convenient.

Fifty scheduled tasks whose purpose, owner, budget, and fallback live only inside a provider's interface are an operational dependency.

You may still be able to export the prompt. That does not mean you can move the worker.

Do not solve this by avoiding the best tool

There is a bad answer to lock-in, which is to refuse every useful provider-specific capability in the name of theoretical portability.

That normally gives you a weaker system today and an imaginary portable system tomorrow.

If Codex is the best route for a coding task, use Codex. If Cowork is better for a document-heavy task, use Cowork. If Kimi Code or another harness is particularly strong for a task, use it. If a local model gives you the privacy and control you need, use that.

The aim is not to make every execution route identical.

The aim is to keep the business meaning of the work outside the route.

Build a portable job contract

This is the part I would build into an agentic operating system from the beginning.

Before a job reaches Codex, Cowork, an API, or a local model, describe it in a portable contract:

  • Goal: What outcome are we trying to achieve?
  • Context: Which information is authoritative and where does it live?
  • Constraints: What must the worker not do?
  • Tools: Which capabilities are required, rather than which product buttons?
  • Evidence: What proof must come back with the answer?
  • Approval: Which actions require a human or another agreed gate?
  • Budget: What is the maximum spend, time, calls, or retries?
  • Success condition: How do we know the job is actually complete?
  • Receipt: What happened, what changed, and what remains uncertain?

That contract belongs in the operating layer, not inside one vendor conversation.

For me, that is part of the role of Orchistra. It should understand the work, the route, the owner, the budget, the evidence, and the result. The harness executes the job. It should not become the only place that knows what the job was.

Two-route agentic architecture showing Orchistra and a portable job contract feeding a primary harness route and a tested API, local, or sovereign fallback route, with shared state, receipts, budgets, and evaluation outside both routes.
Optimise the primary harness route, but keep the job contract, state, receipts, and fallback outside it.

The fallback does not need to be equal

An escape route does not have to reproduce the primary harness perfectly.

It may be slower. It may need more human supervision. It may use a smaller model. It may produce a simpler deliverable. It may require somebody to start it manually.

That is fine.

Operational resilience is not always about maintaining full performance during a disruption. Sometimes it is about preserving the important service well enough until the preferred route returns.

Your first fallback may simply be the same provider's API. That proves you can run the job without the product interface. The next fallback may be a compatible API from another provider. For particularly sensitive or jurisdiction-bound work, it may be an approved local or sovereign deployment.

Mistral documents cloud, EU-hosted, and local deployment routes. Moonshot publishes open Kimi model weights and compatible APIs. DeepSeek provides OpenAI- and Anthropic-compatible API formats. These options do not make switching effortless, and the model names will change, but they make a real fallback possible.

Test it before you need it

A fallback written in an architecture diagram but never run is not a fallback.

Pick one representative job. Run it through the main harness. Then run it through the alternative route.

Compare:

  • Did it achieve the outcome?
  • Did it preserve the evidence and audit trail?
  • How much human correction did it need?
  • How long did it take?
  • What did it cost?
  • Did the approval and stop-line rules still work?
  • Could another person understand the receipt?

Do this periodically, because both the harness and the alternative models will change.

You do not need to automate the failover on day one. In fact, a manual fallback is often better while the job is still changing. You need to know that the route exists, that someone can start it, and that it still works.

My recommendation

If you are building a new agentic business with limited capital, work in the harness.

Use the context handling, tools, skills, permissions, interfaces, and product economics that already exist. Do not rebuild all of that merely to prove you can make an API call.

But keep the canonical state outside the harness. Keep the job contract portable. Keep prompts and skills versioned where practical. Keep costs visible. Keep receipts. Keep a tested route through an API, another provider, or an approved local model.

Use the harness for leverage.

Keep the escape route for resilience.

You will thank me later.

Sources and notes