fix(audio): derive transcription filename with os.path.basename

[anxkhn]

Relevant issues

No existing issue. This is a small correctness fix found while reading the
file-input hardening added in #27762.

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

process_audio_file builds the multipart file name that is sent to provider
transcription APIs. For a PathLike input on Windows the file name was the
whole path instead of the base name. The added regression test reproduces
Windows path semantics on any host by pointing the module's os.path at
ntpath:

Before the fix (old file_path.split("/")[-1]):

assert result.filename == "audio recording.mp3"
AssertionError: assert 'C:\\Users\\me\\audio recording.mp3' == 'audio recording.mp3'

After the fix (os.path.basename(file_path)):

tests/test_litellm/litellm_core_utils/test_audio_utils.py::TestProcessAudioFile::test_process_windows_pathlib_input_basename PASSED

Type

🐛 Bug Fix

Changes

process_audio_file (in litellm/litellm_core_utils/audio_utils/utils.py)
derived the multipart file name from a PathLike input with
filename = file_path.split("/")[-1], where file_path = str(audio_file).

That split assumes a POSIX separator. On Windows,
str(Path("C:/dir/name.mp3")) is "C:\\dir\\name.mp3", which contains no
forward slash, so split("/")[-1] returns the entire path (drive letter and
backslashes) rather than the base name. The full path then reaches provider
transcription requests as the form-data file part name (for example the
files={"file": (filename, content, content_type)} payload built by the
mistral, soniox, azure, deepgram and other transcription transformers that call
process_audio_file).

The fix uses os.path.basename(file_path), which extracts the base name
correctly on each OS because str(PathLike) and os.path use the same
separator for the host. This matches the sibling PathLike file-input sink in
litellm/ocr/main.py, which was hardened alongside this code in #27762.

A regression test (test_process_windows_pathlib_input_basename) was added to
the existing mapped test file. It patches the module's os.path to ntpath
and feeds a PureWindowsPath, so it reproduces Windows behavior on the POSIX CI
host: it fails on the old split (the full path leaks) and passes on the fix.

---

Diff (2 files, +30 / -1)

diff --git a/litellm/litellm_core_utils/audio_utils/utils.py b/litellm/litellm_core_utils/audio_utils/utils.py
@@ -69,7 +69,7 @@ def process_audio_file(audio_file: FileTypes) -> ProcessedAudioFile:
         file_path = str(audio_file)
         with open(file_path, "rb") as f:
             file_content = f.read()
-        filename = file_path.split("/")[-1]
+        filename = os.path.basename(file_path)
     elif isinstance(audio_file, tuple):

Plus the new test test_process_windows_pathlib_input_basename in
tests/test_litellm/litellm_core_utils/test_audio_utils.py.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[greptile-apps]

Greptile Summary

Replaces a POSIX-only split("/")[-1] with os.path.basename() in process_audio_file so that PathLike inputs on Windows yield only the file's base name instead of the full drive path when building the multipart form-data file name sent to provider transcription APIs.

• litellm/litellm_core_utils/audio_utils/utils.py: One-line change at the PathLike branch; os was already imported, so no new dependency is introduced.
• tests/test_litellm/litellm_core_utils/test_audio_utils.py: New mock-only regression test that patches the module's os.path to ntpath and supplies a PureWindowsPath, reproducing Windows semantics on any CI host without real network or filesystem I/O.

Confidence Score: 5/5

Minimal, targeted fix with no side-effects on other paths; safe to merge.

The change touches a single line inside a well-isolated branch of process_audio_file. os.path.basename is the idiomatic, cross-platform way to extract a filename and matches the already-fixed sibling in litellm/ocr/main.py. The new test reproduces the exact failure on any host without making real filesystem or network calls, and all existing tests remain unmodified.

No files require special attention.

Important Files Changed

Filename	Overview
litellm/litellm_core_utils/audio_utils/utils.py	Single-line correctness fix: replaces file_path.split("/")[-1] with os.path.basename(file_path) so Windows paths are correctly parsed; os was already imported.
tests/test_litellm/litellm_core_utils/test_audio_utils.py	Adds test_process_windows_pathlib_input_basename, a mock-only regression test that patches os.path to ntpath and open to reproduce Windows path semantics on any CI host, confirming the basename fix is correct.

_{Reviews (1): Last reviewed commit: "fix(audio): derive transcription filenam..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[codspeed-hq]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing anxkhn:patch-8 (dee48d0) with litellm_internal_staging (60729f7)}

[anxkhn]

@yucheng-berri when you have a chance, could you please take a look at this pr and let me know if any update is needed?