Bun 1.4 fetch request compression: should Sume API calls use gzip?

Leave Bun 1.4's fetch request compression off for Sume API calls unless you have tested it against your own workspace. The Bun 1.4 release post lists fetch() request compression with gzip, brotli, zstd and deflate, but Sume's public docs describe request bodies only as application/json, document 413 payload_too_large for a body over the configured API limit and 415 unsupported_media_type for a non-JSON body, and say nothing about a Content-Encoding on requests.

Bun's side is from the Bun 1.4 release post, read 2026-10-03; Sume's side is from Errors and rate limits and Jobs and results. I did not send a compressed request to Sume, so whether it would be accepted is unverified.

Why is there little to gain?

Sume submit bodies are small JSON: a prompt, options and, for image or video input, a public HTTPS URL to the media rather than the media bytes. The errors docs describe input media as a public HTTPS image URL that Sume fetches itself, and image_not_fetchable or input_media_unreachable as the failures when it cannot. A compressed JSON prompt saves little next to that, and a rejected request costs you a retry.

What do the statuses mean if I try it anyway?

Test it with a request you can afford to fail, and read the error envelope: it includes error.code, a message and a request_id that is safe to share with Sume support. If the call fails after you enable compression and succeeds without it, turn it off. Do not compare by resubmitting a paid job: reuse the same Idempotency-Key with the same payload, which returns the original job, and note that the same key with a different payload returns 409 idempotency_conflict.