AISBFA market for model access, not another closed AI silo.
AISBF can be the routing and access layer between people who need AI capacity and people who have models, GPUs, private endpoints, or local CoderAI workers to offer.
What the AISBF market is for
The market idea is simple: if you run useful model capacity, AISBF should make it possible to expose that capacity through controlled provider routes instead of sharing raw server URLs or API keys by hand.
Sell access to your models
Offer access to models you host: local LLMs, image/video/audio pipelines, private fine-tunes, CoderAI workers, RunPod endpoints, or other OpenAI-compatible backends.
Buy routed capacity
Consumers call AISBF routes through familiar OpenAI-compatible APIs while AISBF handles provider selection, credentials, quotas, failover, and policy.
Keep ownership clear
Provider definitions remain scoped to an owner: global/admin capacity or user-owned capacity. The broker identity must match the owner scope.
CoderAI turns local GPUs into sellable capacity.
CoderAI is the most direct local-provider path: run it on a workstation, home-lab GPU, rented GPU box, or private server; connect it to AISBF; then expose selected models through AISBF routes.
1. Run CoderAI
CoderAI exposes local OpenAI-compatible and multimodal endpoints for chat, images, audio, video, profiles, archives, and pipelines.
2. Connect broker mode
The CoderAI broker client dials AISBF over outbound WebSocket/WSS, authenticates with a provider-scoped registration token, and registers capabilities plus hardware metadata.
3. Publish through AISBF
AISBF can route requests to the connected worker through provider, rotation, and autoselect flows, without requiring the worker to expose an inbound public port.
Broker protocol: the seller path for local models
The broker protocol is what makes home/workstation/private GPU selling realistic. Instead of asking sellers to open firewall ports, CoderAI connects outward and keeps a long-lived session with AISBF.
Seller GPU machine ── outbound WSS ──▶ AISBF broker ── routed API ──▶ Buyers / apps
CoderAI provider_id + client_id OpenAI-compatible callsIdentity
provider_id, client_id, username, and registration_token identify exactly which provider and owner scope the worker belongs to.
Capabilities
CoderAI advertises hardware inventory, available endpoints, model capabilities, and Studio/native surfaces such as images, audio, video, and progress routes.
Routing
AISBF can call models.list, chat.completions, capabilities, and proxy operations, then return success, error, binary, or streaming envelopes.
Seller setup shape
A seller creates or receives an AISBF provider identity, puts the same identity into CoderAI, and keeps the worker connected.
{
"broker": {
"enabled": true,
"base_url": "https://aisbf.cloud",
"scope": "user",
"username": "seller-name",
"provider_id": "seller-coderai-gpu",
"client_id": "seller-workstation-01",
"registration_token": "provider-scoped-secret",
"transport": "websocket"
}
}How buyers use it
Buyers should not need to know whether a model is behind a cloud API, a CoderAI worker, a private RunPod, or a future community seller. They call a stable AISBF route and AISBF handles the rest.
Provider route
Directly use a seller/provider when you intentionally want that one model or worker.
Rotation
Pool several sellers/providers for reliability, weighted distribution, and cooldown after errors.
Autoselect
Use policy to choose between local/private, cheap, fast, high-context, media-capable, or hosted fallback routes.
Status and honesty
The broker protocol and CoderAI provider path are the technical foundation for this. The market page describes the intended product direction: selling access through controlled AISBF routes, with CoderAI as the outbound local-model seller path.
That is the right architecture because it separates the money/access layer from the model runtime. CoderAI can focus on running models; AISBF can focus on identity, routing, policy, quotas, and buyer/seller access.