added MiniMax, and made eval and compile configurable by MakiWinster72 · Pull Request #139 · VectifyAI/OpenKB

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72 · 2026-06-25T10:49:46Z

Added MiniMax as an option during init. After init, generates .env at the project root and automatically uses XXX_API_KEY, only falling back to LLM_API_KEY for unknown providers — making it easy for users to edit base URL and key.

and made eval and compile configurable in config.yaml so that users who would otherwise hit their subscription rate limits can dial down the concurrency.

just after init

…ig.yaml - Add eval_concurrency and compile_concurrency to DEFAULT_CONFIG - run_eval reads from <kb>/.openkb/config.yaml; falls back to EVAL_CONCURRENCY - compile_short_doc / compile_long_doc: param > config > DEFAULT_COMPILE_CONCURRENCY - openkb init writes both fields into new KB config.yaml

- Add --base-url CLI flag (-u) to `openkb init` for non-interactive setup - Prompt for base URL only when the chosen model's provider isn't in _KNOWN_PUBLIC_PROVIDERS (openai, anthropic, gemini, deepseek, ...) - Map the URL to the provider-specific *_API_BASE env var (OPENAI_API_BASE, OLLAMA_API_BASE, ...) via _PROVIDER_TO_BASE_ENV and write it alongside LLM_API_KEY in the KB-local .env (chmod 600) - _setup_llm_key reads the env var and applies it to litellm.api_base so LiteLLM uses the override on every request - Emit a post-init reminder pointing the user at .env and .openkb/config.yaml - .env.example: document the *_API_BASE convention - Tests: 9 new cases (public/custom provider, flag, key+url together, blank skip, existing .env preserved, control-char/length rejection, post-init reminder)

MiniMax ships two regional endpoints under the same ``minimax/`` LiteLLM provider prefix (global vs China), so the generic base-URL skip for known public providers doesn't apply. Detect ``minimax/`` models and run a dedicated region picker instead; the chosen URL is written as ``MINIMAX_API_BASE`` in the KB-local .env. - Add _MINIMAX_GLOBAL_URL / _MINIMAX_CHINA_URL constants - Add ``minimax`` to _KNOWN_PUBLIC_PROVIDERS and _PROVIDER_TO_BASE_ENV (-> MINIMAX_API_BASE) - Add MINIMAX_API_KEY to _KNOWN_PROVIDER_KEYS so _setup_llm_key propagates LLM_API_KEY to MiniMax for the Agents-SDK litellm provider - _prompt_minimax_region(): interactive picker that re-prompts on unrecognised input (1/Global default, 2/China) — a typo can't silently route the user to the wrong region - Non-TTY init falls back to the global endpoint silently; users who need China there can pass --base-url explicitly - Model picker text gains a MiniMax row (M2.7 / M3) Tests: 9 new cases — global/china via picker, default-global under non-TTY, --base-url overrides picker, invalid choice re-prompts, key + URL written together, _KNOWN_PROVIDER_KEYS / _PROVIDER_TO_BASE_ENV contain MiniMax, _setup_llm_key applies MINIMAX_API_BASE.

The region picker fired for ``minimax/`` models but its three short lines were easy to miss in the scroll of surrounding model / API-key / language prompts — users reported only seeing "key and language", which meant the picker silently routed them to the wrong region (or the model was never MiniMax to begin with). - Add blank-line + box-drawing separators and a "── MiniMax region ──" heading so the picker can't be confused with the prompts around it - Header text now also explains *why* the picker appears ("two regional endpoints under the same `minimax/` LiteLLM prefix") - Options re-numbered as `[1]` / `[2]` to match the prompt text - Test: new case covers the picker firing when the user TYPES the model interactively, not only when --model is passed (catches future regressions where the picker would be silently skipped) - Tests: update wording assertions to match the new visible text

Previously, ``openkb init`` skipped writing .env entirely when the user provided neither an API key nor a base URL. That left a freshly-initialised KB without any discoverable target for credentials — users had to know that ``LLM_API_KEY`` was the right name and that they could drop it into a file the CLI hadn't created yet. - .env is now ALWAYS created on init (chmod 0600), with commented placeholders for every field the user skipped. Missing fields show the exact env-var name to use (e.g. ``MINIMAX_API_BASE`` for MiniMax, ``ANTHROPIC_API_BASE`` for Anthropic) so the user can copy the line and uncomment it later. - Refactor: pull the .env content builder into ``_build_env_content()`` so it's unit-testable in isolation and stays in sync with whatever fields the active provider expects. - Output message adapts: ``Saved to .env: ...`` when values were written, ``Created .env with commented placeholders — fill in your API key before running compile.`` when everything was empty. Tests: - 3 new tests cover the builder directly (no provider, provider + active key, MiniMax-no-key) - ``test_init_base_url_blank_prompt_still_writes_env_with_comments`` replaces the old "no .env" assertion with the new always-create behaviour and verifies both placeholders appear commented and chmod 600 is applied even for an all-comments file - The ``LLM_API_KEY=sk...`` check elsewhere is replaced with a line-by-line scan that catches active assignments even when the string happens to appear inside a comment Co-Authored-By: Claude <noreply@anthropic.com>

Every LiteLLM provider reads its own ``*_API_KEY`` env var (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``GEMINI_API_KEY``, ...) and ``openkb init`` was writing everything under the generic ``LLM_API_KEY``. That works — ``_setup_llm_key`` propagated it to every known provider — but the .env file then looked generic and mysterious. Users reading the file wouldn't immediately see which variable their OpenAI / Anthropic / MiniMax key should land in. - Add ``_PROVIDER_KEY_ENV``: provider prefix → canonical LiteLLM key env var. Sources (LiteLLM docs, verified): * OPENAI_API_KEY docs.litellm.ai/docs/set_keys * ANTHROPIC_API_KEY docs.litellm.ai/docs/providers/anthropic * GEMINI_API_KEY docs.litellm.ai/docs/providers/gemini * DEEPSEEK_API_KEY docs.litellm.ai/docs/providers/deepseek * MISTRAL_API_KEY docs.litellm.ai/docs/providers/mistral * MOONSHOT_API_KEY docs.litellm.ai/docs/providers/moonshot * DASHSCOPE_API_KEY docs.litellm.ai/docs/providers/dashscope * OPENROUTER_API_KEY docs.litellm.ai/docs/providers/openrouter * MINIMAX_API_KEY user-specified * ZHIPUAI_API_KEY LiteLLM renamed the provider to "Z.AI" but the ``zhipuai/`` prefix is unchanged, so the env var stays the same. * ollama: no key (local server, ``None``) * vllm: HOSTED_VLLM_API_KEY (optional, per LiteLLM docs) - ``_build_env_content`` now writes the key under the provider-specific name and renders its commented placeholder to match. Unknown / custom providers fall back to ``LLM_API_KEY`` so legacy flows still work. - ``_setup_llm_key`` reads the provider-specific env var FIRST and only falls back to ``LLM_API_KEY`` when it's unset, so a user who follows the new .env format never sees the spurious "no key found" warning. - Keyless providers (ollama) get no key section at all — emitting a placeholder would mislead the user into hunting for a credential that doesn't exist. Tests: - Parametrised matrix covers all 10 known providers; asserts the active line uses the right ``*_API_KEY`` env var - ``_key_env_for_provider`` unit test (known / unknown / keyless) - ``_setup_llm_key`` reads provider-specific env var directly (no LLM_API_KEY needed) - ``test_init_ollama_provider_no_key_section``: no ``_API_KEY=`` line - Existing tests updated to assert on provider-specific env vars (``OPENAI_API_KEY``, ``ANTHROPIC_API_KEY``, ``MINIMAX_API_KEY``, ``HOSTED_VLLM_API_KEY``) instead of the generic ``LLM_API_KEY`` Co-Authored-By: Claude <noreply@anthropic.com>

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

MakiWinster72and others added 8 commits June 24, 2026 07:16

Merge branch 'dev'
b5b7d9b

Merge branch 'VectifyAI:main' into main
d11ff18

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

MakiWinster72 commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects