Attachment uploads to /v1/files? Is it intended, and can it be disabled or inlined?

[sciman-top]

Question

I run a self-hosted OpenAI/Anthropic-compatible gateway (CLIProxyAPI) and point DSH at it via baseURL. In the gateway's error dumps I see DSH issuing

POST /v1/files
User-Agent: deepseek-harness/0.2.2-rc.1 (+https://github.com/deepseek-ai/deepseek-harness)
Anthropic-Beta: files-api-2025-04-14
Anthropic-Version: 2023-06-01
Content-Type: multipart/form-data; boundary=----formdata-undici-...
Content-Length: 158331
Sec-Fetch-Mode: cors

The gateway answers 404 (it does not implement the Anthropic Files API), and DSH keeps retrying on subsequent file references — 570 times in one six-hour session.

Nothing is broken for me — I intercept the path and answer locally now. I am asking because I could not work out which DSH surface sends it, and I would rather use the intended path than have DSH talk to an endpoint my backend will never serve.

What I could and could not find

• @anthropic-ai/sdk is bundled and contains client.beta.files.upload(), which is what builds that exact request (/v1/files?beta=true, undici multipart boundary, that beta header).
• I could not find a DSH-side caller: searching the bundle for files.upload( returns only SDK docs/helpers, and no occurrence sits inside a @deepseek-ai/dsh-* module.
• DSH's own attachment/LLM path appears to inline content (image_url, base64) rather than upload, which is why I suspect the Files path is either (a) a fallback taken only under some condition, or (b) triggered by something I have not found.

What I would like to know

1. Is the /v1/files upload an intended DSH feature (e.g. for large attachments that exceed inline limits), or leftover SDK surface that fires on a particular code path?
2. If intended, is there a setting to disable it so attachments always inline? My backend serves text+image inline fine; it will never implement Files API.
3. If it is a fallback, what condition triggers it? I would like to make sure my gateway does not silently degrade attachment handling — right now the upload 404s and I do not know whether DSH then falls back to inlining or drops the attachment.

Why it mattered (context, not a complaint)

My gateway bounds error dumps to 5 files. Because every /v1/files 404 writes one, the ring rotated every 12–25 seconds and a genuine upstream failure dump survived under 90 seconds. That is my gateway's retention design, not a DSH bug — I mention it only to explain why I chased this down.

If the answer is "it is SDK surface we do not use, ignore it", that is completely fine and I will keep intercepting it.

[sciman-top]

Yes — it is intended, and here is the actual call site (0.2.2-rc.1)

The upload is the DeepSeek Messages adapter's Files-API-first image pipeline,
not an Anthropic SDK side effect. Per the package README (@deepseek-ai/dsh-llm-deepseek):

DeepSeek input normally uses the Files API and uses inline base64 only for
per-request recovery.

So the inline-base64 chain you found is the recovery leg; the primary leg is
the Files upload.

Why grepping files.upload( finds nothing in @deepseek-ai/dsh-*

The sender is the adapter's own hand-rolled transport:

• @deepseek-ai/dsh-llm-deepseek (upstream packages/llm/llm-deepseek),
  DeepSeekFilesClient.upload() (src/files-api.ts), called from the request
  loop as client.upload({...}) — the literal text files.upload( never occurs,
  so a package-wide grep for it only matches @anthropic-ai/sdk docs/helpers.
• @anthropic-ai/sdk is present inside app.asar, but no @deepseek-ai/dsh-*
  module imports it (verified by grepping all extracted modules for the import
  specifier), and the only anthropic-beta header writer in the whole bundle is
  dsh-llm-deepseek. The SDK's client.beta.files.upload() (which does post
  /v1/files?beta=true) is a plausible-looking red herring here.

Wire shape (from the 0.2.2-rc.1 bundle)

POST {messagesApiRoot(baseURL)}/files            # no query string
content-type: multipart/form-data
  expires_after[anchor] = created_at
  expires_after[seconds] = <fileExpiresAfterSeconds, default 604800>
  file = <image bytes, media-type blob>
anthropic-version: 2023-06-01
anthropic-beta: files-api-2025-04-14
user-agent: deepseek-harness/0.2.2-rc.1          # from @deepseek-ai/dsh-llm attributionHeaders()

When it fires

Any request whose messages retain images on an image-capable model route
(inputModalities includes image). On failure the request is rebuilt inline
(FileResolutionFailure → inline = true), so chat keeps working — the cost is
one futile upload per turn, because the reuse index
($DSH_HOME/llm-deepseek/files-v3.json) is only written on a successful upload
and therefore never fills when the endpoint has no Files API; every subsequent
turn retries. That matches the rate shape we measured on our gateway
(event-driven, tied to turns with images; zero requests when idle).

Small ask

Against an endpoint that answers 404 for /v1/files, the adapter re-attempts on
every image turn for the life of the process. Two options, either would do:

1. Sticky per-endpoint degrade — after an upload fails with a status that
   classifies as "endpoint has no Files API" (e.g. 404/501) for a given
   baseURL + credential scope, remember it (persistently, like the upload
   index) and skip Files until the endpoint or credential changes.
2. A config knob (filesApi: auto | off) — the 0.2.2-rc.1 schema only
   carries budgets/timeouts (maxRequestFilesBytes, filesApiTimeoutMs,
   fileExpiresAfterSeconds, ...), none of which can express "this endpoint
   has no Files API".

Happy to file this as a feature issue instead if the maintainers prefer.

[sciman-top]

Two corrections to my answer above, after re-checking against the bundle:

1. The inline fallback question is answered — it is unconditional.

I should have closed this out instead of leaving it open. RequestFiles.resolve()
wraps any ensureUploaded failure in FileResolutionFailure (there is no status
filter on the error), and the request loop catches exactly that type and sets
inline = true, then re-serializes with inlineImages(...). So a 404 from a
gateway without Files API always falls back to inline base64 and the turn
still succeeds. Nothing is dropped. There is also a one-shot retried flag for
stale-id reuse, but it is not what handles the 404.

That means the practical cost is precisely one wasted upload attempt per image
turn, plus whatever the retry index costs — not a correctness problem.

2. The digest I quoted was wrong.

I cited payloadDigest 0881fb... for app.asar. That value does not appear in
the archive; the file's actual SHA-256 is 5fa8a6b2.... The call-site findings
stand (they are reproducible from DeepSeekFilesClient.upload(),
MESSAGES_FILES_BETA = "files-api-2025-04-14", and attributionHeaders()),
but treat the digest claim as withdrawn.

3. On the "1908 x 404 in 24h" figure — also withdrawn.

I tried to corroborate the probe volume from nginx access logs and the number
does not hold up. My gateway's access-log format does not record the URI, and
the route=other status=404 count mixes in internet scanners: of 1849 entries
in one day's rotation, 175 are GET with upstream_status=- from scattered
public IPs (40.124.x, 147.185.x, 45.156.x) that never reach the proxy at all,
and the POST remainder is spread across the whole 24h (222 at 00h, 217 at 01h,
225 at 10h) rather than clustered in my image-debugging window.

Decisive check: at two timestamps where I have confirmed upload attempts
(16:54:33 and 16:27:03), both access logs contain zero matching lines.
Those attempts never traversed nginx. So the honest statement is: I can count the
attempts my proxy answered (31 over the whole retention window), and I cannot
independently corroborate a 24h total from access logs at all. The 95/hour
figure came from a six-hour window in an older container's logs and should be
read as such.

The core claim is unaffected — the upload fires per image-bearing turn and the
reuse index never fills — but the volume numbers I attached to it were not
verified and I would rather retract them than leave them standing.

[sciman-top]

Follow-up to my correction above — one of its three points does not survive rechecking.

"Those attempts never traversed nginx" is wrong. The two timestamps I checked
(16:54:33, 16:27:03) are Beijing-local times from desktop-side artifacts, while
the nginx access logs are UTC. 16:54:33 CST = 08:54:33Z, and that day's rotation
does contain an exact probe-signature line at that second:

<egress-ip> method=POST route=other status=404 upstream_status=404 bytes=0 time=[08/Nov/2026:08:54:33 +0000]

More decisively: in the same rotation, the POST remainder — 1,655 lines from a single
egress IP, upstream_status=404, bytes=0 — matches the hourly shape of the
route=other status=200 series (5,505 lines, chat turns) peak for peak and trough
for trough. Same client, same path: chat requests and per-image-turn upload attempts
both traverse the front proxy. (16:27:03 could not be located in either timezone in
that day's rotation; it may belong to the previous day, which is already rotated out.
It does not change the above.)

What still stands from the correction: the GET lines in that count are internet
scanners (194 of the 1,849 total; upstream_status=-, bytes=146) and never reach
the proxy; the URI is not recorded, so the raw total cannot be read as a probe count;
and the earlier volume figures (570 in six hours, ~95/hour, 1908/day) remain
withdrawn — they came from an older container's logs that no longer exist. The
countable facts are now: 1,655 probe-signature POSTs from one egress IP on Nov 8,
and 31 admission-answered probes in the current journal retention. The core claims
(call site, per-image-turn retry, unconditional inline fallback) are unaffected.

[sciman-top]

Withdrawing one more claim of mine, this one in the "never traversed nginx" paragraph.

I said the two probe timestamps I checked produced zero matching access-log lines, and read that as proof the requests bypassed the reverse proxy. That was a timezone mistake on my side: the host runs UTC and my journal tool already prints UTC, so those timestamps were already on the same scale as the log. I treated them as UTC+8, which shifted them 8 hours and manufactured the empty grep.

Re-checked correctly, at 08:54:33Z the log holds an exact probe signature: POST route=other status=404 upstream_status=404 bytes=0 from my own egress IP. So the uploads do go through the proxy, on the same client connection as chat.

What I can reproduce on that log:

• 1655 POST route=other status=404 — all from a single egress IP
• 194 GET route=other status=404 — internet scanners (upstream_status=-, bytes=146), a different population
• hourly histograms that track chat (222/498, 213/491, 100/276 at 00h/01h/02h), with POST-404 falling to zero from 13h onward — the hour local silent-404 handling shipped

One number in my previous comment I could not reproduce: 5505 route=other status=200. On the same log that tuple is 3816 and entirely POST, so wherever 5505 came from it is not this query. Correcting to 3816 rather than repeating it.

None of this changes the substantive answer: the upload is the adapter's Files transport, it fires per image-bearing turn, the 404 degrades to inline base64 unconditionally, and there is no setting to disable it. The volumetric side of my argument has now been wrong twice, so treat the counts above as the only ones I have actually verified — and if a maintainer needs the raw numbers, the log is one day and the commands are grep -c on the tuples above.