What model providers see

kanman does not train or host its own language model. The coding agent and the independent reviewer use models from established providers. This page explains which provider sees what, so you can assess it before you connect a repository.

Which provider is involved

The provider depends on the executor your team uses and on how you pay for compute.

The executor is chosen when you set up a team and can be changed in the team settings under Agent and models.

The reviewer deliberately uses a model from a different vendor than the executor, so that the work is checked by an independent second opinion. If your executor is Claude Code, the reviewer runs on an OpenAI model, and the other way round.

Teams that use their own key get the reviewer and the writing of acceptance specs on that key too, so their code only reaches their own provider contract. Because one key reaches one vendor, the reviewer then uses a model of that vendor (with Azure OpenAI or Amazon Bedrock, the deployment or model you configured) instead of the other vendor’s. If the key is missing or does not work, the review reports an error; kanman never switches to its own model access for it.

Teams on a self-hosted runner can also leave model access entirely to the runner’s environment, for example through their own Amazon Bedrock, Google Vertex AI or Microsoft Foundry account. See Model access on self-hosted runners.

Intake (turning a requirement into stories) also uses a language model. It uses your own key when the team or the workspace has one, otherwise kanman’s model access.

What new teams use

Owners and admins choose how new teams reach the models in Workspace settings > Model access (/<workspace>/settings/models), under New teams use:

• Pay through kanman: provider cost plus 15 percent on the team’s invoice. Nothing to set up.
• Your own key: your provider bills you directly. You add the key once, on the same page.
• Your runners’ model access: only where runs execute on your own runners. The runners use the model access of their own environment, see Model access on self-hosted runners.

The choice saves at once. The team setup starts each new team with it, and a team can still choose otherwise in its Settings > Agent and models. There the field shows Workspace default: with the current default, and Use the workspace default brings a team that chose otherwise back to it. Existing teams keep what they use until you change it for them.

Using your own key

A workspace has one provider key, which teams that are set to Use your own key share. Only workspace admins can add, test, replace or remove it.

1. Open Workspace settings > Model access (/<workspace>/settings/models) and find Your provider key.
2. Click Add provider key.
3. Choose the Provider and enter the key first. Each provider is listed with the executor it works with: Anthropic and Amazon Bedrock for Claude Code, OpenAI and Azure OpenAI for Codex. For your company’s AI gateway or a proxy, choose Use a gateway or proxy instead below the list (see Use your company’s AI gateway).
4. Fill in the other fields for that provider (see the table below). To pin a specific model, open Choose a model; otherwise kanman picks a fitting model for each task.
5. Click Test connection to check the key, then Save key.

After saving, the key shows its status (Working or Check failed), the model and when it was last checked. Use Test connection again at any time, Replace to enter a new key, or Remove key.

The key must fit the team’s executor: a team on Claude Code needs an Anthropic or Bedrock key (or an AI gateway with an Anthropic-compatible endpoint), a team on Codex an OpenAI or Azure OpenAI key (or an AI gateway with the OpenAI Responses API). kanman never falls back silently to its own model access. If the key is missing, removed or does not fit, the team’s runs stop with a clear message until you add a fitting key or switch the team to Pay through kanman.

Keys are stored encrypted and are only handed to the run’s sandbox as environment values. They never appear in logs, run records or the audit log.

Use your company’s AI gateway

Many companies send all model traffic through one AI gateway, for example LiteLLM, Portkey, Kong AI Gateway, Azure API Management, Cloudflare AI Gateway or an internal proxy. If your gateway offers an OpenAI-compatible API, kanman can use it with your company’s key: the gateway applies your company’s rules, routing, logging and contracts, and the provider bills you through it.

Add the gateway

1. Open Workspace settings > Model access and click Add provider key (or Replace next to the current key).
2. Below the provider list, choose Use a gateway or proxy instead. The form then shows Gateway or proxy (an OpenAI-compatible gateway).
3. Fill in the fields:

4. Click Test connection, then Save key.

What Test connection checks

kanman sends a tiny request to the gateway and lists what it offers:

Below the list, kanman names the coding agents that work with this gateway. The key card keeps the result of the last check.

Which coding agent works with which gateway

Current versions of Codex no longer support Chat Completions, so a gateway with only Chat Completions cannot drive a coding agent. In that case, ask your gateway team to also offer the Anthropic Messages API (/v1/messages) or the OpenAI Responses API. LiteLLM, for example, offers both. Until then, a team can keep its assistant steps on the gateway and run the coding agent with another model access (see below).

kanman does not let a team combine a coding agent with a key it cannot run on: the team setup and the team settings say why and do not save the choice.

Choose it per team, per purpose

In Team settings > Agent and models a team chooses its model access twice. Both start with the workspace’s choice under New teams use (see What new teams use):

• Model access of the coding agent: pay through kanman, your own key, or (on self-hosted runners) the model access of the runner environment.
• Model access of kanman’s assistant steps: drafting stories, replies in the conversation, the reviewer and the spec author. By default Same as the coding agent. You can choose another, for example your company’s AI gateway for the assistant steps while the coding agent uses your runner’s model access.

Cost and usage

Gateways rarely report prices. For runs on a model kanman knows (also with a provider prefix, for example openai/gpt-5), kanman estimates the cost as usual. For models without a known price, kanman records the tokens and the run page shows Model usage in tokens instead of euros; euro budgets cannot stop such runs, the turn limit of each run still applies. Your gateway’s own reporting is the place for the real cost.

Keys of the type “OpenAI-compatible” from earlier versions of kanman are treated as gateway keys: test them once to see which coding agents work.

Gateways inside your network

kanman’s cloud only calls gateways at a public HTTPS address. If your gateway is reachable only inside your network or VPN, turn on Run everything on your runners: your runners then call the gateway, internal addresses (also plain http inside your network) are accepted, and Test connection runs on your runner. The form shows Checking with your runner… until it answers; this needs a current runner version. To configure a gateway directly on the runner instead, see AI gateways in the runner environment.

What the coding agent sends

While it works, the coding agent sends its provider the context it needs for the task:

• the story: title, description, acceptance criteria, Demonstrate block and test plan,
• the policy summary for the run (denied paths, limits, budget),
• your team’s conventions and lessons that apply to the areas it works in,
• the files it reads from the repository, and the commands and outputs of its own tool calls (for example test output),
• the changes it writes.

It does not receive secret values (see Sandbox and secrets), other teams’ data, or other repositories.

What the reviewer sends

The reviewer receives the story, its acceptance criteria, the test plan and the diff of the change. It answers with a verdict per criterion, with file and line references.

What intake sends

When you submit a requirement in the app, in a chat with kanman or from a Slack thread, that text is sent to the model that drafts the stories, together with the team context needed to draft them.

What chat and team context send

When kanman takes part in your team’s conversations in Slack or Microsoft Teams, the messages it answers are sent to the model, together with the board state needed for the answer. When the team has team context switched on, kanman reads each source with the team’s own key, or with kanman’s model access if the team has none, and sends the passages that fit a question along with it. Only the team’s own OpenAI key is used to search sources by meaning. If your workspace runs everything on its own runners, reading sources and answering questions happen on your runners.

What providers do with it

What a provider may do with the data is governed by that provider’s terms:

• Pay through kanman: kanman calls the provider under kanman’s business agreement. These agreements do not allow the provider to train models on your data. The providers kanman uses are listed as subprocessors in the DPA (see DPA and subprocessors).
• Your own key: calls run under your own contract with the provider. Your terms, your region choice and your data processing agreement apply. This is the usual choice for regulated teams.

Reducing what is sent

• Keep secrets out of stories and repositories, as you would for any developer.
• Use denied_paths to keep the agent away from areas it should not change, for example infrastructure or customer data fixtures.
• Use your own Azure OpenAI or Amazon Bedrock contract if model calls must stay in a specific region, and switch on EU-only processing so that kanman refuses every route outside the EU.
• Use a self-hosted runner if the checkout and the builds must stay in your network. Note that model calls still go to the provider you choose.
• Turn on Run everything on your runners if kanman’s cloud must not call a model provider at all: the reviewer, the spec author, intake drafts and maintenance then call the model from your runner, with your account.

Related pages

• Plans and billing
• Hosting and data residency
• Budgets and cost
• Policy settings