Integrate/Execution modes

Execution modes

Ether can run coding work in-process (default) or delegate to external harnesses. Integrators choose based on who runs the agent loop.

Modes

Mode	API env	Behavior
Local (default)	`ETHER_HARNESS_MODE=local`	OS brain runs in-process coding agent (stub or live)
Remote pull	`ETHER_HARNESS_MODE=remote`	Skip in-process brain for coding pipelines; external app claims via Harness API
Remote push	`remote` + `ETHER_HARNESS_URL`	OS POSTs `CodingSpec` to your worker; polls until complete

Set on ether-api (ether-core deploy), not on your harness laptop alone.

text

User → POST /api/tasks
Harness → POST /api/harness/tasks/{id}/claim
Harness → steps + POST /api/harness/tasks/{id}/result
App ← task.delivered

Best for: Ether Code CLI, local dev, explicit dispatch, full delivery contract.

Your worker needs only outbound HTTPS to api.tryether.ai — no inbound port required.

text

ether-api (RemoteCodingHarness) → POST {ETHER_HARNESS_URL}/v1/runs
                               → GET  {url}/v1/runs/{run_id}

Best for: Always-on remote workers behind a stable URL.

Run Ether Code serve as reference:

bash

ETHER_CODE_PORT=8791 npm run worker -- serve
# ether-api: ETHER_HARNESS_MODE=remote ETHER_HARNESS_URL=http://worker:8791

Two wires today

Push uses /v1/runs + CodingSpec. Pull uses Harness claim/result. Prefer pull for new integrations until paths are unified.

Scenario	Use
Building a third-party harness product	Pull
User runs agent on laptop	Pull + user JWT
Central GPU farm with inbound HTTP	Push (or pull from farm egress)
Prototyping inside ether-core only	Local

Even on the same machine, Ether Code is a client of Ether OS:

User creates task in app → task_id
Harness claims — scope comes from ExecutionBundle, not “whatever folder is open”

That preserves the same contract for local and cloud runtimes.