Modellzugang auf Self-hosted Runnern

Auf einem Self-hosted Runner kann das Coding-Werkzeug den Modellzugang nutzen, den du auf dem Runner selbst einrichtest. kanman gibt dem Run dann überhaupt keine Zugangsdaten für Modelle: keinen eigenen Schlüssel und keinen in kanman gespeicherten. Was die Umgebung des Runners bereitstellt, nutzt das Coding-Werkzeug.

Wir empfehlen dafür dein eigenes Cloud-Konto: Amazon Bedrock, Google Vertex AI oder Microsoft Foundry für Claude Code und Azure OpenAI für Codex. Die Zugangsdaten bleiben in deiner Infrastruktur, Modellaufrufe laufen unter deinem Cloud-Vertrag und in der Region deiner Wahl, und du nutzt die Identitätsmechanismen, die du schon hast (IAM-Rollen, Workload Identity, Managed Identity).

Betreiber sind dafür verantwortlich, beim Einrichten der Runner-Umgebung die Bedingungen ihres Modellanbieters einzuhalten.

Für ein Team einschalten

Die Einstellung gibt es nur für Workspaces, deren Runs auf eigenen Runnern laufen (Workspace-Einstellungen > Runs und Runner, Unsere Runner oder Alles auf unseren unter Wo Runs laufen).

1. Öffne Team > Modelle und klicke auf Modellzugang.
2. Wähle Zugang deines Runners. Bei der Einrichtung des Teams steht dieselbe Auswahl im Executor-Schritt.
3. Leg die Budgets in Minuten und Runs (siehe unten) unter Ausgabengrenzen unter Team > Budget und Grenzen fest. Jede Änderung wird sofort gespeichert.

kanman sieht in diesem Modus keine Modellkosten. Statt Euro zählen die Budgets des Teams Zeit und Runs:

Expedite- und Störungsarbeit startet auch dann, wenn ein Run-Limit erreicht ist. Deine Modellkosten werden nicht erfasst. In der kanman Cloud wird diese Einstellung abgelehnt: Runs dort nutzen nie die Umgebung eines Runners.

Die Run-Seite zeigt die verbrauchte Zeit eines Runs im Verhältnis zu Minuten pro Run statt Kosten in Euro. Dasselbe gilt für die Run-Karten in der Unterhaltung, die Run-Liste und den Wochenbericht: Sie sagen “Kosten nicht erfasst (Runner-Umgebung)” und zeigen Minuten, nie “0,00 € von 2,00 €”.

Modellzugang pro Team

Ein Runner kann mehrere Teams mit verschiedenen Konten bedienen. Der eigene Modellzugang eines Teams steht in seinem Modell-Login (Reiter Team > Umgebung > Modell-Login; ist Zugang deines Runners gewählt, verlinkt die Zeile Modellzugang dorthin). Bleiben sie leer, nutzt das Team, was der Runner bereitstellt. Mit Variablen dort bekommt das Team einen eigenen Zugang, einzeln oder per Aus .env einfügen, zum Beispiel:

Der Modellzugang des Teams ersetzt den des Runners für dieses Team als Ganzes: Keine Modellvariable des Runners wird genutzt, damit sich zwei Konten nie mischen. kanman speichert die Werte verschlüsselt und gibt sie nur mit den Runs und Schritten des Teams an den Runner; der Runner speichert sie nie, und das Coding-Werkzeug erreicht das Modell über den Zugangs-Proxy des Runners mit einem Platzhalter statt des Werts. Teamleitungen, Owner und Admins ändern sie; alle sehen die Namen, wer sie gesetzt hat und wann. Jede Änderung steht ohne den Wert im Audit-Log. Code-Host-Tokens und andere Variablen des Teams stehen in derselben Liste, nach Zweck gruppiert; siehe Mehrere Teams auf einem Runner.

Modellzugang prüfen über der Liste bittet einen deiner Runner um einen winzigen Modellaufruf mit den aktuellen Einstellungen des Teams. Die Prüfung meldet Modellzugang funktioniert und welches Modell geantwortet hat, oder was zu ändern ist: noch kein Modellzugang eingerichtet, Zugangsdaten vom Anbieter abgelehnt, ein Nutzungslimit erreicht oder der Runner erreicht das Modell nicht. Wer eine Modellvariable speichert, startet die Prüfung automatisch.

Erreicht der Modellzugang des Teams ein Nutzungslimit, sagt der Team-Chat, wann die Arbeit weitergeht. Endet das Limit früher, etwa weil die Nutzung im Konto des Anbieters zurückgesetzt wurde, bemerkt kanman das von selbst: Es prüft den Zugang mit demselben winzigen Aufruf, zuerst nach 15 Minuten und dann höchstens stündlich, und die Arbeit geht weiter, sobald der Zugang antwortet. Jetzt erneut versuchen am Hinweis im Chat prüft sofort. Eine erfolgreiche Prüfung mit Modellzugang prüfen oder eine geänderte Modellvariable beendet das Warten sofort.

Das unabhängige Review

Auch der unabhängige Reviewer nutzt ein Modell. In diesem Modus hat kanman keinen Modellzugang, den es dafür aus seiner Cloud nutzen könnte, und weicht nie auf einen eigenen aus. Schalte Alles auf deinen Runnern ausführen ein, damit er mit genau diesem Modellzugang auf deinem Runner läuft. Ohne diese Einstellung wird ein Run, dessen Änderungen bereit für das Review sind, mit dem Hinweis Wartet auf deinen Runner auf seiner Run-Seite geparkt. Dabei schlägt nichts fehl, und es werden keine Versuche verbraucht.

Eine Konfiguration für jeden Schritt

Mit Alles auf unseren läuft jeder Schritt, der ein Modell nutzt, auf deinem Runner mit dem Zugang, den du dort einrichtest: das Coding-Werkzeug, das Entwerfen von Stories aus einer Anforderung, der unabhängige Reviewer, kanmans Antworten in der Unterhaltung, Antworten aus dem Teamkontext und die Wartungs-Reviewer. Mit Amazon Bedrock, Google Vertex AI, Microsoft Foundry oder einem Anthropic-Schlüssel nutzen alle diese Schritte denselben Claude-Client wie das Coding-Werkzeug. Amazon Bedrock über die IAM-Rolle des Runners deckt zum Beispiel auch Entwürfe und Review ab; dafür ist kein zusätzlicher Schlüssel nötig. Die unten beschriebenen Modell-Festlegungen (ANTHROPIC_DEFAULT_SONNET_MODEL und so weiter) gelten auch für diese Schritte.

Ein Runner, der nur Azure OpenAI oder einen OpenAI-Schlüssel hat, beantwortet diese Schritte mit diesem Anbieter. Für ein anderes Modell in diesen Schritten siehe Verschiedene Modelle für das Coding und die übrigen Schritte.

Für jeden dieser Schritte meldet der Runner kanman die Tokens und die geschätzten Modellkosten. In diesem Modus werden sie beim Eintrag des Schritts im Audit-Log festgehalten und zählen nicht gegen die Budgets des Teams, die Minuten und Runs zählen.

Was der Runner weitergibt

In diesem Modus sehen das Coding-Werkzeug und kanmans übrige Modellschritte die Umgebung des Runners, außer den Tokens von kanman selbst. Setz die Variablen deines Anbieters am Runner-Container. Beim Start nennt das Log des Runners die gefundenen Anbieter (zum Beispiel bedrock), nie deren Werte.

Für Befehle aus deinem Repository gilt das nicht: Die Builds und Tests, die das Coding-Werkzeug ausführt, sehen nie die Umgebung des Runners, sondern nur eine minimale Umgebung. Siehe Secrets des Runners.

Die folgenden Variablen lesen Claude Code und Codex. Um Modellversionen auf Bedrock, Vertex AI oder Foundry festzulegen, setz ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL und ANTHROPIC_DEFAULT_HAIKU_MODEL auf die in deinem Konto freigeschalteten Modell-IDs; kanmans Modellwahl pro Story löst sich dann auf diese auf.

Amazon Bedrock

Google Vertex AI

Microsoft Foundry

Codex mit Azure OpenAI

KI-Gateways in der Runner-Umgebung

Leitet dein Unternehmen den Modellverkehr über ein KI-Gateway, das nur in deinem Netz erreichbar ist, richte den Runner mit den Variablen darauf aus, die die Coding-Werkzeuge lesen. Das gilt für das Coding-Werkzeug und, sofern du kein eigenes Assistenzmodell einrichtest (nächster Abschnitt), auch für kanmans eigene Schritte.

OpenAI-kompatibles Gateway (kanmans eigene Schritte und Codex, wenn das Gateway die OpenAI Responses API anbietet):

Anthropic-kompatibles Gateway (Claude Code und kanmans eigene Schritte über denselben Client):

Claude Code braucht den Anthropic-kompatiblen Endpunkt, Codex die OpenAI Responses API des Gateways (/responses); aktuelle Codex-Versionen unterstützen Chat Completions nicht. Ein Gateway nur mit Chat Completions kann kanmans eigene Schritte bedienen, aber kein Coding-Werkzeug. Siehe Welches Coding-Werkzeug mit welchem Gateway funktioniert.

Ein Team, das seinen Gateway-Schlüssel in kanman hinterlegt (Stattdessen ein Gateway oder einen Proxy nutzen unter Workspace-Einstellungen > Modellzugang), braucht diese Variablen nicht: Der Runner erhält Schlüssel, Header und Modellnamen für jeden Run und jeden Schritt dieses Teams und speichert sie nie.

Beispiel: Codex und kanmans eigene Schritte über ein internes Gateway, das den Schlüssel im Header api-key erwartet:

docker run -d --name kanman-runner --restart unless-stopped \
  -e KANMAN_API_KEY=km_your_runner_token \
  -e RUNNER_EXECUTORS=codex \
  -e OPENAI_BASE_URL=https://ai-gateway.corp.example/v1 \
  -e OPENAI_API_KEY=your_gateway_key \
  -e AI_GATEWAY_AUTH_HEADER=api-key \
  -e 'AI_GATEWAY_HEADERS={"x-tenant-id":"acme"}' \
  -e AI_GATEWAY_MODEL=openai/gpt-5 \
  ghcr.io/kanman-ai/executor-host

Verschiedene Modelle für das Coding und die übrigen Schritte

Du kannst kanmans eigenen Schritten (Stories entwerfen, der Reviewer, Antworten in der Unterhaltung, Antworten aus dem Teamkontext, die Wartungs-Reviewer) ein anderes Modell geben als dem Coding-Werkzeug, zum Beispiel das KI-Gateway deines Unternehmens, während das Coding-Werkzeug weiter Claude nutzt. Alles wird auf dem Runner eingerichtet:

Reasoning-Modelle verwenden einen Teil ihrer Ausgabe auf das Nachdenken, bevor sie antworten. kanman lässt dafür Platz, und wenn eine Antwort trotzdem am Limit endet, fragt kanman einmal mit doppelt so viel Platz nach. Ist auch diese Antwort abgeschnitten, sagt dir kanman, dass dem Modell die Ausgabe-Tokens ausgegangen sind, statt einen kaputten Entwurf zu zeigen. Schick die Anfrage dann in kleineren Teilen oder erhöhe KANMAN_ASSISTANT_MAX_OUTPUT_TOKENS. Lehnt dein Gateway die Reasoning-Einstellung ab, wiederholt kanman den Aufruf von selbst einmal ohne sie; mit einem leeren Wert für KANMAN_ASSISTANT_REASONING_EFFORT sparst du dir diesen zusätzlichen Aufruf.

Welchen Modellzugang ein Schritt nutzt:

1. Den eigenen Schlüssel des Teams, wenn das Team in kanman einen nutzt.
2. Sonst das Assistenzmodell oben: das eigene des Teams (KANMAN_ASSISTANT_-Variablen im Modellzugang des Teams), sonst das des Runners, außer das Team bringt einen eigenen Modellzugang mit.
3. Sonst den Modellzugang des Coding-Werkzeugs: den eigenen des Teams auf deinen Runnern, sonst den des Runners.

Das Coding-Werkzeug sieht die KANMAN_ASSISTANT_-Variablen nie. Beim Start nennt das Log des Runners Host, Format und Modelle des Gateways, nie den Schlüssel. Der Eintrag jedes Schritts im Audit-Log sagt, welche der drei Quellen ihn beantwortet hat, mit seinen Tokens.

Beispiel: Claude auf Amazon Bedrock für das Coding und das Unternehmens-Gateway für alles andere:

services:
  kanman-runner:
    image: ghcr.io/kanman-ai/executor-host
    restart: unless-stopped
    environment:
      KANMAN_API_KEY: ${KANMAN_API_KEY}
      RUNNER_EXECUTORS: claude-code
      CLAUDE_CODE_USE_BEDROCK: "1"
      AWS_REGION: eu-central-1
      KANMAN_ASSISTANT_BASE_URL: https://aigateway.eu/core/v1
      KANMAN_ASSISTANT_API_KEY: ${GATEWAY_KEY}
      KANMAN_ASSISTANT_MODEL: mistral/mistral-large-2411
      KANMAN_ASSISTANT_MODEL_REVIEW: openai/gpt-5

Schritte über ein Gateway melden Tokens, aber keine Kosten, weil kanman die Preise des Gateways nicht kennt.

Beispiel mit Docker Compose

Ein Runner, der Claude Code über Amazon Bedrock mit der IAM-Rolle des Hosts anbietet:

services:
  kanman-runner:
    image: ghcr.io/kanman-ai/executor-host
    restart: unless-stopped
    environment:
      KANMAN_API_KEY: ${KANMAN_API_KEY}
      RUNNER_NAME: runner-fra-1
      RUNNER_EXECUTORS: claude-code
      CLAUDE_CODE_USE_BEDROCK: "1"
      AWS_REGION: eu-central-1
      ANTHROPIC_DEFAULT_SONNET_MODEL: eu.anthropic.claude-sonnet-4-5-20250929-v1:0

Derselbe Runner über Google Vertex AI mit eingebundenem Dienstkonto-Schlüssel:

services:
  kanman-runner:
    image: ghcr.io/kanman-ai/executor-host
    restart: unless-stopped
    environment:
      KANMAN_API_KEY: ${KANMAN_API_KEY}
      RUNNER_EXECUTORS: claude-code
      CLAUDE_CODE_USE_VERTEX: "1"
      CLOUD_ML_REGION: europe-west1
      ANTHROPIC_VERTEX_PROJECT_ID: acme-ai-prod
      GOOGLE_APPLICATION_CREDENTIALS: /secrets/gcp-key.json
    volumes:
      - ./gcp-key.json:/secrets/gcp-key.json:ro

Beispiel mit Kubernetes

Ein Runner mit Microsoft Foundry für Claude Code und Azure OpenAI für Codex. Die Schlüssel liegen in einem Kubernetes-Secret:

apiVersion: v1
kind: Secret
metadata:
  name: kanman-runner
type: Opaque
stringData:
  KANMAN_API_KEY: km_your_runner_token
  ANTHROPIC_FOUNDRY_API_KEY: your_foundry_key
  AZURE_OPENAI_API_KEY: your_azure_openai_key
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kanman-runner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kanman-runner
  template:
    metadata:
      labels:
        app: kanman-runner
    spec:
      containers:
        - name: runner
          image: ghcr.io/kanman-ai/executor-host
          envFrom:
            - secretRef:
                name: kanman-runner
          env:
            - name: RUNNER_EXECUTORS
              value: claude-code,codex
            - name: CLAUDE_CODE_USE_FOUNDRY
              value: "1"
            - name: ANTHROPIC_FOUNDRY_RESOURCE
              value: acme-foundry
            - name: AZURE_OPENAI_BASE_URL
              value: https://acme-openai.openai.azure.com/openai/v1
            - name: AZURE_OPENAI_DEPLOYMENT
              value: gpt-5

Mit Workload Identity (Vertex AI auf GKE) oder einer Managed Identity (Foundry auf AKS) lässt du den Schlüssel aus dem Secret weg und hängst die Identität an das Dienstkonto des Pods.

Verwandte Seiten

• Den Self-hosted Runner betreiben
• Was Modellanbieter sehen
• Richtlinien-Einstellungen
• Budgets und Kosten