Answer the OpenAI-shaped calls from wherever the deployment says

[knowhycodata]

Closes #12.

OPENAI_BASE_URL decides where an OpenAI-shaped request is answered. Unset, that is OpenAI. Set, it is any endpoint speaking the same API: a gateway in front of several providers, a proxy, or a model on hardware you control.

The API server already honoured it — resolveModel in the pinned @copilotkit/runtime@1.67.1 reads process.env.OPENAI_BASE_URL for every openai/* model, so package built-in agents have always been movable, just undocumented. The two shipped Bots did not follow, and compose handed neither of them anything that could carry one. This closes that split: one line now moves the whole deployment rather than the half of it that happens to run outside Docker.

Changes

File	Change
agent-bot/src/index.ts	Passes baseURL to the OpenAI client.
agent-langgraph/src/index.ts	Passes configuration.baseURL to ChatOpenAI.
docker-compose.yml	Hands OPENAI_BASE_URL to both Bot services.
.env.example, docs/configuration.md, README.md	Documents it, with a worked example.
tests/compose.test.ts	Asserts both Bots receive it.

A base URL rather than another BOT_PROVIDER branch, because the API is the contract. BOT_PROVIDER=anthropic and BOT_PROVIDER=google are different APIs, not different URLs for this one, and are untouched. Model names travel verbatim in BOT_MODEL and in the tenant package's default_model, since an endpoint names its own catalogue.

The docs carry the two caveats that bite in practice: not every catalogue entry accepts tools, and a Bot without tool calling cannot drive its computer; and BOT_RESPONSES_API=true needs an endpoint implementing the Responses API, not only chat completions.

Verification

Both Bots were run against a live OpenAI-compatible gateway — OPENAI_BASE_URL=https://llmtr.com/v1, whose catalogue is public at GET /v1/models and needs no key — and both streamed AG-UI end to end with a real tool call, which is what a Bot needs to drive its computer:

data: {"type":"RUN_STARTED","threadId":"t4","runId":"r4"}
data: {"type":"TOOL_CALL_START","toolCallId":"...","toolCallName":"browser_navigate","parentMessageId":"msg_r4"}
data: {"type":"TOOL_CALL_ARGS","toolCallId":"...","delta":"{\"url\":\"http://example.com\"}"}
data: {"type":"TOOL_CALL_END","toolCallId":"..."}
data: {"type":"RUN_FINISHED","threadId":"t4","runId":"r4"}

The server path was verified by reading resolveModel in the pinned runtime rather than run, since that needs Intelligence credentials. It splits on the first / only, so a namespaced default_model: openai/gpt-4o becomes openai/openai/gpt-4o and reaches the endpoint as openai/gpt-4o. The exact pin makes that stable.

bun run format:check, bun run lint and bun run typecheck pass. bun test passes except for the PostgreSQL integration tests and the symlink tests, which fail identically on an unmodified checkout on this machine — no database, and Windows symlinks need elevation. The new compose test passes.

[davidmckayv]

Nice PR. Thank you.