Skip to content

Latest commit

 

History

History
93 lines (80 loc) · 4.13 KB

File metadata and controls

93 lines (80 loc) · 4.13 KB
title Choose an AI provider
description Configure one supported model provider before creating workflows, post-scripts, or scans.

open·kritt needs one AI access method. You can configure more than one and choose between them per run, but a single working provider is enough to start.

Provider Access method Model input
Codex ChatGPT/Codex login or an OpenAI Platform key Account-specific picker
Claude Claude subscription login or ANTHROPIC_API_KEY Subscription aliases or account-specific picker
OpenRouter OPENROUTER_API_KEY Searchable authenticated catalog, with an exact-ID fallback
xAI Grok device login or XAI_API_KEY Searchable authenticated catalog (with key), with an exact-ID fallback
Use the recommended ChatGPT device login or an OpenAI Platform API key. Sign in with an eligible Claude subscription, or use an Anthropic API key. Use one key to access compatible models through OpenRouter. Use Grok device login or an xAI API key with the Grok Build harness.

Common setup flow

From the repository root, run:
```bash
./kritt setup
```
Select **Codex login**, **OpenAI API key**, **Codex API key**, **Anthropic API key**, **OpenRouter API key**, or **xAI API key**. Follow the provider guide above to obtain the correct credential. The CLI configures keys and Codex login; Claude and xAI device login, plus OpenRouter/xAI key management, are also available from the running application's **Accounts** page. ```bash ./kritt start ```
If open·kritt is already running, stop the attached stack with Ctrl+C first. Existing
containers do not receive a newly changed `.env` value until Compose recreates them.
Run `./kritt setup` again and confirm the selected method is marked as present. The workflow generator, post-script generator, and new-scan form will list only providers that open·kritt detects as configured.

Credential handling

API keys configured by the CLI are written to the repository's .env file. Codex logins are stored under ENGINE_CODEX_ACCOUNTS_HOST, which defaults to ./.data/codex-accounts; a Claude login is stored under ENGINE_CLAUDE_HOME, which defaults to ./.data/claude; a Grok/xAI login is stored under ENGINE_GROK_HOME_HOST / ENGINE_GROK_ACCOUNTS_HOST, which default to ./.data/grok and ./.data/grok-accounts. The Accounts page keeps Codex/Claude/xAI account paths and its OpenRouter and xAI keys synchronized with .env, and mirrors those keys under .data/engine/credentials so running services see changes immediately. .env and .data/ are ignored by Git.

Treat `.env`, `./.data/codex`, `./.data/codex-accounts`, `./.data/claude`, `./.data/grok`, `./.data/grok-accounts`, and the engine credential store as secrets. Never commit them, paste them into an issue, or share them with another user. Revoke and replace a credential immediately if it is exposed.

The backend has private write access to .env and the provider stores so Accounts can persist additions and removals, but secret values are never returned by the API. The engine receives the actual credential when it starts a model harness.

`GITHUB_TOKEN` is not an AI provider credential. It is optional and is only needed to clone private GitHub repositories or dependencies.

Next: configure the recommended Codex provider, Claude Code, or OpenRouter, or xAI.