Connect CLIProxyAPI to Fasten Share for Codex and Claude Capacity

CLIProxyAPI can expose supported Codex, Claude, and related capabilities through standardized interfaces. Fasten Share can publish those interfaces so consumers can discover and call them while the service handles routing, metering, and settlement. CLIProxyAPI acts as a protocol and access layer; Fasten Share provides the shared network around it.

This setup is intended for advanced users who are comfortable with local proxies, model protocols, and account policies. Confirm that the relevant account, subscription, or API permits your intended use and sharing pattern. The ability to sign in and make a request is not automatically authorization to forward it to a third party.

Understand the complete path

Consumer tool (Codex / Claude Code / curl)
        ↓
Fasten Share service
        ↓
Fasten Share producer client
        ↓
CLIProxyAPI
        ↓
Upstream capability currently supported by CLIProxyAPI

This path includes at least three distinct credentials:

1. CLIProxyAPI administration or login credentials;
2. a local CLIProxyAPI key used by the Fasten Share producer;
3. a Fasten Share consumer API key used to call the generated service endpoint.

Generate, store, and rotate them separately. Never place any of them in a public tutorial, screenshot, or repository.

Install and validate CLIProxyAPI

CLIProxyAPI changes quickly, so use its current official repository and documentation for installation, sign-in, and configuration. Once it is running, verify the listening address and inspect the current model list through the supported management interface.

Do not copy model names from an old tutorial. An incorrect model identifier will also make Fasten Share health checks fail.

Create a dedicated CLIProxyAPI key for Fasten Share. It should appear only in CLIProxyAPI configuration and in the producer backend stored on your Fasten Share machine.

Test the protocol directly

For a Codex or OpenAI Responses-style endpoint:

curl http://127.0.0.1:8317/v1/responses \
  -H "Authorization: Bearer CLI_PROXY_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-codex-model","input":"reply with OK"}'

For a Claude or Anthropic Messages-style endpoint:

curl http://127.0.0.1:8317/v1/messages \
  -H "x-api-key: CLI_PROXY_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model":"your-claude-model",
    "max_tokens":32,
    "messages":[{"role":"user","content":"reply with OK"}]
  }'

Replace the port, key, and model with your real configuration. Continue only when the direct endpoint returns a valid model response. Resolve 401, 404, model not found, and exhausted-capacity errors in CLIProxyAPI first.

Add the producer backend in Fasten Share

Install and sign in to the Fasten Share client, then add a backend on the producer page.

Codex / Responses setup

Field	Starting point
Base URL	http://127.0.0.1:8317
Protocol	openai-response
Version prefix	/v1
API key	Your dedicated CLI_PROXY_KEY
Models	Exact model names that passed direct testing
Consumer tools	Only tools you have validated, or at least curl

Claude / Anthropic setup

Field	Starting point
Base URL	http://127.0.0.1:8317
Protocol	anthropic
Version prefix	/v1
API key	Your dedicated CLI_PROXY_KEY
Models	Exact Claude model names that passed direct testing
Consumer tools	Validated Claude support, or at least curl

Keep /v1 out of the base URL when it is already in the version-prefix field. Start with conservative concurrency and the default multiplier, then adjust in small steps only after stable testing.

Handle Docker addresses carefully

The examples assume CLIProxyAPI and the Fasten Share client run on the same host. If Fasten Share runs in Docker, 127.0.0.1 inside the container does not reach CLIProxyAPI on the host.

Use host.docker.internal where available, a reachable host LAN address, or a service name on a shared Docker network. Run the direct test from the producer client’s environment. Do not expose an administration port or unauthenticated proxy to the public internet for convenience.

Complete an end-to-end Fasten Share test

After the producer is healthy and registered, switch to the consumer workflow:

1. Create or select a Fasten Share consumer API key.
2. Search for the model you just published.
3. Select your own producer node.
4. Copy the generated curl command or tool configuration.
5. Send a real request and inspect its regular or streaming response.
6. Compare consumer output and producer logs to find the first failing step.

The final request must use the Fasten Share consumer key, not CLI_PROXY_KEY. If direct CLIProxyAPI access works but Fasten Share fails, confirm that the producer still reports running, registered, and healthy, and that the protocol, model, and final request path agree.

Respect feature and policy boundaries

Neither CLIProxyAPI nor Fasten Share can create a capability the upstream does not support. Protocol conversion may omit stateful Responses features, hosted tools, background mode, WebSocket, or parts of tool calling. Consumers should select a node based on its published protocol and supported tools.

Upstream account policy can change, and CLIProxyAPI itself evolves. Recheck official documentation and current Fasten Share fields regularly. Stop sharing immediately if authorization, credentials, or usage become uncertain.

Stable-operation checklist

• Direct CLIProxyAPI requests work consistently.
• Model names come from the current model list, not an old article.
• Administration credentials, CLIProxyAPI key, and consumer key are separate.
• The base URL and version prefix do not duplicate each other.
• Docker or cross-host addressing works from the producer environment.
• Only tested protocols and consumer tools are published.
• Sharing rights and protocol-conversion limits are understood.
• A full consumer-to-backend request succeeds.

For general backend field guidance, read How to Connect Compatible Model APIs. To configure the consumer side next, use How to Use Shared Models in AI Tools.