Add LLM Provider

Use this skill whenever a new agent engine or LLM provider needs to work behind AWF and it is unclear how to "set it up." AWF supports two fundamentally different integration paths — picking the wrong one is the most common source of confusion (e.g. "why is token-usage.jsonl empty for this engine?").

Step 1 — Determine how the engine talks to its LLM backend

Ask: does the engine call the provider's API directly (its own base URL, its own auth), or can it be configured to route through AWF's API-proxy sidecar? The sidecar is always enabled; --enable-api-proxy is deprecated and ignored. Its provider ports are http://172.30.0.30:10000 (OpenAI), :10001 (Anthropic), :10002 (Copilot), :10003 (Gemini), and :10004 (Vertex AI).

• If the engine has built-in support for pointing at AWF's api-proxy ports (env vars like OPENAI_BASE_URL, ANTHROPIC_BASE_URL rewritten to the sidecar) → Path A: Proxied provider.
• If the engine always calls its own hardcoded/native endpoint regardless of proxy env vars (e.g. Cursor CLI calling api2.cursor.sh / api3.cursor.sh directly), or manages its own credentials outside AWF → Path B: Direct-API engine.

When unsure, run the engine once with --keep-containers and inspect docker exec awf-squid cat /var/log/squid/access.log (see docs/squid_log_filtering.md) to see which hosts it actually contacts and whether traffic reaches the api-proxy sidecar or goes straight out through Squid.

Path A — Proxied provider (credentials injected by api-proxy)

Choose this when you want AWF to hold the API key/OIDC token and inject it, keeping secrets out of the agent container.

Use containers/api-proxy/providers/ADDING-A-PROVIDER.md for the adapter interface, then: