AI Providers
Open Harness AI → Configuration to manage AI providers. Provider creation and editing use dedicated pages, while the Configuration tab gives you a compact list for assignments and day-to-day management.
Harness tabs are encoded in the URL. Bookmarks, shared links, and the Open configuration action on an AI warning therefore open the Configuration tab directly.
Each provider stores one model configuration and its encrypted credential. A provider can serve the interactive AI Assistant, the autonomous AI Harness, both features, or neither. A provider without either assignment can still be used by AI-powered custom detectors.
Assistant and Harness are independent
The Assistant and Harness switches beside each provider are assignment and enablement controls:
| Assignment | What it powers |
|---|---|
| Assistant | Interactive Assistant and chat-gateway requests |
| Harness | Autonomous agents, manual Harness runs, and scheduled Harness work |
Each role can have at most one provider. Assigning a different provider moves that role to the new provider; one provider may hold both roles. Clearing an assignment disables only that feature, so the Assistant and Harness can be operated independently.
The AI Harness not configured badges in the sidebar and top bar check only the Harness assignment. An Assistant-only provider does not clear them. Selecting a Harness provider removes the warnings and enables Harness actions.
Supported providers
| Provider | Default model | Base URL |
|---|---|---|
| OpenAI-Compatible | gpt-4o | Configurable—for OpenAI, Azure OpenAI, Together AI, OpenRouter, Groq, self-hosted endpoints, and similar APIs |
| Claude (Anthropic) | claude-sonnet-4-5 | Managed by Classifyre |
| Gemini (Google) | gemini-2.0-flash | Managed by Classifyre |
Add or edit a provider
From Harness AI → Configuration:
- Select Add provider, or use the edit button on an existing provider.
- Configure the provider and model on the dedicated page.
- Choose whether to use it for the Assistant, Harness, both, or neither.
- Run a connection or Harness capability test if required.
- Save. You return to the Harness Configuration tab.
The editor is arranged into provider/model, runtime/pricing, assignments, credential, and verification sections. On smaller screens those sections stack into one column and the save controls remain available at the bottom.
Configuration fields
| Field | Description |
|---|---|
| Name | A recognizable label, such as “Production Claude”. Maximum 120 characters. |
| Provider | OpenAI-Compatible, Claude (Anthropic), or Gemini (Google). |
| Model | The provider’s exact model identifier. Maximum 200 characters. |
| API key | Stored encrypted at rest and never returned in plaintext after saving. |
| Base URL | Available for OpenAI-compatible providers; leave blank for the default OpenAI endpoint or enter a compatible endpoint. |
| Context size | Optional model context window in tokens. Used by Harness capacity analysis. |
| Vision support | Whether the model accepts image and PDF input. |
| Input/output token cost | Optional USD price per one million tokens, used for Harness cost estimates and usage charts. |
Testing a new provider saves its credential first. A later save updates that same provider instead of creating a duplicate.
Test a provider
The verification section offers two test types. Connection is selected by default.
Connection test
The connection test sends one small structured-response request. It verifies that the saved configuration can be decrypted, the provider accepts the API key and model, and the model responds before the timeout.
The result explains why the test passed or failed and includes the provider, model, duration, diagnostic details, token usage when available, and a short response preview. Failures distinguish configuration, authentication, model, rate-limit, and provider errors so the next action is clear.
Harness capability test
The Harness test checks whether the model can drive the real agent-loop contract, not merely answer a request. Progress appears while the test runs, including the active stage and every completed probe with its result and reason.
It exercises:
- strict structured turns and recovery from invalid output;
- choosing tools and producing schema-valid arguments;
- carrying a tool observation into a dependent next call;
- judgment against representative Harness missions;
- context capacity for each configured agent.
The final report gives an overall Ready, Degraded, or Unusable verdict, per-agent readiness and context headroom, detailed probe evidence, token totals, duration, assumptions, and an estimated cost per run when token pricing is configured.
The test makes real model calls and may consume provider quota, but it never runs a tool against workspace data. Tool observations are safe fixtures, so the capability test does not change the workspace. Its verdict is advisory and does not prevent assigning the provider.
Delete a provider
A provider cannot be deleted while it is assigned to the Assistant or Harness, or while a custom detector references it. Clear or move those dependencies first, then delete the provider.
Credential security
- API keys are encrypted at rest.
- The raw key is never returned by the API after creation.
- Existing keys are shown only as a masked value; entering a new key replaces the stored credential.
- Workspace archives strip provider keys. Imported providers must be given new credentials before they can be used.