feat(api): add support for custom API base URL in configuration

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.

[mohammadmaso]

• Introduced resolve_api_base function to extract the api_base key from the configuration, ensuring it is a valid URL string.
• Updated _setup_llm_key to utilize the custom API base URL, falling back to the LLM_API_BASE environment variable if not set in the config.
• Enhanced LLM call functions to include the API base in request parameters.
• Modified build_query_agent to pass the API base as part of extra arguments.

This change allows users to configure a custom API endpoint for LLM requests, improving flexibility and integration with different environments.

[KylinMountain]

Thanks for the PR!

I think a custom api_base may already be configurable without code changes. OpenKB exposes LiteLLM's module settings verbatim through the litellm: passthrough block in .openkb/config.yaml (added in #137). LiteLLM has a module-level api_base global that litellm.completion() falls back to, so you can set it directly:

# .openkb/config.yamllitellm:
api_base: https://your-endpoint/v1

That routes both the compile path (_llm_call → litellm.completion) and the PageIndex calls through your custom endpoint. LiteLLM also picks up provider-native env vars automatically (OPENAI_API_BASE, AZURE_API_BASE, OLLAMA_API_BASE, …).

Could you give that a try and see whether it already covers your use case? If it does, we may not need the extra plumbing; and if there's a path it doesn't reach, that'd be useful to know so we can scope the change to just that gap.

[KylinMountain]

Thanks @mohammadmaso. A custom API base URL is already supported via the litellm: passthrough config block from #138 — e.g. litellm: {api_base: https://your-endpoint/v1} in .openkb/config.yaml sets it process-wide across every provider litellm routes to. A separate top-level api_base key duplicates that and introduces a precedence ambiguity between the two sources. Closing as redundant — appreciate the contribution.