github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-06 08:02:14 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #11623] Add support for a global config file to set default parameters like think = false #33437

New Issue
Open
opened 2026-04-22 16:06:27 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-22 16:06:27 -05:00
Owner
Copy Link

Originally created by @KasraK2K on GitHub (Aug 1, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/11623

Feature Request: Support a Global Config File to Disable Features Like think

What's the issue?
Right now, if you want to disable the think output in Ollama, you have to pass --no-think every time you run a model — either through the CLI or API. This gets repetitive and messy, especially if you're working across multiple scripts or services.

What would help:
A simple global config file (like ~/.ollama/config) where you can set default options once and not worry about it again.

Example:

# ~/.ollama/config
default_parameters = {
  think = false
}

Why this matters:

  • Avoids repeating flags everywhere
  • Keeps scripts cleaner and easier to maintain
  • Makes it easier to control model behavior in production
  • Would apply consistently across CLI and API usage

Extra thoughts:

It’d be great if this config could also support per-model overrides, or even set defaults for other options like temperature, top_k, etc.

Thanks — this would make working with Ollama a lot smoother.

Originally created by @KasraK2K on GitHub (Aug 1, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/11623 ### Feature Request: Support a Global Config File to Disable Features Like `think` **What's the issue?** Right now, if you want to disable the `think` output in Ollama, you have to pass `--no-think` every time you run a model — either through the CLI or API. This gets repetitive and messy, especially if you're working across multiple scripts or services. **What would help:** A simple global config file (like `~/.ollama/config`) where you can set default options once and not worry about it again. **Example:** ```toml # ~/.ollama/config default_parameters = { think = false } ``` **Why this matters:** - Avoids repeating flags everywhere - Keeps scripts cleaner and easier to maintain - Makes it easier to control model behavior in production - Would apply consistently across CLI and API usage **Extra thoughts:** It’d be great if this config could also support per-model overrides, or even set defaults for other options like `temperature`, `top_k`, etc. Thanks — this would make working with Ollama a lot smoother.
GiteaMirror added the feature request label 2026-04-22 16:06:27 -05:00
GiteaMirror commented 2026-04-22 16:06:29 -05:00
Author
Owner
Copy Link

@xpe commented on GitHub (Aug 1, 2025):

@KasraK2K Did you search for related issues? If you didn't, you aren't alone. There is a long and complicated history of related requests. Many of them don't seem to recognize that others exist. 🤦 So, if you want this to happen, I would suggest you read at least eleven of them (see below), think a bit, and summarize what you found, here. This is more likely to move the needle, because this context is necessary for getting support for any change.

Here are some issues to consider reading, in increasing order:

Important: the XDG Base Directory Specification is essential background, because it is what pretty much everyone expects for the location of configuration files.

<!-- gh-comment-id:3144901904 --> @xpe commented on GitHub (Aug 1, 2025): @KasraK2K Did you search for related issues? If you didn't, you aren't alone. There is a long and complicated history of related requests. Many of them don't seem to recognize that others exist. 🤦 So, if you want this to happen, I would suggest you read at least eleven of them (see below), think a bit, and summarize what you found, here. This is more likely to move the needle, because this context is necessary for getting support for any change. Here are some issues to consider reading, in increasing order: - #204 - #228 - #836 - #2941 - #4123 - #4154 - #4883 - #6239 - #7089 - #9477 - #11076 **Important**: the [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/latest/#index) is *essential* background, because it is what pretty much everyone expects for the location of configuration files.
GiteaMirror commented 2026-04-22 16:06:32 -05:00
Author
Owner
Copy Link

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

@xpe I took some time to go through the related issues, and here’s what I found:

  • #204 – Use a Standard Config Format
    People suggested moving away from a custom format (like Modelfile) and using something standard such as YAML, TOML, or JSON5. The main point is readability and better tool support.

  • #228 – Don’t Clutter the Home Directory
    This one raised concerns about Ollama writing into ~/.ollama by default. The suggestion was to follow the usual OS conventions (XDG on Linux, ~/Library on macOS, %AppData% on Windows).

  • #2941 – Global Config Variables
    Someone asked if there could be a way to define global settings (instead of only environment variables), ideally through a config file.

  • #4883 – Add a Config File
    Another request for a config file, mainly to make it easier to manage and sync settings (like via dotfiles).

  • #6239 – Support keep_alive in config.json
    Proposal to allow a global keep_alive option in the config, so it doesn’t need to be set every time with the API.

  • #11076 – Config File Support for Server Settings
    This is the most comprehensive one I found. It suggests using a proper config system (TOML/YAML/JSON), stored in the standard locations depending on the OS. It also recommends a clear precedence order: CLI flags > env vars > user config > system config > defaults. The benefits highlighted were version control, being easier to read/write, and reducing reliance on environment variables.

So overall, there’s a clear recurring theme: people want a proper config file (in a standard format, stored in the right place), with the flexibility to override via env vars or CLI. The more recent proposals (#11076 especially) already outline a good structure for this.

I think building on that makes the most sense, since it ties together most of the earlier requests.

<!-- gh-comment-id:3239403366 --> @KasraK2K commented on GitHub (Aug 30, 2025): @xpe I took some time to go through the related issues, and here’s what I found: - **#204 – Use a Standard Config Format** People suggested moving away from a custom format (like Modelfile) and using something standard such as YAML, TOML, or JSON5. The main point is readability and better tool support. - **#228 – Don’t Clutter the Home Directory** This one raised concerns about Ollama writing into `~/.ollama` by default. The suggestion was to follow the usual OS conventions (XDG on Linux, `~/Library` on macOS, `%AppData%` on Windows). - **#2941 – Global Config Variables** Someone asked if there could be a way to define global settings (instead of only environment variables), ideally through a config file. - **#4883 – Add a Config File** Another request for a config file, mainly to make it easier to manage and sync settings (like via dotfiles). - **#6239 – Support `keep_alive` in config.json** Proposal to allow a global `keep_alive` option in the config, so it doesn’t need to be set every time with the API. - **#11076 – Config File Support for Server Settings** This is the most comprehensive one I found. It suggests using a proper config system (TOML/YAML/JSON), stored in the standard locations depending on the OS. It also recommends a clear precedence order: CLI flags > env vars > user config > system config > defaults. The benefits highlighted were version control, being easier to read/write, and reducing reliance on environment variables. --- So overall, there’s a clear recurring theme: people want a proper config file (in a standard format, stored in the right place), with the flexibility to override via env vars or CLI. The more recent proposals (#11076 especially) already outline a good structure for this. I think building on that makes the most sense, since it ties together most of the earlier requests.
GiteaMirror commented 2026-04-22 16:06:33 -05:00
Author
Owner
Copy Link

@chrisqianz commented on GitHub (Sep 1, 2025):

yes, i think so.

<!-- gh-comment-id:3241437020 --> @chrisqianz commented on GitHub (Sep 1, 2025): yes, i think so.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#33437
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?