> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Import a cloud model batch request set
description: >-
  Each cloud model batch provider gets its own generated profile, level and
  evidence. Endpoint and regional differences are documented rather than folded
  into one cloud claim.
route: /docs/compute/integrations/cloud-model-batch
page_id: docs-compute-integrations-cloud-model-batch
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Engineers importing batch requests written for a cloud model service
voice: D
reader_question: Which cloud model batch formats can Compute import, and how do I check?
primary_action: Read the provider profile, then request a quote
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-integrations-cloud-model-batch-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## What this connects

Batch request files written for a cloud provider's model service, as an input. Lithi reads the file and maps each entry onto a Compute workflow request.

There is no single cloud compatibility level, because there is no single cloud behavior. Each provider has its own generated profile, its own named level and its own published conformance matrix. Read the profile for the provider you are importing from, and treat it as the authority over this page.

## Bind an exact input

Freeze the assembled request file and bind it by identity and digest:

```json
"snapshot": {
  "version_id": "<the request set identity you recorded>",
  "content_sha256": "<the digest of those exact bytes>"
}
```

Per-request identity is preserved. Each entry's custom identifier stays attached to its unit and appears on the matching output row, so results join back by identifier rather than by order. Duplicates are refused by value.

## Credentials

No provider key is involved and none is accepted. Lithi does not call a cloud model service on your behalf.

Where the file is staged, `input.credential_ref` names a registered storage credential as a reference, never a secret value. Register it, test it, read it back, and revoke it when the work ends.

## Formats and limits

Read the provider profile before you assume anything. Each profile states four things that genuinely vary between providers, and getting them from the wrong profile is the most common failure here:

| What varies | Where to read it |
| --- | --- |
| Supported request fields and endpoints | The provider's generated profile |
| Lifecycle steps and their order | The provider's conformance matrix |
| Error shapes and typed refusals | The operation's own generated `error_schema` |
| Regional and data-residency differences | The provider profile, plus your own policy |

Regional differences are documented per provider rather than generalized. A shape that is supported in one region may not be in another, and the profile says which.

An unsupported field is refused by name. It is never defaulted or approximated, because a silently dropped field would change the work you paid for. The maximum item count for a workflow is stated on its descriptor and repeated on your quote.

## Commit the output

Outcomes arrive as a Lithi result bundle, not as a provider-shaped output file. Accepted rows land in `data/part-*`, typed failures and abstentions beside them, and `result-manifest.json` is written last as the only complete-bundle marker.

The lifecycle is Lithi's for every provider. A quote comes first and never authorizes work; approval is a separate act; a job reaches `SUCCEEDED`, `PARTIAL`, `FAILED` or `CANCELLED`; and every non-success carries a safe reason and a concrete next action.

Where your policy constrains where work may run, set that in your policy profile rather than inferring it from a provider's region. See [how regions and jurisdiction are applied](/docs/compute/security/regions-and-jurisdiction).

## What is not supported

There is no blanket cloud compatibility claim, and no provider profile may be read as evidence about another provider.

Outside the adapter:

- Any provider whose profile and conformance matrix have not been published.
- Calling a cloud model service, or holding a cloud provider credential.
- Provider-shaped output files, provider error codes or provider batch identifiers.
- Assuming a field, region or limit carries across providers because the file format looks similar.

If a field or an endpoint is refused, the response names it. Map it against the correct provider profile, rebuild, take a new digest, then quote and approve again.