@ljoukov/llm 6.0.0 → 7.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -46,14 +46,20 @@ Use one backend:
46
46
 
47
47
  - `GEMINI_API_KEY` or `GOOGLE_API_KEY` for the Gemini Developer API
48
48
  - `GOOGLE_SERVICE_ACCOUNT_JSON` for Vertex AI (the contents of a service account JSON key file, not a file path)
49
+ - `LLM_FILES_GCS_BUCKET` for canonical file storage used by `files.create()` and automatic large-attachment offload
50
+ - `LLM_FILES_GCS_PREFIX` (optional object-name prefix inside `LLM_FILES_GCS_BUCKET`)
49
51
  - `VERTEX_GCS_BUCKET` for Vertex-backed Gemini file attachments / `file_id` inputs
50
52
  - `VERTEX_GCS_PREFIX` (optional object-name prefix inside `VERTEX_GCS_BUCKET`)
51
53
 
52
54
  If a Gemini API key is present, the library uses the Gemini Developer API. Otherwise it falls back to Vertex AI.
53
55
 
54
- For Vertex-backed Gemini file inputs, the library mirrors OpenAI-backed canonical files into GCS and then passes the
55
- resulting `gs://...` URI to Vertex. Configure a lifecycle rule on that bucket to delete objects after 2 days if you
56
- want hard 48-hour cleanup for mirrored objects.
56
+ Canonical files are stored in GCS with a default `48h` TTL. OpenAI and ChatGPT consume those files via signed HTTPS
57
+ URLs. Gemini still mirrors canonical files lazily into provider-native storage when needed:
58
+
59
+ - Gemini Developer API mirrors into Gemini Files
60
+ - Vertex-backed Gemini mirrors into `VERTEX_GCS_BUCKET` and uses `gs://...` URIs
61
+
62
+ Configure lifecycle rules on those buckets if you want hard 48-hour cleanup for mirrored objects.
57
63
 
58
64
  #### Vertex AI service account setup
59
65
 
@@ -260,9 +266,9 @@ const result = await generateText({ model: "gpt-5.4-mini", input });
260
266
  console.log(result.text);
261
267
  ```
262
268
 
263
- Canonical storage defaults to OpenAI Files with `purpose: "user_data"` and a `48h` TTL.
269
+ Canonical storage now uses GCS-backed objects with a `48h` TTL.
264
270
 
265
- - OpenAI models use that `file_id` directly.
271
+ - OpenAI and ChatGPT models resolve that `file_id` to a signed HTTPS URL.
266
272
  - Gemini Developer API mirrors the file lazily into Gemini Files when needed.
267
273
  - Vertex-backed Gemini mirrors the file lazily into `VERTEX_GCS_BUCKET` and uses `gs://...` URIs.
268
274
 
@@ -294,7 +300,7 @@ When the combined inline attachment payload in a single request would exceed abo
294
300
  the library automatically uploads those attachments to the canonical files store first and swaps the prompt to file
295
301
  references:
296
302
 
297
- - OpenAI: uses canonical OpenAI `file_id`s directly
303
+ - OpenAI / ChatGPT: use signed HTTPS URLs for canonical files
298
304
  - Gemini Developer API: mirrors to Gemini Files and sends `fileData.fileUri`
299
305
  - Vertex AI: mirrors to `VERTEX_GCS_BUCKET` and sends `gs://...` URIs
300
306
 
@@ -320,8 +326,8 @@ console.log(result.text);
320
326
 
321
327
  You can mix direct `file_id` parts with `inlineData`. Small attachments stay inline; oversized turns are upgraded to
322
328
  canonical files automatically. Tool loops do the same for large tool outputs, and they also re-check the combined size
323
- after parallel tool calls so a batch of individually-small images/files still gets upgraded to `file_id` references
324
- before the next model request if the aggregate payload is too large.
329
+ after parallel tool calls so a batch of individually-small images/files still gets upgraded to canonical-file
330
+ references before the next model request if the aggregate payload is too large.
325
331
 
326
332
  You can also control image analysis fidelity with request-level `mediaResolution`:
327
333
 
@@ -927,15 +933,17 @@ Standard integration suite:
927
933
  npm run test:integration
928
934
  ```
929
935
 
930
- Large-file live integration tests are opt-in because they upload multi-megabyte fixtures to real provider file stores:
936
+ Large-file live integration tests are opt-in because they upload multi-megabyte fixtures to real canonical/provider
937
+ file stores:
931
938
 
932
939
  ```bash
933
940
  LLM_INTEGRATION_LARGE_FILES=1 npm run test:integration
934
941
  ```
935
942
 
936
- Those tests generate valid PDFs programmatically so the canonical upload path, `file_id` reuse, and automatic large
943
+ Those tests generate valid PDFs programmatically so the canonical upload path, signed-URL reuse, and automatic large
937
944
  attachment offload all exercise real provider APIs. The unit suite also covers direct-call upload logging plus
938
- `runAgentLoop()` upload telemetry/logging for combined-image overflow.
945
+ `runAgentLoop()` upload telemetry/logging for combined-image overflow, and the integration suite includes provider
946
+ format coverage for common document and image attachments.
939
947
 
940
948
  ## License
941
949