batch-compress
When this skill is the preferred path
For corpus-scale pre-processing, batching amortizes network round-trips
and returns one aggregate savings report. A loop of ingest_context
calls is the slow and expensive path for the same work.
How to use it
- Enumerate the files. Respect
.gitignore. Skip binaries, generated files, lockfiles,node_modules,vendor,dist,build. - Group into batches of up to 50 documents (the API cap). Larger corpora need multiple calls.
- Call
batch_ingest_documents(MCP tool; Pro+). Returns ajob_idimmediately. - Poll job status via
GET /v1/batch-queue/{id}(REST) or subscribe toGET /v1/batch-queue/streamfor SSE updates. - When complete, retrieve each compressed item by its item id.
- Report to the user:
- Total files processed
- Aggregate tokens saved
- Any failures (rate limit, invalid input, permissions) — the API returns per-item errors so failures don't block the batch
When the raw read or a simpler skill fits better
- Single file or a small set (<3 files) —
shrink-for-claude. - Files the user is actively editing — stale snapshots will confuse.
Plan gating
batch_ingest_documents returns HTTP 403 on Free with an upgrade
link. Surface that response faithfully — don't paper over it with a
fallback loop. The user wanted batch throughput; they should see the
upgrade path instead of a silent slow fallback.
Warn before starting
If the batch will have >200 items, confirm before enqueuing. Processing time scales linearly and the user may have wanted a smaller slice.