The load-bearing line is `ScriptApp.getOAuthToken()`. In this architecture the script never fetches the artifact. It injects its own OAuth access token into the sandbox, and ggsrun, a Go CLI, runs inside the container and performs the Drive upload itself [9]. The bytes go container to Drive over Google Cloud's internal backbone, which is where the reported rate above 2 MB/s comes from [10]. Apps Script allocates no blob and decodes nothing [8], so the platform limits are not raised, they are just off the path [10].
Work out what the old path could carry. UrlFetchApp caps a response at 50 MB [4]. Base64 inflates binary by roughly a third [7], so 50 divided by 1.33 leaves about 37.5 MB of real payload as the theoretical ceiling [13]. You do not reach it, because the code execution environment's stdout buffer truncates multi-megabyte Base64 mid-stream first [5]. Whatever did come back would then sit in conversation history against a 200,000 tokens-per-minute quota [6], where accumulated output earns a 429 [7]. Base64 is an expensive way to describe bytes to a model that has no reason to read them.
Treat 2 MB/s as a claim about the author's workload, not a specification. That 37.5 MB ceiling, the largest thing the Base64 path could in theory have returned, moves in about 19 seconds at that rate [14]. The number only transfers when the artifact is generated inside the sandbox, the destination is Drive, and the leg you care about is the outbound one. The dev.to write-up also recommends pulling large inbound datasets straight into the sandbox instead of embedding them in prompts [11], and that is sound, but the inbound leg starts wherever your data lives and the backbone figure says nothing about it. The piece credits Martin Hawksey's AppsScriptPulse article on Managed Agents and the Google Workspace CLI as its starting point [12].
The cost of adoption is the token. `ScriptApp.getOAuthToken()` hands out the script's own credential, and this design puts it inside a remote container provisioned by a managed service [9][1]. If the script already carries broad Drive scope, that scope is now live in a shell session. The sandbox is described as persistent [15], which is what makes `apt` and `pip` worth using at all [2], and also what means a session is a thing with a lifetime rather than a function call.
In my context I would take that trade for work the runtime structurally cannot do: work like headless rendering or native binaries for transcoding and signal processing, the kind of job that needs a compiler [3]. I would not take it to avoid a few seconds of Base64 decoding. The API is still v1beta [1], and 4 vCPU with 16 GB RAM is a fixed shape [2], so this is an escape hatch for jobs that fit inside it.
