[GH-ISSUE #10575] Setting priority of Ollama under Windows #84642

New Issue

GiteaMirror · 2026-05-09T21:15:28-05:00

GiteaMirror commented

2026-05-09 21:15:28 -05:00

Originally created by @pereswa on GitHub (May 5, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/10575

Originally assigned to: @dhiltgen on GitHub.

I noticed that Ollama runs the instance running an active model with "above normal" priority (I hope that's the correct translation for German "Höher als normal") in Windows 10 & 11.
Unfortunatelly this instance is then completely blocking the whole PC when processing a request - it becomes completely unresponsive until Ollama is finished (or cancelled via Ctrl+C).

Therefore I tried to start the server with "below normal" priority - but that doesn't work:
Every instance loading a model is started with "above normal" priority.
Today I always check the priority before sending a request to make sure it doesn't block my PC.

I didn't find a solution for this - maybe there is a environment variable for this issue?
I didn't find any documentation about these - two are mentioned in FAQ "Setting environment variables on Windows".

So, I wish there was either an environment variable to set instance priority or the priority was inherited from the server.

While looking for a solution I also noticed when limiting the instance running a model to certain CPU cores (simulating a "below normal" priority ;) this instance becomes very very very slow. E.g. if limited to 4 of 6 cores, it runs with like 5% of the performance as before when it had all 6 cores.

Originally created by @pereswa on GitHub (May 5, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/10575 Originally assigned to: @dhiltgen on GitHub. I noticed that Ollama runs the instance running an active model with "above normal" priority (I hope that's the correct translation for German "Höher als normal") in Windows 10 & 11. Unfortunatelly this instance is then completely blocking the whole PC when processing a request - it becomes completely unresponsive until Ollama is finished (or cancelled via Ctrl+C). Therefore I tried to start the server with "below normal" priority - but that doesn't work: Every instance loading a model is started with "above normal" priority. Today I always check the priority before sending a request to make sure it doesn't block my PC. I didn't find a solution for this - maybe there is a environment variable for this issue? I didn't find any documentation about these - two are mentioned in FAQ "Setting environment variables on Windows". So, I wish there was either an environment variable to set instance priority or the priority was inherited from the server. While looking for a solution I also noticed when limiting the instance running a model to certain CPU cores (simulating a "below normal" priority ;) this instance becomes very very very slow. E.g. if limited to 4 of 6 cores, it runs with like 5% of the performance as before when it had all 6 cores.

GiteaMirror added the windows feature request labels 2026-05-09 21:15:29 -05:00

GiteaMirror commented

2026-05-09 21:15:36 -05:00

@mrpras commented on GitHub (May 9, 2025):

Try Process Tamer - was the lightest solution for me in terms of something I want to leave running constantly and it's simple, just works.

www donationcoder com/software/mouser/popular-apps/process-tamer

@mrpras commented on GitHub (May 9, 2025): Try Process Tamer - was the lightest solution for me in terms of something I want to leave running constantly and it's simple, just works. www donationcoder com/software/mouser/popular-apps/process-tamer

GiteaMirror commented

2026-05-09 21:15:38 -05:00

@pereswa commented on GitHub (May 14, 2025):

This tool doesn't seem to work on Windows 10 or 11.

@pereswa commented on GitHub (May 14, 2025): This tool doesn't seem to work on Windows 10 or 11.

GiteaMirror commented

2026-05-09 21:15:39 -05:00

@pereswa commented on GitHub (May 26, 2025):

I found the reason for this behaviour:
https://github.com/ollama/ollama/blob/main/llm/llm_windows.go#L22

The explanation "Setting Above Normal priority class ensures when running as a "background service" with "programs" given best priority, we aren't starved of cpu cycles" seems to be valid for current and recent but not for older hardware.

On a i3-1115G4 Ollama runs fine with above normal priority.
But on my i5-8500t it grabs all ressources and renders the PC unresponsive while processing requests.
Both running Windows 10.

I just tried "How to Permanently Set Priority Processes Using Registry Editor":
https://answers.microsoft.com/en-us/windows/forum/all/how-to-permanently-set-priority-processes-using/df82bd40-ce52-4b84-af34-4d93da17d079
And it works, kind of:

I started the server with: start "Ollama" /low "%LOCALAPPDATA%\Programs\Ollama\ollama app.exe"
-> it runs with Low (Niedrig) OK

Subsequently started programs are started with th priority set via registry, as described above.
-> these run with Below normal (Niedriger als Normal) OK

But the also subsequently started model instance overrides the registry setting (nor inherits priority from server) and sets its own priority.
-> the model runs with Above normal (Höher als normal) Not OK

So, the current implementation overrides all local settings and preferences.

Maybe this should be seen as a support for older/weaker hardware fix.

@pereswa commented on GitHub (May 26, 2025): I found the reason for this behaviour: https://github.com/ollama/ollama/blob/main/llm/llm_windows.go#L22 The explanation _"Setting Above Normal priority class ensures when running as a "background service" with "programs" given best priority, we aren't starved of cpu cycles"_ seems to be valid for current and recent but not for older hardware. On a i3-1115G4 Ollama runs fine with above normal priority. But on my i5-8500t it grabs all ressources and renders the PC unresponsive while processing requests. Both running Windows 10. I just tried "How to Permanently Set Priority Processes Using Registry Editor": https://answers.microsoft.com/en-us/windows/forum/all/how-to-permanently-set-priority-processes-using/df82bd40-ce52-4b84-af34-4d93da17d079 And it works, kind of: I started the server with: start "Ollama" /low "%LOCALAPPDATA%\Programs\Ollama\ollama app.exe" -> it runs with Low (Niedrig) _OK_ Subsequently started programs are started with th priority set via registry, as described above. -> these run with Below normal (Niedriger als Normal) _OK_ But the also subsequently started model instance overrides the registry setting (nor inherits priority from server) and sets its own priority. -> the model runs with Above normal (Höher als normal) **_Not OK_** ![Image](https://github.com/user-attachments/assets/63430ef8-6e84-43cf-8c6a-7dfa03872599) So, the current implementation overrides all local settings and preferences. Maybe this should be seen as a support for older/weaker hardware fix.

GiteaMirror commented

2026-05-09 21:15:40 -05:00

@mrpras commented on GitHub (May 27, 2025):

This tool doesn't seem to work on Windows 10 or 11.

I'm using it on Windows 10 right now to "tame" Ollama and some other tasks. You can also set things to higher priority.

Otherwise you could try "system informer" which is much deeper but also does have the option to save priorities per process.

@mrpras commented on GitHub (May 27, 2025): > This tool doesn't seem to work on Windows 10 or 11. I'm using it on Windows 10 right now to "tame" Ollama and some other tasks. You can also set things to higher priority. Otherwise you could try "system informer" which is much deeper but also does have the option to save priorities per process.

GiteaMirror commented

2026-05-09 21:15:40 -05:00

@pereswa commented on GitHub (May 27, 2025):

That's strange. I tried it on both versions and it did nothing.
The build in "task list" showed the running tasks but all with 0% CPU usage.

The developer's programs look all very Windows 7-ish or older ;)
But it's/was nice to share the stuff he made probably for his own usage.

I now have a batch file (WMIC process where name="ollama.exe" CALL setpriority "below normal") linked to my task bar - whenever Ollama gets out of control, relief is just one click (and 2-3 seconds) away.
As Ollama is the only program with such strange behaviour, I can live with this fix.
Nonetheless I think this "above normal" priority setting for a non-system program should be fixed - I hope someone has a heart for older/weaker hardware.

@mrpras, thank you for trying to help me :)

@pereswa commented on GitHub (May 27, 2025): That's strange. I tried it on both versions and it did nothing. The build in "task list" showed the running tasks but all with 0% CPU usage. The developer's programs look all very Windows 7-ish or older ;) But it's/was nice to share the stuff he made probably for his own usage. I now have a batch file (WMIC process where name="ollama.exe" CALL setpriority "below normal") linked to my task bar - whenever Ollama gets out of control, relief is just one click (and 2-3 seconds) away. As Ollama is the only program with such strange behaviour, I can live with this fix. Nonetheless I think this "above normal" priority setting for a non-system program should be fixed - I hope someone has a heart for older/weaker hardware. @mrpras, thank you for trying to help me :)

GiteaMirror commented

2026-05-09 21:15:40 -05:00

@mrpras commented on GitHub (May 28, 2025):

@mrpras, thank you for trying to help me :)

Happy to try :)

A couple of final thoughts though - possibly windows defender is blocking the execution of the process tamer (I always strip out defender because it's rubbish). It might also be a lack of the correct VC Redistributables (you can install the whole lot via a pack such as this - https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/

Also you might try to set the priority in the registry
https://answers.microsoft.com/en-us/windows/forum/all/how-to-permanently-set-priority-processes-using/2f9ec439-5333-4625-9577-69d322cfbc5e

@mrpras commented on GitHub (May 28, 2025): > [@mrpras](https://github.com/mrpras), thank you for trying to help me :) Happy to try :) A couple of final thoughts though - possibly windows defender is blocking the execution of the process tamer (I always strip out defender because it's rubbish). It might also be a lack of the correct VC Redistributables (you can install the whole lot via a pack such as this - https://www.techpowerup.com/download/visual-c-redistributable-runtime-package-all-in-one/ Also you might try to set the priority in the registry https://answers.microsoft.com/en-us/windows/forum/all/how-to-permanently-set-priority-processes-using/2f9ec439-5333-4625-9577-69d322cfbc5e

GiteaMirror commented

2026-05-09 21:15:41 -05:00

@LanceJZ commented on GitHub (Jun 11, 2025):

Even on not old/weak hardware it makes it so if you try to do anything else on the system it causes pain. Please fix so you can either adjust using a environment variable or something. Having to do a work around is a pain.

@LanceJZ commented on GitHub (Jun 11, 2025): Even on not old/weak hardware it makes it so if you try to do anything else on the system it causes pain. Please fix so you can either adjust using a environment variable or something. Having to do a work around is a pain.

GiteaMirror commented

2026-05-09 21:15:41 -05:00

@LanceJZ commented on GitHub (Jun 11, 2025):

That's strange. I tried it on both versions and it did nothing. The build in "task list" showed the running tasks but all with 0% CPU usage.

The developer's programs look all very Windows 7-ish or older ;) But it's/was nice to share the stuff he made probably for his own usage.

I now have a batch file (WMIC process where name="ollama.exe" CALL setpriority "below normal") linked to my task bar - whenever Ollama gets out of control, relief is just one click (and 2-3 seconds) away. As Ollama is the only program with such strange behaviour, I can live with this fix. Nonetheless I think this "above normal" priority setting for a non-system program should be fixed - I hope someone has a heart for older/weaker hardware.

@mrpras, thank you for trying to help me :)

I tried WMIC process where name="ollama.exe" CALL setpriority "below normal" but I got ERROR:
Description = Invalid query

Oh, so that was in Powershell, doh. Is there a way to run this as a Powershell script?

@LanceJZ commented on GitHub (Jun 11, 2025): > That's strange. I tried it on both versions and it did nothing. The build in "task list" showed the running tasks but all with 0% CPU usage. > > The developer's programs look all very Windows 7-ish or older ;) But it's/was nice to share the stuff he made probably for his own usage. > > I now have a batch file (WMIC process where name="ollama.exe" CALL setpriority "below normal") linked to my task bar - whenever Ollama gets out of control, relief is just one click (and 2-3 seconds) away. As Ollama is the only program with such strange behaviour, I can live with this fix. Nonetheless I think this "above normal" priority setting for a non-system program should be fixed - I hope someone has a heart for older/weaker hardware. > > [@mrpras](https://github.com/mrpras), thank you for trying to help me :) I tried WMIC process where name="ollama.exe" CALL setpriority "below normal" but I got ERROR: Description = Invalid query Oh, so that was in Powershell, doh. Is there a way to run this as a Powershell script?

GiteaMirror commented

2026-05-09 21:15:42 -05:00

@pereswa commented on GitHub (Jun 12, 2025):

Hi, @LanceJZ. I simplified the solution in the meantime.

Just create a Shortcut on your desktop and put this in the target field:

C:\Windows\System32\cmd.exe /c WMIC process where name="ollama.exe" CALL setpriority "below normal"

For "Run:" choose "Minimized".
(I use the blue downward arrow icon in shell32.dll as icon ;)

Then drag it to your taskbar.

When running Ollama and just before sending a request, just click on it.

@pereswa commented on GitHub (Jun 12, 2025): Hi, @LanceJZ. I simplified the solution in the meantime. Just create a Shortcut on your desktop and put this in the target field: `C:\Windows\System32\cmd.exe /c WMIC process where name="ollama.exe" CALL setpriority "below normal"` For "Run:" choose "Minimized". (I use the blue downward arrow icon in shell32.dll as icon ;) Then drag it to your taskbar. When running Ollama and just before sending a request, just click on it.

GiteaMirror commented

2026-05-09 21:15:44 -05:00

@dhiltgen commented on GitHub (Jul 5, 2025):

I'm not quite sure what the right answer is, but we added this bump in priority to address what numerous users were seeing where the ollama serve running at "normal" priority was getting starved of CPU and inference speeds were horribly slow. "Above normal" fixed that problem.

@dhiltgen commented on GitHub (Jul 5, 2025): I'm not quite sure what the right answer is, but we added this bump in priority to address what numerous users were seeing where the `ollama serve` running at "normal" priority was getting starved of CPU and inference speeds were horribly slow. "Above normal" fixed that problem. - https://github.com/ollama/ollama/blob/main/llm/llm_windows.go#L9 - https://github.com/ollama/ollama/pull/6905

GiteaMirror commented

2026-05-09 21:15:45 -05:00

@pereswa commented on GitHub (Jul 20, 2025):

Hi @dhiltgen ,
thank you for adding the reference to the initial change.

I understand you fixed the issue many users had with setting the priority to "above normal".
But it causes other users to have issues running Ollama - probably on weaker machines (like a i5-8500t).

Like @Lukasr29, I don't need an immedieate answer on my PC, but I'm fine letting Ollama produce an answer in the background.
I even prefer to run Ollama at "below normal" than "normal" - thus not slowing my foreground tasks.
Unfortunately the always performed set to "above normal" when a model is loaded or reloaded blocks the PC completely.

>ollama run -h
Run a model

Usage:
  ollama run MODEL [PROMPT] [flags]

Flags:
      --format string      Response format (e.g. json)
  -h, --help               help for run
      --insecure           Use an insecure registry
      --keepalive string   Duration to keep a model loaded (e.g. 5m)
      --nowordwrap         Don't wrap words to the next line automatically
      --verbose            Show timings for response

Environment Variables:
      OLLAMA_HOST                IP Address for the ollama server (default 127.0.0.1:11434)
      OLLAMA_NOHISTORY           Do not preserve readline history

As the "above normal" priority is set when a model is (re)loaded, it probably makes sense to make the desired priority setting part of the run command. That would add more flexibility than setting an environment variable.
It probably could be simplified to the desired use case: --background (for "below normal") or --foreground (for "above normal").
Or "above normal" as default with an optional flag like --belownormal for weaker PCs which stay responsive with this priority.

Unfortunately I'm not familiar with the language Ollama is coded in, nor the environment.
So, I rely on someone who is capable and willing to help me (and the other users with weaker machines).

@pereswa commented on GitHub (Jul 20, 2025): Hi @dhiltgen , thank you for adding the reference to the initial change. I understand you fixed the issue many users had with setting the priority to "above normal". But it causes other users to have issues running Ollama - probably on weaker machines (like a i5-8500t). Like @Lukasr29, I don't need an immedieate answer on my PC, but I'm fine letting Ollama produce an answer in the background. I even prefer to run Ollama at "below normal" than "normal" - thus not slowing my foreground tasks. Unfortunately the always performed set to "above normal" when a model is loaded or reloaded blocks the PC completely. ``` >ollama run -h Run a model Usage: ollama run MODEL [PROMPT] [flags] Flags: --format string Response format (e.g. json) -h, --help help for run --insecure Use an insecure registry --keepalive string Duration to keep a model loaded (e.g. 5m) --nowordwrap Don't wrap words to the next line automatically --verbose Show timings for response Environment Variables: OLLAMA_HOST IP Address for the ollama server (default 127.0.0.1:11434) OLLAMA_NOHISTORY Do not preserve readline history ``` As the "above normal" priority is set when a model is (re)loaded, it probably makes sense to make the desired priority setting part of the run command. That would add more flexibility than setting an environment variable. It probably could be simplified to the desired use case: --background (for "below normal") or --foreground (for "above normal"). Or "above normal" as default with an optional flag like --belownormal for weaker PCs which stay responsive with this priority. Unfortunately I'm not familiar with the language Ollama is coded in, nor the environment. So, I rely on someone who is capable and willing to help me (and the other users with weaker machines).

GiteaMirror commented

2026-05-09 21:15:45 -05:00

@pereswa commented on GitHub (Aug 22, 2025):

Update:
I came to the conclusion that this issue is probably linked to the cores-threads relation.
I noticed that on PCs with hyper-threading CPUs there is no issue - Ollama runs with above-normal priority and the system is responsive.
But on PCs with CPUs w/o hyper-threading (cores=threads) - especially weaker ones - Ollama even can even crash after blocking the system for several minutes. I have lost some nice discussions due to this aleady :(

On a very weak G5400t (2 cores/4 threads) w/o GPU but 16 GB RAM Ollama works (but too slow) and the system is still responsive and usable. Likewise Ollama works fine on a i7-8700t (w/o GPU) or Ryzen 7 7435 HS (with RTX 4060) and the system is responsive.

But on a i5-7500 (4/4) or i5-8500t (6/6) w/o GPU but 32 GB RAM Ollama grabs all CPU power and blocks the user out.

I noticed related discussions about why Ollama isn't utilizing all threads but only real cores:
we allocate 1 thread per real core, and don't create 2 threads accidentally based on hyperthreads, which yields thrashing and much poorer performance

So, Ollama does not utilize the whole CPU on systems with a CPU with hyper-threading (because hyper-threading makes unused CPU resources available). But Ollama utilizes the whole CPU on systems with CPU w/o hyper-threading b/c no ressources left.
Should this be considered a bug, as it can crash Ollama and can make the PC unresponsive?

I noticed - beside the work-around described above - I can prevent the issue by setting num_thread to the number of CPU cores - 1.
(btw. num_thread is not described for the "/set parameter" command, but works)
Maybe running with one thread less than cores available on CPUs w/o hyper-threading could be a general solutions?

@pereswa commented on GitHub (Aug 22, 2025): Update: I came to the conclusion that this issue is probably linked to the cores-threads relation. I noticed that on PCs with hyper-threading CPUs there is no issue - Ollama runs with above-normal priority and the system is responsive. But on PCs with CPUs w/o hyper-threading (cores=threads) - especially weaker ones - Ollama even can even crash after blocking the system for several minutes. I have lost some nice discussions due to this aleady :( On a very weak G5400t (2 cores/4 threads) w/o GPU but 16 GB RAM Ollama works (but too slow) and the system is still responsive and usable. Likewise Ollama works fine on a i7-8700t (w/o GPU) or Ryzen 7 7435 HS (with RTX 4060) and the system is responsive. But on a i5-7500 (4/4) or i5-8500t (6/6) w/o GPU but 32 GB RAM Ollama grabs all CPU power and blocks the user out. I noticed related discussions about why Ollama isn't utilizing all threads but only real cores: [we allocate 1 thread per real core, and don't create 2 threads accidentally based on hyperthreads, which yields thrashing and much poorer performance](https://github.com/ollama/ollama/issues/2929#issuecomment-1981312519) So, Ollama does not utilize the whole CPU on systems with a CPU with hyper-threading (because hyper-threading makes _unused_ CPU resources available). But Ollama utilizes the whole CPU on systems with CPU w/o hyper-threading b/c no ressources left. Should this be considered a bug, as it can crash Ollama and can make the PC unresponsive? I noticed - beside the work-around described above - I can prevent the issue by setting num_thread to the number of CPU cores - 1. (btw. num_thread is not described for the "/set parameter" command, but works) Maybe running with one thread less than cores available on CPUs w/o hyper-threading could be a general solutions?

GiteaMirror commented

2026-05-09 21:15:46 -05:00

@kymograph commented on GitHub (Aug 30, 2025):

There is a pr waiting quite a while already for review to configure the process priority with an environment variable https://github.com/ollama/ollama/pull/8751

Would love to see this being merged.

@kymograph commented on GitHub (Aug 30, 2025): There is a pr waiting quite a while already for review to configure the process priority with an environment variable https://github.com/ollama/ollama/pull/8751 Would love to see this being merged.

Sign in to join this conversation.

Branches Tags

main

hoyyeva/fix-claude-channels-env

parth-update-hermes-launch

hoyyeva/vscode-extension-docs-update

parth-gemma4-chat-template-renderer

parth-api-status-context-length

hoyyeva/wire-up-context-length

hoyyeva/claude-code-context-doc

jmorganca/investigate-issue-17046

hoyyeva/hermes-docs

jmorganca/agent-loop-style

hoyyeva/openclaw

parth-agent-loop

hoyyeva/ollama-vscode-extension

brucemacd/cache-metrics

brucemacd/hermes-desktop

hoyyeva/docs-vscode

parth-input-style-experiment

brucemacd/docs-glm52

hoyyeva/poc-docs

Parth/mlx-launch-recommendations

parth-first-time-app-cli-experience

test/darwin-xcode-pin

improve-cloud-model-recommendations

hoyyeva/goose-docs

jmorganca/context-limit-fixes

hoyyeva/qwen-doc

hoyyeva/vscode-docs

jmorganca/remove-mlx-imagegen-code

parth-copilot-token-length-defaults

hoyyeva/poolside-windows

laguna-support

jmorganca/harden-markdown-rendering

laguna-renderer-parser

laguna-llamacpp

codex/make-integration-hidden-and-lunchable

brucemacd/omp-docs

pdevine/gguf-mtp-oldstyle

hoyyeva/migrate-pi

hoyyeva/anthropic-local-image-path

parth-launch-codex-app

hoyyeva/anthropic-reference-images-path

parth-anthropic-reference-images-path

brucemacd/download-before-remove

hoyyeva/editor-config-repair

parth-mlx-decode-checkpoints

parth/hide-claude-desktop-till-release

parth-add-claude-code-autoinstall

release_v0.22.0

pdevine/manifest-list

codex/fix-codex-model-metadata-warning

pdevine/addressable-manifest

brucemacd/launch-fetch-reccomended

jmorganca/llama-compat

launch-copilot-cli

release_v0.20.7

parth-auto-save-backup

parth-test

jmorganca/gemma4-audio-replacements

fix-manifest-digest-on-pull

hoyyeva/vscode-improve

brucemacd/install-server-wait

parth/update-claude-docs

brucemac/start-ap-install

pdevine/mlx-update

pdevine/qwen35_vision

drifkin/api-show-fallback

mintlify/image-generation-1773352582

hoyyeva/server-context-length-local-config

jmorganca/faster-reptition-penalties

jmorganca/convert-nemotron

parth-pi-thinking

pdevine/sampling-penalties

jmorganca/fix-create-quantization-memory

dongchen/resumable_transfer_fix

pdevine/sampling-cache-error

jessegross/mlx-usage

hoyyeva/openclaw-config

hoyyeva/app-html

pdevine/qwen3next

brucemacd/sign-sh-install

brucemacd/tui-update

brucemacd/usage-api

jmorganca/launch-empty

fix-app-dist-embed

mxyng/mlx-compile

mxyng/mlx-quant

mxyng/mlx-glm4.7

mxyng/mlx

brucemacd/simplify-model-picker

jmorganca/qwen3-concurrent

fix-glm-4.7-flash-mla-config

drifkin/qwen3-coder-opening-tag

brucemacd/usage-cli

fix-cuda12-fattn-shmem

ollama-imagegen-docs

parth/fix-multiline-inputs

brucemacd/config-docs

mxyng/model-files

mxyng/simple-execute

fix-imagegen-ollama-models

mxyng/async-upload

jmorganca/lazy-no-dtype-changes

imagegen-auto-detect-create

parth/decrease-concurrent-download-hf

fix-mlx-quantize-init

jmorganca/x-cleanup

usage

imagegen-readme

jmorganca/glm-image

mlx-gpu-cd

jmorganca/imagegen-modelfile

parth/agent-skills

parth/agent-allowlist

parth/signed-in-offline

parth/agents

parth/fix-context-chopping

improve-cloud-flow

parth/add-models-websearch

parth/prompt-renderer-mcp

jmorganca/native-settings

jmorganca/download-stream-hash

jmorganca/client2-rebased

brucemacd/oai-chat-req-multipart

jessegross/multi_chunk_reserve

grace/additional-omit-empty

grace/mistral-3-large

mxyng/tokenizer2

mxyng/tokenizer

jessegross/flash

hoyyeva/windows-nacked-app

mxyng/cleanup-attention

grace/deepseek-parser

hoyyeva/remember-unsent-prompt

parth/add-lfs-pointer-error-conversion

parth/olmo2-test2

hoyyeva/ollama-launchagent-plist

nicole/olmo-model

parth/olmo-test

mxyng/remove-embedded

parth/render-template

jmorganca/intellect-3

parth/remove-prealloc-linter

jmorganca/cmd-eval

nicole/nomic-embed-text-fix

mxyng/lint-2

hoyyeva/add-gemini-3-pro-preview

hoyyeva/load-model-list

mxyng/expand-path

mxyng/environ-2

hoyyeva/deeplink-json-encoding

parth/improve-tool-calling-tests

hoyyeva/conversation

hoyyeva/assistant-edit-response

hoyyeva/thinking

origin/brucemacd/invalid-char-i-err

parth/improve-tool-calling

jmorganca/required-omitempty

grace/qwen3-vl-tests

mxyng/iter-client

parth/docs-readme

nicole/embed-test

pdevine/integration-benchstat

parth/remove-generate-cmd

parth/add-toolcall-id

mxyng/server-tests

jmorganca/glm-4.6

jmorganca/gin-h-compat

drifkin/stable-tool-args

pdevine/qwen3-more-thinking

parth/add-websearch-client

nicole/websearch_local

jmorganca/qwen3-coder-updates

grace/deepseek-v3-migration-tests

mxyng/fix-create

jmorganca/cloud-errors

pdevine/parser-tidy

revert-12233-parth/simplify-entrypoints-runner

parth/enable-so-gpt-oss

brucemacd/qwen3vl

jmorganca/readme-simplify

parth/gpt-oss-structured-outputs

revert-12039-jmorganca/tools-braces

mxyng/embeddings

mxyng/gguf

mxyng/benchmark

mxyng/types-null

parth/move-parsing

mxyng/gemma2

jmorganca/docs

mxyng/16-bit

mxyng/create-stdin

pdevine/authorizedkeys

mxyng/quant

parth/opt-in-error-context-window

brucemacd/cache-models

brucemacd/runner-completion

jmorganca/llama-update-6

brucemacd/benchmark-list

brucemacd/partial-read-caps

parth/deepseek-r1-tools

mxyng/omit-array

parth/tool-prefix-temp

brucemacd/runner-test

jmorganca/qwen25vl

brucemacd/model-forward-test-ext

parth/python-function-parsing

jmorganca/cuda-compression-none

drifkin/num-parallel

drifkin/chat-truncation-fix

jmorganca/sync

parth/python-tools-calling

drifkin/array-head-count

brucemacd/create-no-loop

parth/server-enable-content-stream-with-tools

qwen25omni

mxyng/v3

brucemacd/ropeconfig

jmorganca/silence-tokenizer

parth/sample-so-test

parth/sampling-structured-outputs

brucemacd/doc-go-engine

parth/constrained-sampling-json

jmorganca/mistral-wip

brucemacd/mistral-small-convert

parth/sample-unmarshal-json-for-params

brucemacd/jomorganca/mistral

pdevine/bfloat16

jmorganca/mistral

brucemacd/mistral

pdevine/logging

parth/sample-correctness-fix

parth/sample-fix-sorting

jmorgan/sample-fix-sorting-extras

jmorganca/temp-0-images

brucemacd/parallel-embed-models

brucemacd/shim-grammar

jmorganca/fix-gguf-error

bmizerany/nameswork

jmorganca/faster-releases

bmizerany/validatenames

brucemacd/err-no-vocab

brucemacd/rope-config

brucemacd/err-hint

brucemacd/qwen2_5

brucemacd/logprobs

brucemacd/new_runner_graph_bench

progress-flicker

brucemacd/forward-test

brucemacd/go_qwen2

pdevine/gemma2

jmorganca/add-missing-symlink-eval

mxyng/next-debug

parth/set-context-size-openai

brucemacd/next-bpe-bench

brucemacd/next-bpe-test

brucemacd/new_runner_e2e

brucemacd/new_runner_qwen2

pdevine/convert-cohere2

brucemacd/convert-cli

parth/log-probs

mxyng/next-mlx

mxyng/cmd-history

parth/templating

parth/tokenize-detokenize

brucemacd/check-key-register

bmizerany/grammar

jmorganca/vendor-081b29bd

mxyng/func-checks

jmorganca/fix-null-format

parth/fix-default-to-warn-json

jmorganca/qwen2vl

jmorganca/no-concat

parth/cmd-cleanup-SO

brucemacd/check-key-register-structured-err

parth/openai-stream-usage

parth/fix-referencing-so

stream-tools-stop

jmorganca/degin-1

brucemacd/install-path-clean

brucemacd/push-name-validation

brucemacd/browser-key-register

jmorganca/openai-fix-first-message

jmorganca/fix-proxy

jessegross/sample

parth/disallow-streaming-tools

dhiltgen/remove_submodule

jmorganca/ga

jmorganca/mllama

pdevine/newlines

pdevine/geems-2b

jmorganca/llama-bump

mxyng/modelname-7

mxyng/gin-slog

mxyng/modelname-6

jyan/convert-prog

jyan/quant5

paligemma-support

pdevine/import-docs

jmorganca/openai-context

jyan/paligemma

jyan/p2

jyan/palitest

bmizerany/embedspeedup

jmorganca/llama-vit

brucemacd/allow-ollama

royh/ep-methods

royh/whisper

mxyng/api-models

mxyng/fix-memory

jyan/q4_4/8

jyan/ollama-v

royh/stream-tools

roy-embed-parallel

bmizerany/hrm

revert-5963-revert-5924-mxyng/llama3.1-rope

royh/embed-viz

jyan/local2

jyan/auth

jyan/local

jyan/parse-temp

jmorganca/template-mistral

jyan/reord-g

royh-openai-suffixdocs

royh-imgembed

royh-embed-parallel

jyan/quant4

royh-precision

jyan/progress

pdevine/fix-template

jyan/quant3

pdevine/ggla

mxyng/update-registry-domain

jmorganca/ggml-static

mxyng/create-context

jyan/v0.146

mxyng/layers-from-files

build_dist

bmizerany/noseek

royh-ls

royh-name

timeout

mxyng/server-timestamp

bmizerany/nosillyggufslurps

royh-params

jmorganca/llama-cpp-7c26775

royh-openai-delete

royh-show-rigid

jmorganca/enable-fa

jmorganca/no-error-template

jyan/format

royh-testdelete

bmizerany/fastverify

language_support

pdevine/ps-glitches

brucemacd/tokenize

bruce/iq-quants

bmizerany/filepathwithcoloninhost

mxyng/split-bin

bmizerany/client-registry

jmorganca/if-none-match

native

jmorganca/native

jmorganca/batch-embeddings

jmorganca/initcmake

jmorganca/mm

pdevine/showggmlinfo

modenameenforcealphanum

bmizerany/modenameenforcealphanum

jmorganca/done-reason

jmorganca/llama-cpp-8960fe8

ollama.com

bmizerany/filepathnobuild

bmizerany/types/model/defaultfix

rmdisplaylong

nogogen

bmizerany/x

modelfile-readme

bmizerany/replacecolon

jmorganca/limit

jmorganca/execstack

jmorganca/replace-assets

mxyng/tune-concurrency

jmorganca/testing

whitespace-detection

jmorganca/options

upgrade-all

scratch

cuda-search

mattw/airenamer

mattw/allmodelsonhuggingface

mattw/quantcontext

mattw/whatneedstorun

brucemacd/llama-mem-calc

mattw/faq-context

mattw/communitylinks

mattw/noprune

mattw/python-functioncalling

rename

mxyng/install

pulse

remove-first

editor

mattw/selfqueryingretrieval

cgo

mattw/howtoquant

api

matt/streamingapi

format-config

mxyng/extra-args

shell

update-nous-hermes

cp-model

upload-progress

fix-unknown-model

fix-model-names

delete-fix

insecure-registry

ls

deletemodels

progressbar

readme-updates

license-layers

skip-list

list-models

modelpath

matt/examplemodelfiles

distribution

go-opts

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/ollama#84642