Hi, and thanks for this great tool!
Over the past two days I've extensively tested deepwiki-rs with various local models via Ollama on different hardware (CPU-only cloud servers and a MacBook Pro M4 Pro with 48GB RAM). I wanted to share my findings and suggest an improvement.
The problem
When using local models via Ollama, deepwiki-rs produces a high rate of errors like:
- ❌ Failed to deserialize the extracted data: invalid type: string, expected struct CodeDossier
- ❌ Failed to deserialize the extracted data: invalid value: map, expected map with a single key
- ❌ Failed to deserialize the extracted data: missing field
importance
The root cause (confirmed by inspecting raw traffic via socat proxy) is that local models often return valid and complete JSON as a plain string inside content instead of a structured tool_calls response. The data itself is correct – deepwiki-rs just can't parse it.
This is consistent with issue #47.
Models tested
- qwen2.5-coder:32b – fails, puts tool call in content
- qwen3:8b, qwen3:32b – partial success, schema mismatches
- mistral-nemo, mistral-small3.2 – mostly fails
- llama3.1:8b – fails
- openai/gpt-4o-mini via OpenRouter – works reliably ✅
Suggested improvement
When deserializing tool call responses, add a fallback that:
Checks if content contains a valid JSON string
Attempts to parse it as the expected struct
Only fails if both tool_calls and the content fallback are unparseable
This would make deepwiki-rs significantly more useful for local/offline setups without any model changes required.
Happy to help test any fixes. Thanks for considering this!
Hi, and thanks for this great tool!
Over the past two days I've extensively tested deepwiki-rs with various local models via Ollama on different hardware (CPU-only cloud servers and a MacBook Pro M4 Pro with 48GB RAM). I wanted to share my findings and suggest an improvement.
The problem
When using local models via Ollama, deepwiki-rs produces a high rate of errors like:
importanceThe root cause (confirmed by inspecting raw traffic via socat proxy) is that local models often return valid and complete JSON as a plain string inside content instead of a structured tool_calls response. The data itself is correct – deepwiki-rs just can't parse it.
This is consistent with issue #47.
Models tested
Suggested improvement
When deserializing tool call responses, add a fallback that:
Checks if content contains a valid JSON string
Attempts to parse it as the expected struct
Only fails if both tool_calls and the content fallback are unparseable
This would make deepwiki-rs significantly more useful for local/offline setups without any model changes required.
Happy to help test any fixes. Thanks for considering this!