Enhancement: Support authentication for custom OpenAI-compatible endpoints (openai: + base_url)

[romankurnovskii]

Feature Suggestion

The Problem
Currently, in condor/acp/pydantic_ai_client.py, when a custom base_url is configured alongside an openai model prefix (e.g., pointing to vLLM, a secure corporate proxy, or third-party providers like DeepInfra / Together AI using custom URLs), the API key is hardcoded to "not-needed":
pydantic_ai_client

The Proposed Solution https://github.com/hummingbot/condor/pull/104/changes

Impact

Without this behavior, developers cannot deploy Hummingbot Condor in production-grade cloud environments where inference endpoints must be secured.

Production Security Blocked: Secure gateways (like vLLM running with token authentication or enterprise LiteLLM proxies) are currently completely unusable because the client always injects a dummy "not-needed" key.

@rapcmia @david-hummingbot

[HerShin5]

I think the important distinction here is that Codex/OAuth login and OpenAI-compatible HTTP authentication are two different auth paths.

For a custom base_url, Condor should not assume the endpoint accepts the same credential source as api.openai.com or that a dummy key is harmless. Many production gateways reject missing/dummy bearer tokens even when they implement the OpenAI chat schema correctly.

A small contract that would cover this safely:

• If base_url is explicitly configured, allow an explicit API key or env var to be passed through to the OpenAI client.
• Keep the current not-needed behavior only for known local endpoints that really do not authenticate, or make it an explicit opt-in.
• Add a regression test for openai: model prefix + custom base_url + OPENAI_API_KEY (or Condor-specific env var), asserting the constructed client receives both the custom URL and non-dummy key.
• Add a second test for a local no-auth endpoint so Ollama/vLLM-without-auth remains easy.
• In logs/errors, print only the base URL host/path and whether a key was configured, never the key value.

This would also avoid confusing users who run secure vLLM/LiteLLM/enterprise gateways: a 401 from the gateway should mean "bad or missing gateway credential", not "Condor silently replaced my key with not-needed".

Disclosure: I'm associated with/evaluating KiroForge. A gateway such as https://kiroforge.cloud/v1 is exactly the kind of OpenAI-compatible endpoint I would include in a smoke test here: it should behave like a normal OpenAI-compatible HTTP API, but still require the client to respect both base_url and bearer auth instead of relying on OpenAI/Codex-specific login state.

[lianzhiweivincent-cloud]

The key/auth distinction here matters a lot for production gateways.

If base_url is explicitly configured, I would not silently replace the key with a placeholder. A secure OpenAI-compatible endpoint usually needs both pieces to be preserved: the custom URL and a real bearer token.

A safe contract would be:

1. custom base_url + explicit API key/env var are passed through together
2. local no-auth endpoints keep an explicit opt-in path
3. logs show host/path and whether auth was configured, without printing secrets

That makes it much easier to debug 401s from real gateways versus missing credentials in the client.

I wrote a short checklist for OpenAI-compatible endpoint wiring here:
https://black-eagle-ai.vercel.app/guides/chinese-ai-openai-sdk/?src=github-condor-117

Disclosure: I work on Black Eagle AI. The checklist is generic and only meant as a debugging note.