{ "schema_version": "pct-article-edition-1.0", "publication_date": "2026-11-07", "export_scope": "articles_only", "source_edition_id": null, "rights": "PCT reserves rights in original editorial content; third-party rights retained. No general source-data reuse license.", "articles": [ { "id": "pct-2026-11-07-company-de6cc3f6ff", "content_type": "article", "desk": "company", "title": "Modal turns unpredictable AI jobs into a metered cloud business", "publication_date": "2026-11-07", "observation_date": "2026-11-07", "editorial_voice": "AI-assisted Company Desk", "body": "# Modal turns unpredictable AI jobs into a metered cloud business\n\n*Company desk | Peterson Compute Trading | November 7, 2026*\n*AI-assisted public-source analysis. No interviews or independently run performance tests. Dollar amounts are US dollars.*\n\nModal's customer buys the ability to start work quickly, expand it briefly and stop paying when resources are released. That proposition suits a model evaluation that arrives without warning or a coding agent that alternates between waiting and running tests. It becomes harder to justify when the same hardware stays busy all day. Understanding the company requires examining both patterns, rather than treating serverless compute as automatically inexpensive.\n\nThe scale is substantial. On October 14, Modal announced a $750 million Series D at a $15.75 billion post-money valuation and said it had exceeded $1 billion in annualized run rate. Those are company-reported figures. Run rate extrapolates current activity; it is not a statement that Modal has already booked a billion-dollar financial year. [Modal's announcement](https://modal.com/blog/1-billion-annualized-run-rate-series-d)\n\n## A customer needs a completed evaluation\n\nA November 6 Modal case study describes Snorkel running millions of agent simulations monthly, with peaks of tens of thousands of sandbox creations per hour. A sandbox is an isolated execution environment. These tests require different environments: an infrastructure agent may need a full Linux kernel, while an ML agent needs a GPU. Snorkel also uses shared and dedicated inference endpoints to evaluate standard and customized models. The commercial deadline can be a day after a new model appears. [Snorkel case study](https://modal.com/blog/how-snorkel-runs-realistic-agent-simulations-with-modal)\n\nThe same account reports roughly 20% savings on Snorkel's total Sandbox bill after adopting resource bursting, with approximately 10–15% of its sandboxes using that feature. The baseline bill, observation period and detailed workload mix are not disclosed. This is an attributed customer result in supplier material, not a general savings promise. [Snorkel case study](https://modal.com/blog/how-snorkel-runs-realistic-agent-simulations-with-modal)\n\nFor a buyer, the useful unit is a valid evaluation delivered before its deadline. Cheap executions that fail because their environment lacks memory contaminate the comparison. A trial should separate model failures from infrastructure failures and record reruns, queueing and elapsed time alongside the invoice.\n\n## The workflow can outlast the first GPU order\n\nRamp supplies customer-authored evidence of a different use. Its January 12 engineering article describes Inspect sessions running in Modal sandboxes with a full development environment, including Postgres and Temporal. Ramp builds repository images every 30 minutes, installs dependencies ahead of time, snapshots the prepared environment and starts new sessions from that state. It snapshots completed work again so a later follow-up can resume it. [Ramp's engineering account](https://builders.ramp.com/post/why-we-built-our-background-agent)\n\nThis explains how an infrastructure supplier can become embedded in a customer's daily operations. The recurring purchase includes environment preparation, state recovery and concurrent execution. Replacing that supplier means validating the whole workflow again. That is a plausible source of retention, not evidence that customers cannot leave or that Modal earns a particular margin.\n\nFounded by Erik Bernhardsson and Akshat Bubna, Modal combines its software with externally supplied capacity. Its October announcement describes a pool spanning more than 20 clouds and its own scheduler, filesystem, networking and container runtime. Lead investor Accel separately says Sandboxes accounted for $300 million of revenue run rate, about 30% of the stated billion-dollar total. Accel corroborates the financing but is an interested investor, not an independent auditor. [Company account](https://modal.com/blog/1-billion-annualized-run-rate-series-d), [Accel's October 14 statement](https://www.accel.com/news/our-investment-in-modal)\n\n## Price the whole running container\n\nThe public tariff observed November 7 lists an H100 SXM5 at $0.001097 per second, or $3.9492 per hour. Base CPU is $0.0000131 per physical core-second and memory is $0.00000222 per GiB-second. CPU and RAM are separate meters. CPU-only Sandboxes use non-preemptible CPU and memory pricing, listed at three times the base rates. The example below is a GPU Function, not a Sandbox quote. [Modal pricing](https://modal.com/pricing)\n\nConsider an illustrative GPU Function billed for one H100, four physical CPU cores and 64 GiB of RAM throughout an hour. The calculation is $3.9492 for the GPU, $0.18864 for CPU and $0.511488 for memory: **$4.649328 per hour**, before storage, network, plan charges, credits, discounts or region premiums. This is PCT arithmetic, not a customer invoice or a benchmark. Actual charges depend on resources consumed and requested.\n\nNow suppose a genuinely comparable reserved configuration costs $3 per hour continuously. That $3 is an illustrative quote, not an observed competitor offer. Ignoring other differences, the reservation costs $72 per day. Modal reaches that amount after 15.49 billed hours, about 64.5% of the day. Below that utilization, release of capacity can outweigh the higher running rate; above it, the assumed reservation wins on these compute charges.\n\nThe reservation comparison is valid only after matching hardware, throughput, memory, interruption rights and support. Add the customer's operating labor and required headroom to both cases. A less expensive configuration that takes longer to produce the same accepted result can erase the apparent saving.\n\n## Idle time has several meanings\n\nModal's cold-start documentation distinguishes container boot from application readiness. Imports and model initialization can still take time after the container starts. Keeping containers warm reduces waiting but retains billable resources; the default maximum idle window is 60 seconds, and actual scale-down can occur sooner. [Cold-start documentation](https://modal.com/docs/guide/cold-start)\n\nAssume an isolated request occupies an H100 for 240 seconds of useful work, 30 seconds of loading and the full 60-second idle window. The GPU meter records 330 seconds, costing $0.36201 rather than the useful-work-only $0.26328. That is 37.5% additional GPU time. This deliberately simple example assumes no overlapping requests and no early scale-down. Reusing a warm container changes the result.\n\nThe buyer therefore needs two measurements: productive seconds and billed seconds. Test traffic at its real arrival intervals. A continuous load test will hide the cost of sporadic requests; a single cold request will overstate overhead for a busy endpoint. A minimum warm pool may be sensible for latency, but it should appear explicitly in the budget.\n\n## Bursting transfers a sizing decision\n\nModal bills CPU and memory at the greater of requested capacity and actual usage. Requesting a large allocation establishes a floor, even while the process is doing little. Bursting above the request depends on spare host capacity. The documentation recommends monitoring CPU pressure and memory-related evictions, then increasing reservations where necessary. [Resource billing](https://modal.com/docs/guide/resources), [Sandbox sizing](https://modal.com/docs/guide/sandbox-resources)\n\nSuppose, purely illustratively, a CPU sandbox needs eight GiB for one minute and two GiB for nine minutes. An eight-GiB reservation bills 80 GiB-minutes. A two-GiB reservation with successful bursting bills 26: two times nine, plus eight times one. The memory component falls 67.5%. CPU, inference, storage and other costs do not disappear, and this is not a reproduction of Snorkel's 20% result.\n\nThe operational catch matters. Lower reservations can expose a workload to contention or eviction when capacity is tight. Set a resource ceiling to contain a runaway agent, but choose it using actual workload traces. A limit that repeatedly kills valid work simply moves spending into retries. Evaluate cost per successful session and high-percentile completion time together.\n\n## Four conditions belong in procurement\n\n**Location.** Pinning a broad container region carries a 1.15-times usage multiplier; a narrow region carries 1.75 times. In the illustrative H100 configuration, that changes $4.65 per running hour to approximately $5.35 or $8.14. A buyer with a fixed jurisdiction requirement should use the regional price from the beginning. [Region selection](https://modal.com/docs/guide/region-selection)\n\n**Residency.** Compute placement does not settle every data question. Modal's documentation says application logs are stored in the United States. Function payloads above two MiB and asynchronous payloads have additional US-storage implications; explicit Sandbox snapshots are also stored there. Shared Endpoints do not offer selectable regions. Map the complete data path before approving a regulated workload. [Data residency](https://modal.com/docs/guide/data-residency)\n\n**Interruption.** GPU Functions and GPU Sandboxes are preemptible. Paying the CPU non-preemptible premium does not buy non-preemptible GPU Functions. Current documentation also limits GPU Sandboxes to the gVisor runtime, so do not assume the full-VM and GPU configurations are interchangeable. Test checkpoint recovery and safely repeatable operations before relying on a long job. [Preemption rules](https://modal.com/docs/guide/preemption), [GPU Sandbox restrictions](https://modal.com/docs/guide/sandbox-resources)\n\n**Application security.** On July 29, Modal described a customer endpoint that accepted unauthenticated public code execution. Modal said its platform isolation was not breached and other customers were unaffected. The practical lesson is to review the application boundary as well as the sandbox boundary. Current docs allow outbound public-IP access by default, with controls to restrict it. [Incident statement](https://modal.com/blog/a-note-on-the-hugging-face-agent-incident), [Network controls](https://modal.com/docs/guide/sandbox-networking)\n\n## The supplier has its own utilization problem\n\nPooling many customers can improve hardware use because their peaks do not always coincide. That is the economic logic behind Modal's offer. Its success depends on obtaining suitable capacity, packing jobs efficiently and charging enough to cover software, operations and unused commitments. The reviewed public sources do not establish its gross margin, cash consumption, supplier concentration or contractual capacity obligations.\n\nAn October 19 engineering post shows where Modal is looking for further efficiency. Its early NVIDIA Vera test reported up to twice the task throughput of an equivalent x86 GNR machine under load. The benchmark used 50 Terminal-Bench tasks with network calls removed and containers prewarmed. That is a supplier-run CPU experiment, not proof that a complete customer's agent becomes twice as fast. Modal described supporting Arm as requiring infrastructure and image-system changes. [Vera test](https://modal.com/blog/nvidia-vera-sandboxes)\n\nThe competitive question is whether better scheduling and faster environments keep saving customers enough to justify the service layer. When workloads become predictable, customers can renegotiate, reserve capacity or operate more of the stack themselves. When model changes and agent behavior keep workloads irregular, flexible execution retains a clearer purpose.\n\n## A purchase should start with a measured pilot\n\nPCT would ask a prospective customer to replay a representative week, including quiet hours, burst traffic and failures. Record completed valid jobs, total compute and data charges, setup labor, billed-to-productive time, queue delays and recovery time. Run one deliberate restart and one region-constrained test. Confirm account quotas and capacity terms rather than interpreting an autoscaling feature as an availability guarantee.\n\nModal is credible as a candidate for teams whose work changes shape faster than their infrastructure plans. Its reported growth and concrete customer workflows warrant attention. The purchasing decision still belongs in the workload trace: what finished, how long it took, what was retained between requests and what the complete run cost. That evidence is more durable than either a funding valuation or an attractive GPU-hour headline.\n", "sources": [ { "id": "s1", "title": "How Snorkel runs realistic agent simulations with Modal", "url": "https://modal.com/blog/how-snorkel-runs-realistic-agent-simulations-with-modal", "publication_date": "2026-11-06", "observed_on": "2026-11-07", "source_type": "vendor_customer_case", "primary": true, "access": "Full primary-source HTML opened.", "caveat": "Customer statements embedded in supplier case study; baseline bill and measurement period unavailable." }, { "id": "s2", "title": "Why We Built Our Own Background Agent", "url": "https://builders.ramp.com/post/why-we-built-our-background-agent", "publication_date": "2026-01-12", "observed_on": "2026-11-07", "source_type": "customer_engineering_account", "primary": true, "access": "Primary-source article body and date retrieved via targeted web search; direct open returned only page shell.", "caveat": "Customer independently describes its Modal workflow. Historical description, not a current contract or independently tested performance result." }, { "id": "s3", "title": "Modal crosses $1B in Annualized Run Rate and raises $750M Series D", "url": "https://modal.com/blog/1-billion-annualized-run-rate-series-d", "publication_date": "2026-10-14", "observed_on": "2026-11-07", "source_type": "company_announcement", "primary": true, "access": "Full primary-source HTML opened.", "caveat": "Company-reported run rate, growth and financing; run rate is not booked annual revenue or audited accounts." }, { "id": "s4", "title": "Our Investment in Modal", "url": "https://www.accel.com/news/our-investment-in-modal", "publication_date": "2026-10-14", "observed_on": "2026-11-07", "source_type": "investor_primary_statement", "primary": true, "access": "Full primary-source HTML opened.", "caveat": "Lead investor confirms investment and reports operating metrics; interested source rather than independent auditor." }, { "id": "s5", "title": "Pricing Pay per second for GPUs and CPUs", "url": "https://modal.com/pricing", "publication_date": null, "observed_on": "2026-11-07", "source_type": "live_public_tariff", "primary": true, "access": "Full pricing HTML opened.", "caveat": "Undated dynamic tariff observed November 7; no authenticated quote, stock check or enterprise discount obtained." }, { "id": "s6", "title": "Cold start performance", "url": "https://modal.com/docs/guide/cold-start", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Full relevant documentation opened.", "caveat": "Current public rules; application-specific loading and billing behavior was not independently tested." }, { "id": "s7", "title": "Configuring CPU memory and disk", "url": "https://modal.com/docs/guide/resources", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Full relevant documentation opened.", "caveat": "Requests and actual usage determine billed CPU and memory; physical cores, not vCPUs." }, { "id": "s8", "title": "Sandbox resources and pricing", "url": "https://modal.com/docs/guide/sandbox-resources", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Full relevant documentation opened.", "caveat": "Burst capacity is conditional; GPU runtime and preemption constraints apply." }, { "id": "s9", "title": "Region selection", "url": "https://modal.com/docs/guide/region-selection", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Full relevant documentation opened.", "caveat": "Published region premiums; capacity and routing need separate assessment." }, { "id": "s10", "title": "Data residency on Modal", "url": "https://modal.com/docs/guide/data-residency", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Relevant data-location table and product distinctions opened.", "caveat": "Region pinning does not cover every log, payload or snapshot; no legal compliance certification inferred." }, { "id": "s11", "title": "Preemption", "url": "https://modal.com/docs/guide/preemption", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Full documentation opened.", "caveat": "GPU workloads cannot use CPU-only nonpreemptible Function setting." }, { "id": "s12", "title": "A note on the Hugging Face agent incident", "url": "https://modal.com/blog/a-note-on-the-hugging-face-agent-incident", "publication_date": "2026-07-29", "observed_on": "2026-11-07", "source_type": "vendor_incident_statement", "primary": true, "access": "Full primary-source HTML opened.", "caveat": "Scope and isolation conclusions attributed to Modal; not a forensic verification by PCT." }, { "id": "s13", "title": "Networking and security", "url": "https://modal.com/docs/guide/sandbox-networking", "publication_date": null, "observed_on": "2026-11-07", "source_type": "product_documentation", "primary": true, "access": "Relevant default networking and restrictions opened.", "caveat": "Outbound controls have documented limitations; no blanket security guarantee inferred." }, { "id": "s14", "title": "NVIDIA Vera CPUs double throughput for Modal Sandboxes", "url": "https://modal.com/blog/nvidia-vera-sandboxes", "publication_date": "2026-10-19", "observed_on": "2026-11-07", "source_type": "vendor_engineering_benchmark", "primary": true, "access": "Full benchmark methodology and conclusions opened.", "caveat": "Early supplier-run test removes network calls and prewarms containers; not end-to-end agent speed or confirmed fleet-wide rollout." } ], "facts": [ { "source": "s1", "type": "attributed_customer_claim", "claim": "Millions of simulations monthly; peaks tens of thousands of sandbox creations hourly; around 20% total Sandbox bill saving; 10–15% of sandboxes using bursting.", "limits": "Supplier-hosted case; measurement window, baseline bill and mix not disclosed." }, { "source": "s2", "type": "customer_workflow", "claim": "Ramp Inspect uses Modal environments, repository images built every 30 minutes and snapshots to start and resume sessions.", "limits": "January 12 description, not a claim every detail remains unchanged in November." }, { "source": "s3", "type": "reported_financing_and_metrics", "claim": "$750M Series D at $15.75B post-money valuation; over $1B annualized run rate; pool spanning more than 20 clouds.", "limits": "Company-reported; no audited financials or underlying supplier commitments reviewed." }, { "source": "s4", "type": "investor_report", "claim": "Accel led Series D; Sandbox run rate $300M.", "limits": "Interested investor; 30% share is PCT calculation of 300/1000, approximate because total exceeds $1B." }, { "source": "s5", "type": "live_price", "claim": "H100 SXM5 $0.001097/second; base CPU $0.0000131/physical-core-second; memory $0.00000222/GiB-second.", "limits": "Observed November 7; Function base pricing, not CPU Sandbox premium; discounts, credits, other charges excluded from examples." }, { "source": "s6", "type": "billing_and_lifecycle", "claim": "Application readiness includes initialization; default maximum idle window 60 seconds; retained GPU or memory resources can be billed.", "limits": "Autoscaler may terminate earlier; worked example assumes full 60-second window." }, { "source": "s7", "type": "billing_rule", "claim": "CPU and memory bill at max(requested, actual).", "limits": "Actual use can exceed request; worked resource envelope assumed constant." }, { "source": "s8", "type": "capacity_constraint", "claim": "Bursting depends on spare host capacity; GPU Sandboxes gVisor only and preemptible.", "limits": "No guarantee of unlimited burstability or interchangeable GPU/VM runtime." }, { "source": "s9", "type": "region_price_rule", "claim": "Broad-region multiplier 1.15x and narrow-region 1.75x.", "limits": "Applied to usage meters; account-specific concessions not checked." }, { "source": "s10", "type": "residency_constraint", "claim": "Application logs and explicit Sandbox snapshots stored US; Function large and async payloads have US storage; Shared Endpoint regions not selectable.", "limits": "Product-specific paths matter; not legal advice or a full compliance assessment." }, { "source": "s11", "type": "interruption_constraint", "claim": "GPU Functions and GPU Sandboxes are preemptible; nonpreemptible Function parameter not supported for GPUs.", "limits": "No workload interruption frequency measured." }, { "source": "s12", "type": "attributed_incident_statement", "claim": "Modal says July incident involved unauthenticated public code execution in a customer app and did not compromise platform isolation or other workloads.", "limits": "Vendor account, explicitly attributed." }, { "source": "s13", "type": "security_default", "claim": "Sandboxes default to outbound connections to public IPs; restrictions configurable.", "limits": "Controls must be configured; DNS and sidecar exceptions in full docs not exhaustively summarized." }, { "source": "s14", "type": "attributed_benchmark", "claim": "Early Vera test up to 2x throughput versus equivalent x86 GNR; 50 Terminal-Bench tasks; network removed; prewarmed containers.", "limits": "Vendor benchmark; not an end-to-end workload result or fleet rollout confirmation." } ], "inferences": [ "Workflow preparation and recovery can support retention beyond initial GPU access; no measured switching cost or margin established.", "Pooling demand can improve supplier utilization when peaks differ; commercial success depends on procurement, scheduling and cost coverage.", "Serverless value is strongest when releasing capacity materially reduces paid time, after matching delivered work and operating requirements.", "Steadier utilization gives customers greater reason to renegotiate or compare reserved/self-managed capacity.", "Customer should prioritize cost per valid evaluation or successful agent session, including failed work and time requirements." ], "unknowns": [ "Audited revenue, gross margin, cash consumption and supplier capacity commitments not established by reviewed public sources.", "Snorkel savings methodology, baseline spend, period and workload composition not disclosed.", "No customer account quotas, authenticated capacity, performance benchmark or enterprise quote checked.", "No independent reproduction of Modal Vera result or confirmation of fleet-wide rollout.", "No customer-by-customer revenue concentration, retention or contractual switching data reviewed.", "Current public documentation is undated and may change; observed date is November 7, 2026." ], "correction_history": [], "license_status": "Original PCT editorial text; public license not selected. Source rights remain separate.", "public_url": null, "desk_extensions": { "title": "Modal turns unpredictable AI jobs into a metered cloud business", "company": "Modal", "date": "2026-11-07", "word_count": 1724, "estimated_read_minutes": 7.7, "byline": "PCT Company Desk | AI-assisted public-source analysis", "calculations": [ { "id": "c1", "label": "Illustrative H100 Function hourly resource bill", "inputs": { "h100_per_second": 0.001097, "cpu_per_core_second": 1.31e-05, "physical_cores": 4, "memory_per_gib_second": 2.22e-06, "memory_gib": 64, "seconds": 3600 }, "formula": "3600*(0.001097+4*0.0000131+64*0.00000222)", "result_usd": 4.649328, "source_ids": [ "s5", "s7" ], "assumptions": "All resources billed continuously at stated level. No region multiplier or nonpreemptible CPU premium. Other fees, credits, discounts excluded." }, { "id": "c2", "label": "Illustrative reserved-capacity break-even", "formula": "3*24 / 4.649328", "result_hours": 15.486108960262646, "result_day_fraction": 0.6452545400109435, "source_ids": [ "s5" ], "assumptions": "$3/hr fully comparable alternative is hypothetical, NOT observed competitor price. Equal throughput, envelope, and excluded operating costs." }, { "id": "c3", "label": "Isolated request overhead", "formula": "(240+30+60)*0.001097 versus 240*0.001097", "result_billed_usd": 0.36201000000000005, "result_productive_only_usd": 0.26328, "overhead_fraction": 0.375, "source_ids": [ "s5", "s6" ], "assumptions": "Hypothetical job, 30s load, full 60-second idle window, no overlapping work and no early shutdown; GPU only." }, { "id": "c4", "label": "Memory bursting hypothetical", "formula": "8*10 versus 2*9+8*1 GiB-minutes", "reserved_gib_minutes": 80, "burst_gib_minutes": 26, "memory_reduction_fraction": 0.675, "source_ids": [ "s7", "s8" ], "assumptions": "Spare capacity available. Not actual Snorkel workload. Only memory component compared, no total-bill savings claim." }, { "id": "c5", "label": "Regional resource rates", "formula": "4.649328*1.15 and 4.649328*1.75", "broad_usd_per_hour": 5.346727199999999, "narrow_usd_per_hour": 8.136324, "source_ids": [ "s5", "s9" ], "assumptions": "Illustrative Function envelope; no negotiated discount." } ], "dedup_note": "New company distinct from SF Compute, CoreWeave, Crusoe and Nebius. Focus is application execution, CPU/GPU resource sizing, billed-time economics and operational constraints, not campus financing.", "scope": "Research and local canonical draft only. No site changes, outreach, account operations or purchases.", "editorial_note": "Primary sources collected independently for this assignment. Ramp provides customer-authored evidence; Accel is interested investor corroboration. Supplier metrics are attributed and calculations identified as illustrative.", "source_cutoff": "2026-11-07" }, "public_projection": { "version": "1.0.0", "date": "2026-11-10", "changes": [ "Internal workspace artifact paths omitted where present. Historical license/status fields retain original provenance; current public reuse policy is stated separately." ], "rights": "PCT reserves rights in original editorial content; third-party rights retained. No general source-data reuse license." } }, { "id": "pct-2026-11-07-deals-d967c0df2a", "content_type": "article", "desk": "deals", "title": "IREN’s new compute contract puts the chip bill on the buyer’s clock", "publication_date": "2026-11-07", "observation_date": "2026-11-07", "editorial_voice": "AI-assisted Deals Desk", "body": "IREN has disclosed a five-year compute contract with an unusually large customer funding contribution: prepayments covering 90% of estimated GPU capital expenditure. The November 5 announcement puts estimated annual revenue at about $22 million per megawatt of IT load. The agreement was signed after September 30; the exact date was not disclosed. [IREN results announcement](https://www.sec.gov/Archives/edgar/data/1878848/000187884826000065/irenreportsq1-fy27result.htm)\n\nPCT first noted the signed contracts in yesterday’s inventory. Today’s question is what their structure means for a buyer and an operator. Our reading is that an advance this large makes the customer an important source of deployment funding. It can reduce the operator’s initial capital requirement, while making the buyer’s protection against late or inadequate delivery more consequential.\n\n## Establish the transaction before valuing it\n\nThe evidence supports a company-reported signed service agreement. It does not establish the customer’s identity, allocated megawatts, GPU configuration, location, total contract value or acceptance date. Those omissions prevent a useful comparison with an hourly GPU rental and a calculation of the contract’s aggregate value.\n\nThe release’s footnotes define prepayments as amounts contractually payable before service delivery. They do not reconcile the amount due under this particular agreement with cash received. PCT therefore records the payment commitment separately from verified collection. [Results announcement, note 7](https://www.sec.gov/Archives/edgar/data/1878848/000187884826000065/irenreportsq1-fy27result.htm)\n\nThis is a useful example of why a deal record needs several fields. Signature, payment, equipment delivery and customer acceptance can occur on different dates. An operator can have a valuable contracted sale while still needing to collect funds, complete the installation and demonstrate the promised service. A single label such as “closed” would obscure those steps here.\n\n## Put the denominator back into the prepayment\n\nIREN’s accompanying presentation offers a concrete illustration. Per IT-megawatt, its model assumes $40 million of GPU spending and $20 million of data-center spending. A 90% GPU prepayment contributes $36 million. Those are illustrative inputs, not the disclosed cost of the new contract; the company expressly says other inputs can differ from the signed deal. [Presentation, pages 9 and 24](https://iren.gcs-web.com/static-files/f80da6ea-9d04-489c-ba7f-52f4b38e6680)\n\nThe arithmetic leaves $24 million of the modeled $60 million initial investment to fund. In that example, 90% of GPU capex covers 60% of combined GPU and building capex. This calculation excludes any costs outside the model. It is a practical correction to the temptation to treat the headline percentage as the customer funding almost the entire project.\n\nFor an operator comparing proposals, the useful spreadsheet should show both the equipment-only funding gap and the complete deployment funding gap. The first helps evaluate hardware financing. The second shows whether a project can reach operation without another capital raise. A generous chip advance can coexist with a substantial construction bill.\n\n## Earlier cash changes the relationship\n\nIREN’s illustration amortizes the prepayment over the contract term and warns that actual results may be less favorable. It assumes timely construction and acceptance, and excludes delay credits, service credits and terminations. It is not a forecast for this customer. [Presentation assumptions, page 24](https://iren.gcs-web.com/static-files/f80da6ea-9d04-489c-ba7f-52f4b38e6680)\n\nThe commercial interpretation is straightforward: receiving part of the consideration early can reduce the amount the supplier must finance before service starts. It does not create an extra pool of revenue that should automatically be added to the later contractual charges. A buyer comparing offers needs the complete payment schedule to determine how the advance is credited and whether it changes the all-in price.\n\nThe timing also changes the buyer’s exposure. Paying before use means cash is committed before the required output has been demonstrated. The value received in return might include delivery priority, a lower price or stronger remedies, but none of those concessions is established for this agreement. Their presence and enforceability would need to be checked in the contract.\n\nA smaller headline advance could be commercially preferable if it follows verified milestones and gives the buyer better recovery rights. Conversely, a larger advance could make sense where the supplier, schedule and technical specification are dependable. The percentage alone cannot decide between them.\n\n## Delivery remains the operating test\n\nIREN’s November 5 quarterly filing says revenue generally begins at customer acceptance, after construction, energization, hardware installation, integration and testing. It also reports that Horizon 1 was delivered to and accepted by Microsoft in August and remains in service. A Microsoft-requested network change affects other Horizon delivery scheduling. Those are separate deployments, not delivery evidence for the unnamed new contract. [IREN Form 10-Q, customer delivery and operating factors](https://iren.gcs-web.com/node/12706/html)\n\nThe contrast is useful. The Microsoft disclosure names both a customer and a completed acceptance milestone. The new agreement’s public description supplies financing and pricing terms but does not supply equivalent operational evidence. A diligent tracker should preserve that difference without treating the absence of disclosure as evidence of failure.\n\nFor a customer planning a training run or inference launch, the contractual acceptance test matters more than a ribbon-cutting date. The specification should cover the usable cluster: networking, storage, software configuration and workload performance as well as accelerator count. A building becoming available and a production job meeting its requirements are different operational milestones.\n\n## The buyer’s next negotiation\n\nA procurement team considering a similarly funded deployment should start with three linked schedules. First, specify when each advance becomes due and which observable milestones support payment. Second, define the capacity and performance required for acceptance, including who runs the tests and how disputes are resolved. Third, show how advances reduce subsequent invoices and what happens to any unused balance on termination.\n\nThen test a delay scenario. If hardware arrives but networking fails acceptance, who continues paying construction interest and operating expenses? Can the buyer recover its advance, obtain replacement capacity or defer later payments? These are diligence questions prompted by the structure, not claims about IREN’s undisclosed remedies.\n\nPCT’s assessment is that the agreement provides a meaningful example of customers helping finance the capacity they want to consume. The next evidence worth watching is the disclosed deployment size, cash collection and acceptance milestone. Until those appear, the strongest supported conclusion is a signed contract with substantial advance-funding terms, rather than a measured return on a completed deployment.", "sources": [ { "id": "s1", "title": "IREN Reports Q1 FY27 Results, furnished as Exhibit 99.1 to November 5 Form 8-K", "publisher": "IREN / U.S. Securities and Exchange Commission", "url": "https://www.sec.gov/Archives/edgar/data/1878848/000187884826000065/irenreportsq1-fy27result.htm", "publication_date": "2026-11-05", "accessed_date": "2026-11-07", "source_type": "Primary company announcement in SEC exhibit", "locators": [ "Q1 FY27 Business Highlights: Demand and contracting", "Assumptions and Notes 7" ], "evidence_scope": "Contract signing window, term, annual revenue density, prepayment fraction and definition; no full contract or contract-specific collection reconciliation" }, { "id": "s2", "title": "IREN Q1 FY2027 Earnings Presentation", "publisher": "IREN", "url": "https://iren.gcs-web.com/static-files/f80da6ea-9d04-489c-ba7f-52f4b38e6680", "publication_date": "2026-11-05", "accessed_date": "2026-11-07", "source_type": "Primary investor presentation", "locators": [ "Page 9, Illustrative contract economics", "Page 24, notes for page 9" ], "evidence_scope": "Company's explicitly illustrative funding model and assumptions; not actual signed-deal economics" }, { "id": "s3", "title": "IREN Form 10-Q for the quarter ended September 30, 2026", "publisher": "IREN; company-hosted filing copy", "url": "https://iren.gcs-web.com/node/12706/html", "publication_date": "2026-11-05", "accessed_date": "2026-11-07", "source_type": "Primary SEC quarterly filing", "locators": [ "Management discussion: Recent Developments, Customer Delivery", "Key Factors Affecting Performance: Delivery, commissioning, testing and customer acceptance of AI Cloud capacity" ], "evidence_scope": "General revenue acceptance gate and separate Microsoft Horizon delivery evidence", "filing_index_url": "https://www.sec.gov/Archives/edgar/data/1878848/000187884826000066/0001878848-26-000066-index.htm" } ], "facts": [ { "id": "c1", "body_location": "Opening paragraph and transaction record", "classification": "Company-reported executed commercial agreement", "source_ids": [ "s1" ], "qualification": "Disclosure date is not the signing date. Revenue metric is estimated annual revenue per IT-MW, not an executed GPU-hour price." }, { "id": "c2", "body_location": "Establish the transaction before valuing it", "classification": "Primary-source definition and disclosure limitation", "source_ids": [ "s1" ], "qualification": "Contractually payable prepayments do not independently establish collection." }, { "id": "c3", "body_location": "Put the denominator back into the prepayment", "classification": "Company illustration plus independently checked arithmetic", "source_ids": [ "s2" ], "qualification": "Example is not the actual agreement's unit economics or capex disclosure." }, { "id": "c4", "body_location": "Earlier cash changes the relationship", "classification": "Illustrative model assumptions", "source_ids": [ "s2" ], "qualification": "Actual payment crediting and remedies remain undisclosed." }, { "id": "c5", "body_location": "Delivery remains the operating test", "classification": "Quarterly filing disclosure", "source_ids": [ "s3" ], "qualification": "Microsoft Horizon milestone is separate from the new unnamed agreement." } ], "inferences": [ { "id": "i1", "statement": "Advance funding can reduce the operator's initial funding need and increase the importance of buyer delivery protections.", "basis_claims": [ "c1", "c2" ], "confidence": "High as a general commercial interpretation; actual risk allocation is undisclosed." }, { "id": "i2", "statement": "The illustrative combined initial funding gap is $24 million per IT-MW; the advance covers 60% of combined modeled capex.", "calculation": "40 + 20 - (0.90 × 40) = 24; 36 / 60 = 60%, all dollar inputs in millions.", "basis_claims": [ "c3" ], "confidence": "Exact arithmetic on illustrative inputs, not a forecast." }, { "id": "i3", "statement": "Price comparisons require full payment, acceptance and refund terms rather than the prepayment percentage alone.", "basis_claims": [ "c1", "c4", "c5" ], "confidence": "Commercial diligence conclusion, not a claim about unpublished contract terms." } ], "unknowns": [ "Specific customer, exact signing date and whether this is the separately mentioned frontier-lab expansion", "Contract capacity, total value, hardware configuration, deployment location and delivery schedule", "Amount and date of cash actually received under this agreement", "Refundability, escrow or security arrangements, termination rights and creditor priority", "Actual cost, financing terms, margins, cash payback and residual GPU value", "Acceptance status, billable service commencement and recognized revenue" ], "correction_history": [], "license_status": "Original PCT editorial text; public license not selected. Source rights remain separate.", "public_url": null, "desk_extensions": { "desk": "Deals Desk", "publication": "Peterson Compute Trading", "edition_date": "2026-11-07", "title": "IREN’s new compute contract puts the chip bill on the buyer’s clock", "standfirst": "A five-year agreement disclosed November 5 includes prepayments covering 90% of estimated GPU capex. The commercial question is how early funding changes the obligations on both sides.", "disclosure": "AI-assisted analysis of public primary sources. No interviews, private contract access or independent verification of payment receipts.", "article_type": "Independent reported analysis", "target_reading_minutes": "4–6", "transaction_record": { "seller": "IREN", "buyer": null, "buyer_status": "Not identified for this specific agreement in reviewed primary disclosures", "product": "Five-year compute service agreement; exact GPU configuration and deployment allocation undisclosed", "announcement_date": "2026-11-05", "signing_date": null, "signing_date_bounds": { "after": "2026-09-30", "on_or_before": "2026-11-05" }, "signed": "Company-reported signed agreement", "conditional": "Full agreement unavailable; conditions precedent, service acceptance tests and specific remedies not established", "closed": "No separate transaction-closing event established; not used as a delivery or payment status", "cash_received": "Contract-specific amount and receipt date not verified", "delivered": "Not established for this contract", "customer_accepted": "Not established for this contract", "recognized_revenue": "No contract-specific recognition established", "estimated_annual_revenue_usd_per_it_mw": 22000000, "term_years": 5, "customer_prepayment_share_estimated_gpu_capex": 0.9, "gpu_capex_denominator_exclusions": [ "Provincial sales tax", "Goods and services tax" ], "total_contract_value_usd": null, "capacity_it_mw": null, "gpu_count": null, "gpu_model": null, "location": null, "gpu_hour_price": null, "record_source_ids": [ "s1", "s2" ] }, "editorial_checks": { "prior_issue_compared": "PCT_2026-11-06.txt, version 0: IREN appeared only as an inventory signal; Riot–Anthropic was the Deals Desk feature.", "novelty": "Deeper analysis of November 5 disclosure, not a claim of a newly announced November 7 transaction.", "distinct_from_prior_features": [ "Qumulus", "AIB–Nebius", "Nscale", "Riot–Anthropic" ], "source_status": "Primary sources fully opened for relevant sections; 10-Q PDF was too large for web extraction, so official issuer HTML filing was inspected instead.", "no_site_changes": true, "no_external_contact": true, "no_price_index_conflation": true, "no_inferred_customer_identity": true, "no_market_wide_pricing_claim": true, "no_investment_recommendation": true }, "word_count": 1006, "estimated_reading_minutes_at_220_wpm": 4.6 }, "public_projection": { "version": "1.0.0", "date": "2026-11-10", "changes": [ "Internal workspace artifact paths omitted where present. Historical license/status fields retain original provenance; current public reuse policy is stated separately." ], "rights": "PCT reserves rights in original editorial content; third-party rights retained. No general source-data reuse license." } }, { "id": "pct-2026-11-07-formation-f457a81b21", "content_type": "article", "desk": "formation", "title": "Managing spare compute without losing the right to use it", "publication_date": "2026-11-07", "observation_date": "2026-11-07", "editorial_voice": "AI-assisted Formation Desk", "body": "A company can have spare GPUs and still be unwilling to give them up. Its next training run may start early, a customer may request another evaluation, or a batch may need repeating. The unused capacity provides insurance against those surprises. A marketplace that pays for idle hours but destroys that insurance may solve the wrong problem.\n\nOne possible intermediary would manage the surplus while remaining responsible for supplying the original customer's agreed service. Natural-gas asset-management arrangements offer a historical example of that institution. The useful question for Peterson Compute Trading is whether a manager can earn enough from flexibility to preserve the customer's operational protection, cover its own risks and leave both parties better off.\n\n## A manager with an obligation\n\nFERC's Order 712, issued June 19, 2008, changed the rules for U.S. interstate pipeline capacity releases to facilitate asset-management arrangements. These arrangements joined access to a customer's capacity with an obligation to purchase or supply gas for that customer. Qualifying releases received exemptions from competitive-bidding and tying restrictions. The order accommodated an existing commercial relationship; it did not invent the practice from nothing. [Order 712, June 19, 2008](https://www.ferc.gov/sites/default/files/2020-06/OrderNo.712.pdf).\n\nFERC's August 4, 2026 fact sheet describes the operating logic. A customer temporarily releases transportation or storage capacity to a manager. The manager serves that customer's requirements and can use capacity not needed for that purpose for third-party transactions. [FERC capacity-release fact sheet](https://ferc.gov/fact-sheet-capacity-release).\n\nThe retained obligation matters. Under the current regulation, a qualifying arrangement must let the releasing customer call on the manager to deliver or purchase gas up to the released capacity's daily contractual amount during specified periods. The detailed duration rules vary with the arrangement's term. This is a defined commitment, not an unlimited promise of supply whenever requested. [18 CFR 284.8(h)(3), current through November 5, 2026](https://www.ecfr.gov/current/title-18/chapter-I/subchapter-I/part-284/subpart-A/section-284.8).\n\n## What a real agreement protects\n\nA publicly filed agreement between Roanoke Gas Company and Sequent Energy Management, effective November 1, 2013, makes the relationship concrete. It gives the manager operating discretion subject to a firm supply obligation, defines customer forecasting and nomination procedures, and allocates fixed and variable charges. Its force-majeure provisions exclude certain problems caused by the manager's use of capacity for third parties, and exclude an inability to perform profitably. [Roanoke–Sequent agreement, especially Articles I, II, IV and V](https://www.sec.gov/Archives/edgar/data/1069533/000119312513394855/d609841dex101.htm).\n\nThat agreement illustrates a valuable design principle. A manager should not receive the upside from selling flexibility while silently returning the resulting delivery risk to the customer. The historical contract does not prove the arrangement saved money, and its protections are subject to its other terms. It does show that commercial discretion and responsibility can be specified together.\n\n## An eight-GPU example\n\nConsider a hypothetical buyer with 32 reserved GPUs at one operator. It expects eight to be unnecessary for the next 72 hours, but wants those eight available again within six hours of a valid request. These quantities and response times are invented design assumptions, not a supplier offer.\n\nA capacity manager might offer a service under which the buyer keeps that six-hour right while the manager places suitable temporary workloads on the spare machines. All parties, including the operator, would first need to authorize this use. The original buyer would retain its existing reservation payment, offset by an agreed credit from the manager.\n\nThe next buyer runs a restartable batch. It accepts interruption on two hours' notice and pays for the usable service it actually receives. The other four hours in the original customer's response window are reserved for ending the temporary tenancy, clearing its data, restoring the required environment and testing readiness. Whether four hours suffices must be demonstrated before selling the service. No credentials or customer data pass between the two buyers.\n\nThis turns a vague promise to find replacement GPUs into an operating plan. The operator confirms the temporary allocation and the manager records the original customer's deadline. A recall creates a timed sequence with named responsibilities. If the temporary workload cannot stop within its agreed notice period, it is ineligible. If the original buyer needs immediate access, this six-hour product is also ineligible.\n\nThe upper bound on the release is 576 GPU-hours: eight GPUs multiplied by 72 hours. It is not a forecast of billable usage or sale proceeds. Setup, interruption, maintenance and the final handback reduce usable time, and a buyer might never appear. The manager must also explain whether the promised return means the original machines or a tested equivalent. An unverified listing elsewhere cannot support the latter promise.\n\n## Who pays for preserving flexibility\n\nThe manager's economics begin with realized receipts from temporary users. From those receipts it must cover the original buyer's credit, operating costs, any purchased backup capacity and losses from failures. A commission calculated only on gross trading volume can reward deals that consume too much of the safety margin.\n\nThe customer should compare its credit with the restrictions and risk it accepts. A smaller credit with a demonstrated handback process may be more valuable than a larger one backed only by a promise to buy capacity later. If extra backup costs more than temporary users will pay, leaving the machines idle can be the sensible outcome.\n\nThis is also where portfolio arguments need scrutiny. Several customers might need their GPUs back after the same model release or regional outage. Those are stress scenarios, not measured correlations in this article. A manager should test simultaneous calls and loss of its largest supplier rather than assume that one customer's quiet period will always offset another's peak. Financial compensation can help after failure; it cannot recover a missed training deadline.\n\n## Where the analogy stops\n\nGas arrangements operate within a specific regulatory and tariff system. Their exemptions confer no rights on a compute intermediary. Gas can also be stored, whereas an expired computing hour cannot. Compute substitution adds software, networking, memory, security and data-location requirements. A contractual service promise cannot make an incompatible cluster useful.\n\nThere is a strong case for simpler alternatives. The operator may already have an effective interruptible pool. A customer might prefer cancellation rights or accept lower utilization to avoid another counterparty. An independent manager has to demonstrate an advantage after fees and operational complexity, not merely identify unused hardware.\n\nThe first experiment should therefore be narrow: one willing operator, one tested workload class and explicit notice periods. Measure net customer credits, useful work completed, handback times, simultaneous-call failures and the cost of keeping capacity ready. Record the trades rejected for operational reasons as well as successful ones.\n\nThe institution worth testing is a manager whose freedom to trade is bounded by a service obligation that can actually be met. That could make spare compute usable by someone else without asking the original customer to abandon the reason it reserved capacity in the first place.", "sources": [ { "id": "S1", "title": "Order No. 712: Promotion of a More Efficient Capacity Release Market", "publisher": "Federal Energy Regulatory Commission", "url": "https://www.ferc.gov/sites/default/files/2020-06/OrderNo.712.pdf", "published_at": "2008-06-19", "date_note": "Issued June 19, 2008; Federal Register publication June 30, 2008; effective July 30, 2008. Do not confuse the 2020 upload directory with the issue date.", "retrieved_at": "2026-11-07", "evidence_type": "Primary final rule", "supports": "Order facilitated existing asset-management arrangements and exemptions from bidding and tying restrictions.", "verification": "Official PDF search extract verifies title, issue date, summary and paragraph 1; full PDF was not rendered." }, { "id": "S2", "title": "Fact Sheet | Capacity Release", "publisher": "Federal Energy Regulatory Commission", "url": "https://ferc.gov/fact-sheet-capacity-release", "published_at": null, "updated_at": "2026-08-04", "date_note": "Page update date, not a claim that the arrangement was introduced or changed that day.", "retrieved_at": "2026-11-07", "evidence_type": "Primary regulator explanation", "supports": "Manager first serves releasing customer's supply needs and may transact with third parties when capacity is not needed for them.", "verification": "Full HTML read, sections Asset Manager Arrangements and footnote 1." }, { "id": "S3", "title": "18 CFR 284.8: Release of firm capacity on interstate pipelines", "publisher": "Office of the Federal Register / eCFR", "url": "https://www.ecfr.gov/current/title-18/chapter-I/subchapter-I/part-284/subpart-A/section-284.8", "published_at": null, "version_date": "2026-11-05", "date_note": "eCFR stated Title 18 current through November 5, 2026. The title's last-amended date does not establish that this particular provision changed then.", "retrieved_at": "2026-11-07", "evidence_type": "Primary current regulatory text, authoritative but unofficial eCFR edition", "supports": "Section 284.8(h)(3) defines a required purchase/delivery obligation and qualifying periods.", "verification": "Full HTML read, paragraphs (h)(3) through (h)(3)(iii)." }, { "id": "S4", "title": "Natural Gas Asset Management Agreement between Roanoke Gas Company and Sequent Energy Management, L.P.", "publisher": "Company agreement filed with the U.S. Securities and Exchange Commission", "url": "https://www.sec.gov/Archives/edgar/data/1069533/000119312513394855/d609841dex101.htm", "published_at": null, "effective_at": "2013-11-01", "date_note": "Agreement effective date verified in preamble; not presented as its SEC filing date or as a current contract.", "retrieved_at": "2026-11-07", "evidence_type": "Primary historical agreement exhibit", "supports": "Firm service obligation, operational discretion, customer forecasts, cost allocation, and specified force-majeure exclusions.", "verification": "HTML read of preamble, Article I and sections 2.03, 4.01, 5.04 and 5.05. No claim about actual performance or realized savings." } ], "facts": [ { "id": "F1", "claim": "FERC issued Order 712 on June 19, 2008 to facilitate asset-management arrangements, including specified bidding and tying exemptions.", "source_ids": [ "S1" ] }, { "id": "F2", "claim": "FERC describes managers serving the releasing customer's requirements and using otherwise-unneeded capacity for third-party transactions.", "source_ids": [ "S2" ] }, { "id": "F3", "claim": "The qualifying obligation in 18 CFR 284.8(h)(3) covers up to the daily contractual amount during specified periods, with duration conditions.", "source_ids": [ "S3" ] }, { "id": "F4", "claim": "The historical Roanoke–Sequent agreement couples management discretion with firm supply and defines forecasting, cost responsibilities and relevant force-majeure exclusions.", "source_ids": [ "S4" ] } ], "inferences": [ "A compute capacity manager could earn operating discretion by retaining an enforceable, technically credible service obligation to the original buyer.", "The manager must price the cost of protecting recall rights, not count gross idle-hour sales as savings.", "Simultaneous recalls and supplier failures should be tested because portfolio diversification may be least helpful during stress.", "A one-operator pilot can measure the value of managed flexibility before assuming that an independent exchange or broad aggregation is necessary." ], "unknowns": [ "No actual compute provider or buyer has agreed to this proposed arrangement.", "No verified current compute quote, transaction volume, idle-capacity estimate or realized savings figure is provided.", "The six-hour recall and four-hour handback assumptions require operational tests; they are not asserted capabilities.", "The historical agreement demonstrates contract design, not realized performance or economic benefits.", "No causal claim is made that Order 712 increased liquidity or reduced end-user costs.", "Legal permission, security suitability, data-location rules and software licensing would need deal-specific verification.", "Correlated demand examples are hypothetical stress tests, not empirical estimates." ], "correction_history": [], "license_status": "Original PCT editorial text; public license not selected. Source rights remain separate.", "public_url": null, "desk_extensions": { "id": "pct-2026-11-07-market-formation-capacity-management", "date": "2026-11-07", "publication_date": "2026-11-07", "observation_date": "2026-11-07", "desk": "Market formation", "content_type": "market_formation", "title": "Managing spare compute without losing the right to use it", "dek": "Natural-gas asset managers earn room to trade by accepting a supply obligation. A compute equivalent would need to prove it can return useful capacity on time.", "editorial_voice": "Formation Desk | AI-assisted, accessible academic", "word_count": 1130, "estimated_reading_minutes": 5.1, "hypothetical_example": { "status": "Entirely hypothetical; no purchase, quote or provider capability represented", "buyer_reserved_gpus": 32, "eligible_spare_gpus": 8, "maximum_window_hours": 72, "gross_gpu_hour_upper_bound": 576, "original_buyer_recall_hours": 6, "temporary_buyer_interruption_notice_hours": 2, "proposed_handback_validation_hours": 4, "economic_model": "Realized temporary-user receipts minus original-buyer credit, operating costs, backup-capacity costs and failure losses.", "assumptions": [ "Operator and both customers expressly authorize temporary allocation and separate tenancies.", "Temporary workload can end within its agreed notice period.", "Sanitization, restoration and validation fit within a demonstrated handback window.", "Original buyer accepts six-hour access rather than immediate availability.", "Existing reservation payments continue and are offset only by a specified manager credit.", "576 GPU-hours is a pre-overhead upper bound; no realized demand or revenue is assumed." ] }, "counterarguments": [ "Operator-run interruptible service or ordinary cancellation rights may provide the same benefit more cheaply.", "Backup capacity and handback costs may erase all revenue from temporary use.", "Critical workloads may rationally prefer idle capacity to added counterparty and handback risk.", "Common shocks can defeat assumed portfolio diversification." ], "analogy_limits": [ "U.S. gas-market exemptions are sector-specific and confer no compute resale or agency rights.", "Gas inventory can be stored; elapsed compute capacity cannot.", "Compute suitability depends on workload, software, topology, data location and security.", "A money remedy cannot restore a missed workload deadline." ], "distinct_from_previous_issue": "Nov. 6 airport slots concerned authorization to transfer, rights registration and cancellation value. This piece instead examines a manager's continuing supply obligation, operational recall sequence, cost allocation and correlated calls. The new historical institution is the natural-gas asset-management arrangement facilitated by Order 712 (2008), not energy-zone pricing, grain inspection or freight clearing.", "editorial_notes": [ "Only public research and local draft creation; no site changes, outreach, trades or accounts.", "Direct primary-source links included beside factual claims.", "Historical issue dates, current-regulation version date, source update date and retrieval dates separated.", "Article includes no verbatim quotation from the SEC contract.", "Original Order 636 capacity-release angle was dropped after checking the full prior airport-slot article to avoid duplication." ], "license_status": "Original private PCT prose; public license undecided. Source rights retained; no datasets or images reproduced.", "public_url": null }, "public_projection": { "version": "1.0.0", "date": "2026-11-10", "changes": [ "Internal workspace artifact paths omitted where present. Historical license/status fields retain original provenance; current public reuse policy is stated separately." ], "rights": "PCT reserves rights in original editorial content; third-party rights retained. No general source-data reuse license." } }, { "id": "pct-2026-11-07-spotlight-7a74b68779", "content_type": "article", "desk": "spotlight", "title": "Cloud Run Jobs: a thumbnail factory with a one-minute meter", "publication_date": "2026-11-07", "observation_date": "2026-11-07", "editorial_voice": "AI-assisted Spotlight Desk", "body": "A video catalogue needs preview images. There are 1,000 short clips, each about a minute long, and the publishing team wants a small contact sheet's worth of frames from each. The work can run after the uploads finish. Keeping a web server available all day would solve a different problem.\n\nGoogle Cloud Run Jobs is a concrete option: package the extraction code in a container, divide the catalogue into tasks, run them, and exit. Google distinguishes jobs from request-serving Cloud Run services; a job can contain up to 10,000 independent tasks, with the application responsible for distributing the records. [S1]\n\nThe useful buying question is surprisingly small: should one clip equal one task? For this workload, the billing minimum makes that decision worth examining before choosing a larger machine.\n\n## Build a thumbnail factory\n\nPCT's proposed job uses FFmpeg on a CPU. For every five seconds of video, it produces one JPEG, resized to 320 pixels wide with proportional height. Google publishes its own Cloud Run video-transcoding tutorial using GPUs; this example deliberately asks a smaller question about CPU thumbnail extraction rather than assuming a GPU is necessary. [S6]\n\nStart with a fixed manifest of input objects, including each object's generation number. That identifies the specific stored version to process. The example accepts clips between five and sixty seconds and no larger than 50 MiB. Those are protective limits chosen for this recipe, not Cloud Run product limits.\n\nThe worker downloads one clip, runs the extraction, puts the images into one archive, uploads the completed archive, and moves to the next clip. One clip at a time keeps temporary files from accumulating. A representative command is:\n\n`ffmpeg -i input.mp4 -map 0:v:0 -vf \"fps=1/5,scale=320:-2\" -an frame-%04d.jpg`\n\nThe accompanying Python worker adds size checks, error handling and upload preconditions. A local smoke test produced twelve 320-by-180 JPEGs from a synthetic sixty-second video. That verifies a basic output path. The container has not been built or run in Google Cloud, and the smoke test establishes no cloud throughput or cost benchmark.\n\n## The minute that changes the arithmetic\n\nFor regular jobs in Iowa, us-central1, Google's price page lists $0.000018 per vCPU-second and $0.000002 per GiB-second. Jobs pay for an instance's lifetime, with a one-minute minimum for each started instance. The price snapshot here is November 7, 2026. It excludes delayed-job rates and commitment discounts. [S2]\n\nConsider a deliberately explicit planning case. Every task has one vCPU and one GiB of memory. Assume each clip takes twenty seconds for download, processing and upload, plus five seconds of container overhead per task. Assume no failures, retries, sidecars or overlapping executions. These times are modeling assumptions, not observed FFmpeg performance.\n\nThe combined compute rate is $0.000020 per instance-second. Give each clip its own task and its assumed twenty-five-second lifetime is billed as sixty seconds. Across 1,000 tasks, that is 60,000 billed seconds and **$1.20 of gross compute**.\n\nNow put twenty clips into each of fifty tasks. Each instance lives for an assumed 405 seconds: twenty times twenty, plus five. Total billed time becomes 20,250 seconds, costing **$0.405 of gross compute**. The model saves 79.5 cents, or about 66%, without changing the machine size or the amount of useful extraction work.\n\nThese are compute subtotals before free allowances, taxes, storage, object operations, image builds, registry charges, logging and applicable network charges. Google's free tier is shared across projects under a billing account, so an isolated demonstration may have no incremental Cloud Run compute charge at all. [S2] A small example should not be sold as a production invoice.\n\n## Make the bundle a recoverable unit\n\nGrouping records also enlarges the unit that can fail. If clip nineteen is corrupt, restarting an entire twenty-clip bundle wastes work unless the application remembers the eighteen completed results. Google's guidance recommends idempotent jobs and preserving output separately from input. [S3]\n\nOur recipe names each output using the input's bucket, object name, generation and recipe version. It uploads one completed archive per clip, then checks for that archive on a retry. A generation-match precondition of zero permits creation only when there is no live object at the destination name. [S5] That protects against competing attempts overwriting the same result.\n\nThe important distinction is between retrying a container and accepting its outputs. A permanent decoding failure still needs an error record and an operator decision. The minimal recipe fails the task; a production pipeline should quarantine the bad clip and reconcile the full manifest against accepted archives. Otherwise later clips in the same bundle can remain unattempted.\n\nCloud Run's normal writable filesystem is memory-backed and disappears when the instance stops. [S4] A fifty-megabyte source file is therefore part of the memory budget, alongside the decoder, Python process and output images. One GiB is a trial configuration, not a promise that every codec or high-resolution input will fit.\n\n## A small run before the large run\n\nThe supplied recipe includes a Dockerfile, a manifest generator and a worker. It assumes existing authorized buckets, an image repository and a service account with the required access.\n\nFor the 1,000-record case, fifty tasks produce twenty records per task. Set parallelism to ten to cap concurrent task instances. That setting controls how many bundles run together, not how many records belong in each bundle. Cloud Run exposes the task index and task count to the container so the worker can make the assignment. [S1]\n\nStart with a smaller representative manifest. Check image quality, peak memory, complete output coverage, retries and actual billed instance time. Then compare one-clip tasks with bundled tasks using the same inputs and acceptance checks. Long or difficult clips can make equal-sized bundles finish unevenly; a record count alone is a poor estimate of processing effort.\n\n## What the buyer actually learns\n\nThe saving in this example is less than a dollar per run. That is an argument for a simple implementation, not a new scheduling platform. At larger volume, the same minimum-charge effect can become material. At smaller volume, maintainability and correct outputs deserve more attention than the third decimal place on the CPU tariff.\n\nPCT's interpretation is that the unit of work belongs in a compute-price comparison. An attractive per-second price does not fully describe a service when every instance carries a minimum bill. Cloud Run Jobs earns a place on the shortlist when independent, containerized work can finish and release its resources. Whether it wins this catalogue depends on measured runtime, failure behavior and the full bill, not the illustrative saving above.", "sources": [ { "id": "S1", "title": "Create jobs", "publisher": "Google Cloud", "published": null, "updated": "2026-10-30", "url": "https://docs.cloud.google.com/run/docs/create-jobs", "accessed": "2026-11-07", "access_note": "Opened primary documentation; checked task model, task count, task environment variables and creation controls." }, { "id": "S2", "title": "Cloud Run pricing", "publisher": "Google Cloud", "published": null, "updated": null, "url": "https://cloud.google.com/run/pricing", "accessed": "2026-11-07", "access_note": "Opened current pricing page. Jobs table is set to Iowa (us-central1); checked default USD CPU/memory rates, account-wide free-tier aggregation, and minimum one-minute lifetime billing. Page has no displayed update date." }, { "id": "S3", "title": "Jobs retries and checkpoints best practices", "publisher": "Google Cloud", "published": null, "updated": "2026-10-30", "url": "https://docs.cloud.google.com/run/docs/jobs-retries", "accessed": "2026-11-07", "access_note": "Opened primary documentation; checked restart, idempotence, separate outputs and checkpoint guidance." }, { "id": "S4", "title": "Container runtime contract", "publisher": "Google Cloud", "published": null, "updated": "2026-10-30", "url": "https://docs.cloud.google.com/run/docs/container-contract", "accessed": "2026-11-07", "access_note": "Opened primary documentation; checked ephemeral memory-backed filesystem, job exit behavior and task environment variables." }, { "id": "S5", "title": "Request preconditions", "publisher": "Google Cloud", "published": null, "updated": "2026-10-30", "url": "https://docs.cloud.google.com/storage/docs/request-preconditions", "accessed": "2026-11-07", "access_note": "Opened primary documentation; checked generation matching and zero-generation create-only behavior." }, { "id": "S6", "title": "GPU-accelerated video transcoding with FFmpeg on Cloud Run jobs", "publisher": "Google Cloud", "published": null, "updated": "2026-10-30", "url": "https://docs.cloud.google.com/run/docs/tutorials/video-encoding", "accessed": "2026-11-07", "access_note": "Opened official tutorial. Used as evidence of a concrete adjacent video workflow, not as proof of the performance of this CPU thumbnail recipe." } ], "facts": [ { "id": "F1", "claim": "Cloud Run jobs run containers to completion, can have up to 10,000 independent tasks, and expose task index/count for application partitioning.", "source_ids": [ "S1" ], "evidence_type": "current_documentation" }, { "id": "F2", "claim": "Regular jobs in us-central1 list default rates of USD 0.000018/vCPU-second and USD 0.000002/GiB-second. Each started instance has a one-minute minimum.", "source_ids": [ "S2" ], "evidence_type": "current_published_price_not_transaction_quote" }, { "id": "F3", "claim": "Cloud Run free-tier usage is aggregated across projects by billing account.", "source_ids": [ "S2" ], "evidence_type": "current_pricing_terms" }, { "id": "F4", "claim": "Google recommends idempotent jobs and separate input/output locations for safe restarts.", "source_ids": [ "S3" ], "evidence_type": "current_documentation" }, { "id": "F5", "claim": "The default writable container filesystem consumes instance memory and does not persist after the instance stops.", "source_ids": [ "S4" ], "evidence_type": "current_documentation" }, { "id": "F6", "claim": "A Cloud Storage generation-match precondition of zero permits a write only when no live destination object exists.", "source_ids": [ "S5" ], "evidence_type": "current_documentation" }, { "id": "F7", "claim": "Google provides an official FFmpeg video-transcoding tutorial using GPUs on Cloud Run Jobs.", "source_ids": [ "S6" ], "evidence_type": "primary_implementation_example_not_independently_reproduced" } ], "inferences": [ { "id": "I1", "claim": "Task grouping affects the effective cost of a short-record workload because the minimum applies per started instance.", "basis_fact_ids": [ "F1", "F2" ], "label": "PCT engineering interpretation" }, { "id": "I2", "claim": "The one-clip layout costs USD 1.20 gross compute; the twenty-clip layout costs USD 0.405; the difference is USD 0.795, or 66.25%.", "basis_fact_ids": [ "F2" ], "label": "illustrative arithmetic, not measured result", "assumptions": [ "1,000 clips", "1 vCPU and 1 GiB per instance", "20 seconds per clip including download, processing and upload", "5 additional lifetime seconds of overhead per task", "No failures, retries, sidecars or overlapping executions", "50 tasks with 20 clips each in the bundled layout", "Regular us-central1 default USD pricing; free tier and other line items excluded" ] }, { "id": "I3", "claim": "Completed per-clip output archives let a retry skip accepted clips without rerunning the whole bundle.", "basis_fact_ids": [ "F4", "F6" ], "label": "PCT proposed implementation; cloud path not executed" }, { "id": "I4", "claim": "A 1 GiB memory request is only a trial configuration; decoder use and filesystem usage must be measured on representative inputs.", "basis_fact_ids": [ "F5" ], "label": "PCT implementation caution" }, { "id": "I5", "claim": "Per-second price comparisons should account for task size, minimum charges and acceptance criteria.", "label": "PCT market interpretation" } ], "unknowns": [ "Actual Cloud Run runtime, startup/teardown overhead, image quality, memory usage and cost for a production collection.", "Live project quotas, IAM policies, regional capacity, storage classes and network path for any prospective reader.", "Whether the proposed Docker image builds successfully in the reader's environment; no cloud image build or deployment was performed.", "Cloud object download/upload, authentication and retry behavior of this exact implementation; only its local extraction and sharding paths were executed.", "The all-in invoice after free allowances, taxes, storage, object operations, build, registry, logs and data-transfer charges.", "Production handling of corrupt clips: the minimal example fails a task and requires additional quarantine/reconciliation logic." ], "correction_history": [], "license_status": "Original PCT editorial text; public license not selected. Source rights remain separate.", "public_url": null, "desk_extensions": { "id": "pct-2026-11-07-spotlight-cloud-run-jobs", "title": "Cloud Run Jobs: a thumbnail factory with a one-minute meter", "section": "Product spotlight", "publisher": "Peterson Compute Trading", "editorial_voice": "Spotlight Desk | AI-assisted, builder-focused", "as_of_date": "2026-11-07", "status": "desk_research_with_local_functional_smoke_test", "subject": "Google Cloud Run Jobs for CPU video-thumbnail extraction", "deck": "A 1,000-clip planning case shows why task size belongs beside the per-second compute price.", "editorial_word_count": 1080, "reading_minutes": 4.9, "cost_model": { "currency": "USD", "region": "us-central1", "pricing_mode": "regular jobs, default on-demand rates", "as_of": "2026-11-07", "vcpus_per_instance": 1, "gib_per_instance": 1, "cpu_rate_per_vcpu_second": 1.8e-05, "memory_rate_per_gib_second": 2e-06, "minimum_seconds_per_instance": 60, "records": 1000, "assumed_record_seconds": 20, "assumed_overhead_seconds_per_task": 5, "single_record_tasks": { "tasks": 1000, "assumed_lifetime_seconds_each": 25, "billed_seconds_each": 60, "total_billed_seconds": 60000, "gross_compute_usd": 1.2 }, "bundled_tasks": { "tasks": 50, "records_per_task": 20, "assumed_lifetime_seconds_each": 405, "total_billed_seconds": 20250, "gross_compute_usd": 0.405 }, "gross_savings_usd": 0.795, "gross_savings_percent": 66.25, "exclusions": "Free allowances, taxes, storage, object operations, Cloud Build, Artifact Registry, logging, network charges, retries, sidecars, operator labor; hypothetical timing is not a benchmark." }, "runnable_workload": { "purpose": "Runnable local smoke mode and proposed Cloud Run deployment recipe. Cloud setup and execution are reader actions, not performed here.", "files": { "Dockerfile": "FROM python:3.12-slim-bookworm\nRUN apt-get update && apt-get install -y --no-install-recommends ffmpeg && rm -rf /var/lib/apt/lists/*\nWORKDIR /app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\nCOPY main.py manifest.jsonl ./\nCMD [\"python\", \"-u\", \"main.py\"]\n", ".gcloudignore": ".git\n__pycache__/\n*.pyc\nfixture.mp4\nthumbnails.tar\nREADME.md\n", "main.py": "\"\"\"CPU-only thumbnail batches. Local smoke mode does not use Google Cloud.\"\"\"\nimport argparse\nimport hashlib\nimport json\nimport os\nfrom pathlib import Path\nimport subprocess\nimport tarfile\nimport tempfile\n\nMAX_BYTES = 50 * 1024 * 1024\n\n\ndef assigned_rows(rows, index, count):\n if count < 1 or not 0 <= index < count:\n raise ValueError(\"Invalid task index/count\")\n return rows[index::count]\n\n\ndef make_archive(input_path, output_path):\n input_path, output_path = Path(input_path), Path(output_path)\n if input_path.stat().st_size > MAX_BYTES:\n raise ValueError(\"Example accepts clips no larger than 50 MiB\")\n probe = json.loads(subprocess.check_output([\n \"ffprobe\", \"-v\", \"error\", \"-show_entries\", \"format=duration\",\n \"-of\", \"json\", str(input_path)\n ]))\n duration = float(probe[\"format\"][\"duration\"])\n if not 5 <= duration <= 60.5:\n raise ValueError(\"Example accepts clips between 5 and 60 seconds\")\n with tempfile.TemporaryDirectory() as work:\n pattern = str(Path(work) / \"frame-%04d.jpg\")\n subprocess.run([\n \"ffmpeg\", \"-nostdin\", \"-hide_banner\", \"-loglevel\", \"error\",\n \"-threads\", \"1\", \"-i\", str(input_path), \"-map\", \"0:v:0\",\n \"-vf\", \"fps=1/5,scale=320:-2\", \"-an\", \"-threads\", \"1\",\n \"-q:v\", \"3\", pattern\n ], check=True, timeout=120)\n frames = sorted(Path(work).glob(\"frame-*.jpg\"))\n if not frames:\n raise ValueError(\"No thumbnails produced\")\n with tarfile.open(output_path, \"w\") as archive:\n for frame in frames:\n archive.add(frame, arcname=frame.name)\n return len(frames)\n\n\ndef run_cloud():\n from google.cloud import storage\n from google.api_core.exceptions import PreconditionFailed\n\n rows = [json.loads(line) for line in Path(\"manifest.jsonl\").read_text().splitlines() if line.strip()]\n index = int(os.getenv(\"CLOUD_RUN_TASK_INDEX\", \"0\"))\n count = int(os.getenv(\"CLOUD_RUN_TASK_COUNT\", \"1\"))\n selected = assigned_rows(rows, index, count)\n client = storage.Client()\n output_bucket = client.bucket(os.environ[\"OUTPUT_BUCKET\"])\n # Change RECIPE_ID whenever code, dependencies, or transform parameters change.\n recipe_id = os.environ[\"RECIPE_ID\"]\n for row in selected:\n generation = int(row[\"generation\"])\n identity = json.dumps([row[\"bucket\"], row[\"name\"], generation, recipe_id])\n key = hashlib.sha256(identity.encode()).hexdigest()\n output = output_bucket.blob(f\"thumbnails/{key}.tar\")\n if output.exists():\n print(json.dumps({\"id\": key, \"status\": \"already_complete\"}), flush=True)\n continue\n source = client.bucket(row[\"bucket\"]).blob(row[\"name\"], generation=generation)\n source.reload()\n if source.size > MAX_BYTES:\n raise ValueError(f\"Input larger than 50 MiB: {row['name']}\")\n with tempfile.TemporaryDirectory() as work:\n input_path = Path(work) / \"input.mp4\"\n output_path = Path(work) / \"thumbnails.tar\"\n source.download_to_filename(str(input_path), if_generation_match=generation)\n frames = make_archive(input_path, output_path)\n output.metadata = {\"recipe_id\": recipe_id, \"source_generation\": str(generation)}\n try:\n output.upload_from_filename(str(output_path), content_type=\"application/x-tar\", if_generation_match=0)\n status = \"created\"\n except PreconditionFailed:\n # Another attempt already committed this deterministic result name.\n status = \"already_complete\"\n print(json.dumps({\"id\": key, \"frames\": frames, \"status\": status}), flush=True)\n\n\nif __name__ == \"__main__\":\n parser = argparse.ArgumentParser()\n parser.add_argument(\"--local-input\")\n parser.add_argument(\"--local-output\", default=\"thumbnails.tar\")\n args = parser.parse_args()\n if args.local_input:\n print(json.dumps({\"frames\": make_archive(args.local_input, args.local_output)}))\n else:\n run_cloud()\n", "README.md": "# Cloud Run Jobs thumbnail batch\n\nThis is an editorial implementation example, not a deployed service. The local FFmpeg path and task sharding were tested. The Docker build, Google authentication, IAM, object transfers, and Cloud Run execution were not tested. Running the cloud commands below can incur charges; none was run in preparing the article.\n\n## Workload\n\nTake rights-cleared MP4 clips, each 5–60 seconds and no larger than 50 MiB. Sample one JPEG every five seconds at 320 pixels wide, preserving aspect ratio. Upload one complete TAR archive per source clip to a separate output bucket. The number of frames depends on input timestamps and duration; a synthetic 60-second CFR fixture produced 12.\n\nThe default container filesystem is memory-backed. The 1 GiB example is a starting configuration, not a proven memory bound for arbitrary codecs or resolutions. The code processes one clip at a time. Profile your actual inputs, including decoder memory, before raising the input limit or running a full collection.\n\n## Local smoke test without Google Cloud\n\nRequires Python 3 and FFmpeg installed. From this directory:\n\n```sh\nffmpeg -nostdin -hide_banner -loglevel error -y \\\n -f lavfi -i 'testsrc2=size=640x360:rate=30' -t 60 \\\n -c:v libx264 -preset ultrafast -pix_fmt yuv420p fixture.mp4\npython main.py --local-input fixture.mp4 --local-output thumbnails.tar\ntar -tf thumbnails.tar\n```\n\nDo not use this smoke-test timing as a Cloud Run benchmark. The cloud image uses Debian Bookworm's FFmpeg package, whereas the editorial test used FFmpeg 7.1.5 in the local workspace.\n\n## Cloud prerequisites\n\nUse an existing billing-enabled Google Cloud project, enabled Cloud Run/Cloud Build/Artifact Registry APIs, an existing Docker Artifact Registry repository, and authorized input/output buckets. Use us-central1 for the article's price example. Read the current provider pricing and storage/network charges before execution.\n\nUse an existing dedicated Cloud Run service account authorized to read the input objects and to read/create output objects. Bucket-scoped Storage Object Viewer on inputs, and Storage Object Viewer plus Storage Object Creator on outputs, are one least-privilege starting point for these operations. Other policies, such as CMEK, can require additional permissions. Do not give public access. The deployer needs the Cloud Run and service-account-use permissions described in Google's create-jobs guide; the build identity needs the corresponding build/repository permissions. Ask the project administrator to verify these prerequisites rather than granting project-wide administrator roles.\n\nSet these shell variables to your own verified resources:\n\n```sh\nexport PROJECT='YOUR_PROJECT_ID'\nexport REGION='us-central1'\nexport REPO='YOUR_EXISTING_ARTIFACT_REGISTRY_REPOSITORY'\nexport INPUT_BUCKET='YOUR_INPUT_BUCKET'\nexport OUTPUT_BUCKET='YOUR_OUTPUT_BUCKET'\nexport INPUT_PREFIX='clips/'\nexport SERVICE_ACCOUNT='YOUR_EXISTING_SERVICE_ACCOUNT_EMAIL'\nexport IMAGE=\"$REGION-docker.pkg.dev/$PROJECT/$REPO/pct-thumbnails:nov07-v1\"\nexport RECIPE_ID='nov07-v1'\n```\n\nPrepare `manifest.jsonl` from your authorized input bucket. `make_manifest.py` uses Google Application Default Credentials, which you must configure using your normal approved authentication process. It lists only MP4 objects under INPUT_PREFIX. Review the resulting file; it is embedded in the container image, so the image's access controls must protect any non-public object names.\n\n```sh\npython -m pip install -r requirements.txt\npython make_manifest.py > manifest.jsonl\n```\n\nFor the worked example the manifest has exactly 1,000 distinct clips. For an initial cloud test use a small representative manifest and set the task count accordingly. Keep object generations available for the execution's duration. A missing or replaced generation is an error, not permission to silently process another version.\n\nBuild and create the job (this uploads the source and manifest, stores an image, and creates billable cloud resources):\n\n```sh\ngcloud builds submit --project=\"$PROJECT\" --tag=\"$IMAGE\" .\ngcloud run jobs create pct-thumbnails \\\n --project=\"$PROJECT\" --region=\"$REGION\" --image=\"$IMAGE\" \\\n --service-account=\"$SERVICE_ACCOUNT\" \\\n --cpu=1 --memory=1Gi \\\n --tasks=50 --parallelism=10 \\\n --task-timeout=15m --max-retries=1 \\\n --set-env-vars=\"OUTPUT_BUCKET=$OUTPUT_BUCKET,RECIPE_ID=$RECIPE_ID\"\n```\n\nThen execute explicitly:\n\n```sh\ngcloud run jobs execute pct-thumbnails \\\n --project=\"$PROJECT\" --region=\"$REGION\" --wait\n```\n\nA Cloud Run task reads CLOUD_RUN_TASK_INDEX and CLOUD_RUN_TASK_COUNT. With 1,000 rows and 50 tasks, each task receives 20 rows by strided partitioning. `--parallelism=10` caps concurrent task instances, not records per task. With a different manifest length the counts can differ by one. Setting more tasks than records creates useless empty tasks and can still incur minimum billing.\n\n## Completion and retries\n\nOutput names hash the input bucket/name/generation and RECIPE_ID. Change RECIPE_ID for every change to code, dependencies, or transform parameters, and use a unique image tag or digest. Output objects are created with `if_generation_match=0`, avoiding overwrite by competing attempts. A retry checks completed objects and skips them. Use an output namespace controlled by this pipeline; a pre-existing object under that deterministic name is considered completed.\n\nThe example fails a task on an invalid clip. A production system should record/quarantine permanent input failures and reconcile the full manifest against accepted outputs; otherwise one corrupt clip can prevent later clips in its shard from being attempted even after a retry. Do not equate a count of log lines with acceptance. Verify archive contents and dimensions, preserve error details, and measure actual billed instance time, output coverage, retries, and peak memory.\n\nThe example intentionally does not create a schedule, change IAM, create credentials, or include destructive cleanup commands. Stored images/objects can continue to incur charges after the job stops; apply your normal retention process.\n", "manifest.example.jsonl": "{\"bucket\":\"YOUR_INPUT_BUCKET\",\"name\":\"clips/example.mp4\",\"generation\":\"REPLACE_WITH_OBJECT_GENERATION\"}\n", "make_manifest.py": "\"\"\"Run with authorized Google Application Default Credentials. Read-only.\"\"\"\nimport json\nimport os\nfrom google.cloud import storage\n\nclient = storage.Client()\nbucket = os.environ[\"INPUT_BUCKET\"]\nprefix = os.getenv(\"INPUT_PREFIX\", \"clips/\")\nrows = [\n {\"bucket\": bucket, \"name\": blob.name, \"generation\": str(blob.generation)}\n for blob in client.list_blobs(bucket, prefix=prefix)\n if blob.name.lower().endswith(\".mp4\")\n]\nfor row in sorted(rows, key=lambda row: row[\"name\"]):\n print(json.dumps(row))\n", "requirements.txt": "google-cloud-storage==3.17.1\n" }, "local_validation": { "date": "2026-11-07", "status": "passed", "python_syntax": "main.py and make_manifest.py compile", "ffmpeg_version": "7.1.5-0+deb13u1", "input": "Synthetic 60-second 640x360 H.264 video at 30 fps", "output": "12 JPEGs in one TAR archive; each 320x180", "sharding": "1,000 integers split across 50 task indices; exactly 20 each; coverage exact and no duplicates", "not_tested": [ "Docker build", "Cloud IAM and authentication", "Cloud Storage object I/O", "Cloud Run execution", "Cloud retries", "Throughput", "Provider bill" ] } } }, "public_projection": { "version": "1.0.0", "date": "2026-11-10", "changes": [ "Internal workspace artifact paths omitted where present. Historical license/status fields retain original provenance; current public reuse policy is stated separately." ], "rights": "PCT reserves rights in original editorial content; third-party rights retained. No general source-data reuse license." } } ], "corrections": [ { "date": "2026-11-05", "scope": "PCT_2026-11-04.json", "description": "H100 spot and on-demand 06.ai records shared an identifier; prior file remains unchanged, this edition uses unique observation IDs. No price correction implied.", "prior_archive_id": "libfile_5a5661b01848819197ddf74ee9b1d16d" } ], "omitted": "Separate benchmark, provider-price and market-signal datasets are not republished in this article archive." }