ollama/ollama-python
1
0
Fork 0
mirror of https://github.com/ollama/ollama-python.git synced 2026-07-21 09:05:23 -04:00
Code Issues 101 Packages Projects Releases 10 Wiki Activity

ollama-python does not expose the name field returned by /api/tags #291

New Issue
Closed
opened 2026-02-15 16:29:38 -05:00 by yindo · 3 comments
yindo commented 2026-02-15 16:29:38 -05:00
Owner
Copy Link
Copy Source

Originally created by @Wu2406 on GitHub (Aug 13, 2025).

Environment

  • ollama: 0.11.4
  • ollama-python: 0.5.3
  • Python: 3.10
  • OS: Windows 10

Background

I downloaded a GGUF file locally and created a model with a custom Modelfile:

FROM ./qwen3-embedding-0.6b-q8_0.gguf

After running:

ollama create Qwen3-Embedding:0.6B -f Modelfile

the CLI confirms the model is correctly registered:

ollama show Qwen3-Embedding:0.6B
  Model
    architecture        qwen3
    parameters          595.78M
    context length      32768
    embedding length    1024
    quantization        Q8_0

  Capabilities
    embedding

The REST endpoint /api/tags returns the expected JSON, including the name field:

{
  "models": [
    {
      "name": "Qwen3-Embedding:0.6B",
      "model": "Qwen3-Embedding:0.6B",
      "modified_at": "2025-08-13T21:02:21.918215+08:00",
      "size": 639150858,
      "digest": "43f15..........0112",
      "details": {
        "parent_model": "",
        "format": "gguf",
        "family": "qwen3",
        "families": ["qwen3"],
        "parameter_size": "595.78M",
        "quantization_level": "Q8_0"
      }
    }
  ]
}

Problem

When I use the official ollama-python client:

from ollama import Client
client = Client(host="http://localhost:11434")
models = client.list()["models"]
print(models)

the returned objects do not contain the name attribute, only:

[Model(
  model='Qwen3-Embedding:0.6B',
  modified_at=datetime.datetime(...),
  digest='43f15..........0112',
  size=639150858,
  details=ModelDetails(...)
)]

This breaks downstream libraries (e.g. mem0) that rely on:

# site-packages\mem0\embeddings\ollama.py
local_models = self.client.list()["models"]
if not any(model.get("model") == self.config.model for model in local_models):
    self.client.pull(self.config.model)

Because model.get("model") is None, the condition always evaluates to True, leading to unnecessary pulls or runtime errors.

Question

Is this discrepancy intentional, or am I missing a configuration step when importing a local GGUF?
Could the ollama-python SDK expose the same name field that the REST API already provides?

Thank you for your time and for maintaining this great project!

Originally created by @Wu2406 on GitHub (Aug 13, 2025). ### Environment - **ollama**: 0.11.4 - **ollama-python**: 0.5.3 - **Python**: 3.10 - **OS**: Windows 10 ### Background I downloaded a GGUF file locally and created a model with a custom `Modelfile`: ```bash FROM ./qwen3-embedding-0.6b-q8_0.gguf ``` After running: ```bash ollama create Qwen3-Embedding:0.6B -f Modelfile ``` the CLI confirms the model is correctly registered: ```text ollama show Qwen3-Embedding:0.6B Model architecture qwen3 parameters 595.78M context length 32768 embedding length 1024 quantization Q8_0 Capabilities embedding ``` The REST endpoint `/api/tags` returns the expected JSON, **including the `name` field**: ```json { "models": [ { "name": "Qwen3-Embedding:0.6B", "model": "Qwen3-Embedding:0.6B", "modified_at": "2025-08-13T21:02:21.918215+08:00", "size": 639150858, "digest": "43f15..........0112", "details": { "parent_model": "", "format": "gguf", "family": "qwen3", "families": ["qwen3"], "parameter_size": "595.78M", "quantization_level": "Q8_0" } } ] } ``` ### Problem When I use the official `ollama-python` client: ```python from ollama import Client client = Client(host="http://localhost:11434") models = client.list()["models"] print(models) ``` the returned objects **do not contain the `name` attribute**, only: ```python [Model( model='Qwen3-Embedding:0.6B', modified_at=datetime.datetime(...), digest='43f15..........0112', size=639150858, details=ModelDetails(...) )] ``` This breaks downstream libraries (e.g. [mem0](https://github.com/mem0ai/mem0)) that rely on: ```python # site-packages\mem0\embeddings\ollama.py local_models = self.client.list()["models"] if not any(model.get("model") == self.config.model for model in local_models): self.client.pull(self.config.model) ``` Because `model.get("model")` is `None`, the condition always evaluates to `True`, leading to unnecessary pulls or runtime errors. ### Question Is this discrepancy intentional, or am I missing a configuration step when importing a local GGUF? Could the `ollama-python` SDK expose the same `name` field that the REST API already provides? Thank you for your time and for maintaining this great project! ```
yindo added the bug label 2026-02-15 16:29:38 -05:00
yindo closed this issue 2026-02-15 16:29:39 -05:00
yindo commented 2026-02-15 16:29:39 -05:00
Author
Owner
Copy Link
Copy Source

@Wu2406 commented on GitHub (Aug 13, 2025):

Follow-up: name field missing from ollama._types.ListResponse.Model in ollama-python

Root-cause investigation

After opening the issue I did a quick local audit and can confirm the mismatch is inside the SDK itself, not in Ollama’s REST layer.

  1. The HTTP endpoint /api/tags does return

    {
  "models": [
    { "name": "Qwen3-Embedding:0.6B", ... }
  ]
}

  2. However, the ListResponse type defined in
    site-packages/ollama/_types.py (line 463) only maps the following fields:

    class ListResponse(SubscriptableBaseModel):
  class Model(SubscriptableBaseModel):
    model: Optional[str] = None
    modified_at: Optional[datetime] = None
    digest: Optional[str] = None
    size: Optional[ByteSize] = None
    details: Optional[ModelDetails] = None

  3. In _client.py, list() calls

    self._request(ListResponse, 'GET', '/api/tags')

    The JSON is deserialized into the Model sub-class above, so any extra keys (like name) are silently dropped by Pydantic.

Minimal repro

from ollama import Client
client = Client(host="http://localhost:11434")
print(client.list().models[0].dict())
# -> {'model': 'Qwen3-Embedding:0.6B', 'modified_at': ..., 'digest': ..., 'size': ..., 'details': {...}}
# 'name' is missing

Proposed fix

Add a single optional field to ListResponse.Model:

class Model(SubscriptableBaseModel):
  name: Optional[str] = None   # ← keep parity with /api/tags
  model: Optional[str] = None
  modified_at: Optional[datetime] = None
  digest: Optional[str] = None
  size: Optional[ByteSize] = None
  details: Optional[ModelDetails] = None

This is a non-breaking change (defaults to None) and restores 1-to-1 compatibility with the REST API.

Pull request

Based on the findings above, I've implemented this code change and verified its functionality. I've also submitted a pull request. Whenever you have a moment, I would be grateful if you could kindly take a look.

Here is my pull request link: https://github.com/ollama/ollama-python/pull/563

@Wu2406 commented on GitHub (Aug 13, 2025): ## Follow-up: `name` field missing from `ollama._types.ListResponse.Model` in `ollama-python` ### Root-cause investigation After opening the issue I did a quick local audit and can confirm the mismatch is **inside the SDK itself**, not in Ollama’s REST layer. 1. The HTTP endpoint `/api/tags` **does** return ```json { "models": [ { "name": "Qwen3-Embedding:0.6B", ... } ] } ``` 2. However, the `ListResponse` type defined in `site-packages/ollama/_types.py` (line 463) only maps the following fields: ```python class ListResponse(SubscriptableBaseModel): class Model(SubscriptableBaseModel): model: Optional[str] = None modified_at: Optional[datetime] = None digest: Optional[str] = None size: Optional[ByteSize] = None details: Optional[ModelDetails] = None ``` 3. In `_client.py`, `list()` calls ```python self._request(ListResponse, 'GET', '/api/tags') ``` The JSON is deserialized **into the `Model` sub-class above**, so any extra keys (like `name`) are silently dropped by Pydantic. ### Minimal repro ```python from ollama import Client client = Client(host="http://localhost:11434") print(client.list().models[0].dict()) # -> {'model': 'Qwen3-Embedding:0.6B', 'modified_at': ..., 'digest': ..., 'size': ..., 'details': {...}} # 'name' is missing ``` ### Proposed fix Add a single optional field to `ListResponse.Model`: ```python class Model(SubscriptableBaseModel): name: Optional[str] = None # ← keep parity with /api/tags model: Optional[str] = None modified_at: Optional[datetime] = None digest: Optional[str] = None size: Optional[ByteSize] = None details: Optional[ModelDetails] = None ``` This is a **non-breaking change** (defaults to `None`) and restores 1-to-1 compatibility with the REST API. ## Pull request Based on the findings above, I've implemented this code change and verified its functionality. I've also submitted a pull request. Whenever you have a moment, I would be grateful if you could kindly take a look. Here is my pull request link: https://github.com/ollama/ollama-python/pull/563 ```
yindo commented 2026-02-15 16:29:39 -05:00
Author
Owner
Copy Link
Copy Source

@ParthSareen commented on GitHub (Sep 18, 2025):

name is set to be deprecated

@ParthSareen commented on GitHub (Sep 18, 2025): `name` is set to be deprecated
yindo commented 2026-02-15 16:29:39 -05:00
Author
Owner
Copy Link
Copy Source

@Wu2406 commented on GitHub (Sep 18, 2025):

name is set to be deprecated

If the 'name' field is set to be deprecated, should we use the 'Model' field instead? Are these two fields the same?

@Wu2406 commented on GitHub (Sep 18, 2025): > `name` is set to be deprecated If the 'name' field is set to be deprecated, should we use the 'Model' field instead? Are these two fields the same?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
pull-request
Mirrored from GitHub Pull Request
 thinking
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ollama/ollama-python#291
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?