Blog · Review
Three releases in three days, and the vision model flubbed a spreadsheet
August 25, 2026 · dshbase · hands-on vision testing
Between August 19 and 21, DeepSeek Harness shipped three releases: v0.1.0-rc.8 → v0.1.1-rc.1 → v0.1.1-rc.2. The through-line is unmistakable: getting the agent to actually see images. Here's what each release did, and what happened when a real user put the new vision model to work on a spreadsheet screenshot.
rc.8: pave the road first
rc.8 (Aug 19) built the multimodal plumbing: the model adapter gained configurable native image requests, /goal and /plan started accepting mixed image+text input, and the @ mention menu could reference files and past sessions. One embarrassment remained: the road was ready but no officially-supported "seeing" car was on it — the default model catalog still held only the text-only DeepSeek-V4-Flash and DeepSeek-V4-Pro.
rc.1: a first-party vision model arrives
rc.1 (Aug 21 afternoon) landed the missing piece: DeepSeek-V4-Flash-Vision-Exp (input modality text + image) entered the default catalog. Multimodal was no longer "bolt a third-party plugin on as eyes" — it became a first-party adapter capability. Equally important was the safety fallback: the adapter now validates whether the model declares image support, returning UNSUPPORTED_CONTENT instead of silently pushing pixels into a text model. The same release fixed an input-box @ layout bug and a Bubblewrap sandbox escape (a restricted process could reach out via /proc/<pid>/root).
rc.2: from "can see" to "sees comfortably"
A few hours later rc.2 shipped one thing that hits a real pain point: the adapter now prefers the Files API for image uploads and reuses uploaded files instead of re-uploading the same large image every request, and pre-processing auto-scales and converts images to what the model expects. That directly addresses the "oversized image / accumulated history payload blows the request" failure mode.
The test: an Excel screenshot, four totals
With the vision model selected (DeepSeek-V4-Flash-Vision-Exp High), the tester screenshotted a server resource-planning table and asked: "read the image and compute the totals for CPU, memory, system disk and data disk."
The model answered with professional-looking confidence: 18 rows; CPU 213 vCPU; memory 674 GiB; system disk 2810 GiB; data disk 8536 GiB — even annotating "row 9 has the highest data-disk value" and "empty data-disk rows," the picture of diligence.
The original table had 21 rows. Every total was wrong: CPU 213 vs 230 (−17), memory 674 vs 724 (−50), system disk 2810 vs 3430 (−620), data disk 8536 vs 7936 (+600 — it double-expanded rows like "300+300" and "200+200" during accumulation). It saw the image; it just missed three rows.
"Check your work" — three times, still wrong
Told to double-check, the model ran a self-audit with three confirmation questions — "row 9 data disk reads 100+100+500+1536 = 2236, correct?" "row 18 system disk reads 400, correct?" "summing 300+300 / 200+200 capacities, is this the right convention?" — all confirmed, "all three checks passed ✅," same four wrong numbers. Every layer of verification rested on the same flawed read: the more it re-verified, the more confident the error became.
What this tells installers
- "Sees" ≠ "reads precisely." Structured tables remain high-risk: missed rows, missed columns, merged cells. Natural-scene understanding is improving fast; exact table-boundary reading is not there yet.
- Confident re-checks can be circular. Confirmation prompts built on a wrong base just re-ratify the mistake.
- Use it for input expansion, not accounting. Error screenshots, UI sketches, simple charts: good. Financial, procurement or resource-summing numbers: cross-check against the raw CSV/Excel file, and treat vision as assisted reading, not an automatic calculator.
The three-release sprint shows how seriously the team is betting on multimodal, and the engineering tempo is real. But the quick verdict stands: the eyes are in, the prescription still needs to be checked.