LLM Providers

SiteKit uses an LLM to help author and repair adapters. The generated SDKs, MCP tools, tests, auth handlers, and production data pipelines are deterministic and do not need model credentials.

Runtime Boundary

LLM-assisted commands:

• sitekit analyze
• sitekit review
• sitekit repair
• sitekit onboard --mode autonomous
• Drafting operation names, descriptions, schemas, transforms, tests, and docs.

Deterministic commands:

• sitekit generate
• sitekit test
• Generated TypeScript and Python clients.
• Generated MCP servers.
• Auth, session refresh, pagination, retries, validation, and writes.

The adapter IR is the contract between those worlds. LLM output becomes useful only after it is written into reviewed files, tested, and versioned.

Provider Config

SiteKit does not ship with a shared hosted model key. For local use, bring your own key through environment variables, 1Password, Keychain, or another local secret provider.

llm:
  provider: openai
  model: gpt-5
  apiKey:
    env: OPENAI_API_KEY
  redaction:
    mode: strict

Provider adapters should be pluggable:

llm:
  provider: anthropic
  model: claude-sonnet
  apiKey:
    env: ANTHROPIC_API_KEY

llm:
  provider: openai-compatible
  baseUrl: http://localhost:11434/v1
  model: local-web-discovery
  apiKey:
    value: unused

CLI

The LLM config can live in a workspace config file:

sitekit init
sitekit config set llm.provider openai
sitekit config set llm.model gpt-5
sitekit config set llm.apiKey.env OPENAI_API_KEY

Or be supplied for one command:

SITEKIT_LLM_PROVIDER=openai \
SITEKIT_LLM_MODEL=gpt-5 \
OPENAI_API_KEY=sk-... \
sitekit analyze source_portal

Secrets

Discovery and repair need model credentials. Generated clients do not.

For personal use:

llm:
  provider: openai
  apiKey:
    onePasswordItem: SiteKit OpenAI
    field: credential

For cloud jobs or team infrastructure:

llm:
  provider: openai
  apiKey:
    secretRef: projects/sitekit/secrets/openai-api-key

Runtime website credentials are configured separately from LLM credentials. That separation keeps adapter execution usable in cron jobs and pipelines without granting those jobs access to model keys.

Redaction

SiteKit should redact captures before sending them to an LLM. The model needs routes, methods, shapes, example values, screen context, and user intent. It does not need passwords, session cookies, bearer tokens, CSRF values, or raw personally sensitive records.

llm:
  redaction:
    mode: strict
    keepExamples:
      ids: true
      dates: true
      enumValues: true
      names: false
      emails: false

The redacted capture should be saved as a fixture so discovery is repeatable and so repair prompts can be reviewed without exposing live secrets.

MCP

The generated MCP server does not call an LLM. It exposes deterministic tools with descriptions generated from reviewed adapter metadata.

The MCP host may have its own model. That model reads tool descriptions and chooses when to call source_portal_events_list or destination_portal_records_update, but SiteKit itself is not making model calls in the MCP request path.

Autonomous Browsing

Autonomous discovery uses an LLM with browser-control tools during onboarding. That model can inspect screens, click links, fill safe draft fields, and explain which traffic appears relevant to the onboarding goal.

The generated adapter should not depend on that model. After discovery, useful behavior is captured as adapter IR, Playwright scripts, schemas, tests, and reviewed docs.

Team Mode

A later hosted or team version can centralize LLM usage:

• One organization-level model provider config.
• Per-site redaction policy.
• Audit logs for discovery and repair prompts.
• Model budgets for expensive analysis runs.
• Optional approved-model lists for regulated workflows.

That is a control-plane feature. The core adapter packages should still be portable, versioned, and runnable without SiteKit hosting.