AI summaries and BYOK

PatchArc's review is deterministic. The six sections are computed from recorded evidence, so you get the same review every time you seal the same Arc, and you can verify it without trusting a model. AI is an optional layer on top, and in 0.2.0 that layer is mostly plumbing: the key broker and the connection API exist; summaries are not generated yet.

What works without AI

Everything in the local loop: capture, the six-section review, sealing, verification, scopes, sharing. If you never touch this page, you lose nothing that the product does today.

Local provider config

config.yaml accepts a list of providers for the local engine:

ai:
  default_provider: anthropic
  providers:
    - name: anthropic
      kind: anthropic          # openai | anthropic | google | groq | openai-compatible | ollama
      mode: local              # the only mode the open-source engine accepts
      api_key_env: ANTHROPIC_API_KEY
      models:
        summary: claude-sonnet-4-5

The config is validated (mode must be local; name and kind are required), but no CLI command reads it yet. patcharc ai:add, ai:list, ai:use, ai:test, and ai:usage print a "not enabled in this build" message in 0.2.0.

Bring your own key (cloud)

The cloud can hold a provider key for your account so that hosted summaries run on your provider bill. Keys are never returned by any API and never sent to a model gateway from the API worker.

How a key is stored

1. You send the key once to POST /v1/ai/connections over TLS.
2. The API forwards it to the key-broker worker, which has no public route and is reachable only by service binding.
3. The broker encrypts the key with a fresh per-connection AES-256-GCM data-encryption key (DEK), then wraps the DEK with a versioned key-encryption key (KEK) held only by the broker. Both nonces and the KEK version are stored with the ciphertext.
4. The API stores ciphertext and metadata. Plaintext exists only inside the broker, only for the duration of one resolution call.

Register a key

$ TOKEN=$(jq -r .refresh_token ~/.patcharc/credentials.json)
$ curl -s https://api.patcharc.dev/v1/ai/connections \
    -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" \
    -d '{"name":"anthropic-main","provider":"anthropic","mode":"cloud_relay","api_key":"sk-ant-…"}'
{"id":"conn_…","name":"anthropic-main","provider":"anthropic","created_at":"…"}

Providers accepted: openai, anthropic, google, groq, mistral, openai-compatible, ollama. mode must be cloud_relay.

Manage connections

# list (metadata only; no key material)
$ curl -s https://api.patcharc.dev/v1/ai/connections -H "Authorization: Bearer $TOKEN"
# test that the broker can decrypt and reach the provider
$ curl -s -X POST https://api.patcharc.dev/v1/ai/connections/conn_…/test -H "Authorization: Bearer $TOKEN"
# revoke (soft delete)
$ curl -s -X DELETE https://api.patcharc.dev/v1/ai/connections/conn_… -H "Authorization: Bearer $TOKEN"

POST /v1/ai/connections/:id/rotate only increments the key version in 0.2.0; to change the key, create a new connection and revoke the old one.

Managed AI

Accounts have a credit wallet (GET /v1/ai/wallet) and a ledger. POST /v1/ai/jobs reserves credits and hands the job to the orchestrator, which routes to Workers AI models through the AI Gateway with content logging off. The orchestrator is a minimal stub in 0.2.0: it does not produce a summary that reaches an ArcLink, and costs are not settled. Treat managed AI as not yet available.

What this means for your data

• Your code is never sent to a model by the local CLI. There is no model in the local loop.
• A BYOK key is encrypted before it is stored and cannot be read back through any API.
• When summaries ship, the prompt will be built from the capsule you already chose to upload, nothing more.

See Security and privacy for the full posture.