# Batch AI

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-084-batch-ai
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-084-URL-54DA17A685AD, EVD-EA-084-URL-DBCB362197DB, EVD-EA-084-URL-1A16A6E71D17, EVD-EA-084-URL-D1910CF4F698, EVD-EA-084-URL-AF1B5C331102, EA-084-R11-RESEARCH, EA-084-R11-WEB-READBACK
UNKNOWN_IDS: EA-084-UNKNOWN-01, EA-084-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
“For non-urgent independent workloads, provider batch APIs can trade interactive latency for lower unit cost and higher bulk throughput. Treat batch as an asynchronous job system with explicit manifests, item IDs, reconciliation, partial-failure handling, and retention controls.”

## Current judgment
Batch is an execution class, not merely “many synchronous calls.” The Core should route work by deadline/SLO, dependency graph, mutability, ordering, data locality, output size, and cost sensitivity. Every input needs a stable request_id/custom_id and immutable request manifest/hash; outputs must be reconciled by ID, not assumed position. Batch creation, partial failure, cancellation, expiration, completion, output retrieval, and retry are separate states. Provider price discounts are current product claims, not permanent architecture guarantees.

## Scope
Enterprise AI Core / provider mapping / architecture / cost / operability / governance

## Confirmed
- Batch is an execution class, not merely “many synchronous calls.” The Core should route work by deadline/SLO, dependency graph, mutability, ordering, data locality, output size, and cost sensitivity. Every input needs a stable request_id/custom_id and immutable request manifest/hash; outputs must be reconciled by ID, not assumed position. Batch creation, partial failure, cancellation, expiration, completion, output retrieval, and retry are separate states. Provider price discounts are current product claims, not permanent architecture guarantees.

## UNKNOWN
- EA-084-UNKNOWN-01: exact per-model batch coverage, quotas, file/request limits, and enterprise residency/retention matrix as of publication. STOP_CONDITION: architecture and failure contract established; volatile provider matrix deferred to update Work.

---
- EA-084-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-084-URL-54DA17A685AD (RESEARCH): 1. source class: official product documentation; exact title: Batch API; author/org: OpenAI; canonical URL: — https://developers.openai.com/api/docs/guides/batch
- EVD-EA-084-URL-DBCB362197DB (RESEARCH): 2. source class: official product documentation; exact title: Batch processing; author/org: Anthropic; canonical URL: — https://platform.claude.com/docs/en/build-with-claude/batch-processing
- EVD-EA-084-URL-1A16A6E71D17 (RESEARCH): 3. source class: official product documentation; exact title: Batch API; author/org: Google; canonical URL: — https://ai.google.dev/gemini-api/docs/batch-api
- EVD-EA-084-URL-D1910CF4F698 (RESEARCH): 4. source class: official product documentation; exact title: Batch Predict with Gemini using GCS data / BigQuery data; author/org: Google Cloud; canonical URLs: — https://docs.cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-batch-predict-gemini-createjob-gcs
- EVD-EA-084-URL-AF1B5C331102 (RESEARCH): 4. source class: official product documentation; exact title: Batch Predict with Gemini using GCS data / BigQuery data; author/org: Google Cloud; canonical URLs: https://docs.cloud — https://docs.cloud.google.com/vertex-ai/generative-ai/docs/samples/googlegenaisdk-batchpredict-with-bq
- EA-084-R11-RESEARCH (RESEARCH): EA-084 監査済みresearch / canonical revision binding
- EA-084-R11-WEB-READBACK (IMPL): EA-084 Web body identity / canonical readback

## Failure / limits
No interactive latency guarantee; provider turnaround target can be too slow for operational triggers; submitted jobs may be immutable; partial request failures; duplicate resubmission after uncertain status; result ordering mismatch; model/endpoint/tool/modality coverage gaps; input/output file retention and residency concerns; batch completion notification loss; stale business data by execution time; large failed batches causing expensive replay.
## Practice
Provider/model/endpoint/modality; region; input source/file limits; request count/token limits; completion window; batch-specific quota/rate limits; data residency; pricing; cancellation/expiration behavior; output retention.
## Practice
OpenAI, Anthropic, Gemini API, and Vertex AI expose current batch/asynchronous bulk inference mechanisms. Exact model coverage and quotas are provider-volatile.
## Practice
identical workload through synchronous and batch paths with fixed model/revision. Measure quality equivalence, completion-time distribution, throughput, cost/request and cost/token, partial-failure rate, reconciliation correctness, retry amplification, duplicate-output rate, and operational recovery time. Include cancellation and malformed-request fixtures.
## Practice
Persist batch manifest hash, submitter/service identity, provider/project/region, model revision, request IDs, input/output object references and hashes, submit/start/complete/expire timestamps, per-item status, retry lineage, cost, and deletion/retention state. Batch discount must not justify moving sensitive data to a weaker residency/retention path.
## Practice
Add BATCH_EXECUTION_CONTRACT: deadline/SLO, immutable input manifest/hash, provider/model/revision, request_id, job_id, lifecycle state, output mapping/hash, retry lineage, completion notification, retention/deletion, and cost. Re-pin provider discounts and turnaround commitments at publication.
## Practice
OpenAI Batch API numeric/product claims stay as-of; batch acceptance, completion window and item outcomes remain distinct.
## WHY_THIS_MATTERS_TO_UPDATE
A large share of enterprise AI work—classification, enrichment, evaluation, summarization, embedding, media processing—does not require interactive latency. Batch paths can materially lower cost and raise throughput, but trade away immediate completion, ordering assumptions, mutability, and sometimes endpoint/tool coverage.

## SCOPE_ROUTING
Enterprise AI Core / provider mapping / architecture / cost / operability / governance

## CLAIM_OR_RESEARCH_QUESTION
When should a workload be routed from synchronous inference to provider batch execution, and what manifest, SLA, retry, reconciliation, and provenance controls preserve correctness?

## EVIDENCE TABLE
1. source class: official product documentation; exact title: Batch API; author/org: OpenAI; canonical URL: https://developers.openai.com/api/docs/guides/batch ; access date: 2026-09-16; API revision: current docs; locator: Batch API overview; evidence label: VERIFIED_SPEC / PRODUCT_VOLATILE; relation: support/availability. Current docs state 50% cost discount vs synchronous APIs, separate/higher rate-limit headroom, and completion within 24 hours; requests use unique custom_id for result correlation and an input file is single-model.
2. source class: official product documentation; exact title: Batch processing; author/org: Anthropic; canonical URL: https://platform.claude.com/docs/en/build-with-claude/batch-processing ; access date: 2026-09-16; API revision: current docs; locator: pricing / batch lifecycle; evidence label: VERIFIED_SPEC / PRODUCT_VOLATILE; relation: support/limit. Current docs state 50% discount; submitted batch cannot be modified, requiring cancel/new submission for changes; batch rate limits are separate from Messages API limits.
3. source class: official product documentation; exact title: Batch API; author/org: Google; canonical URL: https://ai.google.dev/gemini-api/docs/batch-api ; access date: 2026-09-16; API revision: current Gemini API; locator: overview / supported models / pricing / SLO; evidence label: VERIFIED_SPEC / PRODUCT_VOLATILE; relation: support/availability. Current docs state asynchronous processing at 50% standard cost, target 24-hour turnaround, generateContent-only note, model-specific support, and context caching support within batch requests.
4. source class: official product documentation; exact title: Batch Predict with Gemini using GCS data / BigQuery data; author/org: Google Cloud; canonical URLs: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/samples/generativeaionvertexai-batch-predict-gemini-createjob-gcs and https://docs.cloud.google.com/vertex-ai/generative-ai/docs/samples/googlegenaisdk-batchpredict-with-bq ; access date: 2026-09-16; evidence label: VERIFIED_SPEC / PRODUCT_VOLATILE; relation: implementation/context. Demonstrates Vertex AI batch prediction paths using GCS and BigQuery inputs/outputs.

## FINDINGS
Batch is an execution class, not merely “many synchronous calls.” The Core should route work by deadline/SLO, dependency graph, mutability, ordering, data locality, output size, and cost sensitivity. Every input needs a stable request_id/custom_id and immutable request manifest/hash; outputs must be reconciled by ID, not assumed position. Batch creation, partial failure, cancellation, expiration, completion, output retrieval, and retry are separate states. Provider price discounts are current product claims, not permanent architecture guarantees.

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
No interactive latency guarantee; provider turnaround target can be too slow for operational triggers; submitted jobs may be immutable; partial request failures; duplicate resubmission after uncertain status; result ordering mismatch; model/endpoint/tool/modality coverage gaps; input/output file retention and residency concerns; batch completion notification loss; stale business data by execution time; large failed batches causing expensive replay.

## AVAILABILITY_GATES
Provider/model/endpoint/modality; region; input source/file limits; request count/token limits; completion window; batch-specific quota/rate limits; data residency; pricing; cancellation/expiration behavior; output retention.

## IMPLEMENTATION_STATE
OpenAI, Anthropic, Gemini API, and Vertex AI expose current batch/asynchronous bulk inference mechanisms. Exact model coverage and quotas are provider-volatile.

## TEST_PROFILE
identical workload through synchronous and batch paths with fixed model/revision. Measure quality equivalence, completion-time distribution, throughput, cost/request and cost/token, partial-failure rate, reconciliation correctness, retry amplification, duplicate-output rate, and operational recovery time. Include cancellation and malformed-request fixtures.

## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY
Persist batch manifest hash, submitter/service identity, provider/project/region, model revision, request IDs, input/output object references and hashes, submit/start/complete/expire timestamps, per-item status, retry lineage, cost, and deletion/retention state. Batch discount must not justify moving sensitive data to a weaker residency/retention path.

## SAFE_WORDING_FOR_FUTURE_BOOK
“For non-urgent independent workloads, provider batch APIs can trade interactive latency for lower unit cost and higher bulk throughput. Treat batch as an asynchronous job system with explicit manifests, item IDs, reconciliation, partial-failure handling, and retention controls.”

## UPDATE_WORK_HANDOFF
Add BATCH_EXECUTION_CONTRACT: deadline/SLO, immutable input manifest/hash, provider/model/revision, request_id, job_id, lifecycle state, output mapping/hash, retry lineage, completion notification, retention/deletion, and cost. Re-pin provider discounts and turnaround commitments at publication.

## OPEN_UNKNOWN
exact per-model batch coverage, quotas, file/request limits, and enterprise residency/retention matrix as of publication. STOP_CONDITION: architecture and failure contract established; volatile provider matrix deferred to update Work.

---

## AUDITED_CURRENTNESS_BOUNDARY
OpenAI Batch API numeric/product claims stay as-of; batch acceptance, completion window and item outcomes remain distinct.

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.