llama.cpp build b10275 fixes a silent data-loss bug in its server’s built-in tools on Windows. Child processes spawned without a console write in the OEM code page — not UTF-8 on western Windows installs — so accented characters reached the JSON layer as invalid bytes and got replaced, quietly dropping them from tool output.
The fix handles three cases:
- Wrong code page: decode with
MB_ERR_INVALID_CHARSso text comes through untouched rather than emitting replacement characters - Already UTF-8: text that decodes as valid UTF-8 passes through without a second decode, so a child emitting UTF-8 is never double-decoded
- Streamed chunks: incomplete trailing multi-byte sequences are stripped before validating, since a streamed chunk can end mid-character
The root cause is that run() spawns child processes without a console, so they never inherit the console code page. GetOEMCP is what applies — and on a western Windows install that’s not UTF-8. The bug was silent: no error, no crash, just missing characters. A tool returning “café” would deliver “caf” or a replacement glyph depending on the active code page.
Build b10275 ships artifacts for macOS Apple Silicon (arm64), macOS Intel (x64), iOS XCFramework, and Linux Ubuntu x64/arm64/s390x (CPU) plus Ubuntu x64 (Vulkan).
NOTE
The macOS Apple Silicon build with KleidiAI enabled is listed as DISABLED in this release. If you were using that variant, stick with the standard arm64 build.
Available now at the b10275 release page. Standard arm64 macOS and Ubuntu x64 Vulkan builds remain the primary targets for local-LLM workflows.