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

[GH-ISSUE #9019] Ollama API: Rename response field done_reason to finish_reason #52377

New Issue
Closed
opened 2026-04-28 23:06:57 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-28 23:06:57 -05:00
Owner
Copy Link

Originally created by @d-kleine on GitHub (Feb 11, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/9019

Originally assigned to: @ParthSareen on GitHub.

Follow up of #4235

Problem

Impact

  • Creates unnecessary friction when switching between APIs
  • Requires additional code adaptations for compatibility
  • Makes integration with existing LLM tools more complex

Proposed Solution

  • Rename done_reason to finish_reason in the API response
  • Maintain backward compatibility by supporting both fields temporarily
  • Deprecate done_reason in future releases
  • Update documentation to reflect the change

Benefits

  • Better alignment with industry standards
  • Improved API consistency across LLM platforms
  • Easier integration with existing codebases
Originally created by @d-kleine on GitHub (Feb 11, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/9019 Originally assigned to: @ParthSareen on GitHub. Follow up of #4235 ### Problem - The Ollama API uses `done_reason` to indicate why a response ended, while most other LLM APIs (OpenAI, Anthropic, Google, etc.) use `finish_reason` https://github.com/ollama/ollama/blob/main/docs/api.md#response-17 ### Impact - Creates unnecessary friction when switching between APIs - Requires additional code adaptations for compatibility - Makes integration with existing LLM tools more complex ### Proposed Solution - Rename `done_reason` to `finish_reason` in the API response - Maintain backward compatibility by supporting both fields temporarily - Deprecate `done_reason` in future releases - Update documentation to reflect the change ### Benefits - Better alignment with industry standards - Improved API consistency across LLM platforms - Easier integration with existing codebases
GiteaMirror added the feature request label 2026-04-28 23:06:57 -05:00
GiteaMirror commented 2026-04-28 23:06:59 -05:00
Author
Owner
Copy Link

@ParthSareen commented on GitHub (Feb 12, 2025):

Been thinking about this too - will consider and figure something out in the coming bit :)

<!-- gh-comment-id:2652516472 --> @ParthSareen commented on GitHub (Feb 12, 2025): Been thinking about this too - will consider and figure something out in the coming bit :)
GiteaMirror commented 2026-04-28 23:06:59 -05:00
Author
Owner
Copy Link

@d-kleine commented on GitHub (Feb 13, 2025):

Alright, thanks!

I have also noticed another potential source of confusion in the API parameters.

  • prompt_eval_count: number of tokens in the prompt
  • prompt_eval_duration: time spent in nanoseconds evaluating the prompt
  • eval_count: number of tokens in the response
  • eval_duration: time in nanoseconds spent generating the response

The use of "eval" in in these names isn't very intuitive imho as they might suggest some kind of (model) evaluation. Maybe more descriptive names like prompt_token_count, etc. would make their purpose clearer to users.

Additionally, I think it would be helpful to have a parameter that provides the total token count (input + output combined), maybe total_token_count or context_length.

<!-- gh-comment-id:2656714740 --> @d-kleine commented on GitHub (Feb 13, 2025): Alright, thanks! I have also noticed another potential source of confusion in the API parameters. - `prompt_eval_count`: number of tokens in the prompt - `prompt_eval_duration`: time spent in nanoseconds evaluating the prompt - `eval_count`: number of tokens in the response - `eval_duration`: time in nanoseconds spent generating the response The use of "eval" in in these names isn't very intuitive imho as they might suggest some kind of (model) evaluation. Maybe more descriptive names like `prompt_token_count`, etc. would make their purpose clearer to users. Additionally, I think it would be helpful to have a parameter that provides the total token count (input + output combined), maybe `total_token_count` or `context_length`.
GiteaMirror commented 2026-04-28 23:07:00 -05:00
Author
Owner
Copy Link

@ParthSareen commented on GitHub (Apr 16, 2025):

Don't think we'll be picking this exact thing up but are planning to do general API improvements

<!-- gh-comment-id:2810943571 --> @ParthSareen commented on GitHub (Apr 16, 2025): Don't think we'll be picking this exact thing up but are planning to do general API improvements
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#52377
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?