fix(providers): keep every attachment that works today working

Auditing the routing change for backwards compatibility turned up two bands it
silently broke.

Lowering the single inline cap made the upload path mandatory above ~6 MB, but
every large-file path reads its bytes back out of cloud object storage. A
deployment without it — local dev, any disk-backed self-host — inlines those
files as base64 today and would have started failing outright with "requires
cloud file storage". Split the one number in two: the inline ceiling stays at
10 MiB, and a separate threshold marks where an upload becomes *preferable*
because the base64 copy no longer fits the payload store. Where no upload path
is reachable, base64 hydration now runs to the inline ceiling as before, and a
missing cloud-storage backend leaves the file for the inline path instead of
throwing.

The two strategies also cross over at different sizes now. `files-api` carries
every type the provider already accepts, so it takes over at the lower
threshold. `remote-url` only fetches images and PDFs, so switching early would
have started rejecting 6-10 MB text documents that inline fine today; it takes
over only once inlining is genuinely impossible.

Revert the Groq ceilings. Its published "20MB" governs a request carrying an
image URL, and on this path the body holds only the URL, so it cannot bind on
the files maxBytes guards. Groq documents no limit on the image it fetches, so
tightening the per-file cap to 20,000,000 and summing raw bytes against the
request cap would both reject uploads that work today on no documented basis.

Author: waleedlatif1

apps/sim/executor/handlers/agent/agent-handler.ts

@@ -54,9 +54,11 @@ import { resolveVertexCredential } from '@/executor/utils/vertex-credential'
 import { executeProviderRequest } from '@/providers'
 import {
   INLINE_ATTACHMENT_THRESHOLD_BYTES,
+  LARGE_FILE_PATH_THRESHOLD_BYTES,
   shouldUseLargeFilePath,
   supportsFileAttachments,
 } from '@/providers/attachments'
+import { canUseProviderLargeFilePath } from '@/providers/file-attachments.server'
 import { isAutoModel, SIM_AUTO_MODEL_ID } from '@/providers/models'
 import { getProviderFromModel, transformBlockTool } from '@/providers/utils'
 import type { SerializedBlock } from '@/serializer/types'
@@ -946,6 +948,15 @@ export class AgentBlockHandler implements BlockHandler {
     const requestId = ctx.executionId || ctx.workflowId || 'agent-files'
     const nextMessages = [...messages]
 
+    /**
+     * Stop hydrating base64 early only where an upload can actually take over. Where it cannot —
+     * an inline-only provider, or any deployment without cloud storage — base64 stays the only
+     * delivery path, so it has to be hydrated all the way to the inline ceiling.
+     */
+    const inlineMaxBytes = canUseProviderLargeFilePath(providerId)
+      ? LARGE_FILE_PATH_THRESHOLD_BYTES
+      : INLINE_ATTACHMENT_THRESHOLD_BYTES
+
     for (let messageIndex = 0; messageIndex < messages.length; messageIndex++) {
       const message = messages[messageIndex]
       if (!message.files?.length) {
@@ -963,16 +974,17 @@ export class AgentBlockHandler implements BlockHandler {
         allowLargeValueWorkflowScope: ctx.allowLargeValueWorkflowScope,
         userId: ctx.userId,
         logger,
-        maxBytes: INLINE_ATTACHMENT_THRESHOLD_BYTES,
+        maxBytes: inlineMaxBytes,
       })
 
       const missingFile = hydratedFiles.find(
-        (file) => !file.base64 && !shouldUseLargeFilePath(file, providerId)
+        (file) =>
+          !file.base64 &&
+          !(canUseProviderLargeFilePath(providerId) && shouldUseLargeFilePath(file, providerId))
       )
       if (missingFile) {
-        const inlineMB = (INLINE_ATTACHMENT_THRESHOLD_BYTES / (1024 * 1024)).toFixed(0)
-        const oversized =
-          Number.isFinite(missingFile.size) && missingFile.size > INLINE_ATTACHMENT_THRESHOLD_BYTES
+        const inlineMB = (inlineMaxBytes / (1024 * 1024)).toFixed(0)
+        const oversized = Number.isFinite(missingFile.size) && missingFile.size > inlineMaxBytes
         throw new Error(
           oversized
             ? `File "${missingFile.name}" (${(missingFile.size / (1024 * 1024)).toFixed(2)}MB) exceeds the ${inlineMB}MB inline attachment limit, and provider "${providerId}" has no large-file upload path for it.`

apps/sim/providers/attachments.test.ts

@@ -16,6 +16,7 @@ import {
   getProviderFileStrategy,
   INLINE_ATTACHMENT_THRESHOLD_BYTES,
   inferAttachmentMimeType,
+  LARGE_FILE_PATH_THRESHOLD_BYTES,
   prepareProviderAttachments,
   shouldUseLargeFilePath,
 } from '@/providers/attachments'
@@ -288,13 +289,27 @@ describe('provider attachments', () => {
 
 describe('provider large-file capability', () => {
   /**
-   * Guards the regression where the inline cap (10 MB) sat above what the payload store could
-   * hold once base64 inflated it, so every 6-10 MB attachment died with "Execution memory limit
-   * exceeded" instead of taking the provider's large-file path.
+   * Guards the regression where every 6-10 MB attachment died with "Execution memory limit
+   * exceeded": past this size the base64 copy no longer fits the payload store, so an upload
+   * has to take over wherever one is reachable.
    */
-  it('keeps the inline cap inside the payload store ceiling once base64-encoded', () => {
-    const encodedBytes = Math.ceil(INLINE_ATTACHMENT_THRESHOLD_BYTES / 3) * 4
+  it('starts preferring an upload before base64 outgrows the payload store', () => {
+    const encodedBytes = Math.ceil(LARGE_FILE_PATH_THRESHOLD_BYTES / 3) * 4
     expect(encodedBytes).toBeLessThanOrEqual(LARGE_VALUE_THRESHOLD_BYTES)
+    expect(LARGE_FILE_PATH_THRESHOLD_BYTES).toBeLessThan(INLINE_ATTACHMENT_THRESHOLD_BYTES)
+  })
+
+  /**
+   * A `remote-url` provider only fetches images and PDFs, so it must not take over from base64
+   * early — text documents in the 6-10 MB band inline fine today and would start failing.
+   */
+  it('crosses over to an upload at different sizes for files-api and remote-url', () => {
+    const midBand = { size: LARGE_FILE_PATH_THRESHOLD_BYTES + 1, type: 'text/plain' }
+    expect(shouldUseLargeFilePath(midBand, 'openai')).toBe(true)
+    expect(shouldUseLargeFilePath(midBand, 'anthropic')).toBe(false)
+
+    const aboveInline = { size: INLINE_ATTACHMENT_THRESHOLD_BYTES + 1, type: 'application/pdf' }
+    expect(shouldUseLargeFilePath(aboveInline, 'anthropic')).toBe(true)
   })
 
   it('reports per-provider strategy and ceiling, defaulting others to inline', () => {
@@ -316,7 +331,7 @@ describe('provider large-file capability', () => {
 
   it('routes only oversized files on capable providers to the large-file path', () => {
     const small = { ...imageFile, size: 1024 }
-    const large = { ...imageFile, size: INLINE_ATTACHMENT_THRESHOLD_BYTES + 1 }
+    const large = { ...imageFile, size: LARGE_FILE_PATH_THRESHOLD_BYTES + 1 }
     expect(shouldUseLargeFilePath(small, 'openai')).toBe(false)
     expect(shouldUseLargeFilePath(large, 'openai')).toBe(true)
     expect(shouldUseLargeFilePath(large, 'bedrock')).toBe(false)
@@ -325,7 +340,7 @@ describe('provider large-file capability', () => {
   it('does not expose generated source through a remote-url large-file path', () => {
     const generated = {
       ...pdfFile,
-      size: INLINE_ATTACHMENT_THRESHOLD_BYTES + 1,
+      size: LARGE_FILE_PATH_THRESHOLD_BYTES + 1,
       type: 'text/x-python-pdf',
     }
     expect(shouldUseLargeFilePath(generated, 'openai')).toBe(true)

apps/sim/providers/attachments.ts

@@ -15,6 +15,7 @@ import type { UserFile } from '@/executor/types'
 import {
   getProviderFileAttachment,
   INLINE_ATTACHMENT_MAX_BYTES,
+  LARGE_FILE_PATH_THRESHOLD_BYTES,
   type ProviderFileAttachmentStrategy,
 } from '@/providers/models'
 import type { ProviderId } from '@/providers/types'
@@ -75,13 +76,12 @@ type ProviderFormattedMessage = {
   [key: string]: unknown
 }
 
-/**
- * Files at or below this size are inlined as base64; larger files take the provider's
- * large-file path. Sized to the execution payload store, not to any provider — see
- * {@link INLINE_ATTACHMENT_MAX_BYTES}.
- */
+/** Largest file that can be carried as inline base64 when no upload path is available. */
 export const INLINE_ATTACHMENT_THRESHOLD_BYTES = INLINE_ATTACHMENT_MAX_BYTES
 
+/** Re-exported so callers choosing a hydration cap do not reach into `models.ts` directly. */
+export { LARGE_FILE_PATH_THRESHOLD_BYTES }
+
 export type ProviderFileStrategy = ProviderFileAttachmentStrategy
 
 /** Large-file delivery strategy for a provider, sourced from its `models.ts` definition. */
@@ -90,9 +90,17 @@ export function getProviderFileStrategy(providerId: ProviderId | string): Provid
 }
 
 /**
- * True when an oversized file has a safe provider path. Remote URLs point at the
- * primary storage object, so source-backed documents can only use artifact-aware
- * Files API uploads.
+ * True when a file should be delivered through the provider's large-file path rather than as
+ * inline base64.
+ *
+ * The two strategies cross over at different sizes on purpose. `files-api` carries every type
+ * this provider already accepts, so it takes over as soon as base64 stops being cacheable. A
+ * `remote-url` provider only fetches images and PDFs, so switching early would start rejecting
+ * text documents that inline fine today; it therefore only takes over once inlining is no longer
+ * possible at all.
+ *
+ * Remote URLs point at the primary storage object, so source-backed generated documents can only
+ * use artifact-aware Files API uploads.
  */
 export function shouldUseLargeFilePath(
   file: Pick<UserFile, 'size' | 'type'>,
@@ -101,7 +109,9 @@ export function shouldUseLargeFilePath(
   const strategy = getProviderFileAttachment(providerId).strategy
   if (strategy === 'inline') return false
   if (strategy === 'remote-url' && isGeneratedDocumentSourceType(file.type)) return false
-  return Number.isFinite(file.size) && file.size > INLINE_ATTACHMENT_THRESHOLD_BYTES
+  const threshold =
+    strategy === 'files-api' ? LARGE_FILE_PATH_THRESHOLD_BYTES : INLINE_ATTACHMENT_THRESHOLD_BYTES
+  return Number.isFinite(file.size) && file.size > threshold
 }
 
 const PDF_MIME_TYPE = 'application/pdf'

apps/sim/providers/file-attachments.server.test.ts

@@ -128,6 +128,23 @@ describe('OpenAI large-file attachment lifecycle', () => {
     expect(request.messages?.[0].files?.[0].remoteUrl).toBeUndefined()
   })
 
+  /**
+   * Local and disk-backed deployments have no cloud storage, so the upload path cannot read the
+   * bytes back. These files inline as base64 today and must keep doing so rather than hard-fail.
+   */
+  it('leaves the file for the inline path when cloud storage is unavailable', async () => {
+    mockHasCloudStorage.mockReturnValue(false)
+    const request = makeRequest(CSV_BYTES)
+
+    await attachLargeFileRemoteUrls(request, 'openai')
+    await uploadLargeFilesToProvider(request, 'openai')
+
+    expect(fetch).not.toHaveBeenCalled()
+    const file = request.messages?.[0].files?.[0]
+    expect(file?.remoteUrl).toBeUndefined()
+    expect(file?.providerFileId).toBeUndefined()
+  })
+
   it('rejects a request whose attachments together exceed the combined ceiling', async () => {
     const request = makeRequest(30 * 1024 * 1024)
     const [first] = request.messages?.[0].files ?? []

apps/sim/providers/file-attachments.server.ts

@@ -33,12 +33,21 @@ function* iterateRequestFiles(messages: Message[] | undefined): Generator<UserFi
   }
 }
 
+/**
+ * True when this deployment can actually deliver an oversized attachment through the provider's
+ * large-file path. A provider strategy alone is not enough — every large-file path reads the
+ * bytes back out of cloud object storage, so a deployment without it has to keep inlining.
+ */
+export function canUseProviderLargeFilePath(providerId: ProviderId | string): boolean {
+  return getProviderFileStrategy(providerId) !== 'inline' && StorageService.hasCloudStorage()
+}
+
 /**
  * Resolves every attachment that exceeds the inline threshold on a large-file-capable
  * provider to a short-lived signed URL on `file.remoteUrl`. `remote-url` providers send it
  * to the model directly; for `files-api` providers it marks the file for upload (the bytes
- * are read from storage at upload time). Requires cloud storage — a large file (already past
- * the inline base64 cap) cannot be sent without it, so the request fails with a clear error.
+ * are read from storage at upload time). Every large-file path needs cloud storage to read the
+ * bytes back, so without it the file is left for the inline base64 path instead.
  *
  * Runs for every request in {@link executeProviderRequest} (after the API key resolves), so
  * the server-only handle fields are first cleared on every file for every provider — a forged
@@ -74,11 +83,9 @@ export async function attachLargeFileRemoteUrls(
 
     if (!StorageService.hasCloudStorage()) {
       logger.warn(
-        `[${requestId}] "${file.name}" exceeds the inline limit for "${providerId}" but cloud storage is unavailable`
-      )
-      throw new Error(
-        `File "${file.name}" exceeds the inline attachment limit and requires cloud file storage, which is not configured`
+        `[${requestId}] Sending "${file.name}" inline for "${providerId}": the large-file path needs cloud storage, which is not configured`
       )
+      continue
     }
 
     if (!request.userId) {

apps/sim/providers/models.ts

@@ -143,16 +143,20 @@ export interface ProviderFileAttachment {
   strategy: ProviderFileAttachmentStrategy
 }
 
+/** Inline base64 attachment cap, also the fallback limit for providers without a large-file path. */
+export const INLINE_ATTACHMENT_MAX_BYTES = 10 * 1024 * 1024
+
 /**
- * Inline base64 attachment cap, also the fallback limit for providers without a large-file path.
+ * Size above which an attachment should prefer the provider's Files API over base64, when the
+ * deployment can reach one.
  *
- * Bounded by the execution payload store rather than by any provider. Base64 inflates bytes by
- * 4/3 and a single stored value may not exceed {@link LARGE_VALUE_THRESHOLD_BYTES}, so the
- * largest raw file whose base64 still fits is three quarters of that ceiling. A larger cap does
- * not send a bigger file — it fails the run with "Execution memory limit exceeded" partway
- * through hydration instead of routing the file to the provider's large-file path.
+ * Set by the execution payload store, not by any provider. Base64 inflates bytes by 4/3 and a
+ * single stored value may not exceed {@link LARGE_VALUE_THRESHOLD_BYTES}, so past three quarters
+ * of that ceiling the encoded copy no longer fits the cache. Inlining still succeeds above this
+ * point — the cache write is skipped, not fatal — but it carries a needlessly large encoded
+ * payload, so an upload is preferred wherever one is available.
  */
-export const INLINE_ATTACHMENT_MAX_BYTES = Math.floor(LARGE_VALUE_THRESHOLD_BYTES / 4) * 3
+export const LARGE_FILE_PATH_THRESHOLD_BYTES = Math.floor(LARGE_VALUE_THRESHOLD_BYTES / 4) * 3
 
 const DEFAULT_FILE_ATTACHMENT: ProviderFileAttachment = {
   maxBytes: INLINE_ATTACHMENT_MAX_BYTES,
@@ -2443,12 +2447,14 @@ export const PROVIDER_DEFINITIONS: Record<string, ProviderDefinition> = {
   },
   groq: {
     id: 'groq',
-    /** "Maximum allowed size for a request containing an image URL as input is 20MB." */
-    fileAttachment: {
-      maxBytes: 20_000_000,
-      perRequestMaxBytes: 20_000_000,
-      strategy: 'remote-url',
-    },
+    /**
+     * Left at the pre-existing ceiling: Groq's published "20MB" governs a request carrying an
+     * image URL, and on this path the request body holds only the URL, so it cannot bind on the
+     * files this guards. Groq documents no ceiling on the image it fetches, so both tightening
+     * the per-file cap and summing raw bytes against the request cap would reject uploads that
+     * work today on no documented basis.
+     */
+    fileAttachment: { maxBytes: 20 * 1024 * 1024, strategy: 'remote-url' },
     name: 'Groq',
     description: "Groq's LLM models with high-performance inference",
     defaultModel: 'groq/llama-3.3-70b-versatile',