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

[GH-ISSUE #9208] Logging options too coarse, need to know if input is truncated without logging all user activity #6000

New Issue
Open
opened 2026-04-12 17:21:06 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-12 17:21:06 -05:00
Owner
Copy Link

Originally created by @JubilantJerry on GitHub (Feb 19, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/9208

When the input is truncated, it can be argued that the output of the LLM is entirely wrong. In my opinion, the severity of input truncation is comparable to a server process crashing to due to OOM and returning a zero-length result, input truncation badly breaks downstream tools (e.g. AI-powered IDEs) since they depend on the model being aware of important information in the context window.

So I think it's very important to be able to continuously monitor if this is happening in the logs at any time.

However, there are only two logging levels in Ollama now, either it logs almost no information, or it logs every event with OLLAMA_DEBUG=1. I can only see if input truncation is happening if debugging logs are turned on. This would also mean every single prompt and query will be logged as well, which is an information security hazard.

I think that the input truncation event should be set to logging level WARN (currently I see level=DEBUG source=prompt.go:77 msg="truncating input messages which exceed context length" truncated=3, I think the severity ought to be higher than DEBUG).

And, it should be possible to see such messages even when OLLAMA_DEBUG=0. At least, this should happen if either the system prompt or the most recent user query is being truncated.

Originally created by @JubilantJerry on GitHub (Feb 19, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/9208 When the input is truncated, it can be argued that the output of the LLM is entirely wrong. In my opinion, the severity of input truncation is comparable to a server process crashing to due to OOM and returning a zero-length result, input truncation badly breaks downstream tools (e.g. AI-powered IDEs) since they depend on the model being aware of important information in the context window. So I think it's very important to be able to continuously monitor if this is happening in the logs at any time. However, there are only two logging levels in Ollama now, either it logs almost no information, or it logs every event with `OLLAMA_DEBUG=1`. I can only see if input truncation is happening if debugging logs are turned on. This would also mean every single prompt and query will be logged as well, which is an information security hazard. I think that the input truncation event should be set to logging level WARN (currently I see `level=DEBUG source=prompt.go:77 msg="truncating input messages which exceed context length" truncated=3`, I think the severity ought to be higher than DEBUG). And, it should be possible to see such messages even when `OLLAMA_DEBUG=0`. At least, this should happen if either the system prompt or the most recent user query is being truncated.
GiteaMirror added the feature request label 2026-04-12 17:21:06 -05:00
GiteaMirror commented 2026-04-12 17:21:06 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Feb 19, 2025):

Related: https://github.com/ollama/ollama/issues/7043

<!-- gh-comment-id:2668330837 --> @rick-github commented on GitHub (Feb 19, 2025): Related: https://github.com/ollama/ollama/issues/7043
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#6000
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?