My local LLM kept talking itself in circles until I changed two settings

Published Aug 9, 2026, 2:00 PM EDT Nolen began their writing career in 2019, with three years dedicated to editing the Creative section at MakeUseOf. Their expertise lies at the crossroads of technology and creativity, covering areas like photography, video editing, and graphic design. Outside of work, you'll often find Nolen diving into a good book, writing their own stories, or playing video games. Running a local LLM long enough teaches you what a spiral looks like pretty quickly. Sometimes the response opens with the same rephrased intro line three times, and other times whole paragraphs restate the point that was just made. My first instinct was to blame the model and that the solution was to swap it out for a bigger one, then a smaller one, then a completely different family. But you just end up back where you started. So, that means the fix isn't necessarily the model. It's two sliders in the settings panel that most people never touch until they're forced to fiddle with them due to bad results. The majority of runners have them and they both do specific and distinct jobs, and both of them also get conflicted a lot… Want to stay in the loop with the latest in AI? The XDA AI Insider newsletter drops weekly with deep dives, tool recommendations, and hands-on coverage you won't find anywhere else on the site. Subscribe by modifying your newsletter preferences! Local models don't ship configured for you, they ship configured for benchmarks And the runner you're using adds its own guesses on top The defaults that come with any local model aren't tuned for the conversation you're actually having. They're tuned for the eval that got the model onto the leaderboard, and those don't really reflect how many of us use these models in day-to-day. At least, I don't think most of us are giving the model five carefully selected examples per request or handing it chain-of-thought directions, most of the time. But the defaults you get are still calibrated for that world. Then the inference engine, or runner, adds another variable on top of all that. LM Studio, Ollama, and llama.cpp all use the same core engine, but they ship with their own defaults sitting over the model's, and those defaults can differ between them. What you're actually running is a config someone else decided would probably work for most people. Quantization amplifies the problem even more. Most people running local aren't touching FP16, and are on Q4 or Q5 to fit within their VRAM. Repetition and looping are among the first behaviors when the precision drops, and smaller models suffer from this harder than the larger ones. The model family itself has a personality too. For example, Qwen tends to over-explain, and Gemma can get repetitive with longer sessions. Repeat penalty and presence penalty do different jobs, and most guides conflate them One handles the exact words, the other handles the ideas underneath them Repeat penalty and presence penalty sound like they do the same thing, and a lot of coverage online kind of treats them like they do. But they don't. Repeat penalty is a token-level control that was formalized in a 2019 paper called CTRL, and it penalizes specific tokens that have already shown up in the output. The neutral value is 1.0, and above that discourages reuse. The sweet spot is small, and a nudge to 1.05 or 1.1 usually cleans up those word-level loops without too many side effects. But push it to 1.2 and the model can start dodging common words like "the" just to avoid the penalty, and that's a sure way to get really weird outputs. Quick side note on the naming here… llama.cpp calls this repeat_penalty. In OpenAI-style APIs the closest equivalent is frequency_penalty. Hugging Face uses repetition_penalty as a single multiplier. These are just different names for the same thing. Then there's presence penalty. It also works at the token level, but the math is different. Repeat penalty scales up the harder a token gets reused, and presence penalty just applies a flat penalty to any token that's already appeared. Once is enough, and appearing ten times doesn't get you penalized any harder than appearing once. It's neutral at 0 and typically ranges from -2.0 to 2.0. In practice, presence penalty pushes the model away from the exact words it just used, and different words usually end up dragging the model onto a different topic. So that's the reason behind the "circling back to the same point four different ways" behavior. There isn't actually semantic understanding from the model, it's just a side effect of the model running out of easy tokens, giving the appearance of it understanding on the concept level. If you want to see the math laid out, I recommend checking out this publication by Michael Brenndoerfer, an AI expert who understands the mathematics behind LLMs. Here's what actually changed when I tested them side by side The differences weren't subtle at all Of course, to demonstrate, I gave this a little test, but the applications and implications are broader. The test was the same prompt three times in a fresh chat each run: "Explain what a REST API is in three different ways: for a beginner, for someone who knows HTTP, and for someone building one." I kept everything else standardized at the same values, including the model, temperature, min-p, system prompt, and so on. Nothing changed except the two penalties. The first run had both repeat and presence at their neutral levels. The response looked fine at first glance, but Qwen fell into its usual over-explanation habit and every section restated the same "REST API is a set of rules" line before actually adding anything new. This kind of demonstrates that for this model in particular, if you don't reel it in, it can get a little annoying. Run two was both cranked up, with repeat at 1.3 and presence at 1.8. The response started fine, then somewhere around the end it stopped generating actual sentences and turned into a word-salad list of geography terms. "Wetlands bog fen swamp moraine kettle pond lake river stream." I had to stop the generation manually because it was only getting worse. That's what overcorrection looks like, since the penalties starve the model of legitimate high-probability tokens that it just reaches for whatever's left. The last run was the balanced middle with repeat at 1.1 and presence at 0.6. It came back with a clean three-part explanation, and each audience got a genuinely different and useful angle from the same prompt. The takeaway here is that these sliders reward (or punish) tiny movements. My values worked for a Qwen 9B in LM Studio, but they're just a starting point rather than a rule of thumb. Temperature matters alongside them too - for example, if you're at 0 or 0.1 the penalties are fighting a model that's already deterministic, but somewhere between 0.6 and 0.8 gives them room to work. My only recommendation here is to not leave them at their defaults, but to also not crank them all the way. It's going to be about finding the middle sweet spot depending on everything else: your model, the quant, your temp, the other settings and samplings, system prompt, and most importantly, the actual task you're doing. Coding work wants repeat penalty near neutral because code legitimately repeats syntax. Reasoning models tend to need lower presence penalty since they're supposed to revisit ideas. And smaller quants like Q3 or Q4 want lighter penalties in general because the model's already fragile at that precision. If the model's Hugging Face page has a recommended config, honestly just start there. I was blaming the wrong thing every time my local model started spiralling These two tiny sliders and about ten seconds of adjusting them is the gap between a model that spirals and one that stays on point. The only catch is that the values aren't transferable, meaning what works for you today might not tomorrow, depending on the surrounding environment of the task, model, and other settings. A habit worth building is knowing these two sliders exist and what they each do, and being willing to adjust them when a session starts drifting.