You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
--llm flag is parsed but not used; OMB_ANSWER_LLM env default is 'groq' (not 'gemini') #15
Two compound issues in the answer-LLM wiring at commit 45fa380 mean omb run --llm gemini still dispatches answer generation to Groq:
--llm is parsed but never threaded to get_answer_llm(). At src/memory_bench/cli.py#L39 the flag is captured into a local llm variable, but cli.py#L68 calls get_answer_llm() with no arguments:
Combined effect: the --llm flag is decorative; OMB_ANSWER_LLM env var is the only way to actually pick an answer LLM, and the default disagrees with --llm's documented default of "gemini".
Reproducer
git clone https://github.com/vectorize-io/agent-memory-benchmark.git
cd agent-memory-benchmark
git checkout 45fa380
# Even though --llm gemini matches the documented default, Groq is invoked:unset OMB_ANSWER_LLM
uv run --python 3.12 omb run --dataset locomo --memory bm25 --split locomo10 --query-limit 1 --llm gemini
# → answer phase hits memory_bench/llm/groq.py:32 (GroqLLM.generate) and# APIConnectionError / 401 / etc. depending on GROQ_API_KEY presence and# network egress to api.groq.com.
Workaround for callers today: OMB_ANSWER_LLM=gemini omb run ... (env var wins because --llm is unused).
Matches the Gemini 2.5 Flash judge baseline landed in 45fa380 and the README/CLI documented default. The current "groq" default makes the CLI ship with internally inconsistent semantics.
Happy to file a PR with both fixes if helpful — let me know whether you'd prefer one combined PR or two separated by concern.
Activity