github/langchain
1
0
Fork 0
mirror of https://github.com/hwchase17/langchain.git synced 2025-08-14 23:26:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(docs): enhance ResponseMetadata documentation with provider field usage notes (#32472)

Browse Source
This commit is contained in:
Mason Daugherty 2025-08-11 09:16:16 -04:00 committed by GitHub
parent 13d67cf37e
commit 23c3fa65d4
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 48 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
libs/core/langchain_core/v1/messages.py
View File

@ -110,6 +110,22 @@ class ResponseMetadata(TypedDict, total=False):
The common fields (``model_provider``, ``model_name``) provide a baseline
contract while preserving flexibility for provider innovations.
.. note::
Not all providers will return the metadata required by this class. In this case,
it is acceptable to inject these fields with values at invocation.
For instance, requests to OpenAI's responses API will not return a provider
field in the raw response, as it can be inferred that by making the request, the
provider responding is OpenAI. In this case, it is safe to set the
``model_provider`` field to ``'openai'`` when creating the message.
On the other hand, ``model_name`` is often returned, and in such cases it is
expected that you populate this field with the unmodified model name (such as
``'o1-2024-12-17'``). Only in situations where the provider does not return a
model name should you artifically set this field - in which case, the value
should be set to the ``model`` or ``model_name`` parameter passed in during
invocation.
"""
model_provider: str

16
libs/core/tests/unit_tests/runnables/__snapshots__/test_graph.ambr
View File

@ -1450,6 +1450,22 @@
The common fields (``model_provider``, ``model_name``) provide a baseline
contract while preserving flexibility for provider innovations.
.. note::
Not all providers will return the metadata required by this class. In this case,
it is acceptable to inject these fields with values at invocation.
For instance, requests to OpenAI's responses API will not return a provider
field in the raw response, as it can be inferred that by making the request, the
provider responding is OpenAI. In this case, it is safe to set the
``model_provider`` field to ``'openai'`` when creating the message.
On the other hand, ``model_name`` is often returned, and in such cases it is
expected that you populate this field with the unmodified model name (such as
``'o1-2024-12-17'``). Only in situations where the provider does not return a
model name should you artifically set this field - in which case, the value
should be set to the ``model`` or ``model_name`` parameter passed in during
invocation.
''',
'properties': dict({
'model_name': dict({

16
libs/core/tests/unit_tests/runnables/__snapshots__/test_runnable.ambr
View File

@ -10455,6 +10455,22 @@
The common fields (``model_provider``, ``model_name``) provide a baseline
contract while preserving flexibility for provider innovations.
.. note::
Not all providers will return the metadata required by this class. In this case,
it is acceptable to inject these fields with values at invocation.
For instance, requests to OpenAI's responses API will not return a provider
field in the raw response, as it can be inferred that by making the request, the
provider responding is OpenAI. In this case, it is safe to set the
``model_provider`` field to ``'openai'`` when creating the message.
On the other hand, ``model_name`` is often returned, and in such cases it is
expected that you populate this field with the unmodified model name (such as
``'o1-2024-12-17'``). Only in situations where the provider does not return a
model name should you artifically set this field - in which case, the value
should be set to the ``model`` or ``model_name`` parameter passed in during
invocation.
''',
'properties': dict({
'model_name': dict({