Ollama generator discards max_tokens, temperature, top_k and context_len without warning

[Panchal-Sahil]

Steps to reproduce

OllamaGenerator and OllamaGeneratorChat accept max_tokens, temperature, top_k and
context_len, then never send them to Ollama.

The snippet below makes two calls to the same server and model with the same 10-token cap, one
through garak and one through the ollama client. It needs no scan or config file and takes about
15 seconds.

1. Pull any model and confirm the server is up: ollama pull llama3.1:8b && ollama ps
2. Run:

import ollama
from garak import _config
from garak.attempt import Conversation, Message, Turn

MODEL, PROMPT = "llama3.1:8b", "Count from 1 to 100, writing each number on its own line."

_config.load_base_config()
_config.plugins.generators = {"ollama": {"OllamaGeneratorChat": {"max_tokens": 10}}}
from garak.generators.ollama import OllamaGeneratorChat

conv = Conversation([Turn(role="user", content=Message(text=PROMPT))])
a = OllamaGeneratorChat(name=MODEL, config_root=_config).generate(conv)[0].text

b = ollama.Client("127.0.0.1:11434").chat(
    model=MODEL,
    messages=[{"role": "user", "content": PROMPT}],
    options={"num_predict": 10},
).get("message", {}).get("content", "")

print(f"via garak      : {len(a):5} chars")
print(f"via raw client : {len(b):5} chars")

3. Output:

via garak      :   306 chars      <- counted all the way to 100
via raw client :    19 chars      <- stopped at "3"

Both calls use the same client library, server and model. They differ in one respect: whether garak
populates options. Ollama honours num_predict when garak sends it.

It reproduces on every run, on both 0.15.1 and main. I did not test older releases.

The same effect shows through a full scan. encoding.InjectROT13, 32 prompts, seed: 1337,
max_tokens: 10 on both generators against the same server, where a 10-token cap should give
responses near 40 characters:

Generator	n	Median	p90	Max	Runtime
ollama (native)	32	323	901	1711	118.90s
openai.OpenAICompatible	32	41	53	63	15.04s

Were you following a specific guide/tutorial or reading documentation?

No.

Expected behavior

Configured generation parameters reach the model, or garak warns that this generator ignores them.

Current behavior

garak drops them with nothing in the log. Sampling falls back to whatever the Modelfile specifies,
nothing caps output length, and the context window stays at the server default.

Neither _call_model populates options, the key Ollama reads generation parameters from:

# OllamaGeneratorChat._call_model
response = self.client.chat(
    model=self.name,
    messages=messages,
)

# OllamaGenerator._call_model
response = self.client.generate(self.name, prompt.last_message().text)

Only timeout and host survive, because __init__ consumes both when it builds the client. The
outgoing HTTP request body has no options key at all.

garak version

• 0.15.1 from pypi
• Also reproduced on main at 548619981bb9fd8f21245335af4c893dc9d7293d (0.16.0.pre1), checked
  2026-07-27

Additional Information

1. Operating system: Fedora Linux 44 (Workstation Edition), kernel 7.1.5
2. Python version: 3.12.13
3. Install method: pypi for 0.15.1; direct git checkout for main
4. Logs: report.jsonl or garak.log available on request; the reproduction needs neither.
5. Execution config: --config with a nested
   plugins.generators.ollama.OllamaGeneratorChat block setting max_tokens: 10, plus
   run.soft_probe_prompt_cap: 32 and run.seed: 1337.
6. Hardware: not a factor. The options key is absent from the request body regardless of
   backend. Server side: Ollama 0.12.11 serving llama3.1:8b Q4_K_M (digest 46e0c10c039e); any
   model reproduces it.

Impact on results

context_len carries the worst consequence. Ollama defaults to a 4096-token window and truncates
payloads overflowing it. encoding probes inflate their payloads, so Ollama cuts the long ones. The
model then appears to resist an attack it received only part of, and garak scores it as a pass.

Related issues

• Not changing ollama host after updating host value inside generator config #1166 fixed this same class of bug for host on this generator. That fix did not extend to
  generation parameters. Closest precedent.
• Not a duplicate of --generator_options '{"uri": "..."}' is ignored by OpenAICompatible generator #1527. That one was --generator_options failing to apply before client
  init, with a nested YAML config as the workaround. My runs used that YAML path: the values arrive
  on the instance correctly and get dropped later, when garak assembles the request.
• Searched the tracker for ollama, max_tokens, temperature and generator options across open
  and closed issues and PRs, plus the web. Nothing else covers this.

[Panchal-Sahil]

Happy to work on this if you decide it's worth fixing. I have a local branch that forwards the parameters and passes the existing suite, so a PR can follow once you've had a look.

[jmartin-tech]

Recent enhancements to the BedrockGenerator suggest a way forward for this the project is starting to standardize on.

For anyone that want to offer enhancement to support passing some of these more common values to ollama please see the discussion in #1842, and consider the patterns in OpenAICompatible, LiteLLM, LLMGenerator, and AnthropicGenerator around extra_params and suppressed_params in the DEFAULT_PARAMS configuration options. While there is not strict guidance in place as each library client will have different inspection options parameter name mappings there are some good general flows to build from in expanding the interaction.

[Panchal-Sahil]

I'd like to work on this, I'll go over #1842 and the BedrockGenerator pattern you pointed at, and follow that shape.

Could you assign it to me?