[kcoopermiller]

Summary

Raises the SDK's trace upload limits to match the service: 1 GiB per JSONL line (was 64 MiB) and 1100 MiB per request (was 256 MiB).

The SDK rejects an oversized line locally with TraceTooLargeError, before any request. So until this ships, episodes over 64 MiB can't be uploaded through the SDK, prime traces upload, or prime-runs, whatever the service allows. prime-runs logs the rejection as a warning and drops that batch.

• MAX_LINE_BYTES is now 1 GiB and MAX_BATCH_BYTES is 1100 MiB.
• DEFAULT_TARGET_BATCH_BYTES stays at 30 MiB, because an oversized line already gets its own batch. Its comment no longer cites a Cloud Run request cap, which doesn't fit single lines this large.
• Comments that stated the old sizes are updated.

Before you merge

• Order: release this after the service accepts the new limits. Against a service still on the old limits, a line over 64 MiB gets a 400 trace_too_large instead of the local error.
• Release: this PR doesn't bump versions. The CLI needs a prime-traces release and a dependency bump to pick this up.

Testing

• packages/prime-traces tests pass (185), including new ones that pin the limits and upload a line just over the old 64 MiB limit through default batching.
• Ruff check and format pass.
• Not tested: a real upload over 64 MiB against a live service.

Known costs at 1 GiB

• Client memory: batching and gzipping one 1 GiB line peaked at about 4 GiB RSS and took about 7s locally. That measured those two steps only, on a hex payload that compressed to about 58%. The line is held whole, joined into a second copy, then gzipped in memory, which could matter inside a training job.
• Response timeout: DEFAULT_TIMEOUT still allows 120s to wait for a response. A timeout retries safely under the same idempotency key, but each attempt compresses and sends the whole request again.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes the core upload path and enables multi‑GiB in-memory batching/compression; clients deployed before the service raises limits will see server 400s instead of local errors.

Overview
Aligns prime-traces client-side rejection and batching caps with the service: MAX_LINE_BYTES goes from 64 MiB to 1 GiB, and MAX_BATCH_BYTES from 256 MiB to 1100 MiB. Oversized lines still fail locally with TraceTooLargeError before any HTTP call; with the old SDK cap, episodes between 64 MiB and 1 GiB could not be uploaded even when the server allowed them.

DEFAULT_TARGET_BATCH_BYTES remains 30 MiB; its comment is rewritten to emphasize retry/memory cost instead of a Cloud Run request ceiling. Sync/async stream_bytes docstrings and the HTTP client DEFAULT_TIMEOUT comment now describe 1 GiB / 1100 MiB payloads. The prime traces get --raw CLI comment is updated similarly.

Tests assert the new default constants and that a line just over the former 64 MiB limit batches successfully under default settings.

^{Reviewed by Cursor Bugbot for commit 2326bfc. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-02T19:49:48.095435Z	2326bfc	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.