Harness

A harness is an agent that works on a repository in a loop. A maker model writes the change and a checker model reviews it. Each organization can run one harness. It calls models only through the inference gateway of your organization.

What a harness is#

A harness runs as a workload in your organization. It has its own key for the gateway, so its calls follow your allow-list, your guardrails and your quota. A run is one pass of the loop over the target repository, with a token budget and an iteration cap.

Deploy a harness#

Create the harness in the panel, or with the CLI or the SDK. A create that carries the model map mints the credentials of the harness at once. You can then install it with no extra save.

platform harness deploy --name build-agent \
  --repo https://git.example.com/acme/app --ref main \
  --maker-model mistral-large-latest --checker-model mistral-small-latest
platform harness install HARNESS_ID
platform harness get HARNESS_ID

import { PlatformClient } from "@type-driven/platform-sdk";

const client = PlatformClient.fromEnv();

const harness = await client.harness.createHarness({
  name: "build-agent",
  target_repo: "https://git.example.com/acme/app",
  target_ref: "main",
  model_map_json: JSON.stringify({
    maker: "mistral-large-latest",
    checker: "mistral-small-latest",
  }),
});
await client.harness.triggerHarnessOperation(harness.id, { operation: "install" });

const run = await client.harness.startHarnessRun({ token_budget: 200000 });
console.log(run.loop_id, run.status);

The models#

The harness needs a maker model and a checker model. The platform checks both when you save the config, before it writes anything:

• The map must be valid. The error names the field that is wrong.
• Your organization policy must allow each model: the allow-list, the inference switch and the default guardrail.
• The gateway catalog must list each model as a chat model it can serve.

If the catalog is not available at that moment, the save is refused and you can retry. A harness without a saved model map cannot install. The install is refused and the answer lists the missing names.

Install, restart and teardown#

Each operation answers accepted at once. The work runs on its own. Read the harness again to see the result.

A teardown checks first that the resources belong to this harness. Then it removes the stack and its network policy, revokes the key of the harness, removes the forge user and its access, revokes the Plane token and deletes the Plane project, deletes the stored credentials and deletes the config. It deletes the credentials for good. It keeps no copy. To use the harness again, install a new one. The platform mints new credentials. After a teardown the name is free to use again.

Why a run stopped#

A run that stops for a reason carries a halt reason. The harness page shows it in words. These are the reasons the platform knows and the fix for each.

A reason that is not in this list is shown as plain text from your own harness, cut to a safe length.

The three limits#

Three limits can stop a harness. A stop for any of them reads gateway_quota_exceeded.

The policy posture#

The platform reports a policy posture for the harness: enforced or not enforced, and the reason. A posture reads enforced only when the policy mode is on, the policy gateway is ready in the namespace of the harness, and the harness is serving. The policy mode in the config is your intent. It is not the posture.

What a run costs#

The cost of a run is an estimate at the plan overage rates. It is not an invoice. The tokens come from one of two sources, and the answer always says which.

platform harness run list
platform harness run cost RUN_ID
platform inference usage --harness-run RUN_ID