Attachments
LLM Integration
How attachments become multimodal parts for provider requests
Part Mapping
Attachments that resolve successfully are converted to provider‑agnostic parts:
| Attachment | Resolution | LLM Part | Notes |
|---|---|---|---|
image | URL | ImageURLPart | Sent as a URL reference (no binary payload) |
image | Path | BinaryPart | Read and included as binary (image/*) |
audio, video | URL or Path | BinaryPart | Remote URLs are downloaded to temp under limits; MIME must match allow‑list |
pdf | URL or Path | TextPart or BinaryPart | Tries text extraction up to a configured limit; falls back to binary |
file | Path | TextPart or BinaryPart | text/* files are loaded as text (bounded); others as binary |
url | URL | — | Validated but not included as a part in this phase |
Choosing URL vs Path
- 1URL for images
When supported by the provider, image URLs are cheaper and faster than uploading bytes.
- 2Path for reliability
Local paths embed the bytes, ensuring the prompt remains self‑contained regardless of external availability.
- 3Large media
Ensure global limits are sized appropriately to avoid truncation; otherwise prefer URLs when possible.
Prompt Assembly
Attachments are passed alongside the user content. Adapters must avoid duplicating text content when parts are present.
User message → { content: "...", parts: [ImageURLPart | BinaryPart | TextPart, ...] }