1. CoderAI opens outbound WebSocket to AISBF broker
2. AISBF registers a live session keyed by `provider_id` and `client_id`
2. AISBF registers a scoped live session keyed by `provider_id` and `client_id`, plus `username` / `global` scope
3. CoderAI sends `register` metadata/capabilities over that socket
4. `CoderAIProviderHandler` prefers the live broker session when `coderai_config.broker_preferred=true`
5. AISBF forwards `models.list`, `chat.completions`, `capabilities`, `register`, and `proxy` operations through the active session
6. Response envelopes are correlated by `request_id` and returned to the original AISBF request
5. In multi-node deployments, AISBF forwards `models.list`, `chat.completions`, `capabilities`, `register`, and `proxy` operations through cache-backed broker queues keyed by the active session id
6. The AISBF node holding the actual WebSocket consumes queued requests, sends them to CoderAI, and publishes replies back through cache-backed reply keys
7. Response envelopes are correlated by `request_id` and returned to the original AISBF request from any AISBF node
### Configuration Notes
...
...
@@ -1408,7 +1410,7 @@ Token rotation is performed inline from the provider editor and updates the owni
### Important Limitation
Active broker routing still requires a live WebSocket, but AISBF now persists broker session metadata snapshots in `~/.aisbf/coderai_broker_sessions.json` so the dashboard can show last-known broker status after restart. Remote CoderAI must still reconnect before requests can be routed again.
Active broker routing still requires a live WebSocket, but AISBF now persists broker session metadata snapshots in `~/.aisbf/coderai_broker_sessions.json` and mirrors live broker state into the configured cache backend so clustered AISBF nodes can route through one connected broker client. Remote CoderAI must still reconnect before requests can be routed again after a total disconnect.
Enable `coderai` to appear in AISBF as a first-class provider with two modes:
This document is the single source of truth for implementing the CoderAI side of the AISBF broker and bridge integration.
1.**Direct local HTTP mode**: AISBF talks to a local OpenAI-compatible CoderAI server.
2.**NAT-friendly WebSocket bridge mode**: CoderAI connects outward and exchanges OpenAI-compatible requests/responses through framed WebSocket messages.
The target audience is another LLM or engineer implementing CoderAI, not AISBF.
CoderAI is the upstream implementation source for Studio-native endpoints, so capability and endpoint discovery should be explicit and machine-readable.
This document is mirrored in `docs/coderai-broker-implementation-reference.md` and should be kept identical in purpose and protocol coverage.
## AISBF broker mode
AISBF now includes a public broker-side WebSocket endpoint for outbound-only NAT traversal.
@@ -28,6 +30,13 @@ Registration tokens are resolved from the owning provider configuration. This me
- each user configures the token for their own user-scoped `coderai` providers
- a broker session is only usable by requests belonging to the same owner principal
Broker registration is now scope-aware:
- global providers register with `username=global`
- user-owned providers register with `username=<aisbf_username>`
- the same scoped path must be used by the CoderAI client when connecting over WebSocket
- deployments behind TLS termination or reverse proxies must connect with the externally visible `wss://...` URL and preserve proxy headers so AISBF can remain scheme-aware
The AISBF dashboard now exposes this token directly inside each `coderai` provider configuration:
- token input is stored in `coderai_config.registration_token`
...
...
@@ -83,6 +92,7 @@ Use provider type:
- For `transport=http`, AISBF uses the OpenAI Python client against `endpoint + /v1`.
- For `transport=websocket`, AISBF uses a WebSocket bridge and sends framed JSON envelopes.
- This keeps AISBF transport-simple and lets CoderAI own protocol correctness.
- Include `data: [DONE]\n\n` as one of the streamed chunks when the upstream semantics require it.
## Broker session visibility and persistence
## Broker session visibility, persistence, and multi-node routing
AISBF now tracks two broker states:
...
...
@@ -306,6 +323,15 @@ AISBF now tracks two broker states:
Persisted metadata is dashboard-facing only. It is used to show the last known session details after restart, but it is not treated as an active transport path until CoderAI reconnects.
For multi-node AISBF deployments behind a reverse proxy / load balancer:
- session status and ownership metadata are stored in the configured AISBF cache backend
- requests are enqueued into cache-backed broker queues keyed by broker session id
- the AISBF node holding the live WebSocket consumes queued requests and forwards them to CoderAI
- replies are written back through cache-backed reply keys so the AISBF node that originated the request can receive the result
Redis is the preferred backend for this distributed mode. SQLite/MySQL can operate as polling-based fallbacks. Memory/file cache backends are not suitable for cross-node broker routing.
Expected behavior:
- after reconnect, the persisted snapshot is refreshed with the new live session details
Streaming and progress responses may emit multiple envelopes with `event` values like `progress`, `output`, `log`, `data`, `chunk`, and finally `done` or `completed`.
Capability advertisements should include endpoint metadata for custom pipelines, including supported methods, streaming mode, expected input/output modalities, and whether multipart or binary transport is required.