bun run --check: type errors stop before a Sume job submits

Run your Sume script with bun run --check script.ts. Bun 1.4.3 type checks first, and if there is a type error your code never runs, so a typo in a request field cannot reach a paid generation endpoint.

That ordering is the whole point for a billing API. The Bun v1.4.3 post (read 2026-10-10) describes bun check and the --check flag; this post shows where it fits in a Sume job script.

What Bun 1.4.3 added

Facts below are from the Bun release post, dated October 10, 2026 (read 2026-10-10).

Where it helps in a Sume script

The Sume SDK generates one typed function per operation. Generated operations do not throw on an API error: they resolve with data, error and response, and the SDK docs say so on the runs page. Types are what remind you to handle the error branch before you read data.

• A wrong field name in the request body fails the check, not the API call.
• Reading submitted.data without handling error is flagged when the type allows undefined.
• Because the check runs before the script, no job is created and nothing is reserved against your balance.

The script

This is the generation-job pattern from the SDK docs: submit async with an idempotency key, then wait on the job id. Save it as sume-video.ts.

import { createSumeClient, generateVideoV1, waitForJob } from "@sume-com/sdk";

const client = createSumeClient({ apiKey: process.env.SUME_API_KEY! });

const { data: submitted, error } = await generateVideoV1({
  client,
  headers: { "idempotency-key": crypto.randomUUID() },
  body: { prompt: "Slow push-in on a ceramic mug", mode: "async" },
});
if (error) throw new Error(JSON.stringify(error));

const job = await waitForJob(submitted!.data.request_id, {
  client,
  onStatus: (status, snapshot) => console.log(status, snapshot.next_action),
});

console.log(job.status, job.result.artifacts);

Then run it with the check on:

bun run --check sume-video.ts

Limits worth knowing

A type check cannot know your balance, your key scopes or whether the prompt is accepted. Those come back as API errors, with a code and a request id in the error envelope. The check also does not make a retry safe: keep the Idempotency-Key and reuse it only for an exact retry of the same request. Use bun test --check for the same guard on your tests, and keep the full request shapes in the API reference.