OHarness

What the harness already knows

Connecting it

The endpoint above is built in, so there is nothing to configure. Put the key in the environment and the provider appears in the model picker:

Worth knowing

The official plan: sign in with an OHarness account, or paste an oh- key created on the site. Usage is metered against the account balance and the upstream keys are never the subscriber's — which gateway serves the models is an implementation detail, moved by OHARNESS_BASE_URL. This host is our metering gateway, NOT the upstream one: they speak the same paths, so the two are easy to confuse and the mistake is quiet — the model list is public upstream and answers 200, and only the first completion comes back invalid_api_key. No docsUrl: the way in is the sign-in, not a key page, so pointing at one would send people the long way round. The two lines above are the upstream gateway's, not any model's: it wants an Idempotency-Key on every completion and caps max_tokens at its own GATEWAY_MAX_OUTPUT_TOKENS — 4096 by default, and nothing in /models mentions either, so both have to be stated here. Raise the number in step with the deployment, or a shorter answer is the least of it: over the line is a 400, not a truncation.

Pointing it somewhere else

A regional host, a gateway, or a server of your own. Overrides in ~/.oharness/config.json are field level, so changing the endpoint does not mean restating the rest of the provider — this is the whole block, shown holding the default so the shape is clear:

{
  "providers": {
    "official": {
      "baseUrl": "https://api.oharness.ai/api/v1"
    }
  }
}

What you get either way

The same agent loop, the same tools, the same MCP servers and the same permission rules, whichever provider is underneath — and switching between them mid-session converts nothing, because history is never stored in a vendor’s shape. What an agent harness is covers why that is the hard part, and the providers reference covers the catalogue itself.

All 27 providers · Install OHarness