[kcoopermiller]

Patch release of two packages. It ships the upload performance work from #1129, #1136 and #1140, and the higher upload limits from #1138. Nothing else under packages/prime-traces or packages/prime-runs has changed since the last release.

• prime-traces: 0.0.11 → 0.0.12
• prime-runs: 0.1.5 → 0.1.6

Dependency floor: prime-runs now requires prime-traces>=0.0.12. Its traces sink can hand TracesClient records already encoded as bytes, which 0.0.11 can't take.

The CLI is not released here. It keeps prime-traces>=0.0.10, so a fresh install picks up 0.0.12 and prime traces upload starts sending up to 8 requests at once.

What's new

prime-traces 0.0.12

• Upload bodies gzip at level 1 instead of 9 (fix: gzip trace uploads at level 1 #1129). On real long traces that is about 5x faster for about 20% more bytes.
• upload_lines, upload_records and upload_file keep up to max_in_flight batches in flight, default 8 (feat: non-blocking, concurrent run uploads in prime-runs and prime-traces #1136). Receipts still come back in batch order, and on_batch runs on the calling thread.
• upload_records accepts a record already encoded as one JSON line (bytes) (feat: upload an episode's own to_json when it names the run #1140).
• The client's upload limits rise to 1 GiB per line and 1100 MiB per request, from 64 MiB and 256 MiB (feat(prime-traces): raise the client line limit to 1 GiB #1138). Episodes over 64 MiB no longer fail locally. Against a deployment still on the old limits, they get a 400 trace_too_large instead.

prime-runs 0.1.6

• Logging never blocks. The upload queue holds up to 10,000 records, and a batch that doesn't fit is dropped and counted at once (feat: non-blocking, concurrent run uploads in prime-runs and prime-traces #1136).
• TracesSink prepares records as the client encodes them (feat: non-blocking, concurrent run uploads in prime-runs and prime-traces #1136).
• TracesSink uploads an episode's own to_json() when the episode and each of its traces already name this run (feat: upload an episode's own to_json when it names the run #1140). Anything else is stamped as before. This needs feat: encode episodes to JSON one node at a time and record runs on traces verifiers#3042 to take effect, and upload IDs for those records change because the key order differs.

Breaking: UploadWorker(max_queue_size=..., put_timeout=...) becomes UploadWorker(max_queued_records=...), and DEFAULT_QUEUE_SIZE and DEFAULT_PUT_TIMEOUT are gone. Run and init() are unchanged.

Known limitations

Raised in review on #1136 and shipping as they are:

• One rejected record can cost the rest of the write. A write takes everything queued, and a failed batch stops the rest of it. With 500 episodes queued and one rejected, 370 were lost in a mock test.
• Failures are over-reported. The same test reported 500 failed although 130 were stored.
• Exit can outlast the drain budget. Python joins the upload threads at interpreter exit. With 20 s requests in a local test, close(timeout=1) returned at 1.5 s and the process lived 20 s.
• The queue has no byte limit. Memory grows with episode size: 1000 episodes of about 2.3 MiB peaked at 1.8 GiB.
• A 1 GiB line is expensive on the client. Batching and gzipping one peaked at about 4 GiB of memory (feat(prime-traces): raise the client line limit to 1 GiB #1138), and no upload over 64 MiB has been tested against a live service.

Release

Merging triggers release-traces.yml and release-runs.yml. They publish to PyPI and create the prime-traces-v0.0.12 and prime-runs-v0.1.6 tags. Neither tag exists yet.

prime-runs 0.1.6 can't be installed until prime-traces 0.0.12 is on PyPI. If the runs workflow finishes first, installs fail for a short time.

Validation

• prime-traces: 187 passed at this PR's head, and 189 with feat(prime-traces): raise the client line limit to 1 GiB #1138 merged.
• prime-runs: 304 passed, 1 skipped, in both.
• ruff check and ruff format --check pass.
• 1000 episodes of about 2.3 MiB through the real uploader against a dev Prime Traces deployment, at feat: non-blocking, concurrent run uploads in prime-runs and prime-traces #1136's head: all 1000 stored in 42 s, longest submit() 0.1 ms. feat: upload an episode's own to_json when it names the run #1140 was not part of that run. Production-sized episodes and several runs uploading at once are untested against a real service.

🤖 Generated with Claude Code

---

Note

Low Risk
The diff only changes version strings and a dependency minimum; operational risk is limited to release ordering if prime-runs publishes before prime-traces on PyPI.

Overview
This PR is a patch release that only bumps package versions and aligns the dependency floor—no functional code changes in the diff.

prime-traces goes 0.0.11 → 0.0.12, and prime-runs goes 0.1.5 → 0.1.6. prime-runs now requires prime-traces>=0.0.12 (was >=0.0.11), matching the runs SDK’s need for traces APIs that accept pre-encoded JSONL bytes and the upload performance work already merged in earlier PRs (#1129, #1136, #1140).

Merging is intended to trigger the existing release workflows and publish both wheels to PyPI with the corresponding version tags.

^{Reviewed by Cursor Bugbot for commit e55c7e7. 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-02T23:10:30.698482Z	e55c7e7	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.