Do you have better solution for the following several issues?

[yjcyxky]

I've been working with this library over the past few days and have encountered several areas where I ran into conflicting behaviors or ambiguous logic—particularly around configuration loading and validation.

I've summarized the questions and observations below for reference and discussion. Most of them center on how api_key, provider, and related fields are validated and normalized, as well as how environment variables are handled.

---

1. Should we switch to mode="after" for the validator?

Using @model_validator(mode="before") means fields like provider and api_key may still be None when validation runs, because default values and type coercion haven’t been applied yet. Would using mode="after" improve reliability by ensuring that all defaults are applied and types like SecretStr are already in place?

---

2. Should api_key always be normalized to SecretStr?

We currently assign values to api_key from various sources (explicit input, env vars, fallback lookups), which may result in it being either a str or a SecretStr. Should we always convert non-None values to SecretStr within the validator to ensure consistent internal usage and avoid mistakes when accessing the raw value?

---

3. Should we stop writing API keys into os.environ?

The current code writes the resolved api_key into os.environ, potentially exposing secrets in the process environment. Is this necessary, or should we keep API keys in memory only and let consumers explicitly manage their own integration logic?

---

4. Can we simplify API key resolution logic?

Right now we perform multiple checks in several branches to resolve the api_key, including checking explicit input, fallback keys like OPENAI_API_KEY, and possibly logging warnings. Would a clearer priority order (e.g. input > env-prefixed > provider env var) make the logic easier to follow and test?

---

5. Is the custom from_env() method needed?

Since BaseSettings already handles environment variable parsing (including .env files and prefixes), is our manual from_env() implementation necessary? Or can we just rely on cls() and let Pydantic handle the loading?

---

6. Should we refine provider/base_url handling?

When base_url is set, we currently override provider to "custom" even if it was originally one of the known providers (e.g., "openai"). This might block valid use cases like Azure/OpenAI-compatible endpoints. Should we be more conservative and only change provider to "custom" if it’s not a known one?

---

7. Can we downgrade some warnings to info logs?

Certain messages, like detecting a custom base_url, are currently logged at the warning level. Should we downgrade these to info to avoid alarming users for intentional setups?

---

[huang-sh]

@yjcyxky great comments!

1. I know provider and api_key will be None. BIOMINER_AI_LLM_PROVIDER and BIOMINER_AI_LLM_API_KEY are default field, But I hope when BIOMINER_AI_LLM_API_KEY is None. biominer-llm can get api key from other environment variable, like OPENAI_API_KEY, GEMINI_API_KEY, ANTHROPIC_API_KEY and others. for example, if you set BIOMINER_AI_LLM_PROVIDER=OPENAI, but BIOMINER_AI_LLM_API_KEY=None, I hope we can get api key from OPENAI_API_KEY
2. didn’t quite get what you mean.., but biominer-llm always hope get raw api_key for input, and default LLMConfig.api_key will be SecretStr.
3. biominer-llm has stop writing API keys into os.environ in previous commit 5679197
4. I think biominer-llm follows this logic(. input > biominer-prefixed-env var > provider env var). if something wrong, please show an example.
5. yes,we can remove from_env
6. there should also be some improvements. However, I think that for ChatGPT, unless it comes from OpenAI, everything else is custom.
7. the logger is introduced in 72b2ab7, I have change to logger.info

[huang-sh]

There are test cases for biominer-llm located in the tests
These cover manual input, .env configuration files, and mixed-priority tests.

For any conflicting behaviors or ambiguous logic, please provide concrete examples.

[yjcyxky]

When I used the following config:
BIOMINER_AI_LLM_PROVIDER=gemini
BIOMINER_AI_LLM_MODEL=gemini-2.5-flash
GOOGLE_API_KEY=xxx

Traceback (most recent call last):
File "/Users/jy006/miniconda3/envs/biominer-ai/bin/biominer-ai", line 5, in
from biominer_ai.cli import cli
File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/init.py", line 3, in
from .config import Config
File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/config.py", line 196, in
config = Config.from_env()
^^^^^^^^^^^^^^^^^
File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/config.py", line 107, in from_env
llm = LLMConfig()
^^^^^^^^^^^
File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/pydantic_settings/main.py", line 188, in init
super().init(
File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/pydantic/main.py", line 253, in init
validated_self = self.pydantic_validator.validate_python(data, self_instance=self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/biominer_llm/config.py", line 45, in adjust_llm_config
elif os.environ[f"{provider.upper()}_API_KEY"] is not None:
~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 679, in getitem
KeyError: 'GEMINI_API_KEY'

It seems the configuration logic is not consistent among different LLM providers.

[yjcyxky]

When I used the following config: BIOMINER_AI_LLM_PROVIDER=gemini BIOMINER_AI_LLM_MODEL=gemini-2.5-flash GOOGLE_API_KEY=xxx

Traceback (most recent call last): File "/Users/jy006/miniconda3/envs/biominer-ai/bin/biominer-ai", line 5, in from biominer_ai.cli import cli File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/init.py", line 3, in from .config import Config File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/config.py", line 196, in config = Config.from_env() ^^^^^^^^^^^^^^^^^ File "/Users/jy006/Documents/Code/BioMiner/biominer-ai/biominer_ai/config.py", line 107, in from_env llm = LLMConfig() ^^^^^^^^^^^ File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/pydantic_settings/main.py", line 188, in init super().init( File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/pydantic/main.py", line 253, in init validated_self = self.pydantic_validator.validate_python(data, self_instance=self) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Users/jy006/miniconda3/envs/biominer-ai/lib/python3.11/site-packages/biominer_llm/config.py", line 45, in adjust_llm_config elif os.environ[f"{provider.upper()}_API_KEY"] is not None: ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "", line 679, in getitem KeyError: 'GEMINI_API_KEY'

It seems the configuration logic is not consistent among different LLM providers.

I found that it’s fixed in the latest version, thanks. After reinstalling, the issue is gone.

[huang-sh]

@yjcyxky

There is a new approach to handling provider and base_url:

• If base_url is set but provider is not, then LLMConfig.provider will be custom.
• If base_url and provider are set, then LLMConfig.provider will use the specified value.

from biominer_llm.config import LLMConfig

config = LLMConfig(base_url="http://localhost", api_key="dummy")
assert config.provider == "custom"

config = LLMConfig(provider="openai", base_url="http://localhost", api_key="dummy")
assert config.provider == "openai"

config = LLMConfig(
    provider="biominer", base_url="http://localhost", api_key="dummy"
)
assert config.provider == "biominer"