Skip to content

Chronological research archive

Historical archive · Browse supplements · Current report

The full historical research and planning record, organized into readable chapters. It includes earlier proposals and test stages that may have been superseded. Use the current report for the assessment and current boundaries.

Download original audit text · Search source evidence · Supplement

Open a chapter to read it. The download preserves the original text; no historical trial is promoted to a completed deployment or college commitment.

1. Original findings and method

TEACHING ON BORROWED COMPUTE

Research and claim audit | Greg Chism | Checked October 8, 2026

Core problem: What we have previously relied on can no longer be guaranteed

RESEARCH METHOD

Window: October 8, 2021 through October 8, 2026. Exa discovery used 13 targeted searches requesting 77 result slots across four workstreams: named provider changes; other withdrawals; ACCESS and NAIRR program fit; date and policy verification. Search results were discovery material, not accepted as proof. The initial compute audit used 15 evidence entries, mostly provider/program records. The degree update expanded this to 27; the October 10 repository update brings the then-current deck to 37; the October 10 expanded evidence contained 73 records; the October 11 Codabench correction and resource comparison brought the October 11 ledger to 88 records; the October 12 federal map brings the current ledger to 130 records. Fourteen original provider/program URLs returned HTTP 200 on direct checks. The Replit original returned HTTP 404, so its staged closure is linked to Bucknell's live institutional record, corroborating the indexed provider announcement.

FINDING

The evidence supports a continuity problem across multiple layers of teaching infrastructure: free compute and premium education benefits, student app hosting, and classroom orchestration. The selected history is not a measured estimate of total educational compute capacity, market prevalence, or learning losses. It does not establish that every free option has disappeared.

CLAIM BOUNDARIES

1. GitHub Classroom closed August 28, 2026; GitHub repositories, organizations and accounts remain. Allocation compute alone cannot replace Classroom workflows.
2. Colab Pro for Education closed to new sign-ups. Free Colab remains. Existing verified education subscriptions retain their remaining year under the FAQ conditions. No exact effective closure date is established. The limited offer was announced July 18, 2025. 'Quietly' describes the FAQ-based notice; the absence of another announcement is not proven.
3. AWS's new general Free Tier free plan lasts at most six months for accounts created July 15, 2025 onward. This is not a documented six-month reduction to all AWS student, Educate or Academy accounts. The new plan changes credits, eligible instances and spending protection as well as duration. Credits can outlast the free plan if the user upgrades to an eligible paid plan.
4. Heroku and Glitch were general-purpose services used in teaching, not education-only accounts. Replit's 2023 and 2024 milestones are stages of one withdrawal. Studio Lab is closed to new customers, not all existing customers.
5. Colab and Studio Lab appear in the timeline under the year they were observed. The deck does not manufacture an effective date from an undated current notice.

TIMELINE

November 28, 2022 | Heroku | Hosting
Free app hosting and databases end. Heroku withdraws free Dynos, Postgres, and Redis plans. Existing free apps and data services face shutdown or deletion.
Scope: General-purpose services used in teaching; not an education-only account.
Source: https://devcenter.heroku.com/changelog-items/2461

November 15, 2023 | Replit · new teams | Classroom
No new Teams for Education. New education team creation stops. Updates and bug fixes end, leaving instructors unable to use the same setup for a new cohort.
Scope: The start of a staged withdrawal; Replit’s broader product continues.
Source: https://bucknell.teamdynamix.com/TDClient/40/IT/KB/Article/529/Replit-FAQ

August 1, 2024 | Replit · removal | Classroom
Teams for Education is removed. The education product closes and its data is deleted after an export period. Teaching materials need a new home.
Scope: This is the final stage of the withdrawal announced in 2023.
Source: https://bucknell.teamdynamix.com/TDClient/40/IT/KB/Article/529/Replit-FAQ

July 8, 2025 | Glitch | Hosting
Project hosting shuts down. Glitch ends app hosting and user profiles. Live student apps and teaching demonstrations must move.
Scope: General-purpose coding/hosting platform. Export access continued through 2025.
Source: https://blog.glitch.com/post/changes-are-coming-to-glitch

July 15, 2025 · new accounts | AWS Free Tier | Compute
The free-plan window gets shorter. The former 12-month limited benefits give way to a credit-based free plan of at most 6 months, ending earlier if credits run out.
Scope: General Free Tier used by students; not a blanket change to AWS Educate or Academy. New credits and spending protection also change.
Source: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-free-tier-usage.html

August 28, 2026 | GitHub Classroom | Classroom
GitHub Classroom shuts down. The Classroom website, APIs, and related services are decommissioned. New sign-ups had already stopped on May 26.
Scope: GitHub accounts, repositories, and organizations remain. Some Classroom metadata is subject to deletion.
Source: https://github.blog/changelog/2026-08-27-github-classroom-deprecated/

Observed October 8, 2026 · change date unverified | Colab education offer | Compute benefit
The education Pro offer quietly closes. Google’s FAQ now says free one-year Colab Pro for Education subscriptions are unavailable to new sign-ups. Existing verified users keep their remaining year.
Scope: Free Colab still exists. “Quietly” describes the FAQ notice; no exact closure date is established. The original offer was limited.
Source: https://research.google.com/colaboratory/faq.html

Observed October 8, 2026 · change date unverified | SageMaker Studio Lab | Compute access
Another free notebook door closes. AWS no longer accepts new Studio Lab customers and plans no new features. Existing users can continue.
Scope: A new-access restriction, not a full service shutdown. The current provider notice does not state an effective date.
Source: https://docs.aws.amazon.com/sagemaker/latest/dg/studio-lab-availability-change.html

PROPOSED TEACHING SERVICE

Pool instructor demand into a justified ACCESS allocation structure agreed with the program and provider. Select a project type from measured need, rather than assuming that 'large' automatically requires Maximize. In parallel, assist eligible AI-course instructors with NAIRR Classroom requests. Operate a local service around the resources: browser labs, tested course environments, accounts and quotas, support, LMS/assignment/grading connections, and portable exports. These are proposed capabilities, not a deployment report or award confirmation.

The local program should offer instructor intake, benchmark assistance, proposal/biosketch preparation support, course rehearsals, cohort onboarding, primary technical support, usage/outcome evidence, midterm and final reports, and a plan for the next teaching cycle. NAIRR Classroom final reports are due within 30 days of course completion. No proposal has been submitted by this deck-building task.

ACCESS classroom periods generally follow courses, and classroom projects are typically not extended. NAIRR awards depend on resource match and availability and support U.S.-based AI instruction for U.S.-based participants. Both paths need future requests and capacity planning. Neither is a perpetual entitlement. A central service/umbrella allocation structure must be confirmed with the program and provider.

ILLUSTRATIVE CAPACITY MODEL

12 courses x 40 students = 480 course seats (not necessarily unique people).
CPU: 12 x 40 x 15 weeks x 8 core-hours/student/week = 57,600 core-hours.
With 25% allowance: 72,000 CPU core-hours.
GPU subset: 4 courses x 40 students x 6 weeks x 2 GPU-hours/student/week = 1,920 GPU-hours.
With 25% allowance: 2,400 GPU-hours.
CPU and GPU hours cannot be added or treated as ACCESS credits. Convert using the selected resource's accounting after benchmarks. GPU model, simultaneous access, memory, storage, idle use, licensing, security, accessibility, staffing and fallback operation need separate planning. No current allocation size or available quota was verified for this deck.

The proposed lead-in schedule begins 12 weeks before teaching; it is an operating target, not a promise of program review or provisioning speed. Rehearse at class concurrency and prepare an alternate lab before the first assignment. Keep code, environment definitions, data and assessment records portable. Institutionally supported staff time is a real cost even when students do not pay for compute.

SOURCE LEDGER

GitHub Classroom · full shutdown
Notice: August 27, 2026 · effective August 28, 2026
Evidence quality: Provider announcement; dated change
Claim: GitHub decommissioned Classroom’s website, APIs, and related services on August 28, 2026. Its May 26 announcement had already stopped new sign-ups. Accounts, repositories, and organizations remain; some Classroom-specific metadata is subject to deletion.
Boundary: This removes a course-management and automation layer. It does not remove GitHub itself or establish that all free Actions or Codespaces benefits have ended.
https://github.blog/changelog/2026-08-27-github-classroom-deprecated/

Google Colab Pro for Education · offer closed
Current FAQ checked October 8, 2026 · effective closure date not stated
Evidence quality: Provider policy; verified status, uncertain change date
Claim: The FAQ says new sign-ups for the free one-year Pro for Education subscription are no longer available. Previously verified users keep the benefit until their one-year mark, unless replaced with a paid personal subscription.
Boundary: Google announced a limited number of these subscriptions on July 18, 2025. The current FAQ establishes withdrawal of the offer, not deletion of education accounts or the end of free Colab. The phrase “quietly pulled” is an interpretation of the FAQ-only notice; the absence of a separate announcement cannot be proved. Free Colab still has variable, non-guaranteed resource limits.
https://research.google.com/colaboratory/faq.html

Google · original education offer
July 18, 2025
Evidence quality: Provider launch announcement
Claim: Google offered a limited number of free one-year Colab Pro subscriptions to verified students and faculty at U.S. higher education institutions.
Boundary: The original offer was explicitly limited. It was not a permanent entitlement or a commitment to every future cohort.
https://blog.google/products-and-platforms/products/education/colab-higher-education/

AWS · twelve-month and six-month Free Tier comparison
New-account boundary: July 15, 2025
Evidence quality: Provider documentation with an explicit before/after table
Claim: For accounts created before July 15, 2025, the documented EC2 Free Tier benefit lasted 12 months with usage limits and possible overage billing. Newer accounts receive a credit-based free plan lasting at most six months, ending sooner if credits run out; usage cannot exceed the free-plan limits.
Boundary: This is the general Free Tier used by students, not a verified six-month change to AWS Educate or Academy. The new plan also changes eligible instances, credits, and spending protection. Remaining credits may last up to 12 months if a user upgrades to a paid plan, subject to terms.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-free-tier-usage.html

AWS · credit and free-plan expiration rules
Current FAQ checked October 8, 2026
Evidence quality: Provider FAQ; confirms distinction between credits and free plan
Claim: The free plan ends after six months or exhaustion of credits. Free Tier credits generally expire twelve months after account creation and can apply after an eligible upgrade to a paid plan.
Boundary: A six-month free plan is not equivalent to a six-month expiry for every credit or every educational program.
https://aws.amazon.com/free/free-tier-faqs/

Heroku · free compute and databases withdrawn
Announced August 25, 2022 · effective November 28, 2022
Evidence quality: Provider changelog; dated change
Claim: Heroku ended its free Dynos, Postgres, and Redis plans and began scaling down free dynos and deleting free databases on November 28, 2022.
Boundary: General-purpose hosting and data services used in teaching. This is not evidence that every later Heroku student credit offer ended.
https://devcenter.heroku.com/changelog-items/2461

Replit · Teams for Education decommissioned
Provider notice December 6, 2023 · removal August 1, 2024
Evidence quality: University service record, corroborating the indexed provider announcement
Claim: Users were notified November 14, 2023. New team creation and updates stopped November 15. Replit removed Teams for Education and deleted its data on August 1, 2024 after an export period.
Boundary: The original Replit announcement at blog.replit.com/update-on-teams-for-education was readable through Exa’s indexed copy but returned HTTP 404 during direct verification. This link opens Bucknell’s institutional notice with the same staged timeline. Replit’s broader product continued; the 2023 and 2024 milestones are one product withdrawal.
https://bucknell.teamdynamix.com/TDClient/40/IT/KB/Article/529/Replit-FAQ

Glitch · project hosting ended
Announced May 22, 2025 · effective July 8, 2025
Evidence quality: Provider announcement; dated change
Claim: Glitch ended project hosting and user profiles on July 8, 2025. Code downloads remained available through the end of 2025, with a redirect transition.
Boundary: General-purpose creative coding and hosting used in teaching; this is a hosting loss, not a withdrawal of GPU notebooks or an education-only account.
https://blog.glitch.com/post/changes-are-coming-to-glitch

AWS SageMaker Studio Lab · new customers closed
Current provider documentation checked October 8, 2026 · effective date not stated
Evidence quality: Provider policy; verified status, uncertain change date
Claim: Studio Lab is closed to new customers. Existing customers may continue using it; AWS plans security and availability work but no new features.
Boundary: The existing free notebook service is not fully shut down. An external documentation-change tracker suggests July 30, 2026, but the current primary notice does not date the change; the deck deliberately uses the observation date.
https://docs.aws.amazon.com/sagemaker/latest/dg/studio-lab-availability-change.html

ACCESS · eligibility, educational periods, review, renewal
Current policy checked October 8, 2026
Evidence quality: Official program policy
Claim: Eligible U.S.-based educators may lead allocations. Educational projects align with individual courses or training periods; they are typically not extended. ACCESS accepts educational uses at all scales with suitable justification. Smaller project requests are reviewed continually; Maximize requests use semiannual review and renewal.
Boundary: A pooled teaching-service proposal needs program/provider agreement about structure and eligible uses. An award does not guarantee future approval, permanent student accounts, synchronous GPU availability, or local support staffing.
https://allocations.access-ci.org/allocations-policy

ACCESS · allocation scale
Current program page checked October 8, 2026
Evidence quality: Official program description
Claim: Explore, Discover, and Accelerate have published credit limits of 400,000, 1,500,000, and 3,000,000 respectively; Maximize requests resource-specific allocations. Discover explicitly includes large classes and training events. Start smaller and upgrade if needed.
Boundary: Limits are not guaranteed awards. Current policy awards up to half of the credit limit initially and the remainder through a justified supplement. Credits are not interchangeable with CPU core-hours or GPU-hours without resource-specific conversion. The deck does not prescribe Maximize merely because the user wants a large allocation.
https://allocations.access-ci.org/project-types

NAIRR Pilot Classroom · instructor request
Current classroom call checked October 8, 2026
Evidence quality: Official classroom opportunity and proposal instructions
Claim: U.S.-based instructors can request resources for undergraduate or graduate AI coursework or short training in any discipline with U.S.-based participants. Prepare a course/resource description of at most three pages plus a lead biosketch. Identify software, compute and storage needs, support, readiness, a preferred provider, and an alternate.
Boundary: Only selected providers support this call. Resource match and availability are conditional. Instructors or their teams provide primary student technical support. Course development/testing is also eligible. A central program should assist instructors rather than imply that pilot awards are automatic or unrestricted.
https://nairrpilot.org/opportunities/education-call

Jetstream2 · teaching environments
Current resource documentation checked October 8, 2026
Evidence quality: Resource-provider teaching guide
Claim: Jetstream2 documents classroom workflows including JupyterHub, reproducible environments, AI/ML, virtual desktops, and web hosting.
Boundary: This supports the feasibility of the diagram’s software choices. The pictured service is proposed; it is not a verified deployment. A gateway or hub still needs engineering, operating ownership, and the appropriate allocation.
https://docs.jetstream-cloud.org/tutorial/classroom/overview/

Jetstream2 · classroom allocation planning
Current planning guide checked October 8, 2026
Evidence quality: Resource-provider sizing guidance
Claim: Plan course duration, student count, instance size, GPU needs, active hours, and storage. Account for idle instances and operational overhead when estimating resource use.
Boundary: The calculator uses illustrative demand assumptions, not provider benchmarks. CPU and GPU hours must be mapped to the chosen resource’s accounting; shared-service and course quotas require an actual operating design.
https://docs.jetstream-cloud.org/tutorial/classroom/allocation/

NAIRR Classroom · reporting requirements
April 2025, version 2 · current guidance checked October 8, 2026
Evidence quality: Official reporting guidance; corroborated by April 2026 newsletter
Claim: Submit a progress report halfway through the course or training and a final report within 30 days of completion. Report resource use, participation, educational outcomes, and issues.
Boundary: The proposed program needs to collect enough course evidence to complete these reports; allocation acquisition is only one stage of delivery.
https://nairrpilot.org/app/site/media/docs/NAIRR_Pilot_Classroom_Reporting.pdf

VISUALS AND FORMAT

Five HTML slides, using the project's Barlow Condensed, Literata and IBM Plex Sans styles. All illustrations and diagrams are original SVG figures created for this deck. No externally licensed photographs or provider logos are redistributed. Source panels are reference material within the five-slide presentation, not additional slides.

2. Early degree and platform comparison

CURRENT FREE OPTIONS BY DEGREE | checked October 8, 2026

Coverage: current college program finder; nine non-cyber degree awards. Certificates, minors, accelerated pathways and dual-degree combinations are not additional awards. Current names are used rather than legacy game/society names. Recommendations below are assignment-level judgments based on curriculum descriptions and documented platform capability, not rankings from classroom trials. No new provider account or classroom deployment was tested by this research.

BS Information Science
Program: https://infosci.arizona.edu/bs-information-science
Free starting point: GitHub Codespaces + Kaggle Notebooks
Suitable: Python / R / SQL labs, small-data models and short GPU experiments. Browser prototypes for the immersive emphasis.
Boundary: Large training, concurrent GPUs, high-memory data or immersive hardware are required.
Next step: ACCESS CPU / GPU labs; NAIRR Classroom for AI courses; campus XR hardware.

MS Data Science
Program: https://infosci.arizona.edu/ms-data-science
Free starting point: GitHub Codespaces + Kaggle Notebooks
Suitable: Reproducible notebooks, tabular ML, sampled datasets and checkpointed deep-learning labs.
Boundary: Data exceeds RAM / storage, models exceed available VRAM, or jobs need long / distributed training.
Next step: ACCESS for larger data and scheduled capacity; NAIRR Classroom for AI instruction.

MS Information Science
Program: https://infosci.arizona.edu/ms-information-science
Free starting point: GitHub Codespaces + Kaggle Notebooks
Suitable: ML subplan: notebook experiments. Human-Centered Computing: web prototypes and small public-data studies.
Boundary: Training or deployment must persist; studies need controlled data, full desktops or specialized devices.
Next step: Managed ACCESS environments; NAIRR Classroom where the course teaches AI.

BA Emerging Technologies in Society
Program: https://infosci.arizona.edu/ba-emerging-technologies-society
Free starting point: GitHub Codespaces + GitHub Pages
Suitable: Small public-text / network analyses, web development, digital storytelling and public portfolios.
Boundary: Live app backends, licensed social-media data, private participant records or large corpora are required.
Next step: ACCESS for larger analysis or managed servers; retain institution-approved study tools.

BA Game Design
Program: https://infosci.arizona.edu/ba-game-design
Free starting point: Twine + GitHub Pages
Suitable: Branching narratives, rules and interaction prototypes, browser playtesting and published HTML games.
Boundary: A project needs a full 3D engine, large assets, persistent multiplayer servers or VR headsets.
Next step: Campus engine / device labs; evaluate allocated GPU desktops and server support.

BS Game Development
Program: https://infosci.arizona.edu/bs-game-development
Free starting point: GitHub Codespaces + GitHub Pages
Suitable: Game logic, headless tests, small JavaScript games and browser-playable prototypes.
Boundary: Unity / Unreal desktop workflows, heavy 3D builds, rendering, VR or persistent multiplayer are required.
Next step: Campus game / XR labs; ACCESS servers or GPU desktops after software and license checks.

BA Information Science & Arts
Program: https://infosci.arizona.edu/ba-information-science-arts
Free starting point: p5.js Web Editor + GitHub Pages
Suitable: Creative coding, interactive graphics, audio-visual sketches and web-based UX prototypes.
Boundary: Work needs high-end rendering, large media, installed creative software, XR devices or physical installations.
Next step: Campus media / XR labs; allocated GPU or remote desktops where appropriate.

MA Library & Information Science
Program: https://infosci.arizona.edu/ma-library-information-science
Free starting point: GitHub Codespaces + GitHub Pages
Suitable: Metadata cleaning, Python / R / SQL exercises, small text collections and static digital exhibits.
Boundary: A repository / ILS must run continuously, preservation storage must endure, or collections need access controls.
Next step: Managed ACCESS teaching servers plus library systems; NAIRR Classroom for AI coursework.

PhD Information
Program: https://infosci.arizona.edu/phd-information
Free starting point: GitHub Codespaces + Kaggle Notebooks
Suitable: Methods coursework, pilot analyses, reproducible examples and small model feasibility studies.
Boundary: Dissertation work needs sustained GPU time, large-scale simulation, controlled data or durable services.
Next step: ACCESS / appropriate NAIRR research requests for research; Classroom only for eligible instruction.

PROVIDER CONSTRAINTS AND RECOMMENDATION METHOD

Codespaces is the preferred CPU baseline because its monthly entitlement is documented and portable dev containers support notebooks and code. Kaggle is the preferred free GPU supplement among the reviewed options because it offers notebook accelerators, with weekly quota and session limits. This is not a claim that it is universally best or more reliable than all alternatives. Free Colab remains a fallback; its variable quota and GPU availability cannot guarantee synchronous labs. Neither platform replaces a managed whole-class capacity commitment.

The mappings cover all three BS Information Science emphases and both MS Information Science subplans. Game and arts recommendations explicitly separate browser/device execution from cloud hosting. There is no complete free cloud workstation recommendation for heavy 3D / XR. ACCESS GPU desktops require software, licensing, device and latency validation; physical XR and installation work still needs campus equipment. PhD research belongs under research allocations, not a Classroom award merely because its user is a student.

Codabench is the intended benchmark platform, corrected October 11, 2026. It provides free competition hosting and a shared CPU scoring queue capped at 20 minutes; organizers supply code/GPU queues. cuda.live remains an independent optional micro-exercise route.

NEW SOURCE LEDGER

UArizona InfoSci · current degree roster
Checked October 8, 2026
The current program finder lists nine non-cyber degree awards: five bachelor’s degrees, MS Data Science, MS Information Science, MA Library & Information Science, and PhD Information.
Boundary: BAS Cyber Defense, BS Cyber Operations and MS Cyber Operations are excluded. Certificates, minors and accelerated pathways are not additional degree awards. Platform-to-assignment matches are an instructional assessment, not a college endorsement or tested curriculum deployment.
https://infosci.arizona.edu/programs

Codespaces · free personal-account quotas
Checked October 8, 2026
Personal Free includes 120 core-hours and 15 GB-month; Pro includes 180 core-hours and 20 GB-month. On a 2-core machine those amounts mean 60 and 90 active wall-clock hours. Larger machines spend the quota faster.
Boundary: Organizations have no included free quota. Stored codespaces consume storage even when stopped. Without a payment method usage stops at the limit; paid overages depend on billing settings. Use personal ownership deliberately; Classroom’s former organization benefit is not assumed.
https://docs.github.com/en/billing/concepts/product-billing/github-codespaces

Codespaces · verified student benefit
Checked October 8, 2026
Verified students receive up to 180 core-hours per month on personal accounts, with storage equivalent to GitHub Pro.
Boundary: Verification and benefit eligibility must be established before teaching. Some documentation still describes the closed Classroom integration; the recommendation uses only the personal-account benefit.
https://docs.github.com/en/education/about-github-education/github-education-for-students/about-github-education-for-students

Codespaces · machine learning and GPU boundary
Checked October 8, 2026
GitHub documents notebook-based ML and JupyterLab. Its GPU machine trial is not generally available.
Boundary: Installing CUDA software does not confer a GPU. Treat ordinary free Codespaces as CPU compute; a full desktop game / XR workstation is outside this recommendation.
https://docs.github.com/en/codespaces/developing-in-a-codespace/getting-started-with-github-codespaces-for-machine-learning

Kaggle · free accelerator notebooks
Checked October 8, 2026
Kaggle offers free GPU notebooks subject to availability. Current notebook documentation lists 12-hour CPU/GPU sessions and 20 GB of saved working space, and references T4 and P100 hardware.
Boundary: An older official GPU tips page still says 9-hour sessions and 30 hours/week. Plan short checkpointed labs below nine hours and check the live timer, quota and available hardware. Large-model fit depends on actual VRAM; two GPUs do not automatically pool memory. No classroom concurrency reservation is established.
https://www.kaggle.com/docs/notebooks

Kaggle · floating weekly GPU quota
Checked October 8, 2026
The provider describes a weekly floating GPU quota, with the account/editor showing the current allowance; it can vary with demand and resource availability.
Boundary: The historical 30-hour figure is not presented as a guaranteed class entitlement. Extra hours linked to a paid Colab promotion are excluded from the free recommendation.
https://www.kaggle.com/product-feedback/173129

GitHub Pages · static hosting
Checked October 8, 2026
Pages serves HTML, CSS and JavaScript from repositories. GitHub Free supports Pages in public repositories.
Boundary: This hosts a browser project; it does not supply server-side application compute or a GPU. Public project hosting is unsuitable for private study records.
https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages

GitHub Pages · size and bandwidth limits
Checked October 8, 2026
Published sites may be at most 1 GB, with a soft 100 GB monthly bandwidth limit and deployment / rate limits.
Boundary: Large game assets, media archives, persistent databases and multiplayer backends need another service. Free public hosting does not imply private access control.
https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits

p5.js · free browser creative coding
Checked October 8, 2026
p5.js is a free open-source JavaScript library with a web editor for interactive and audio-visual works, including WebGL.
Boundary: Rendering runs on the learner’s device. Device performance, browser capabilities and peripheral access remain course constraints; this is not cloud GPU capacity.
https://p5js.org/about/

Twine · free interactive narratives
Checked October 8, 2026
Twine supports browser or desktop authoring of nonlinear stories and exports HTML, with optional CSS and JavaScript.
Boundary: Suitable for narrative and interaction prototypes, not a replacement for full game-engine or VR labs. Export backups rather than depending on browser storage.
https://twinery.org/

Codabench · free benchmark hosting and bounded CPU scoring
Checked October 11, 2026
The public instance allows free participation and competition hosting. Its current announcement provides a shared default CPU queue for small jobs, typically result submissions, capped at 20 minutes per job. Organizers are expected to supply their own queue for code submissions.
Scope: This is the service intended by the user, correcting the earlier CUDA benchmark-suite identification. It is a benchmark/evaluation service, not a general GPU notebook entitlement. Shared-queue capacity, storage and class concurrency were not reserved or tested. Exa/web extracted unrelated text for the homepage; direct live HTML returned the actual Codabench announcement and is saved locally. No security incident is inferred from that extraction anomaly.
https://www.codabench.org/

cuda.live · optional CUDA micro-exercises
Checked October 8, 2026
The independent provider advertises 15 free execution credits per month, a five-runs-per-15-minute rate limit, and T4 GPUs with 16 GB memory. One credit is one execution.
Boundary: Useful for a tightly bounded CUDA demonstration, not a primary semester GPU environment. This is an independent micro-exercise service, not Codabench. No classroom capacity guarantee was verified.
https://cuda.live/pricing

3. Repository changes and continuity

REPOSITORY ACCESS UPDATE | checked October 10, 2026
Research window: October 10, 2021 to October 10, 2026. Original compute claims remain checked October 8. Repository means Git/source-code hosting here, not research data repositories, general drive storage or classroom orchestration.

Finding: documented losses concern free private-team scale, aggregate storage, features and new-customer access. This is not a quantitative decline in the total number of free repositories or a measured loss across the market. GitHub Free remains a viable unlimited-repository route. GitLab Education and public/self-managed exceptions matter. GitLab’s 2022 and 2026 private-user milestones are phases of one limit. The separate 2026 three-group limit is not a three-repository cap.

Discovery: four additional Exa searches requested 20 result slots. Primary source checks used current provider documentation, dated announcements, and UArizona Libraries guidance. No existing institutional Git service, license, backup readiness or pilot capacity was verified. Bitbucket’s dated announcement and storage support page establish the 1 GB aggregate workspace rule even though some pricing pages use inconsistent per-repository wording.

December 28, 2022 · new private groups | GitLab · private teams
New private Free groups are limited to five users across the namespace. A full cohort needs another plan or a qualifying education program.
Boundary: Public groups and qualifying Education/Open Source programs are exempt. This restriction rolled out in stages.
Source: https://about.gitlab.com/blog/efficient-free-tier/

June 17, 2024 | Google source hosting
Google Cloud Source Repositories stops accepting new customers. The five-user, 50 GB free route cannot onboard a new eligible organization.
Boundary: Organizations already using it before the cutoff are unaffected by this access change; no existing-repository shutdown is claimed.
Source: https://cloud.google.com/source-repositories/pricing

May 29, 2025 · revised enforcement date | Bitbucket · storage
Bitbucket caps combined repository storage at 1 GB per Free workspace. Over-limit workspaces become read-only; Downloads and Snippets also leave Free.
Boundary: This is Git storage, not the separate LFS allowance. Paid plans are excluded; special academic-plan terms need checking.
Source: https://www.atlassian.com/blog/bitbucket/important-changes-coming-to-bitbucket-clouds-free-plan

Accounts created after January 27, 2026 | GitLab · new groups
New GitLab Free accounts can create only three top-level groups. Repeated course and cohort namespaces need a different organizational plan.
Boundary: This limits groups, not the number of repositories. Existing accounts are outside this new-account boundary.
Source: https://docs.gitlab.com/user/free_user_limit/

August 15, 2026 · provider’s enforcement schedule | GitLab · remaining rollout
GitLab’s updated notice schedules enforcement on remaining private Free namespaces. Keeping an old class group does not preserve its former allowance.
Boundary: Final stage of the earlier five-user restriction. Public groups, self-managed Free and qualifying education programs remain exempt.
Source: https://about.gitlab.com/blog/efficient-free-tier/

REPOSITORY CONTINUITY PLAN

Proposed repository program, not an existing campus service or completed migration. Start with two courses before scaling to all nine degree programs.

1 · Keep a viable free route
Use GitHub Free for ordinary Git hosting now. Assess an institution-sponsored GitLab for Education application for private class teams and additional features; annual renewal and use restrictions still apply.
Responsibility / timing: Instructor lead + college IT · before the next course

2 · Establish campus ownership
Inventory course repos, sizes, LFS, issues, wikis, artifacts and grading links. Give each course a responsible owner and successor. Keep submissions private; do not make student work public to escape a quota.
Responsibility / timing: Course owner + college IT · weeks 12–10

3 · Pilot a managed fallback
Evaluate a supported campus Git service first. If none fits, pilot Forgejo or self-managed GitLab on an institution-managed host with authentication, private projects, quotas and isolated grading runners. Budget staff, durable storage and recovery separately from compute awards.
Responsibility / timing: College IT + central IT · weeks 10–4

4 · Preserve more than Git
Take versioned nightly Git and LFS backups to independent storage; export issues, wikis, release files and course assessment links through supported paths. Define retention, access and deletion rules. A live mirror can copy deletions and cannot replace a separate backup.
Responsibility / timing: Named service operator · nightly; alert on failures

5 · Prove recovery, then scale
Before teaching, restore a private sample course on a second host and confirm history, LFS, permissions and grading links. Proposed pilot targets: at most 24 hours of data loss and recovery within one business day. Validate these targets before promising them.
Responsibility / timing: Operator + instructor · pre-term and after major changes

6 · Close the teaching cycle
Give students portable code exports, retain institutional assessment records under approved policy, and archive releasable research code/data with Libraries/ReDATA when appropriate. Review storage, restores, licenses and allocation renewal before the next cohort.
Responsibility / timing: Instructor + IT + Libraries · each term

Implementation boundary: Git/code mirrors do not preserve all forge or course metadata. LFS requires its own transfer; backed-up issues or assessment data need a usable export/restore design, not just a downloaded archive. Keep backups independent and versioned. Isolate execution of student grading jobs. ReDATA is for appropriate publicly releasable research outputs, not private submissions or the live course Git server. Retention periods must follow applicable institution policy; no arbitrary universal retention period is prescribed. Proposed 24-hour recovery-point and one-business-day recovery-time targets need a measured rehearsal. Operating infrastructure, storage and staffing need a college/IT commitment beyond time-limited ACCESS/NAIRR awards. No compute, GitLab or campus service request was submitted.

NEW REPOSITORY SOURCE LEDGER

GitLab · five-user private-group limit rollout
Announced March 24, 2022; new groups from December 28, 2022; remaining enforcement August 15, 2026
GitLab’s staged Free SaaS change limits private top-level groups to five users. Its June 18, 2026 update schedules enforcement on all remaining affected namespaces for August 15, 2026.
Boundary: Public groups, self-managed Free and qualifying Education/Open Source programs are exempt. The 2022 and 2026 entries are stages of one restriction, not two vanished services. Earlier proposed rollout dates were revised.
https://about.gitlab.com/blog/efficient-free-tier/

GitLab · current free user and group limits
New-account group boundary: January 27, 2026; checked October 10, 2026
New Free accounts created after January 27, 2026 are limited to three top-level groups. A private Free namespace exceeding five users becomes read-only.
Boundary: Groups are organizational containers, not a three-repository limit. The documentation gives June 13, 2023 for older private groups; the announcement separately documents remaining enforcement in 2026. Avoid a universal one-day rollout claim.
https://docs.gitlab.com/user/free_user_limit/

Bitbucket · free workspace storage and feature reduction
Announced January 27, 2025; enforcement delayed to May 29, 2025
Free workspaces receive a 1 GB aggregate repository storage cap, lose Downloads and Snippets, and have 90-day pipeline-log retention. Over-limit workspaces become read-only.
Boundary: The provider update supersedes the original April 28 date. Paid plans are excluded. Inactive free repositories may be archived, with admin restoration; this is not a blanket deletion announcement. Special academic plans must be checked separately.
https://www.atlassian.com/blog/bitbucket/important-changes-coming-to-bitbucket-clouds-free-plan

Bitbucket · aggregate Git storage versus LFS
Checked October 10, 2026
Current support guidance confirms 1 GB total repository storage across a Free workspace.
Boundary: Git storage is distinct from the LFS allowance. Some pricing/billing pages retain per-repository wording; this deck follows the dated change and current support policy, and advises checking the actual workspace quota.
https://support.atlassian.com/bitbucket-cloud/docs/reduce-repository-size/

Google Cloud Source Repositories · new access withdrawn
Effective June 17, 2024; checked October 10, 2026
Cloud Source Repositories is unavailable to new customers. Its free tier included five project-users and 50 GB of storage; organizations already using it before the cutoff are unaffected by the new-access change.
Boundary: This is loss of a new free-hosting route, not proof that existing repositories were shut down or deleted. Secure Source Manager is a separate product, not assumed to be a free classroom substitute.
https://cloud.google.com/source-repositories/pricing

GitHub · free repositories still available
Checked October 10, 2026
GitHub Free still includes unlimited public and private repositories and collaborators for personal accounts and organizations, with limited private-repository features.
Boundary: Repository count is not unlimited file storage, build time, premium controls or permanent policy. Classroom shutdown is separate. This counterexample prevents an unsupported claim that free repository hosting universally disappeared.
https://docs.github.com/en/get-started/learning-about-github/githubs-plans

GitLab for Education · viable institutional bridge
Checked October 10, 2026
Qualifying institutions can apply for free Ultimate licenses with unlimited seats, for instruction and non-commercial academic research. Licenses last one year with annual renewal and community support.
Boundary: Full-time faculty/staff apply; students do not receive direct institutional licenses. Administrative IT operations are excluded. Eligibility and renewal are conditional; this task verified neither a UArizona license nor an application or deployment.
https://about.gitlab.com/solutions/education/join/

Repository recovery · code and related records
Checked October 10, 2026
A Git mirror clone preserves revision history; Git LFS objects must also be fetched. Wikis and selected metadata require additional export paths.
Boundary: A Git clone is not a complete course-system backup. Migration archives omit some data and have no documented supported GitHub restore. The proposed service must test its own restore path for LFS, issues, permissions, artifacts and assessment links.
https://docs.github.com/en/repositories/archiving-a-github-repository/backing-up-a-repository

Forgejo · candidate managed mirror service
Checked October 10, 2026
Forgejo documents pull and push mirroring of commits, branches and tags, supporting a proposed managed Git continuity layer.
Boundary: A mirror is not an independent backup: deletions can propagate. LFS and non-Git records need separate handling. Hosting, authentication, patching, support and storage cost staff time; no campus installation or capacity has been verified.
https://forgejo.org/docs/latest/user/repo-mirror/

UArizona Libraries · archival code and data
Checked October 10, 2026
Libraries recommend a trusted data repository, such as ReDATA, for citable publicly releasable code/data, while retaining an offline copy. ReDATA integrates with GitHub.
Boundary: A curated research deposit is distinct from live Git hosting and private student submissions. Retention, eligibility and storage are purpose-specific; a compute allocation alone is not a durable archive.
https://lib.arizona.edu/research/data/data-management/best-practices/sharing

4. Library repositories, hosting and databases

LIBRARY, HOSTING AND DATABASE EVIDENCE EXTENSION | checked October 10, 2026
Historical window: October 10, 2021–October 10, 2026. Upcoming OSF November 2026 / February 2027 restrictions are announced future events, not already-effective losses.
Method: 13 Exa discovery searches requested 74 result slots across hosting, databases and current options. Primary provider and institutional pages were read. Library-repository findings from the preceding discussion were reverified. These slots are not independently validated source counts.
Current source ledger: 73 records; 36 added in this extension. The five-slide timeline remains a selected history; the expanded appendix carries the additional evidence without adding slides.

Key boundaries: Existing quotas alone do not prove recent reductions. Dryad fees are a changed model, not loss of universally free publishing. OSF public records persist; its active Projects workflow is being withdrawn. Cloud drive storage is not preservation. ReDATA’s warning is operational, not account withdrawal. Railway now has a smaller Free plan; Fly legacy allowances remain for eligible old organizations. Netlify changed new-account metering but retains free and legacy routes. Firebase’s change concerns object storage and a billing-linked plan, not Firestore/Hosting shutdown. ElephantSQL’s final blackout/deletion date is February 28, 2025, after January EOL.

Neon verification: Exa’s older free-tier indexed page returned 0.5 GB while current pricing/plans returned 1 GB. Direct live retrieval of both docs URLs confirmed 1 GB/project and 20 GB/account total. Use live account/documentation and recheck before term.

Deta Space: excluded from primary-provider-verified additions because the sunset notice is defunct and discovery returned an affected app maintainer’s report.

LIBRARY REPOSITORIES

OSF Projects | Upcoming withdrawal | November 16, 2026 → after February 19, 2027
New project creation stops; existing projects become read-only. Active research collaboration and file-management exercises need a new workspace.
Boundary: Public records remain; preregistration and community preprint services continue. Both effective dates are upcoming as of this audit.
https://www.cos.io/osf-changes

Generalist OSF Preprints | Submission route withdrawn | August 25, 2025; indefinite from October 16, 2025
New submissions to the generalist server stopped, narrowing a scholarly-communication teaching route.
Boundary: Existing papers and revisions remain; community-led preprint servers are excluded.
https://www.cos.io/blog/update-on-future-of-osf-preprints
https://help.osf.io/article/687-osf-preprints-suspension

Dryad | Changed publishing costs | May 6, 2025
Size-based charges make sponsorship and dataset size material to publishing costs; partner coverage generally stops at 10 GB.
Boundary: Dryad was not universally free before this change. Sponsorship and waivers can cover eligible deposits; no campus agreement was verified.
https://datadryad.org/help/requirements/costs

Google education working storage | Storage-policy change | July 2022
Education storage moved to a baseline institutional pool of 100 TB across users and accounts.
Boundary: A shared Drive quota affects preparing deposits and collaboration, not the preservation status of an institutional repository. Campus contract capacity may differ.
https://support.google.com/a/answer/10403871

Microsoft education working storage | Free-plan restriction | February / August 2024 rollout
Free A1 OneDrive users face a 100 GB cap; institutional pooled storage adds a separate constraint.
Boundary: Paid-license additions and contract-renewal timing matter. This is not a 100 GB cap on every UArizona account.
https://www.microsoft.com/en-us/education/products/microsoft-365-storage-options

Figshare and Zenodo | Current limits; no verified cut | Observed October 10, 2026
Figshare offers 20 GB private storage; Zenodo provides a default 50 GB per published record with additional quota options.
Boundary: Useful continuing publication routes. Current limits alone cannot establish a five-year reduction.
https://info.figshare.com/user-guide/account-limits/
https://help.zenodo.org/docs/deposit/manage-quota/

Omeka digital collections | Current limit; no verified cut | Observed October 10, 2026
One free hosted site and 500 MB fit a small metadata/exhibition assignment. Large scans and audiovisual collections need another storage plan.
Boundary: No recent free-plan reduction was verified. Self-hosting moves infrastructure and support responsibility to the institution.
https://info.omeka.net/signup/

Institutional preservation systems | Operating dependency | Observed October 10, 2026
DSpace software is free; managed repository and preservation services fund hosting, maintenance and support through subscriptions.
Boundary: A sustainability dependency, not proof of a recent account cut. Free software and funded preservation are separate commitments.
https://wiki.lyrasis.org/spaces/DSPACE/pages/19006250/User+FAQ
https://lyrasis.org/hosting/

UArizona ReDATA | Availability warning | Posted January 6, 2026; observed October 10
Libraries reports intermittent errors and temporary automated-download restrictions due to high-volume traffic.
Boundary: This is not a closure, account reduction or breach. ReDATA remains a curated public research repository with DOIs.
https://lib.arizona.edu/research/data/redata

UArizona Campus Repository | Surviving institutional route | Observed October 10, 2026
Free-to-campus public deposit of suitable publications, reports, theses and other scholarly materials remains available.
Boundary: Coordinate collections and content suitability with Libraries; private submissions and live apps require other services.
https://lib.arizona.edu/research/share/campus-repository

HOSTING AND DATABASES

Heroku apps + Postgres + Redis | Free tiers withdrawn | November 28, 2022
Free Dynos, Postgres and Redis plans ended; free databases faced deletion.
Boundary: General-purpose teaching infrastructure. Hosting and databases are one provider event; later student credits require separate verification.
https://devcenter.heroku.com/changelog-items/2461

Railway recurring credits | Allowance withdrawn; smaller free plan now | July 3–August 1, 2023
The original recurring $5 monthly Starter allowance became a one-time trial. Railway now offers a $1 monthly Free allowance.
Boundary: Avoid the stale claim that Railway has no free tier today. Current credits still do not guarantee a semester of hosting or databases.
https://blog.railway.com/p/pricing-and-plans-migration-guide-2023
https://docs.railway.com/pricing/plans

PlanetScale Hobby | Free database tier withdrawn | April 8, 2024
The free Hobby plan retired and remaining databases were put to sleep, with a short export wake-up route.
Boundary: PlanetScale continues as a paid service; this is not the closure of all its databases.
https://planetscale.com/changelog/hobby-deprecated

Cyclic app hosting | Service shutdown | Free turn-off began May 10; all usage May 31, 2024
A free full-stack app-hosting route disappeared when Cyclic shut down.
Boundary: Dates describe the provider’s announced staged turn-off; individual deployment or deletion outcomes were not audited.
https://kamlasater.com/blog/cyclic-is-shutting-down/

Render free PostgreSQL | 90 days → 30 days | May 20, 2024, new databases
Free database lifetime shortened by two thirds. The 14-day upgrade grace period follows expiry, then data is deleted.
Boundary: Legacy databases retained their original expiry. Free web hosting survives; a free 30-day database is not a semester solution.
https://render.com/changelog/free-postgresql-instances-now-expire-after-30-days-previously-90
https://render.com/docs/free

Fly.io new organizations | Legacy/new-account boundary | Plans discontinued October 7, 2024; current policy checked October 10, 2026
Old eligible organizations retain free allowances; new organizations receive a short trial and pay for continued billable resources.
Boundary: Do not portray October 2024 as the first removal of every free Hobby signup. Earlier plan changes existed; the current new-account trial lasts at most two runtime hours or seven days.
https://docs.fly.io/about/discontinued-plans
https://docs.fly.io/about/pricing

ElephantSQL managed Postgres | Service shutdown | EOL January 27; final blackout February 28, 2025
After end of life and a staged brownout, the service terminated and its timeline specified deletion of all data.
Boundary: The final data-deletion date is February 28, not January 27. Both free and paid customers were affected.
https://www.elephantsql.com/eol.html

Fauna managed database | Confirmed service shutdown | May 30, 2025
The database service shut down; applications needed a new endpoint and exported data.
Boundary: A whole-service loss affecting free and paid customers, confirmed by the provider status page.
https://docs.fauna.com/fauna/current/eol-faq/
https://fauna.statuspage.io/

Glitch app hosting | Service shutdown | July 8, 2025
Project hosting and user profiles ended. Live student apps and demos needed migration.
Boundary: Code downloads continued through the end of 2025; this did not preserve execution of the apps.
https://blog.glitch.com/post/changes-are-coming-to-glitch

Netlify Free | New-account quota model | September 4, 2025 onward
New Free accounts share 300 monthly credits across deploys, compute and traffic; all web projects pause when credits are exhausted.
Boundary: Free hosting remains. Eligible older accounts can retain legacy plans. The new model is not an equivalent capacity cut for every workload.
https://docs.netlify.com/manage/accounts-and-billing/billing/billing-for-credit-based-plans/how-credits-work

Firebase Cloud Storage | Billing-free access withdrawn | Existing-bucket requirement from February 3, 2026
Access requires a Blaze project linked to Cloud Billing, even when usage fits a no-cost allowance.
Boundary: Object storage, not a shutdown of Firebase Hosting or Firestore. Existing data remains inaccessible until upgrade; overages can cost money.
https://firebase.google.com/docs/storage/faqs-storage-changes-announced-sept-2024

CURRENT FREE OPTIONS (recommendations for bounded coursework; not campus deployment confirmations)
GitHub Pages / Cloudflare Pages
Fit: Static course sites, public exhibits, metadata presentations and browser apps.
Limits: Pages does not run a persistent backend. GitHub published sites are limited to 1 GB; Cloudflare has 20,000 files/site and 25 MiB/asset. Public outputs need appropriate rights.
https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages
https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits
https://developers.cloudflare.com/pages/platform/limits/

Cloudflare Workers + D1
Fit: Lightweight web APIs and small SQLite-style CRUD exercises.
Limits: Workers: 100,000 requests/day and 10 ms CPU/invocation. D1: ten databases/account, 500 MB each, 5 GB total, five million rows read/day and 100,000 written/day. Not PostgreSQL or a long-running analysis server.
https://developers.cloudflare.com/workers/platform/limits/
https://developers.cloudflare.com/d1/platform/limits/
https://developers.cloudflare.com/d1/platform/pricing/

Neon Free
Fit: Small PostgreSQL exercises and intermittent student app backends.
Limits: 100 CU-hours/project/month; 1 GB/project and 20 GB/account total. Scales to zero after five idle minutes. Short recovery history needs independent exports; benchmark full-class concurrency.
https://neon.com/docs/introduction/plans
https://neon.com/pricing

Supabase Free
Fit: Small PostgreSQL + authentication + file/API projects.
Limits: Two active projects; 500 MB database/project and 1 GB file storage. Pauses after a week idle. Export database and uploaded files separately; free managed-backup guarantees must not be assumed.
https://supabase.com/pricing
https://supabase.com/docs/guides/platform/backups

Render Free
Fit: Small Python/Node web demos when cold starts are acceptable.
Limits: Sleeps after 15 minutes idle; 750 service-hours shared per workspace. Ephemeral filesystem. Free Postgres expires in 30 days; use another durable database for a semester project.
https://render.com/docs/free
https://render.com/changelog/free-postgresql-instances-now-expire-after-30-days-previously-90

MongoDB Atlas Free
Fit: Small document-database, metadata and aggregation exercises.
Limits: 0.5 GB includes data and indexes; one Free cluster/project. No managed backups or sharding; pauses after 30 days without connections. Export and rehearse manual restore.
https://www.mongodb.com/docs/atlas/reference/free-shared-limitations/

Netlify Free
Fit: Small static and serverless demos with measured credit consumption.
Limits: 300 credits/month; quota exhaustion pauses all web projects. Legacy account terms differ. Deploy/traffic/compute compete for the same allowance.
https://docs.netlify.com/manage/accounts-and-billing/billing/billing-for-credit-based-plans/how-credits-work

Vercel Hobby
Fit: Eligible personal, non-commercial student web demos.
Limits: Personal-use terms and no paid team collaboration. Execution and usage quotas apply; a college-wide service cannot be assumed eligible.
https://vercel.com/docs/plans/hobby

Railway Free
Fit: Very small metered deployments or an introductory deployment exercise.
Limits: $1 recurring monthly credit is useful but insufficient to promise a full semester or always-on database. Distinguish this from the $5 one-time trial and paid Hobby.
https://docs.railway.com/pricing/plans

PROPOSED SERVICE CONTINUITY PROGRAM

Inventory the whole course stack
For two pilot courses, map compute, live app, database, object files, Git, and archival deposits. Record each owner, account, region, quota, expiry and course requirement. Distinguish public teaching examples from private submissions and research materials.
Owner / timing: Instructor + college IT + Libraries · 12–10 weeks before term

Choose a bounded free route and a funded fallback
Use static hosting where no backend is needed; Neon for small Postgres coursework, Workers/D1 for lightweight SQLite-style apps, or Supabase when integrated auth is part of the exercise. Provision through supported institutional services when available. For persistent multi-user courses, fund managed app/database hosting or an IT-supported environment through the assessment and export period.
Owner / timing: College IT + course lead · 10–8 weeks before term

Separate compute awards from service operations
Request reviewed ACCESS capacity and eligible NAIRR Classroom pilots for instruction and analysis. Separately commit the budget and operator for databases, application availability, durable object storage, identity, backups and renewal. Do not assume a research allocation supports permanent public hosting or preservation; check the awarded resource’s rules.
Owner / timing: College leadership + IT + allocation lead · before committing the course

Make the course portable and recoverable
Keep versioned app source, schema migrations, dependency definitions and synthetic seed data. Export the database and uploaded files independently to institution-approved storage; include metadata, licenses, checksums and necessary access configuration. Protect credentials and define retention with the appropriate institutional owners. A Git mirror or provider snapshot alone does not preserve this whole stack.
Owner / timing: Named service operator · automated backups with failure alerts

Rehearse real class load and a second-host restore
Test simultaneous class use, cold starts, deployment/egress/query quotas, inactivity and expiration handling. Restore an app, database and sample file set onto a second host; verify private access, schema, queries and grading links. Proposed pilot recovery targets remain at most 24 hours of data loss and one business day to restore; measure them before promising them.
Owner / timing: Operator + instructor · 4–2 weeks before term and after major changes

Close and preserve the course deliberately
Offer portable student exports; retain assessment records under approved policy. Coordinate suitable public scholarly deposits with Campus Repository, ReDATA or a disciplinary repository, including metadata and persistent identifiers. Budget stewardship beyond the award period. Recheck vendor terms and test recovery before the next cohort; move active OSF Projects before the announced freeze.
Owner / timing: Instructor + Libraries + IT · end of term and annual review

ADDED SOURCE LEDGER

OSF · announced Projects withdrawal
Announced in 2026; upcoming November 16, 2026 and after February 19, 2027
OSF will stop creation of new projects and child components starting November 16, 2026. After February 19, 2027, public and private projects become read-only. Existing public projects remain accessible and citable; OSF anticipates eventual removal of private projects with 12 months advance notice.
Scope: Future effective dates fall outside the five-year historical window. OSF Registries and community-run preprint workflows continue. This is withdrawal of an active collaboration/file-storage workspace, not immediate deletion of all OSF content. No private-project deletion date is established.
https://www.cos.io/osf-changes

OSF · generalist preprint suspension
October 16, 2025 update
COS made the suspension of new submissions to its generalist preprint server indefinite. Existing preprints remain accessible and can be revised. Community-led services such as SocArXiv and PsyArXiv continue.
Scope: Loss of a generalist submission route, not shutdown of every OSF preprint service or loss of existing papers.
https://www.cos.io/blog/update-on-future-of-osf-preprints

OSF · start of generalist submission suspension
Effective August 25, 2025
The generalist OSF Preprints server suspended new submissions on August 25, 2025. Existing content and revisions continued; community-run servers were excluded.
Scope: August and October notices are stages of one withdrawal, not two separate lost repositories.
https://help.osf.io/article/687-osf-preprints-suspension

Dryad · size-based publishing charges
Fee schedule effective May 6, 2025; vouchers no longer accepted from June 2024
Unsponsored publishing charges are $150 up to 5 GB, $180 up to 10 GB and $520 up to 50 GB. Partner sponsorship covers submissions up to 10 GB; larger submissions incur additional charges under the partner agreement. Any author may request a waiver, but submissions over 10 GB are excluded from waivers.
Scope: A changed funding model and size boundary, not a universal transition from free to paid. Sponsorship and waiver eligibility must be verified for the actual author, journal and institution; no UArizona sponsorship is assumed.
https://datadryad.org/help/requirements/costs

Figshare · current free-account limits
Checked October 10, 2026; no reduction date established
Free figshare.com accounts provide 20 GB of private storage, a 20 GB individual-file limit and a 500-item account limit. Institutional settings may differ; larger publication needs may require Figshare Plus.
Scope: Current capacity limits, not evidence of a recent cut or closure. Public scholarly publication and private collaboration are different uses.
https://info.figshare.com/user-guide/account-limits/

Zenodo · current storage quota
Checked October 10, 2026; no reduction date established
Zenodo documents a default 50 GB quota per record and an additional 150 GB allowance distributable across uploads. Its quota page permits multiple records below the default limit.
Scope: An available research-publication route with limits, not evidence of withdrawal. Appropriate research content, record organization, permissions and preservation needs still matter; this is not private course database hosting.
https://help.zenodo.org/docs/deposit/manage-quota/

Omeka.net · free collection hosting
Checked October 10, 2026; no reduction date established
The free hosted plan includes one site, 500 MB of storage and a limited set of themes and plugins. Larger plans are paid.
Scope: Useful for a small digital-collection or exhibition exercise. Large scans, audio and video can exceed the quota. No recent free-plan reduction was verified; self-hosted Omeka has separate operating costs.
https://info.omeka.net/signup/

UArizona ReDATA · availability warning
Warning dated January 6, 2026; checked October 10, 2026
UArizona Libraries warns of intermittent latency and request errors due to high-volume automated traffic, including forced logouts, occasional saving difficulties and temporary restrictions on automated downloads. ReDATA remains the official public research-materials repository with curated deposits and DOIs.
Scope: An availability/automation incident, not a storage-account cut, repository closure or security breach. A current posted warning does not prove uninterrupted failure since January.
https://lib.arizona.edu/research/data/redata

UArizona · Campus Repository remains free
Checked October 10, 2026
The Campus Repository is free to campus and provides public access to scholarly publications, presentations, reports, theses, dissertations and related materials. Faculty, researchers and departments can establish collections with Libraries.
Scope: A surviving institutional route. Public deposit requires suitable rights and content; this is not a private assignment-submission system or live application backend. No recent reduction was verified.
https://lib.arizona.edu/research/share/campus-repository

Google Workspace Education · pooled storage
Policy effective July 2022
Google moved education subscriptions to pooled storage in July 2022, with a baseline 100 TB shared across users and accounts, including Drive, Gmail and Photos. Additional capacity and institutional allocation settings depend on the subscription.
Scope: A working-storage policy change affecting preparation and collaboration around repositories. It is not a claim that a library repository lost 100 TB or that UArizona currently has this baseline quota.
https://support.google.com/a/answer/10403871

Microsoft Education · pooled storage and A1 cap
A1 cap: February 1, 2024; pooled-storage rollout: contract renewal no earlier than August 1, 2024
Free Office 365 A1 users are capped at 100 GB of OneDrive storage. Education tenants receive 100 TB baseline pooled storage across OneDrive, SharePoint and Exchange, plus capacity for eligible paid licenses and purchased storage. Administrators may assign lower A1 limits.
Scope: The A1 cap does not apply identically to every education license. The institutional pool and any account quota depend on the actual contract. Working storage is not curated long-term repository stewardship.
https://www.microsoft.com/en-us/education/products/microsoft-365-storage-options

DSpace · software and export capabilities
FAQ updated April 10, 2023; checked October 10, 2026
DSpace is freely available under an open-source BSD license. It supports institutional digital objects and export/import of content and metadata through documented formats.
Scope: Free software does not supply free hosting, staff or durable storage. No DSpace free-account reduction was verified. Export formats and restores must be tested against the deployed version.
https://wiki.lyrasis.org/spaces/DSPACE/pages/19006250/User+FAQ

Lyrasis · managed repository and preservation hosting
Checked October 10, 2026
Lyrasis offers managed ArchivesSpace, CollectionSpace, DSpaceDirect and DuraCloud Preserve hosting. Its subscription model funds hosting support and the open-source communities behind these services.
Scope: Evidence of an operating and stewardship cost, not a dated reduction in a previously free hosting entitlement. No campus subscription or service availability was verified.
https://lyrasis.org/hosting/

PlanetScale · free Hobby retired
New Hobby creation stopped March 6, 2024; retirement April 8, 2024
PlanetScale retired Hobby on April 8, 2024 and put remaining Hobby databases to sleep. Users needed to upgrade or wake their database for a 24-hour export window.
Scope: Loss of the former free database plan, not closure of PlanetScale or all its paid databases. No perpetual ability to recover an old database is promised.
https://planetscale.com/changelog/hobby-deprecated

Render · free Postgres shortened
Effective May 20, 2024 for newly created free databases
New free Render PostgreSQL databases expire after 30 days, down from 90. Databases created before the change retained their original expiry date. A 14-day upgrade grace period follows expiry before deletion.
Scope: An explicit duration reduction affecting new free databases. A 30-day database cannot cover a normal semester without migration or paid continuation. It does not establish that free web hosting ended.
https://render.com/changelog/free-postgresql-instances-now-expire-after-30-days-previously-90

Render · current free hosting and database limits
Checked October 10, 2026
Free web services spin down after 15 minutes without inbound traffic and share 750 running instance-hours per workspace per month. Their filesystem is ephemeral. Free Postgres has 1 GB storage, one active database per workspace, 30-day expiry and no provider backups. Free Key Value is in-memory and loses data on restart.
Scope: Current limits must be separated from the dated Postgres reduction. Persistent assessment data must not live solely on a web filesystem or free in-memory store. Quota exhaustion can suspend services; bandwidth/build overages depend on payment and spend settings.
https://render.com/docs/free

ElephantSQL · service end of life and deletion
No new signups May 1, 2024; EOL January 27, 2025; blackout February 28, 2025
ElephantSQL stopped new signups, reached EOL January 27, 2025, then entered a staged brownout. Its customer timeline sets February 28, 2025 as final termination and deletion of all data.
Scope: Full service withdrawal affecting free and paid usage. January 27 is not the final deletion date; the staged dates must not be collapsed. PostgreSQL elsewhere remains available.
https://www.elephantsql.com/eol.html

Fauna · service shutdown and account deletion
Effective May 30, 2025, noon Pacific
Fauna announced shutdown of the managed database service at noon Pacific on May 30, 2025. Customers had to migrate applications and export data; the FAQ stated accounts and associated data would be permanently deleted afterward.
Scope: Historical provider FAQ read through Exa’s indexed copy; its original URL no longer resolves on a direct check. The separate live provider status record confirms shutdown. This was a full managed-service withdrawal, including Free, not merely a plan cut; announced deletion was not independently audited.
https://docs.fauna.com/fauna/current/eol-faq/

Fauna · shutdown confirmed by service status
May 30, 2025, 12:02 Pacific update
The provider status page confirmed the service was shut down on May 30, 2025. Its preceding notices said unmigrated applications would cease functioning and no extension was available.
Scope: Corroborates the effective shutdown instead of treating an announcement alone as execution.
https://fauna.statuspage.io/

Fly.io · legacy allowances retained for old organizations
Plans deprecated October 7, 2024; checked October 10, 2026
Fly.io discontinued its old plans for new customers and retained their included free allowances for eligible existing organizations. Those allowances included up to three 256 MB shared-CPU VMs and 3 GB persistent volumes. Existing Legacy Free Hobby has no subscription fee, subject to its terms.
Scope: The October date is the documented discontinued-plan boundary, not proof that every new user had free Hobby until that day. Older changes had already introduced paid Hobby. Do not claim all legacy allowances were revoked.
https://docs.fly.io/about/discontinued-plans

Fly.io · current new-account trial
Checked October 10, 2026; current trial effective date not established
New organizations have no recurring free hosting tier or monthly free compute allowance. A card-free trial lasts at most two hours of Machine runtime or seven days, whichever comes first; continued billable resources require a card. Some ancillary allowances remain free.
Scope: A current trial is not semester infrastructure. Eligible legacy organizations retain documented allowances; this is not a provider shutdown or evidence that every resource is charged.
https://docs.fly.io/about/pricing

Railway · original recurring credits withdrawn
Announced June 2, 2023; rollout July 3–August 1, 2023
Railway replaced its former recurring $5 monthly Starter credits with a one-time $5 trial grant and introduced a $5/month Hobby subscription with included usage. Some qualified existing users received subscription-fee waivers.
Scope: Historical change, not the current entire product. Railway now documents a smaller recurring Free plan; do not claim it has no free tier today.
https://blog.railway.com/p/pricing-and-plans-migration-guide-2023

Railway · current smaller Free plan
Checked October 10, 2026; reintroduction date not established
Railway now offers Free at $0/month with $1 monthly usage credit for small apps, alongside a one-time $5 trial and paid Hobby/Pro. Hobby is $5/month even when resource use is lower than its included $5.
Scope: A counterexample to permanent disappearance of all free usage. A dollar of metered usage is not a promised number of class hours, persistent database capacity or guaranteed course availability. Billing and data-retention terms need checking before deployment.
https://docs.railway.com/pricing/plans

Cyclic · hosting shutdown
Announced April 26, 2024; free usage shutdown began May 10; all usage May 31, 2024
Cyclic disabled new signups immediately and announced it would begin turning off free-tier usage May 10, 2024 and all usage May 31. The provider attributed closure to insufficient sales to sustain the service.
Scope: A general application-hosting shutdown, not an education-account policy. The original provider URL now fails certificate verification; the same dated notice remains on its author’s site. Dates describe the announced staged turn-off; no individual student deployment or data-deletion outcome was inspected.
https://kamlasater.com/blog/cyclic-is-shutting-down/

Netlify · new-account credit model
New accounts from September 4, 2025; checked October 10, 2026
New accounts use credit-based plans. Free receives 300 credits per month with a hard limit; when credits run out, all web projects on the account pause. Existing eligible pre-September 4, 2025 accounts can retain legacy plans.
Scope: A changed quota model, not a universal removal of free hosting or a measured capacity reduction for every workload. Credit consumption depends on deploys, compute and traffic; old allowances must not be compared with credits as interchangeable units.
https://docs.netlify.com/manage/accounts-and-billing/billing/billing-for-credit-based-plans/how-credits-work

Firebase Cloud Storage · billing required
Announced September 2024; existing-bucket access requirement from February 3, 2026
Cloud Storage for Firebase requires a Blaze pay-as-you-go project linked to Cloud Billing, including access to legacy default buckets from February 3, 2026. Without upgrade, users lose read/write and console access; existing bucket data remains. No-cost usage still exists on Blaze.
Scope: Object/file storage, not Firestore database or Firebase Hosting shutdown. Loss of a billing-free access path is different from all usage becoming paid. This current FAQ supersedes older documentation carrying earlier planned deadlines.
https://firebase.google.com/docs/storage/faqs-storage-changes-announced-sept-2024

Cloudflare Pages · free static hosting limits
Checked October 10, 2026
Free Pages sites can contain up to 20,000 files with a maximum 25 MiB per asset. Pages Functions consume Workers quota and have separate execution constraints.
Scope: A surviving route for static exhibits and course sites; static hosting does not itself supply a database, general persistent server or archival storage. No recent reduction is claimed.
https://developers.cloudflare.com/pages/platform/limits/

Cloudflare Workers · free execution limits
Checked October 10, 2026
Workers Free provides 100,000 requests per day and a 10 ms CPU-time limit per invocation. Exceeding the daily quota can return an error. Static-asset requests and other product quotas have separate rules.
Scope: Suitable for lightweight APIs and request handling within limits, not long CPU analyses or arbitrary always-on application servers. CPU time is not elapsed request time.
https://developers.cloudflare.com/workers/platform/limits/

Cloudflare D1 · free database limits
Documentation updated April 21, 2026; checked October 10, 2026
D1 Free supports ten databases per account, 500 MB per database, 5 GB aggregate storage and seven days of Time Travel recovery.
Scope: Small SQLite-style web databases. SQL dialect, API, per-query limits and platform integration differ from PostgreSQL/MySQL and are not a drop-in replacement for every database course. Recovery windows do not replace independent exports.
https://developers.cloudflare.com/d1/platform/limits/

Cloudflare D1 · free daily query allowance
Documentation updated April 21, 2026; checked October 10, 2026
Workers Free includes five million rows read per day and 100,000 rows written per day for D1, with 5 GB total database storage. Rows scanned count even if a query returns fewer rows.
Scope: Allowance units are rows, not SQL requests or students. Full-table scans can exhaust a class budget faster than indexed queries. No recent cut was verified.
https://developers.cloudflare.com/d1/platform/pricing/

Neon · current free Postgres plan
Direct live provider page checked October 10, 2026
The live plan table provides 100 projects, 100 CU-hours per project monthly, 1 GB storage per project and 20 GB aggregate account storage. Free compute scales to zero after five idle minutes; recovery history is limited to six hours and a data-change allowance.
Scope: A viable small PostgreSQL teaching route with a compute and storage ceiling, not guaranteed always-on capacity. An indexed older free-tier URL returned 0.5 GB, but direct live retrieval of both URLs confirmed 1 GB and the 20 GB total. Recheck the actual account before class; a short history window is not semester backup.
https://neon.com/docs/introduction/plans

Neon · current free plan pricing corroboration
Checked October 10, 2026
Neon lists Free at $0, 100 CU-hours per project and 1 GB database storage per project, with scale to zero. Paid plans meter usage separately.
Scope: Corroborates the current per-project allowance. Use the plan documentation for the 20 GB aggregate account boundary. Do not use a cached older quota as evidence of a new reduction.
https://neon.com/pricing

Supabase · current free backend plan
Checked October 10, 2026
Free includes a 500 MB database per project, 1 GB file storage and two active projects. Free projects pause after one week of inactivity; other API, egress, authentication and function limits apply.
Scope: Useful for small course apps that teach PostgreSQL, auth and backend APIs. Shared organization quotas and inactivity pauses constrain full-class provision and between-term continuity. No recent database free-tier removal is established.
https://supabase.com/pricing

Supabase · free backups and file-storage boundary
Checked October 10, 2026
Automatic daily backups are documented for Pro, Team and Enterprise. Supabase recommends regular database exports and off-site backups for Free projects. Database backups exclude the actual objects stored through the Storage API.
Scope: A database dump does not preserve uploaded images, documents or media; export objects separately. No hosted backup or restoration was performed in this research.
https://supabase.com/docs/guides/platform/backups

MongoDB Atlas · current free document database
Checked October 10, 2026
Atlas Free supports one cluster per project and 0.5 GB of data plus indexes. It has no managed backups, limits operations and connections, and automatically pauses after 30 days with no connections. MongoDB documents manual dump/restore as an alternative.
Scope: Suitable for small document-database exercises, not sharding, full administration, realistic high-load benchmarks or durable records without separate recovery. Free remains available; no recent withdrawal is claimed.
https://www.mongodb.com/docs/atlas/reference/free-shared-limitations/

Vercel · personal Hobby hosting limits
Checked October 10, 2026
Hobby remains free for personal, non-commercial use. It lacks paid team collaboration and has resource quotas; exceeding most allowances requires waiting up to 30 days. Functions and platform services have execution limits.
Scope: Suitable for eligible personal student demos; an institution-wide course service or team deployment cannot be assumed eligible under personal-use terms. No recent free-plan withdrawal was verified.
https://vercel.com/docs/plans/hobby

SOURCE ACCESS NOTES

The former Fauna documentation hostname no longer resolves; its indexed provider FAQ was reviewed and the still-live provider status page confirms shutdown.
The Cyclic provider URL fails certificate verification; the same notice is linked on its author’s live site.
Direct automated checks were blocked for Figshare, Microsoft, DSpace and Lyrasis (403) and reset for Omeka; primary-page contents were read through Exa.
Neon’s stale indexed 0.5 GB page was corrected against direct live documentation showing 1 GB/project and 20 GB/account.

5. Codabench and classroom platforms

CODABENCH CORRECTION AND CLASSROOM RESOURCE REPORT | checked October 11, 2026
Method: 10 successful Exa discovery queries requested 60 result slots in three search passes. Initial schema-rejected calls returned no sources and are excluded. Primary documentation and direct live content were checked; dynamic Lightning pricing was rendered in a browser. Discovery slots are not independent verified sources. No accounts, classes, payments or workers were provisioned. Original October 8/10 policies not all reverified.

Decision: Codabench and Kaggle Community Competitions are the closest verified free benchmark routes; CodeGrade is a bounded teaching/autograding alternative. EvalAI hosted plans are paid; ChaGrade remains a work-in-progress candidate without verified entitlement. CodaLab Competitions is retired, with a free successor and incomplete leaderboard migration. Development, short inference, evaluation and durable hosting are distinct layers.

Codabench | Free benchmark hosting; compute depends on queue
Fit: Prediction scoring, reproducible code benchmarks and common test environments.
Boundary: Shared CPU scoring jobs ≤20 minutes. Organizers supply queues for code submissions and all GPU workers; no GPU notebook or whole-class reservation.
https://www.codabench.org/
https://docs.codabench.org/latest/Organizers/Running_a_benchmark/Compute-Worker-Management---Setup/
https://docs.codabench.org/latest/Organizers/Running_a_benchmark/Queue-Management/

Kaggle Community Competitions | Free self-service hosts and participants
Fit: Prediction-file competitions with live leaderboards; judged hackathons for open-ended projects.
Boundary: Training happens elsewhere or in separately limited notebooks. Restricted-email competitions disable notebooks by default; community hosting has no hands-on support.
https://www.kaggle.com/c/about/community
https://www.kaggle.com/docs/competitions-setup

CodeGrade | Advertised free for courses ≤50 students
Fit: Programming labs with browser editing, immediate autograding and instructor feedback.
Boundary: Check free-plan execution/LMS limits and roster scope. No verified free GPU entitlement or campus deployment; grading records need approved retention.
https://www.codegrade.com/landing/free

ChaGrade | Adjacent project; current free entitlement unverified
Fit: Challenge-linked individual/team homework and instructor grading beyond leaderboard scores.
Boundary: Live page labels version 0.1 / Work In Progress. Support, quotas and current Codabench integration need verification; not a ready college-wide baseline.
https://chagrade.lri.fr/

EvalAI | Hosted service paid; open-source self-hosting
Fit: Custom prediction/code evaluation and organizer-controlled remote workers.
Boundary: Hosted plans $125–850/month; remote evaluation $100/month plus own compute. Self-hosting requires funded staff, infrastructure and storage. No verified hosted free tier.
https://evalai.readthedocs.io/en/latest/01-getting-started/pricing.html
https://github.com/Cloud-CV/EvalAI

CodaLab Competitions | Retired at end of 2025; successor available
Fit: Historical challenge service; migrate compatible competition bundles to Codabench.
Boundary: New account required; leaderboards do not transfer automatically. Preserve submissions/results separately. Separate CodaLab Worksheets is not covered.
https://docs.codabench.org/latest/Newsletters_Archive/CodaLab-in-2025/
https://docs.codabench.org/latest/Organizers/Benchmark_Creation/How-to-transition-from-CodaLab-to-Codabench/

GitHub Codespaces | Bounded free personal CPU quotas
Fit: Reproducible Python/R/SQL labs, small analysis and code development before submission.
Boundary: 60 two-core hours/month, or 90 for verified students; storage quota and machine sizes matter. No generally available GPU; not continuous application hosting.
https://docs.github.com/en/billing/concepts/product-billing/github-codespaces
https://docs.github.com/en/education/about-github-education/github-education-for-students/about-github-education-for-students
https://docs.github.com/en/codespaces/developing-in-a-codespace/getting-started-with-github-codespaces-for-machine-learning

Kaggle Notebooks | Free accelerator notebooks; quota varies
Fit: Checkpointed small-model GPU experiments and training for a competition.
Boundary: Check each account’s GPU quota, available hardware, session timer and saved disk. No reserved class seats or distributed/long-running training promise.
https://www.kaggle.com/docs/notebooks
https://www.kaggle.com/product-feedback/173129

Free Google Colab | Base free tier remains available
Fit: Short shared notebooks, CPU analysis and opportunistic accelerator exercises.
Boundary: GPU access and resource/session limits fluctuate. Free Colab is separate from the closed new-signup education Pro offer; never promise class GPU availability.
https://research.google.com/colaboratory/faq.html

mybinder.org | Free ephemeral CPU sessions
Fit: Small Python/R notebooks launched from a reproducible repository, including metadata/text workshops.
Boundary: 1–2 GB RAM; ten-minute idle shutdown; aims for ≤6 hours or one CPU-hour; 100 concurrent sessions per repo. Download work; no GPU or persistent workspace promise.
https://mybinder.readthedocs.io/en/latest/about/user-guidelines.html

Lightning AI Studio | Free CPU studio; conditional introductory GPU credits
Fit: Browser development, small pilot experiments and checkpointed training within actual credit balance.
Boundary: Four-hour free restart boundary; five credits at signup, 25 more with a card, not a fixed monthly grant. Ten GB free storage; rates/machine size and stopping/billing behavior need checking.
https://lightning.ai/pricing/
https://lightning.ai/docs/platform/overview/faq/billing.md

Hugging Face ZeroGPU / Spaces | Five GPU minutes/day for signed-in Free users
Fit: Short Gradio inference demos and model-behavior comparisons; static exhibits on free Static Spaces.
Boundary: Two own ZeroGPU Spaces only for eligible personal accounts ≥30 days old. Shared queues and Gradio constraints; organization hosting paid. Ordinary compute-backed Space creation also needs a paid plan.
https://huggingface.co/docs/hub/spaces-zerogpu
https://huggingface.co/docs/hub/spaces-overview

cuda.live | 15 executions/month; bounded CUDA exercises
Fit: Tiny CUDA kernel/compiler demonstrations independent of the Codabench workflow.
Boundary: Advertised T4 16 GB, five runs per 15 minutes; per-execution allowance is not GPU-hours. Existing October 8 verification, no reserved class capacity.
https://cuda.live/pricing

DEGREE-SPECIFIC SUPPLEMENTARY ROUTES (assignment-level assessment)
BS Information Science
Codabench / Kaggle competitions for small prediction benchmarks; Binder for short CPU labs; CodeGrade for ≤50-student coding labs.

MS Data Science
Codabench / Kaggle competitions for model evaluation; Lightning for credit-bounded pilots; ZeroGPU for brief inference demos.

MS Information Science
Codabench / Kaggle competitions for ML; ZeroGPU for HCC model demos; CodeGrade for small programming labs.

BA Emerging Technologies in Society
Binder for short public-text analysis; CodeGrade for small coding labs; Kaggle hackathons for judged public-data projects.

BA Game Design
Kaggle hackathons for judged prototypes; CodeGrade for small scripting labs. Neither supplies a 3D engine, XR device or game server.

BS Game Development
CodeGrade for small code/test labs; Codabench only for bounded custom-scored agents with supplied workers. Heavy engine builds remain elsewhere.

BA Information Science & Arts
ZeroGPU for brief AI behavior demos; Kaggle hackathons for judged creative projects. Rendering/XR work still needs appropriate hardware.

MA Library & Information Science
Binder for metadata/text workshops; Codabench / Kaggle competitions for retrieval or classification metrics. Archives/ILS require durable systems.

PhD Information
Codabench / EvalAI for research evaluation; Binder for reproducible methods; Lightning for small pilots. Sustained research compute requires an allocation.

PROPOSED BENCHMARK PILOT

Pilot a permitted Codabench evaluation queue backed by reviewed ACCESS capacity; isolated workers, scheduling, operations, storage, backups and grade exports remain separate requirements. Develop in bounded notebooks; submit predictions or packaged code; score on a permitted queue; preserve code, environments, scoring bundles, submissions, leaderboard results and grade exports independently. Rehearse full-class concurrency and restore on a second host before term.

CURRENT RESOURCE SOURCE LEDGER

Codabench · free benchmark hosting and bounded CPU scoring
Checked October 11, 2026
The public instance allows free participation and competition hosting. Its current announcement provides a shared default CPU queue for small jobs, typically result submissions, capped at 20 minutes per job. Organizers are expected to supply their own queue for code submissions.
Scope: This is the service intended by the user, correcting the earlier CUDA benchmark-suite identification. It is a benchmark/evaluation service, not a general GPU notebook entitlement. Shared-queue capacity, storage and class concurrency were not reserved or tested. Exa/web extracted unrelated text for the homepage; direct live HTML returned the actual Codabench announcement and is saved locally. No security incident is inferred from that extraction anomaly.
https://www.codabench.org/

Codabench · organizer-supplied CPU / GPU workers
Checked October 11, 2026
Organizers can attach physical or virtual machines as compute workers. CPU and GPU worker setup is documented; GPU workers require suitable hardware, NVIDIA support and a compatible competition image.
Scope: GPU support is an integration capability, not a free GPU allocation. Hosting, worker operations, data, isolation and resource limits need separately funded/approved compute. An ACCESS-backed queue is a proposed design, subject to resource, networking and container policies.
https://docs.codabench.org/latest/Organizers/Running_a_benchmark/Compute-Worker-Management---Setup/

Codabench · shared and dedicated queues
Checked October 11, 2026
Queues dispatch submissions between competitions and internal/external workers. Organizers can create queues, control public access and add collaborators; multiple workers can serve a queue.
Scope: A queue does not create CPU/GPU capacity. Class concurrency and deadline bursts require a tested worker pool. Protect broker credentials and use an appropriately isolated submission environment.
https://docs.codabench.org/latest/Organizers/Running_a_benchmark/Queue-Management/

Codabench · CodaLab migration boundaries
Checked October 11, 2026
Codabench is the maintained successor to CodaLab Competitions. Sign-up is free; old competition bundles are compatible. Migration requires a new account and export/re-upload of the competition bundle. Leaderboard results do not transfer automatically; submissions must be re-submitted.
Scope: Compatible software is not complete preservation of course history. Export submissions, results and grading records independently; do not promise recovery from an already phased-out service.
https://docs.codabench.org/latest/Organizers/Benchmark_Creation/How-to-transition-from-CodaLab-to-Codabench/

CodaLab Competitions · phased out in 2025
End of 2025; project retrospective checked October 11, 2026
The project’s 2025 retrospective states that CodaLab Competitions and its main servers were phased out at the end of 2025 and development/community activity moved to Codabench.
Scope: A confirmed project-reported platform transition, not disappearance of all free benchmarking. No exact final day or deletion of every archive is established. CodaLab Worksheets is a separate service and is not covered by this finding.
https://docs.codabench.org/latest/Newsletters_Archive/CodaLab-in-2025/

Kaggle · no-cost Community Competitions
Checked October 11, 2026
Kaggle offers self-service Community Competitions with no cost to hosts or participants, dataset hosting, live leaderboards and automated prediction scoring. Educators are explicitly eligible to host.
Scope: Competition scoring is not an allocation for arbitrary training or sustained GPU work. Participants develop locally or in separately quota-limited notebooks. Community hosting has no hands-on support; featured/managed competitions have different terms.
https://www.kaggle.com/c/about/community

Kaggle · competition access and notebook limits
Checked October 11, 2026
Prediction competitions score answer files; hackathon competitions use judges for open-ended work. Hosts can select public/private visibility and link or email-based access. Restricted-email competitions disable notebooks by default to prevent data leaks.
Scope: Invite/private settings must be rehearsed. Do not assume a locked class competition also supplies usable notebook GPUs. A leaderboard score is not a complete course assessment; use approved data and follow account rules.
https://www.kaggle.com/docs/competitions-setup

EvalAI · paid hosted challenge plans
Checked October 11, 2026
Current hosted plans are monthly subscriptions: Essentials $125, Core $250, Advanced $850, and Remote Evaluation $100 with organizer-supplied compute. Hosted worker plans include one concurrent evaluation; extra workers are billed separately.
Scope: A functional analogue to Codabench, but not a verified free hosted classroom route. Remote evaluation still carries a hosting fee and compute costs. No historical free-tier withdrawal date is established; these are current prices, not a new dated loss.
https://evalai.readthedocs.io/en/latest/01-getting-started/pricing.html

EvalAI · open-source self-hosting
Checked October 11, 2026
The official open-source project supports customized challenge evaluation, remote workers and local Docker deployment.
Scope: Open-source availability does not provide free operated hosting or GPUs. A self-hosted pilot needs an operator, service host, storage, worker isolation, backups and actual license/deployment review.
https://github.com/Cloud-CV/EvalAI

Binder · free ephemeral teaching notebooks
Checked October 11, 2026
mybinder.org provides at least 1 GB RAM, up to 2 GB; exceeding 2 GB restarts the kernel. Sessions shut down after ten idle minutes and aim for up to six hours or one CPU-hour of intensive work. The default per-repository concurrent-user cap is 100; larger events can request an increase without a guarantee.
Scope: Useful for short reproducible Python/R demonstrations and small-data workshops; not persistent files, reserved capacity, a GPU entitlement, long training or controlled-data teaching. Download work before the session ends. A funded BinderHub/JupyterHub is the capacity route if this is insufficient.
https://mybinder.readthedocs.io/en/latest/about/user-guidelines.html

Lightning AI · current introductory credits and restart boundary
Checked October 11, 2026
The live rendered Free plan provides one active free Studio with four-hour restarts. The FAQ offers five introductory credits at registration and 25 more after adding a card, expiring after 12 months. GPU-hour marketing varies by machine/rate and is not a fixed recurring monthly allowance.
Scope: A conditional development/pilot route. Do not repeat older indexed claims of 15 monthly credits or promise 80 GPU hours to every student. The pricing UI warns that free Studios become paid after four hours; confirm current stopping/billing behavior and use checkpoints. No paid signup or account provisioning was performed.
https://lightning.ai/pricing/

Lightning AI · billing and storage scope
Checked October 11, 2026
Official billing documentation describes one free CPU Studio, promotional non-accumulating credits, and ten GB of free Drive storage. The Free storage ceiling is 50 GB, but storage above ten GB is billed; non-free machines also consume credits.
Scope: The billing text mentions four-CPU while the rendered pricing UI advertises 32-core CPU Studios. Treat machine size as account-specific and verify before adoption. A 50 GB total cap is not 50 GB free storage. Free credit rules can change; no recurring monthly grant is verified.
https://lightning.ai/docs/platform/overview/faq/billing.md

Hugging Face ZeroGPU · short shared GPU demos
Checked October 11, 2026
Existing ZeroGPU Spaces can be used free. Signed-in Free users receive five GPU minutes per daily quota, resetting 24 hours after first use. Free personal accounts with verified email, older than 30 days and in good standing can host up to two ZeroGPU Spaces. Hosting supports Gradio; organization hosting requires a Team or Enterprise plan.
Scope: For short inference/model-behavior demonstrations, not full notebook training, dedicated GPUs or a semester service reservation. Queue priorities vary. Larger GPU sizing consumes quota faster. This current policy supersedes older descriptions that required PRO for every personal host.
https://huggingface.co/docs/hub/spaces-zerogpu

Hugging Face Spaces · current creation and persistence boundaries
Checked October 11, 2026
Static Spaces are free. Creating ordinary compute-backed Gradio/Docker Spaces now requires PRO for personal accounts or Team/Enterprise for organizations, except eligible personal ZeroGPU Spaces. CPU Basic has no hourly compute cost, but creation can require a paid plan. Default disk is nonpersistent, and idle free hardware sleeps.
Scope: Do not describe every CPU demo host as a free account route merely because its hourly rate is zero. Static pages run on the visitor device; ZeroGPU is a special bounded exception. No effective date of a creation-policy change is established here.
https://huggingface.co/docs/hub/spaces-overview

CodeGrade · bounded free classroom autograding
Checked October 11, 2026
The provider advertises a free tier for courses up to 50 students, without a card or expiration, including a browser code editor, automated grading, inline feedback and plagiarism detection across 175+ languages.
Scope: A teaching/assessment analogue, not a GPU notebook or a proven replacement for all GitHub Classroom automation. Verify actual free-plan account scope, execution quotas, LMS features, data handling and roster growth before adoption. No UArizona integration or deployment was tested.
https://www.codegrade.com/landing/free

ChaGrade · challenge-linked classroom workflow
Checked October 11, 2026
The project’s live page offers class creation and grading attached to challenges, individual/team homework and questions beyond challenge performance. It labels the service Work In Progress, version 0.1, and links its open-source project.
Scope: A relevant adjacent workflow to inspect, not a verified production-ready free entitlement. Current support, terms, quotas and Codabench integration were not established; public signup buttons do not prove those properties. Do not promise it as the college grading baseline.
https://chagrade.lri.fr/

6. Federal platforms and products

FEDERALLY SUPPORTED COMPUTING MAP | checked October 12, 2026
Selected map: 32 platform/service/funding families; six named IDSS projects; eight missing categories. Current total source ledger: 130 records, adding 42 primary source records. Method: 34 Exa discovery queries requested 179 result slots across six research areas; these slots are not independent verified source counts. Targeted direct-live checks confirm core funding/cost distinctions. Earlier commercial-platform records were not all reverified. No accounts, allocations, API calls, cloud charges or grant submissions were made; no private MESA proposal/staff plan was published.

SYNTHESIS

The relevant ecosystem is a stack: public investment and grants; access programs and providers; teaching/application environments; data/metadata/workflows; object storage and delivery; identity, support, operations and preservation. Federal funding is not synonymous with all services being free, ready for a class, wholly federally financed or permanent. ACCESS providers, NRP/Nautilus and OSG/OSPool/OSDF must not be summed as independent capacity.

Many small jobs, not one big notebook
Add OSPool/PATh and checkpointed workflow execution for corpus processing, parameter sweeps and independent model evaluation.

Managed teaching environments
Map CloudBank Classroom, Jetstream2 course images, NRP hubs and eligible CyVerse apps separately from raw GPU allocations.

Inference as an API
NRP-hosted model APIs and requested NAIRR model/software access can support assignments without every student operating a GPU server.

Data-first services
MESA, NDP, FabAID, iDLab, BRIDGE and NSDF supply discovery, metadata, reusable workflows and cross-site access; their grants are not all compute accounts.

Object storage, caches and movement
OSN stores active data; OSDF/Pelican distributes it; Globus moves it. None automatically provides archive permanence or all operating costs.

Systems, networks and specialized hardware
Chameleon, CloudLab and FABRIC support systems/edge/distributed experiments and specialized hardware. Use only when the testbed purpose matches.

Campus delivery and staff funding
Open OnDemand, gateways, identity, orchestration, grant-funded facilitators and college operators make allocations teachable. Compute awards alone do not fund all of them.

Domain facilities and mixed funding
DOE, NASA and NIH add mission-specific routes. CC*/MRI can fund campus capability; AI Hubs and CyVerse/UArizona show why state, subscription and federal support need separate labels.

PRACTICAL UARIZONA ROUTING (assessment, not adoption)
1. Compare Jetstream2, CloudBank Classroom and NRP for managed teaching environments.
2. Verify state TRIF-funded CyVerse Pro eligibility, actual account tier, class/workshop terms and GPU availability.
3. Consult OSPool/PATh for many independent checkpointed jobs; MESA research funding makes PATh consultation relevant but grants no automatic credit award.
4. Connect data/metadata learning with MESA and other IDSS projects; use OSN/OSDF where active data delivery is the need.
5. Use specialist testbeds/facilities only where systems/network/domain requirements match.
6. Fund the human/service layer: course images, login/rosters, grading exports, support owner, cost/renewal monitoring, independent backups and library preservation. Pilot two courses before scaling.

IMPORTANT BOUNDARIES

IDSS is Integrated Data Systems and Services, an operator grant program. Its 2026 awards include MESA; computing access remains subject to the actual services. CyVerse says its core NSF awards ended in 2024, and Basic sharing/public links ended June 3, 2025; published UArizona Pro access is TRIF/state-funded. CILogon transitioned to subscription-funded operations in 2019. NSF AI Infrastructure Hubs pay coordination/workforce/course development while partners finance compute. NIH AnVIL platform browsing is free but execution/storage/egress can cost money; it differs from Purdue ACCESS Anvil. CC*/MRI/SCIPE/CyberTraining are funding pathways, not current accounts or verified open calls. CloudBank GPU class capacity and IDSS production service guarantees were not established.

PLATFORM MAP

ACCESS | Allocation and support federation | Documented service; approval/limits apply
Funding: NSF-funded coordination + separately funded resource providers
Entry: ACCESS project request; exchange credits for provider resources
Fit: Broad CPU/GPU research and instruction; resource discovery and support.
Boundary: Provider quotas, scheduling, allocation term and software vary. Counts overlap with participating resource providers.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://access-ci.org/get-started/for-ci-community/

OSG Open Science Pool (OSPool) | Opportunistic distributed throughput pool | Documented service; approval/limits apply
Funding: NSF PATh/IRIS-HEP + institutional/DOE in-kind contributions
Entry: OSG Portal / facilitated access point
Fit: Independent text/image analyses, parameter sweeps, model evaluation and many short CPU/GPU jobs.
Boundary: Interruptible fair share; complete/checkpoint jobs within 20 hours. Educational project fit needs facilitation; no classroom GPU reservation.
Relationship: OSG consortium / PATh services
https://osg-htc.org/about/introduction/
https://osg-htc.org/services/ospool/

PATh Facility | Dedicated credit-based throughput pool | Documented service; approval/limits apply
Funding: NSF PATh
Entry: Consult PATh; NSF-funded project startup/credit process
Fit: Larger HTC research jobs and reliable resource profiles; relevant to MESA-funded work.
Boundary: NSF research scope/credits required. Different from free fair-share OSPool; consultation is not automatic authorization.
Relationship: PATh / also participates in NAIRR
https://portal.path-cc.io/documentation/overview/references/PATh_vs_OSPool/

NRP / Nautilus | Shared GPU/cloud services | Documented service; approval/limits apply
Funding: NSF-supported platform + participating institutions
Entry: Institutional onboarding; hosted JupyterHub, API or project namespace
Fit: Hosted teaching notebooks, GPUs, open-weight model APIs and containerized services.
Boundary: Shared capacity, account policies and operator responsibilities; Nautilus is the NRP cluster, not a separate pool.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://nrp.ai/
https://nrp.ai/documentation/userdocs/ai/llm-managed

Jetstream2 | ACCESS resource provider / VM cloud | Documented service; approval/limits apply
Funding: NSF research-cloud infrastructure
Entry: ACCESS allocation, course images and student/project access
Fit: Notebooks, RStudio, desktops, web/database teaching servers and vGPU environments.
Boundary: Budget credits for always-on instances, term duration, data backup and GPU demand. Not permanent institutional hosting.
Relationship: ACCESS resource provider
https://docs.jetstream-cloud.org/tutorial/classroom/overview/
https://docs.jetstream-cloud.org/overview/overview-doc/

NAIRR / NAIRR Classroom | AI resource access program | Documented service; approval/limits apply
Funding: NSF-led federal partnership + public/private contributions
Entry: Appropriate researcher or Classroom request
Fit: AI coursework, GPUs, model/data/tools and selected managed environments.
Boundary: US-based class eligibility and approved resources; instructor/TA support expected. Research and Classroom requests differ; partner offerings are not all federally purchased.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://nairrpilot.org/opportunities/education-call

CloudBank / CloudBank Classroom | Commercial-cloud broker and managed teaching platform | Documented service; approval/limits apply
Funding: NSF support + awarded cloud budgets
Entry: ACCESS/NAIRR route appropriate to requested service
Fit: Managed Python/R/C++ browser environments with login and student storage.
Boundary: Approved budget/term, provider configuration and GPU availability; not a commercial free tier. Check actual onboarding terminology with CloudBank.
Relationship: ACCESS / NAIRR selected resources
https://www.cloudbank.org/training/nairr-pilot-cloudbank-classroom

Chameleon / CHI@Edge | Reconfigurable cloud and edge testbed | Documented service; approval/limits apply
Funding: NSF-funded experimental infrastructure
Entry: Eligible PI project; allocation and resource lease
Fit: Systems/MLOps, edge/IoT, bare-metal experiments, specialized GPU/FPGA hardware.
Boundary: Experiment purpose, SU budget and short hardware leases. No unrestricted production hosting; student membership normally follows PI approval.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://chameleoncloud.org/learn/frequently-asked-questions/

CloudLab | Bare-metal/VM systems experimentation | Documented service; approval/limits apply
Funding: NSF-funded testbed
Entry: Approved project with planned class reservations
Fit: Distributed systems, reproducible root-access labs and networked application experiments.
Boundary: Use only while actively experimenting; node data disappears at termination. Reserve for deadline bursts and export work.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://docs.cloudlab.us/classes.html
https://www.cloudlab.us/

FABRIC | Programmable network + distributed compute/storage | Documented service; approval/limits apply
Funding: NSF grants for research infrastructure
Entry: Project and experimental resource slices
Fit: Distributed AI, edge workloads, streaming/data movement and instrument-to-compute experiments.
Boundary: Experiment should need the network/testbed capabilities; not a stand-alone generic GPU account or production campus server.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://portal.fabric-testbed.net/

NSF NCAR Derecho / analysis resources | Domain HPC and classroom allocations | Documented service; approval/limits apply
Funding: NSF NCAR
Entry: Classroom/workshop or qualifying research allocation
Fit: Earth-system, environmental and geospatial data/AI instruction with consulting.
Boundary: Earth-system mission fit; setup lead time, accounts, dates and reservations required. Separate grant not required for eligible classes.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://ncar-hpc-docs.readthedocs.io/en/stable/allocations/university-allocations/

DOE NERSC / ALCF / OLCF | Leadership HPC user facilities | Documented service; approval/limits apply
Funding: DOE Office of Science / ASCR
Entry: ALCC, INCITE or facility-specific merit request
Fit: Large mission-aligned scientific simulation, data analysis and AI research.
Boundary: ALCC does not require DOE sponsorship, but merit/mission/scaling requirements apply. Not the default for everyday college labs.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://science.osti.gov/ascr/Facilities/Accessing-ASCR-Facilities/ALCC/Call-for-Proposals

NASA High-End Computing | Mission research HPC | Documented service; approval/limits apply
Funding: NASA mission infrastructure
Entry: NASA-sponsored project / mission request process
Fit: NASA-aligned Earth/space/engineering computing.
Boundary: Sponsorship and mission/award review required; not a general open classroom resource.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://hec.nasa.gov/request/mission_directorates.html

NIH AnVIL / Terra ecosystem | Biomedical data + workflow cloud | Documented service; approval/limits apply
Funding: NIH NHGRI platform funding; cloud usage billed separately
Entry: Project/data authorization plus cloud billing or awarded credits
Fit: Genomic data-science notebooks, workflows and reproducible biomedical training.
Boundary: Free platform browsing does not mean free compute/storage/egress. NIH AnVIL differs from Purdue ACCESS Anvil; old credit calls are not current offers.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://anvilproject.org/overview
https://anvilproject.org/learn/control-cloud-costs/understanding-cloud-costs

CyVerse Discovery Environment / VICE | Managed applications and scientific data platform | Mixed funding; current published UArizona benefit
Funding: Historical core NSF support; new project funding + subscriptions + Arizona TRIF
Entry: Basic account; confirm institutional Pro or collaboration access
Fit: Python/R apps, data management and a practical UArizona course/pilot route.
Boundary: Basic 200 units/year, 5 GB, one job and no sharing/public links. Published UArizona free Pro is state-funded, not universal; GPU and class access need consultation.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://cyverse.org/subscribe

Open Storage Network | Allocated object-storage network | Documented service; approval/limits apply
Funding: NSF seed support + participating storage operators
Entry: Separate storage request through ACCESS; provider capacity
Fit: Large actively used teaching/research datasets and portable object storage.
Boundary: Documented request range 10–50 TB; not CPU time, backup or archival permanence. Actual size/site capacity needs verification.
Relationship: ACCESS storage resource
https://www.globus.org/news/nsf-funds-open-storage-network
https://www.openstoragenetwork.org/get-involved/get-an-allocation/
https://www.openstoragenetwork.org/motivation/our-policy/

OSDF / Pelican | Data delivery and cache federation | Documented service; approval/limits apply
Funding: OSG/PATh federal-supported services + data origins/caches
Entry: Connect existing store or allocated OSN/CC* storage through OSG
Fit: Deliver data to distributed jobs, notebooks and scientific applications.
Boundary: Not another storage or compute award. Backing store/access policy required; not for highly regulated/PII/HIPAA data; preservation is separate.
Relationship: OSG data layer; interoperates with OSPool / OSN
https://osg-htc.org/services/osdf
https://osg-htc.org/about/introduction/

MESA | Metadata/data mesh/lakehouse + AI workflow integration | Funded expansion; published portal/tools, readiness untested
Funding: NSF IDSS; project site cites award 2632685
Entry: Published MESA portal/docs; underlying services govern compute
Fit: Metadata, semantic discovery, reproducible data/agent workflows, Jupyter/R/desktop app layer.
Boundary: Published tools are not a verified class service level. Underlying CyVerse/TACC/ACCESS/NAIRR allocations, GPU entitlement and support remain distinct.
Relationship: IDSS Category II
https://idss-mesa.github.io/
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems
https://www.nsf.gov/funding/opportunities/idss-integrated-data-systems-services/nsf26-509/solicitation

National Data Platform (NDP) | Federated data and education ecosystem | Existing ecosystem + funded national expansion
Funding: NSF IDSS
Entry: Public catalog/education activity; consult NDP for class workspace
Fit: Discoverable compute-ready instructional data, reusable AI activities and capstone content.
Boundary: Some homepage features are forthcoming. Confirm available workspaces, quota, onboarding and underlying compute rather than equating an IDSS grant with a user allocation.
Relationship: IDSS Category I
https://nationaldataplatform.org/
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

Fabric for AI-Driven Science (FabAID) | Composable data-service fabric | Funded deployment; service-specific terms to confirm
Funding: NSF IDSS
Entry: Project service endpoints/consultation
Fit: Storage federation, cache/delivery, transformation, discovery and data-intensive workflows.
Boundary: Data-service integration complements compute allocations; no universal GPU entitlement, class quota or archival guarantee established.
Relationship: IDSS Category I
https://fabaid.io/
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

Interactive Discovery Laboratory (iDLab) | Interactive gateway across sites/clouds | Funded transition; current architecture documented
Funding: NSF IDSS
Entry: Project consultation; existing site account/allocations as required
Fit: Browser applications, interactive workspaces and cross-site data/workflow access.
Boundary: Participating sites retain policies/control. Gateway access is not an extra copy of the sites’ capacity or long-term archives; course readiness must be confirmed.
Relationship: IDSS Category II
https://idlab.onescienceplace.org/
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

BRIDGE National Center / Apache Texera | Reusable workflow/data/model platform | Funded national transition / reusable software
Funding: NSF IDSS
Entry: Project collaboration or own supported platform deployment
Fit: Visual/no-code workflows, reproducible social-science/data analyses and shared community models.
Boundary: May require your own host/cloud/resources and operators. No verified no-cost public compute subscription or guaranteed class capacity.
Relationship: IDSS Category II
https://bridge4science.org/
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

National Science Data Fabric (NSDF) | Distributed scientific data-access framework | Funded transition; detailed onboarding unverified
Funding: NSF IDSS
Entry: Project contact; NSF announcement verifies expansion scope
Fit: Standardized scientific data discovery/access, reproducibility and data/AI workforce development.
Boundary: Funding/intent verified from NSF announcement; current user-specific access terms, compute quota and production readiness not established in this review.
Relationship: IDSS Category II
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

Open OnDemand + JupyterHub / BinderHub | Browser application delivery software | Documented service; approval/limits apply
Funding: Open OnDemand federal-supported development; site funds operation
Entry: Use provider-installed portal or deploy on approved compute
Fit: Notebooks, RStudio, VS Code, remote desktops and visual/science gateways.
Boundary: Software is not hardware/time allocation. Only Open OnDemand’s funding is evidenced here; no claim that every JupyterHub installation is federally funded. Operators and backing resources remain necessary.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://openondemand.org/
https://par.nsf.gov/servlets/purl/10122554
https://docs.jetstream-cloud.org/tutorial/classroom/overview/
https://nrp.ai/

Pegasus / HTCondor / ACCESS Pegasus | Workflow orchestration and job execution products | Documented service; approval/limits apply
Funding: NSF ACCESS/PATh-supported software and services
Entry: Hosted ACCESS Pegasus with active allocation; OSG/PATh tools
Fit: Portable multi-step pipelines, task sweeps, data staging and transparent execution.
Boundary: Uses existing allocations/pools; does not create another pool. Software portability is not data preservation or a substitute for operations.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://support.access-ci.org/tools/pegasus
https://osg-htc.org/about/introduction/
https://portal.path-cc.io/documentation/overview/references/PATh_vs_OSPool/

CILogon / Globus | Identity, authorization and research data movement | Documented service; approval/limits apply
Funding: Historical federal development/integration; current operations include subscriptions
Entry: Institution/provider identity configuration and endpoint support
Fit: Campus login, role-based access, data transfer and cross-site workflow connections.
Boundary: Basic services may be free while advanced support/sharing costs. Neither supplies a compute/storage allocation; CILogon says operations shifted to subscriptions in 2019.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.cilogon.org/subscribe
https://docs.globus.org/faq/subscriptions/

Science gateways / SGX3 | Gateway expertise and supported interfaces | Documented service; approval/limits apply
Funding: NSF-funded SGX3; substantial operations can be client-funded
Entry: Gateway consultation/community resources; project-specific gateway accounts
Fit: Usable domain applications and teaching interfaces beyond raw HPC command lines.
Boundary: Limited funded planning/UX/training differs from paid development/hosting/operations. A gateway catalog is not a universal free app-hosting plan.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://sciencegateways.org/about

IDSS program | Operator grant program, not a compute account | Program / awards; not end-user capacity
Funding: NSF
Entry: Institutional proposal / funded project collaboration
Fit: National data-service development, transition to operations and planning.
Boundary: Six named 2026 projects have different services/stages; the grant does not award every instructor CPU/GPU hours.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.nsf.gov/funding/opportunities/idss-integrated-data-systems-services/nsf26-509/solicitation
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

Campus Cyberinfrastructure (CC*) | Campus/regional infrastructure grants | Program; current page awaiting new publication
Funding: NSF
Entry: Institutional funding process; actual local award/service rules
Fit: Campus compute, networking, data storage/digital archives and integration.
Boundary: Current page has no upcoming due dates and awaits new guidelines. Not an open national classroom account; sharing, operation and stewardship have to be funded.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.nsf.gov/funding/opportunities/cc-campus-cyberinfrastructure

Major Research Instrumentation (MRI) | Multi-user research instrumentation grants | Program; review current published call
Funding: NSF
Entry: Institutional limited-submission/award process
Fit: Appropriate shared instrumentation and computing-linked research training.
Boundary: Current solicitation, instrument eligibility and campus proposal limits matter. A funding route is not a ready device/GPU account; this map does not assert an open submission window.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.nsf.gov/funding/opportunities/mri-major-research-instrumentation-program

State / Regional AI Infrastructure Hubs | Mixed-funding consortium program | Solicitation/program; no local award assumed
Funding: NSF pays coordination/workforce/education; partners pay infrastructure
Entry: Institution/state/regional consortium; actual award and resource terms
Fit: Faculty course development, facilitators, shared AI-service coordination and regional scale.
Boundary: NSF does not acquire/fund the compute infrastructure under this solicitation. Partners must sustain it; no awarded Arizona hub is verified here.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.nsf.gov/funding/opportunities/us-national-science-foundation-state-regional-artificial/nsf26-513/solicitation

SCIPE / CyberTraining / ACCESS facilitation | People, skills and support layer | Support services + funding programs
Funding: NSF professional/training programs + service support
Entry: Existing facilitator/training services or institutional grant pathway
Fit: Support ownership, instructor onboarding, reusable course materials and train-the-trainer capacity.
Boundary: Grant programs do not promise staff for every instructor. Current call status and actual support agreements must be checked; college effort is still required.
Relationship: See conceptual map; no additional duplicate capacity implied.
https://www.nsf.gov/funding/opportunities/strengthening-cyberinfrastructure-professionals-ecosystem/506137/nsf23-521
https://www.nsf.gov/funding/opportunities/training-based-workforce-development-advanced
https://access-ci.org/get-started/for-ci-community/

FEDERAL EXTENSION SOURCE LEDGER

ACCESS · national resource and support federation
NSF-supported ACCESS connects researchers and educators to compute, cloud, storage, gateways and support. Resource providers supply the underlying systems; access is governed by allocation and provider policies.
Scope: ACCESS is an access/support program, not a single machine. Do not add provider capacity twice when counting ACCESS and Jetstream2 or other participating systems. Grants, account approval and scheduling remain separate.
https://access-ci.org/get-started/for-ci-community/

NAIRR Classroom · AI teaching resource request
US-based instructors can request selected NAIRR Classroom resources for AI coursework or training with US-based participants, including any discipline that incorporates AI. Requests specify hardware, storage, dates and support.
Scope: NSF-led cross-agency/partner ecosystem, including in-kind contributions; not every donated service is federally purchased. Instructor/TA technical support is expected. Selected resource availability and approval govern access; this is not an awarded college pilot.
https://nairrpilot.org/opportunities/education-call

OSG · consortium, funding and services
OSG operates distributed computing/data services across contributing institutions. Its funding page names NSF PATh and IRIS-HEP support and in-kind contributions including DOE laboratories.
Scope: Open Science Grid is the consortium/ecosystem. The general-access compute pool is OSPool; OSDF is a data-delivery federation. These are distinct services, not three independent pools of the same capacity. Funding acknowledgments include dated historical context.
https://osg-htc.org/about/introduction/

OSPool · opportunistic high-throughput capacity
US-affiliated academic, nonprofit and government research projects can request OSG access-point accounts. OSPool supports many independent CPU/GPU jobs under fair share; jobs should complete or checkpoint within 20 hours.
Scope: Contributed capacity can interrupt jobs and does not reserve a whole class or finish any job at a promised time. Consult facilitators for educational projects. It is not the natural environment for interactive notebooks or tightly coupled MPI workloads.
https://osg-htc.org/services/ospool/

PATh Facility · dedicated throughput credits
The NSF-supported PATh Facility provides dedicated credit-based HTC capacity for NSF-funded research, including larger CPU/GPU, memory, disk and longer jobs than opportunistic OSPool work.
Scope: Separate eligibility/credit process from OSPool. User-facing guarantees in the comparison concern provisioned job resources, not unlimited credits, instant start times, classroom reservations or perpetual storage. MESA funding makes consultation relevant, not automatic approval.
https://portal.path-cc.io/documentation/overview/references/PATh_vs_OSPool/

National Research Platform / Nautilus · shared services
NSF-funded NRP offers eligible US nonprofit research and education shared GPUs/CPUs, hosted notebooks, model APIs, storage and Kubernetes-hosted services. Nautilus is its underlying cluster.
Scope: NRP and Nautilus are two names for one platform layer, not independent capacities. Shared scheduling, account onboarding, quotas and operations still apply. Hosted services can help teaching but are not a preservation or availability guarantee.
https://nrp.ai/

NRP · hosted open-weight model APIs
NRP documents hosted browser chat and an OpenAI-compatible API for a changing catalog of open-weight language models.
Scope: Model/API access is a distinct product from a GPU training allocation. Models can be added or retired; verify current quotas, supported use and prompt/data handling before class. No account token or API call was tested.
https://nrp.ai/documentation/userdocs/ai/llm-managed

Jetstream2 · teaching cloud through ACCESS
Jetstream2 provides documented course/workshop workflows for virtual machines, standardized environments, virtual GPUs and web applications. Its classroom guidance links instructors to ACCESS allocations.
Scope: An ACCESS resource provider, not a second federal allocation program. Instance runtime has no notebook-style session cap, but allocation duration, credits, GPU availability, support and backups still bound use. Operators must size always-on services explicitly.
https://docs.jetstream-cloud.org/tutorial/classroom/overview/

Jetstream2 · NSF research-cloud system
Jetstream2 is described as NSF science and engineering cloud infrastructure with CPU, GPU, memory and storage resources.
Scope: Funding provenance establishes public infrastructure, not an approved allocation or a promise of a dedicated GPU per student.
https://docs.jetstream-cloud.org/overview/overview-doc/

CloudBank Classroom · managed teaching environment
NSF-supported CloudBank Classroom offers browser-based Python/R/C++ tools, persistent student storage and university login. US educators request it through NAIRR Classroom; the page describes one-year allocations with renewal.
Scope: CloudBank brokers commercial cloud resources; it is not a vendor free tier. Approval, provider capacity, awarded budget and configuration govern access. GPU availability is not assumed. The page mixes ACCESS/NAIRR terminology; confirm the actual onboarding route with the provider.
https://www.cloudbank.org/training/nairr-pilot-cloudbank-classroom

Chameleon · funded experimental cloud testbed
NSF-funded Chameleon supports computer-science research and education using reconfigurable bare metal, VMs and specialized hardware. Approved projects receive time-limited service-unit allocations and make reservations.
Scope: A systems/ML-systems experimentation route, not unrestricted production hosting. Leases, units and renewal differ by resource; current docs distinguish short GPU/bare-metal leases from longer non-GPU VM leases. Student access normally needs an eligible PI/project.
https://chameleoncloud.org/learn/frequently-asked-questions/

CloudLab · classes and reservation boundaries
CloudLab supports class projects with isolated root-access environments and resource reservations. Nodes should be held only during active experiments; data on experiment nodes is ephemeral.
Scope: Useful for systems, distributed application and network classes. Large deadline bursts can exhaust shared nodes; backups and reservations must be planned. An experiment reservation is not permission to run a semester-long production service.
https://docs.cloudlab.us/classes.html

CloudLab · NSF-supported research facility
CloudLab identifies itself as NSF-supported infrastructure for research into the future of cloud computing.
Scope: Research testbed purpose and project approval distinguish this from ordinary unlimited cloud hosting. Funding and teaching suitability do not establish resource availability on a course date.
https://www.cloudlab.us/

FABRIC · programmable network and edge testbed
FABRIC lists NSF grants supporting distributed compute/storage connected by programmable high-speed networks for networking, distributed computing, machine learning and science experimentation.
Scope: Network/edge experiments, data movement and distributed AI are its defining purpose; it is not just a generic GPU pool. Projects, resource slices and policies must fit the experiment. No course slice was reserved.
https://portal.fabric-testbed.net/

NSF NCAR · domain-specific classroom allocations
NSF NCAR offers no-cost eligible Earth-system science research/instruction, including classroom/workshop allocations for US two- and four-year institutions. It documents individual accounts, compute reservations and setup lead time.
Scope: A domain-specific route for environmental/geospatial data coursework, not a general all-college compute entitlement. Eligible classes need not have a separate external research award. Allocation resource limits and proportional CPU/GPU requests remain provider-specific.
https://ncar-hpc-docs.readthedocs.io/en/stable/allocations/university-allocations/

DOE ASCR · leadership computing allocation routes
DOE ALCC awards computing at NERSC, ALCF and OLCF through scientific/computational merit review. Universities, industry and agencies may apply; DOE sponsorship is not required for ALCC.
Scope: Mission-aligned research capacity, not a routine classroom account offer. INCITE and other facility routes have different scale/eligibility. Do not treat a past cycle deadline as an open call or combine node-hours with CPU/GPU-hours without conversion.
https://science.osti.gov/ascr/Facilities/Accessing-ASCR-Facilities/ALCC/Call-for-Proposals

NASA HEC · sponsored mission-research resources
NASA-supported mission research can request HEC computing through its request-management process; mission-directorate sponsorship and capacity review govern awards.
Scope: Not an open general classroom pool. An allocation is computing time rather than a direct cash grant; some categories are considered case by case without a guarantee. Current request windows and eligibility must be checked.
https://hec.nasa.gov/request/mission_directorates.html

NIH NHGRI AnVIL · domain cloud-analysis platform
NHGRI AnVIL combines genomic data access, cloud analysis, notebooks, workflow tools and data-sharing components such as Terra, Dockstore, Bioconductor and Galaxy.
Scope: NIH AnVIL is distinct from Purdue’s ACCESS Anvil supercomputer. Biomedical/domain and controlled-data access policies apply; the federal-funded platform does not make all execution free.
https://anvilproject.org/overview

AnVIL · execution and storage costs
Browsing AnVIL components is free, while notebooks, workflows, storage and egress can incur commercial cloud charges.
Scope: NIH STRIDES discounts, awarded credits or funded training can cover costs only under their actual terms. Historical 2021/22 credit calls are not counted as currently open free offers. Budget ownership and approved data access remain necessary.
https://anvilproject.org/learn/control-cloud-costs/understanding-cloud-costs

NSF · six named 2026 IDSS awards
NSF announced $83 million in IDSS awards on July 22, 2026. Named projects are FabAID and NDP in Category I; iDLab, BRIDGE, NSDF and MESA in Category II.
Scope: These are data-system investments with computing integration, not six interchangeable free GPU pools. Grant category and announced scope do not establish a user quota, production service level or open access portal. Planning awards are separate.
https://www.nsf.gov/news/nsf-announces-83m-investment-integrated-data-systems

NSF IDSS · program and integration remit
Integrated Data Systems and Services funds national-scale data infrastructure: new systems, transitions/expansions to operations, and planning. It emphasizes transdisciplinary data integration with existing compute, instruments and repositories.
Scope: A grant program funding service operators, not a direct end-user allocation. Operational and planning stages must stay distinct. It complements ACCESS/NAIRR rather than replacing their resource requests.
https://www.nsf.gov/funding/opportunities/idss-integrated-data-systems-services/nsf26-509/solicitation

MESA · published data/AI tools and portal
MESA identifies NSF IDSS award 2632685 and presents metadata/agent tools, a DuckLake/iRODS stack, and portal applications such as JupyterLab, RStudio, VS Code and a remote desktop over national infrastructure.
Scope: Public project documentation, not a hands-on acceptance test. GPU application builds do not guarantee GPU entitlement. CyVerse/TACC/ACCESS/NAIRR resources retain their own policies. No private proposal, staff plan or internal milestone is used as public service evidence.
https://idss-mesa.github.io/

NDP · data discovery and education ecosystem
The National Data Platform describes a federated data ecosystem, educational activities and compute-ready data/AI services; its page also labels some capabilities as forthcoming.
Scope: Separate the existing catalog/education activity from the funded national expansion and forthcoming features. Provider consultation is needed to establish workspace capacity, course onboarding and actual quotas; no unlimited classroom capacity is claimed.
https://nationaldataplatform.org/

FabAID · data services fabric
FabAID describes an NSF-funded open service layer for federated storage, caching, discovery, transformation and workflows supporting data-intensive and AI science.
Scope: Data services complement resource pools; they are not additional allocated GPU-hours or a permanent archive. Current service-specific onboarding, storage responsibility and production guarantees require confirmation.
https://fabaid.io/

iDLab · interactive cross-site environment
iDLab describes a browser layer for interactive applications, data access and workflows across ACCESS/NAIRR sites and clouds. Participating sites retain control over their systems.
Scope: An interactive integration layer, not a replacement for site allocations or a long-term archive. Public architecture describes connected and planned services; validate onboarding and course readiness rather than assuming universal immediate access.
https://idlab.onescienceplace.org/

BRIDGE · reusable data science workflows
BRIDGE describes an NSF-funded national effort built on Apache Texera for reusable datasets, workflows and models, deployable on a community’s own infrastructure or cloud.
Scope: A shareable workflow platform and funded expansion, not a verified no-cost general compute subscription. Labs may need to supply deployment infrastructure, operations and allocations. Prototype and production maturity must be checked.
https://bridge4science.org/

Open Storage Network · federal seed support
The 2018 project announcement identifies NSF support for development of OSN as distributed scientific storage/data management infrastructure.
Scope: Historical federal seed funding, not proof that all ongoing pods and operations are wholly federally financed. Storage supports active data movement and sharing, not automatic archival preservation.
https://www.globus.org/news/nsf-funds-open-storage-network

OSN · ACCESS storage allocation route
OSN documents independent bucket allocations through ACCESS, with a stated 10–50 TB request range, subject to location and available capacity.
Scope: Storage is distinct from CPU/GPU time. Verify actual current quotas and permitted data before applying; a large bucket is not an institutional backup or perpetual preservation agreement.
https://www.openstoragenetwork.org/get-involved/get-an-allocation/

OSN · active-data scope
OSN policy focuses on data in active use for research/education and data transfer/sharing across scientific infrastructure, explicitly distinguishing active data from archives.
Scope: Long-term preservation, retention and recovery require a different stewardship agreement. Treating allocated object storage as archival permanence would overstate this service.
https://www.openstoragenetwork.org/motivation/our-policy/

OSDF / Pelican · distribute data to computation
OSDF, an OSG service powered by Pelican, connects data origins and caches to computing. Eligible institutions can connect stores; OSPool access points provide connected working storage and OSN allocations can be linked.
Scope: A delivery/federation layer, not a second storage allocation or GPU pool. Origin policies apply; documentation says it is not appropriate for highly regulated or sensitive data such as PII/HIPAA. Backing storage and preservation must be separately supplied.
https://osg-htc.org/services/osdf

Open OnDemand · browser access to allocated computing
Open OnDemand provides browser-based access to remote computing and applications, reducing local installation and command-line barriers.
Scope: A software/gateway product installed by operators, not free computing by itself. Users still need accounts and allocations on the backing system; desktop/visualization apps depend on site configuration.
https://openondemand.org/

Open OnDemand · federal-supported software development
The project-authored paper describes Open OnDemand and acknowledges NSF grant 1835725.
Scope: Documents federal development support. This historical award is not a claim of perpetual operating funding for every campus installation.
https://par.nsf.gov/servlets/purl/10122554

ACCESS Pegasus / HTCondor · workflow product layer
ACCESS Pegasus supports workflow construction/monitoring in notebooks, with HTCondor Annex provisioning jobs against a user’s allocated resources. Active ACCESS allocation holders have a hosted Pegasus account.
Scope: Workflow and scheduling products make capacity usable but do not supply a new independent allocation. Data transfer, containers, site setup and underlying allocation expiry remain requirements; HTCondor’s broader federal-supported work is described by OSG/PATh.
https://support.access-ci.org/tools/pegasus

CILogon · basic identity versus sustained paid operations
CILogon says NSF/DOE supported its development from 2009–2018; it transitioned to subscription-funded operations in 2019. Basic authentication remains no-charge for academic research projects, while advanced support/IAM uses paid tiers.
Scope: Federally developed identity infrastructure is not wholly federally financed current operations. Login alone does not confer compute entitlement; operators may require paid service support.
https://www.cilogon.org/subscribe

Globus · research transfer and subscription boundary
Globus provides free file transfer for nonprofit researchers, with subscriptions supporting operations and additional sharing/administrative features.
Scope: Globus connects storage and remote workflows; it does not supply a storage allotment or universal free execution. Federal-supported ecosystem integration and historical development should not be conflated with current subscription funding.
https://docs.globus.org/faq/subscriptions/

SGX3 / SGCI · gateway expertise and operations boundary
NSF-funded SGX3 (award 2231406) provides limited gateway planning, UX, training and community services. More comprehensive development, hosting and operations are client-funded SGCI engagements.
Scope: Science gateway support is an enabling service, not a universal free hosted application service. Check scope/cost of the proposed engagement and budget the backing resource separately.
https://sciencegateways.org/about

NSF CC* · campus/regional infrastructure funding
CC* describes campus/regional networking, computing, storage/digital archives and strategy awards. Its page currently lists no upcoming due dates and says guidelines await a new publication.
Scope: A funding pathway for infrastructure owners, not an open account pool or a currently verified open proposal window. Resulting campus systems have local access rules; sharing commitments and operating costs matter.
https://www.nsf.gov/funding/opportunities/cc-campus-cyberinfrastructure

NSF MRI · research instrumentation funding
MRI supports acquisition/development of multi-user research instrumentation. Its page describes updates toward a future FY2027 opportunity after review of earlier proposals.
Scope: Campus hardware/equipment funding, not instant national allocations. Computing must meet the actual instrument/solicitation criteria; university proposal limits and a current published call must be checked. No grant application is implied.
https://www.nsf.gov/funding/opportunities/mri-major-research-instrumentation-program

AI Infrastructure Hubs · NSF funds people, partners fund compute
NSF’s State and Regional AI Infrastructure Hubs solicitation funds coordination, infrastructure workforce and educator/course development. Consortia must finance acquisition and operation of compute/data/AI infrastructure through their partners.
Scope: A mixed-funding partnership, not NSF-provided hardware or a currently awarded regional pool. It may integrate NRP/PATh resources, but that does not remove consortium funding responsibilities.
https://www.nsf.gov/funding/opportunities/us-national-science-foundation-state-regional-artificial/nsf26-513/solicitation

SCIPE · professional support workforce
SCIPE supports the integration, development and recognition of cyberinfrastructure professionals who help research communities use computational resources and services.
Scope: Workforce capacity rather than end-user compute. A program page is not a confirmed open call or a staffed support promise for this college; inspect current guidelines and awarded local/regional services.
https://www.nsf.gov/funding/opportunities/strengthening-cyberinfrastructure-professionals-ecosystem/506137/nsf23-521

CyberTraining · teaching and workforce development
NSF CyberTraining supports adoption of advanced computing/data infrastructure and integration of appropriate skills into undergraduate/graduate teaching and researcher training.
Scope: Funds curriculum, skills and training rather than automatically purchasing all course computing. Current competition status and grant fit need checking; no training award or educator cohort is claimed here.
https://www.nsf.gov/funding/opportunities/training-based-workforce-development-advanced

CyVerse · federal funding transition and UArizona state support
CyVerse states that core NSF award support ended in 2024. Basic offers 200 normalized compute units/year, 5 GB storage and one concurrent job; free sharing/public links ended June 3, 2025. UArizona users can receive Pro through state TRIF support.
Scope: CyVerse is federally developed and used by federally funded projects, but current account subsidies are mixed; TRIF is state, not federal funding. Pro lists 25,000 units/year, 4 TB and four concurrent jobs, with GPU access by consultation. Published eligibility is not an account or whole-class provisioning test.
https://cyverse.org/subscribe

Source access note: the old FABRIC about-page path returned 404; its provider content was read through the indexed primary page and the live HTTP-200 portal is linked.

7. Classroom service assessment

CLASSROOM ROUTE ASSESSMENT | October 12, 2026
From federal resources to a classroom service
Documentation assessment and illustrative capacity model; not an awarded or tested classroom service

RECOMMENDATION

Use ACCESS for the large CPU and GPU allocation and the classroom pilot. Use campus UITS/AWS only to test CPU components, and free GPU resources to benchmark workloads before piloting. Size the ACCESS request from measured demand; consider CloudBank through ACCESS only if its managed service can meet the confirmed requirements.

WORKLOADS

Data science: 40 illustrative students. Python/R data analysis, reproducible notebooks, small-model CPU labs; optional grouped GPU experiment.
Fallback: Small CPU datasets and downloadable environment/materials.
Library and information science: 40 illustrative students. Metadata normalization, collection analysis, public-corpus text processing, reproducible workflow and repository export.
Fallback: Local small-record workflow and institution-supported storage; no private patron or grade records on batch resources.

QUALITATIVE ROUTE DECISIONS

CloudBank Classroom | Conditional managed alternative
Managed Python/R notebooks and browser IDEs for both courses.
Gate: Confirm managed versus broker service, CPU/GPU availability, actual student limits, accounting, course provisioning and exports; previous CPU-only concept is conditional.
Boundary: No published per-student specification establishes our fit. Fall 2026 GPU pilot is full. General ACCESS route exists; NAIRR Classroom is a separate AI-course route.
Sources: assesscloudbank, assesscbgpu, assesscbscope, access

Jetstream2 through ACCESS | ACCESS implementation candidate for CPU + GPU
Own course images, JupyterHub, isolated teaching web/database services and reviewed benchmark workers.
Gate: Named operator and backup; CPU/GPU/storage exchange; adequate concurrent quota; tested image upgrade, shutdown, restore and end-of-term export.
Boundary: Always-on instances dominate credits. Allocation expiry and overdraw can delete resources after thirty days. Storage replication is not independent backup.
Sources: assessjetflavors, assessjetcredit, assessjetquota, assessjetstorage, assessjetexpiry

NRP hosted hub / private hub / API | Conditional GPU and API module
Notebook canary, grouped GPU demonstrations, model APIs; a primary hub only after class-capacity confirmation.
Gate: Confirm hosted/private hub policy, roster and quota, 20 GB home increase from default 5 GB, GPU access and storage/export agreement.
Boundary: Shared GPU scheduling; ordinary pods have six-hour rules with exceptions. Unused volumes may be purged after six months. APIs are inference products, not training allocations.
Sources: assessnrpedu, assessnrphub, assessnrppolicy, fednrpllm

MESA + CyVerse | Data/workflow component
MLIS metadata cleanup, collection analysis, reproducibility and portable outputs using public/synthetic records.
Gate: Verify each UArizona account’s Pro/TRIF benefit and class approval; rehearse the exact app Save & Exit, restart and export path.
Boundary: MESA reads existing CyVerse quota. Basic 200 CPU core-hours/year is below this modeled 240 per student (300 with allowance); 5 GB is below modeled 20 GB. Pro is 25,000 units/4 TB/four concurrent jobs per account, not a pooled classroom entitlement.
Sources: assessmesaportal, assessmesaapps, assessmesasave, fedcyverse, assesscyteach

OSPool education program | Optional batch component
Independent public-corpus OCR/text analyses and parameter sweeps; teach throughput with a short guest exercise first.
Gate: Rehearse a workflow under four hours; retain outputs externally. Arrange full accounts and event/end dates for semester use.
Boundary: Guest timeout/file loss; full accounts typically expire after event. Interruptible fair share cannot promise synchronous GPU access or assignment completion times. No sensitive/proprietary inputs.
Sources: assessospedu, assessosppolicy

PATh Facility | Research route to clarify
MESA-aligned research ensembles where program eligibility and credits are confirmed.
Gate: Ask whether IDSS/MESA is eligible and what work the award can cover; prototype before any full-credit request.
Boundary: IDSS is not explicitly in the published affiliated-program list. No eligibility or credits verified. Keep required teaching off this route pending confirmation.
Sources: assesspathelig, assesspathcredits, fedpath

College + Libraries operations | Required continuity layer
Support ownership, identity, roster/grade handling, independent backups, durable hosting/databases and archival selection.
Gate: Approve owners, operating budget, support coverage, data classification/retention, tested second-host restore and learner exports.
Boundary: Federal compute does not pay every operating cost or turn working data into preservation. A lab demonstration cannot establish semester service readiness.
Sources: access, assessjetstorage, assessnrppolicy, assessosppolicy

CAPACITY AND ALLOCATION MODEL

{
"assumptions": {
"courses": 2,
"students_per_course": 40,
"seats": 80,
"weeks": 15,
"active_hours_per_week": 8,
"cpu_per_student": 2,
"ram_gb_per_student": 6,
"home_gb_per_student": 20,
"shared_gb_per_course": 200,
"controller_vcpu": 4,
"controller_ram_gb": 15,
"allowance_percent": 25,
"shared_worker_vcpu": 64,
"shared_worker_ram_gb": 250,
"gpu_students": 40,
"gpu_group_size": 5,
"gpu_labs": 6,
"gpu_hours_per_lab": 2,
"gpu_slot_su_per_hour": 16,
"gpu_slot_vram_gb": 10,
"backup_daily_change_percent": 1,
"backup_history_days": 30
},
"scenarios": [
{
"id": "burst",
"name": "Stopped between sessions",
"student_su": 24000,
"controller_su": 12600,
"cpu_su": 36600,
"peak_cpu_vcpu": 164,
"peak_ram_gb": 495,
"workers": null,
"boundary": "Ideal lower bound for individually stopped/autoscaled 2-vCPU instances. Shared workers have rounding, idle tail, image pulls and orchestration overhead; measure actual billing."
},
{
"id": "dedicated",
"name": "Student VMs always on",
"student_su": 504000,
"controller_su": 12600,
"cpu_su": 516600,
"peak_cpu_vcpu": 164,
"peak_ram_gb": 495,
"workers": 80,
"boundary": "80 m3.small student instances plus one m3.quad controller, running 24 hours/day for 15 weeks; includes 25% spending allowance."
},
{
"id": "shared",
"name": "Shared hub workers always on",
"student_su": 604800,
"controller_su": 12600,
"cpu_su": 617400,
"peak_cpu_vcpu": 196,
"peak_ram_gb": 765,
"workers": 3,
"boundary": "Three m3.2xl workers sized to cover 160 student vCPU and 480 GB RAM, plus one m3.quad controller; placement and hub performance remain untested."
}
],
"gpu_model": {
"slots": 8,
"instance_hours": 96,
"instance_hours_with_allowance": 120,
"su": 1920,
"peak_gpu_resource_vcpu": 64,
"peak_gpu_resource_ram_gb": 240,
"vram_per_slot_gb": 10,
"boundary": "Eight g3.medium fractional A100 instances shared by groups of five; 120 planned fractional-instance hours is not 120 full-GPU hours. Separate GPU exchange/permission and networking required."
},
"storage_model": {
"working_gb": 2000,
"backup_gb": 2600,
"boundary": "Decimal GB/TB. Working data = 80\u00d720 GB homes + 2\u00d7200 GB shared. Independent backup estimate = one working copy + 30 days of 1% changed data/day; excludes compression/deduplication, root disks, images, logs and snapshots. This is not a storage quote or approved retention schedule."
}
}
Jetstream2-only modeled totals including optional GPU: 38,520 (ideal burst), 518,520 (always-on student VMs), 619,320 (always-on shared workers). CPU and GPU exchanges remain separate. Explore initial ceiling is 200,000 credits (half of 400,000); Discover initial ceiling is 750,000 (half of 1,500,000). A measured small canary can start with Explore. The two always-on models fit within the Discover initial ceiling on paper; approval, actual overhead and provider capacity remain unverified. CloudBank requests use its provider-specific Explore Classroom route, not this VM sizing model.

READINESS GATES (ALL UNCONFIRMED)

Scope and owners | Before any class dependency | Course lead + Greg
Choose real course/syllabus, data classification, operator and backup; fund support and durable storage for the whole term.
Stop if: No named owner or approved service period.

Provider and access | 6–8 weeks before term (proposed) | Service owner + provider liaison
Confirm approved route, course eligibility, actual roster/login, quotas, images, costs, GPU status and data/expiry terms.
Stop if: Unresolved 80-seat provisioning or missing account/award.

Component canary | 4–6 weeks before term (proposed) | One instructor + up to ten consenting volunteers
Run one representative DS assignment and one public-records MLIS workflow; use a fixed image and retain launch, save/restart/export evidence.
Stop if: Core software or save/export path fails.

Capacity rehearsal | 2–4 weeks before term (proposed) | Operator + teaching assistants
Test approved peak concurrency with provider permission; measure queue/spawn latency, CPU/RAM, storage and actual billed idle time. Suggested p95 login-to-workspace target: five minutes, to negotiate with provider.
Stop if: Unmeasured or insufficient class capacity; credit/storage forecast exceeds award.

Recovery and teach-out | Before course admission | Primary and backup operators + Libraries liaison
Restore files and service onto a second host; verify cross-student isolation, learner export and grade reconciliation. Proposed RPO 24 hours/RTO one business day require measurement.
Stop if: No independent restorable backup or viable offline/CPU fallback.

Two-course pilot | One approved 15-week term | Course leads + operator
80 illustrative seats; required work CPU-capable. GPU/OSPool/MESA modules only after their own gate passes; collect support time, billing and instructional outcomes.
Stop if: Unsafe access, recurring capacity failure or no funded support.

Retire or renew | Decision at least 30 days before expiry (proposed) | Course leads + service owner + Libraries
Export students/grades, reconcile submissions, deposit approved public outputs with Libraries; confirm next-term project/renewal route and verify deletion.
Stop if: Assuming automatic education extension or treating grace periods as service funding.

OPERATING FUNDING

Available cash budget is zero. Work needing paid support, storage, hosting, development or recovery must have a confirmed eligible EduCloud grant and allowable work package before spending. ACCESS is CPU/GPU resource allocation, not payroll. No grant award is asserted. Existing campus test access and free GPU resources must stay within their authorized no-purchase scope. Greg has ten hours/week total. Separate potential TA effort is 102 hours and additional course-lead effort 70 hours across the modeled term; no course-lead salary. No college sponsor/finance role. Distinct backup/support is unfilled until confirmed.

DEGREE EXPANSION

The first canary covers DS and MLIS. Notebook-compatible MS/BS Information Science and PhD projects can reuse the route after workload review. ETS and Information Science and Arts need public-data/browser workflows and durable exhibit hosting. Game Design/Development require a separate engine, graphics, licensing and desktop-access assessment; this notebook pilot does not establish Unreal/Unity or Windows support. Cyber degrees remain excluded.

DRAFT PROVIDER QUESTIONS (NOT SENT)

CloudBank Classroom
- Can the general ACCESS Classroom route support two non-AI/AI-mixed courses and 80 seats with 2 vCPU/6 GB/20 GB per seat? What are the actual limits and credit/budget terms?
- Which packages, version pinning, notebook distribution, grading/export and account-isolation features are supported?
- What are roster provisioning, CILogon/MFA, support hours, independent export/backup and shutdown dates?
- How does the one-year renewal text align with ACCESS education-term/no-typical-extension policy? Is next term a renewal or a new request?
- Please confirm current GPU pilot status and the 2027 request window; required activities will remain CPU-capable.

Jetstream2
- Confirm CPU/GPU/storage exchanges, 164-vCPU dedicated or 196-vCPU shared peak quota, applicable flavor availability and required public/private network quotas.
- Can 2 TB working data plus additional root/image/log/snapshot space be approved? Which shared home/filesystem architecture fits the workload and policy?
- Review a hub or VM autoscaling/shutdown design and independent offsite backup/restore plan; verify classroom identity and grading service rules.
- What renewal/new-course request, warning and deletion process applies to the exact awarded project?

NRP

- For hosted versus private hubs, what class quota, GPU configuration, roster approval, software/image and support arrangements apply?
- Can 80 homes have 20 GB each? What session, exception, persistence and end-of-course export rules apply to this particular hub?
- Which model/API quotas and data-handling terms apply? What GPU fallback is acceptable when shared capacity is busy?

MESA / CyVerse
- Can every eligible UArizona student receive the documented Pro/TRIF benefit, and what class/workshop enrollment limits and maintenance windows apply?
- How are per-user CPU units, concurrency and storage charged across the selected portal app? Is GPU permission available for this specific assignment?
- Demonstrate saving under data-store, Save & Exit, restarting, export and independent restoration for the chosen metadata app.

OSPool
- Does the proposed public-data workflow fit the guest four-hour session? Confirm full roster, account dates, fair-share behavior, job/I/O sizes and training-policy requirements for semester use.
- Which packaging, checkpointing, licensed-software or data-transfer restrictions apply? Agree on outputs retained elsewhere and a CPU/local fallback.

PATh / NSF program officer
- Is IDSS award 2632685/MESA eligible under the affiliated-program policy, and can this particular research/teaching workload be covered?
- If eligible, what startup prototype and job specification are needed for a full credit request, and which program officer should receive it?

College / Libraries
- What institutional data/export/retention and accessibility approvals are required for the exact components?
- Which support/recovery tasks fit Greg’s ten hours/week and separate TA/lead commitments?
- Which necessary paid needs fit an eligible confirmed EduCloud grant, and who provides distinct backup coverage before classroom launch?

METHOD AND LIMITS

16 discovery queries requested 78 result slots; these are discovery counts, not independent evidence counts. Twenty new primary-source ledger records plus reused program/provider records support a qualitative fit assessment. Public documentation was read, with saved extracts and targeted HTTP access checks. No signed-in entitlement, actual compute workload, model API, cloud billing, allocation request, provider message or grant submission was executed. Current user-directed route: campus UITS/AWS is for CPU component testing only; free GPU benchmarks precede piloting; ACCESS covers the planned CPU and GPU classroom allocation. Existing capacity models remain illustrative.

PRIMARY SOURCES

CloudBank Classroom · general ACCESS teaching route
Checked October 12, 2026
U.S. educators can request a managed CPU classroom through Explore ACCESS with a syllabus, roster count and course dates. The provider configures institutional login, persistent student workspaces, Python/R/C++ and notebook/RStudio/VSCode tools.
Scope: This route does not state an AI-course requirement. It is distinct from AI-focused NAIRR Classroom and from general commercial-cloud dollar allocations. Per-student limits and 80-seat capacity are not published here. Its one-year renewal description needs reconciliation with ACCESS education-period policy.
https://www.cloudbank.org/training/access-cloudbank-classroom

CloudBank Classroom · current GPU capacity record
Checked October 12, 2026
The resource registry updated September 28, 2026 states that the fall 2026 GPU pilot is at capacity and additional requests will be considered beginning in 2027.
Scope: Production status is not an available seat. Consideration in 2027 is not approval or guaranteed GPU availability. The registry rendered an as-of October 4 timestamp when checked; this is a documented capacity notice, not an independent real-time utilization measurement.
https://operations-api.access-ci.org/wh2/cider/v1/cider_resource_id/3739/?format=html

CloudBank Classroom · support-document scope conflict
Checked October 12, 2026
The opening sections describe managed Classroom without batch queues; later storage/account sections describe user-created commercial-cloud storage and dollar awards.
Scope: The page contains mixed service scopes. Use the dedicated provider Classroom guide for the pilot design; confirm budget, storage, account and support mechanics for the actual requested service. Do not apply all broker billing terms to the managed hub.
https://support.access-ci.org/documentation/resources/cloudbank-classroom

Jetstream2 · exact instance accounting
Checked October 12, 2026
CPU m3.small has 2 vCPU, 6 GB RAM, 20 GB local root disk and costs 2 SU/hour; m3.quad has 4 vCPU/15 GB and costs 4 SU/hour; m3.2xl has 64 vCPU/250 GB and costs 64 SU/hour. GPU g3.medium has 8 vCPU/30 GB, 25% of an A100, 10 GB VRAM and costs 16 SU/hour.
Scope: Published flavor rates underlie this illustrative model. Partial-GPU instance-hours are not full-GPU hours; GPU/CPU exchanges are separate. Larger/newer GPU flavors have different rates and availability. Application fit requires rehearsal.
https://docs.jetstream-cloud.org/general/instance-flavors/

Jetstream2 · ACCESS credit conversion
Checked October 12, 2026
One ACCESS credit exchanges for one Jetstream2 service unit. Resource use is charged at the chosen flavor rate; CPU, large-memory and GPU resources are distinct.
Scope: This conversion is provider-specific. Do not transfer these rates to CloudBank, NRP, CyVerse or OSPool. Usage reporting can lag; monitor local consumption and maintain headroom.
https://docs.jetstream-cloud.org/general/access/

Jetstream2 · concurrent resource quotas
Checked October 12, 2026
Default CPU quota is 150 vCPU, 585 GB RAM and ten floating IPs; the GPU resource default is 64 vCPU, 250 GB RAM and four floating IPs. Quotas scale above resource-specific allocation thresholds and justified increases can be requested.
Scope: Total credits do not guarantee concurrency. The 80-seat dedicated model needs 164 CPU vCPU with its controller; the shared-worker model needs 196. The eight fractional GPU slots use 64 GPU-resource vCPU. Verify awarded quotas, flavor availability and private networking rather than assuming eight public GPU addresses.
https://docs.jetstream-cloud.org/general/quotas/

Jetstream2 · storage and backup responsibility
Checked October 12, 2026
Jetstream2 offers attached volumes, shared filesystems and object storage; replicated storage and provider snapshots do not replace independent offsite backups.
Scope: Some multi-instance shared filesystem workflows, particularly metadata-heavy/locking applications, require policy and architecture review. Independent restore, retention and deletion controls need a college owner. Persistent working storage is not archival preservation.
https://docs.jetstream-cloud.org/general/storage/

Jetstream2 · default storage allocation
Checked October 12, 2026
The default Jetstream2 storage cap is 1 TB (1,000 GB); request and justify additional storage through the appropriate storage resource.
Scope: The modeled student homes and shared data total 2 TB, excluding root disks, images, logs and snapshots. Credits alone do not automatically increase that storage limit.
https://docs.jetstream-cloud.org/alloc/budgeting/

Jetstream2 · expiry and overdraw lifecycle
Checked October 12, 2026
Expired or overdrawn allocations lose access; instances are shelved after ten days and unresolved resources are destroyed after thirty days.
Scope: The grace period is a recovery window, not a funded continuation service. Schedule export, backup and renewal decisions before expiry. Do not promise permanent course servers or recoverability after destruction.
https://docs.jetstream-cloud.org/general/policies/

NRP · classroom products
Checked October 12, 2026
NRP explicitly offers educators hosted or private JupyterHub, GPU resources, hosted language-model services and Coder IDEs.
Scope: These are different products with different permissions, quotas and operating duties. Education availability is not a reserved GPU for each learner or a campus production service level.
https://nrp.ai/education

NRP · hosted hub storage and login
Checked October 12, 2026
The hosted hub uses institutional CILogon login and selectable hardware; persistent home folders initially have 5 GB, with enlargement by request.
Scope: The 20 GB/student model needs an approved increase or a smaller assignment footprint. Institutional login documentation is not a verified UArizona roster/provisioning flow. This page lists NSF funding acknowledgments.
https://nrp.ai/documentation/userdocs/jupyter/jupyterhub-service/

NRP · workload and data lifecycle
Checked October 12, 2026
Ordinary interactive pods have a six-hour maximum unless a namespace exception is approved; long-lived services need approved exceptions. NRP is not archival storage and unused volumes may be purged after six months without notification.
Scope: Do not impose ordinary-pod limits on every hosted hub without confirming its exceptions. Shared GPUs have utilization requirements; idle GPU deployments are not a classroom reservation strategy. Confirm class quota, persistence, hub-specific lifecycle and data terms.
https://nrp.ai/documentation/userdocs/start/policies

OSPool · documented education access
Checked October 12, 2026
OSPool supports instructor-led events with guest notebooks or facilitated full accounts. Guest sessions time out after four hours and may lose files; full accounts fit multi-day/semester workflows and known rosters. An event includes a short OSG-policy introduction.
Scope: Full accounts are normally disabled several days after the event; continuation needs agreement. Instructors rehearse materials first. Free throughput jobs are not reserved synchronous notebook/GPU capacity; licensed, long or multi-core workflows may be poor fits.
https://portal.osg-htc.org/documentation/support_and_training/training/ospool_for_education/

OSPool · data and access-point rules
Checked October 12, 2026
OSG working filesystems are not backed up; users retain essential copies elsewhere. Privacy-sensitive/proprietary data may not be stored or computed on OSG-managed resources. Persistent/intensive computation belongs in submitted jobs, not access points.
Scope: Use public or synthetic teaching inputs. Independent/checkpointable jobs have fair-share latency and may be interrupted. Required class deadlines need a local or other tested fallback.
https://portal.osg-htc.org/documentation/overview/references/policy/

PATh · affiliated-program eligibility
Checked October 12, 2026
PATh eligibility is tied to an accepted/active or planned/pending NSF award in listed affiliated programs; staff can provide startup credits for workflow prototyping.
Scope: IDSS is not explicitly listed on the checked page. MESA funding alone does not establish eligibility; seek provider/program-officer confirmation before building a course dependency. Absence from the list is not proof of permanent exclusion.
https://portal.path-cc.io/documentation/overview/account_setup/getting-started/

PATh · research-credit request
Checked October 12, 2026
After prototyping, full PATh credits are requested through the relevant NSF program officer using an award reference and a short technical justification of jobs, cores, memory, runtime and I/O.
Scope: This is separate from general OSPool education access. No request was sent and no startup or full credits were obtained. An instructor course is not automatically covered by an existing research award.
https://portal.path-cc.io/documentation/overview/account_setup/request-credits/

MESA portal · existing CyVerse account and quota
Checked October 12, 2026
MESA describes an alternative portal over the user’s CyVerse data, applications and analyses; sign-in reads the existing teams and resource quotas.
Scope: The portal does not create a duplicate compute allowance. Public documentation is not a signed-in entitlement or load test. Distinguish federally funded IDSS development from underlying state-funded or subscription-funded CyVerse accounts.
https://idss-mesa.github.io/docs/portal/overview/

MESA · application/resource selection
Checked October 12, 2026
The portal documents CPU/GPU application variants, launch options and linked Discovery Environment/OSG/Tapis workflows. Its GPU application description names Nvidia A16 nodes.
Scope: A GPU launch option does not prove permission, quota, class-wide capacity or access to the Jetstream2 A100 flavor modeled separately. Confirm the selected app, runtime, image and data-save behavior.
https://idss-mesa.github.io/docs/portal/applications/

MESA · save and session lifecycle
Checked October 12, 2026
Interactive applications have a time limit that can be extended; files intended for retention belong under ~/data-store. Save & Exit retains outputs; Terminate can discard unsaved session data.
Scope: Rehearse the exact app save/exit/restart/export path. The portal and Data Store are workflow/working-data services, not an independent campus backup or approved archival deposit.
https://idss-mesa.github.io/docs/portal/analyses/

CyVerse · class provisioning
Checked October 12, 2026
Instructors can request class/workshop resources, select services, assign organizers and enroll/approve student accounts with institutional addresses. Typical first-Tuesday maintenance should be considered.
Scope: The subscription page requires Pro/Commercial instructor access for workshops and mentions enrollment limits without giving a numeric limit in its current FAQ. Confirm student tiers, class limits and scheduled service windows. One instructor Pro account does not create 80 simultaneous student jobs.
https://learning.cyverse.org/edu/

ACCESS · eligibility, educational periods, review, renewal
Current policy checked October 8, 2026
Eligible U.S.-based educators may lead allocations. Educational projects align with individual courses or training periods; they are typically not extended. ACCESS accepts educational uses at all scales with suitable justification. Smaller project requests are reviewed continually; Maximize requests use semiannual review and renewal.
Scope: A pooled teaching-service proposal needs program/provider agreement about structure and eligible uses. An award does not guarantee future approval, permanent student accounts, synchronous GPU availability, or local support staffing.
https://allocations.access-ci.org/allocations-policy

ACCESS · allocation scale
Current program page checked October 8, 2026
Explore, Discover, and Accelerate have published credit limits of 400,000, 1,500,000, and 3,000,000 respectively; Maximize requests resource-specific allocations. Discover explicitly includes large classes and training events. Start smaller and upgrade if needed.
Scope: Limits are not guaranteed awards. Current policy awards up to half of the credit limit initially and the remainder through a justified supplement. Credits are not interchangeable with CPU core-hours or GPU-hours without resource-specific conversion. The deck does not prescribe Maximize merely because the user wants a large allocation.
https://allocations.access-ci.org/project-types

Jetstream2 · classroom allocation planning
Current planning guide checked October 8, 2026
Plan course duration, student count, instance size, GPU needs, active hours, and storage. Account for idle instances and operational overhead when estimating resource use.
Scope: The calculator uses illustrative demand assumptions, not provider benchmarks. CPU and GPU hours must be mapped to the chosen resource’s accounting; shared-service and course quotas require an actual operating design.
https://docs.jetstream-cloud.org/tutorial/classroom/allocation/

CyVerse · federal funding transition and UArizona state support
Checked October 12, 2026
CyVerse states that core NSF award support ended in 2024. Basic offers 200 normalized compute units/year, 5 GB storage and one concurrent job; free sharing/public links ended June 3, 2025. UArizona users can receive Pro through state TRIF support.
Scope: CyVerse is federally developed and used by federally funded projects, but current account subsidies are mixed; TRIF is state, not federal funding. Pro lists 25,000 units/year, 4 TB and four concurrent jobs, with GPU access by consultation. Published eligibility is not an account or whole-class provisioning test.
https://cyverse.org/subscribe

NRP · hosted open-weight model APIs
Checked October 12, 2026
NRP documents hosted browser chat and an OpenAI-compatible API for a changing catalog of open-weight language models.
Scope: Model/API access is a distinct product from a GPU training allocation. Models can be added or retired; verify current quotas, supported use and prompt/data handling before class. No account token or API call was tested.
https://nrp.ai/documentation/userdocs/ai/llm-managed

8. ACCESS request and DS/MLIS pilot

ACCESS CPU + GPU REQUEST AND TWO-COURSE PILOT | October 12, 2026
Reliable computing for teaching
Discussion draft · no award, staffing or budget approved

Use ACCESS for the large CPU and GPU allocation and the classroom pilot. Use campus UITS/AWS only to test CPU components, and free GPU resources to benchmark workloads before piloting. Size the ACCESS request from measured demand; consider CloudBank through ACCESS only if its managed service can meet the confirmed requirements.

COURSE CONCEPTS

Data science
Build a reproducible data-cleaning and exploratory-analysis notebook, then fit a small CPU model with held-out validation. Explain missingness, leakage, uncertainty and data provenance.
Generate a synthetic civic-service dataset with no real residents; keep core CSV inputs below 250 MB and test peak memory against the awarded workspace. Real/public datasets require a rights and data-classification check.
Requested: Python, JupyterLab, pandas, scikit-learn, matplotlib and an approved reproducible package manifest; R/RStudio only if the course requires it.
Acceptance: Run the whole assignment from a fresh student workspace; require execution without out-of-memory errors at the approved spec, reproducible key outputs and a complete exported submission.
Optional: GPU model training/evaluation can enter the ACCESS pilot after free-resource benchmarking and reproduction on the allocated GPU system, with a CPU-equivalent assessed route. Free notebooks are benchmark tools, not promised semester GPU capacity.

MLIS / Library and information science
Audit a collection catalog, normalize names/dates/identifiers, document a metadata crosswalk, query an embedded catalog database and export a preservation-ready package with README, schema, provenance and checksums.
Use a synthetic 10,000–100,000-record collection catalog with Dublin Core-style fields. Add public/licensed records only after rights review; exclude patron, circulation, donor and restricted collection records.
Requested: JupyterLab/Python, CSV/JSON/XML parsing and embedded SQLite; optional MARC parsing packages after approval. OpenRefine or other hosted applications require a separate provider fit check.
Acceptance: Execute the complete workflow in a fresh workspace; validate schema, record counts, identifiers and query results; reopen the exported package using the fallback environment.
Optional: MESA/CyVerse can demonstrate a data/workflow component after per-user Pro/TRIF, app, save/exit and export checks. It does not add quota or become a required dependency of this pilot.

PHASES

Before piloting · preparation weeks 1–2 | Test components and benchmark GPUs
Use already-authorized campus UITS/AWS CPU component tests and free Kaggle/Colab GPU notebooks. Pin synthetic inputs, run bounded measurements and retain correctness/export/failure evidence before any student canary. Greg’s total work, including grant preparation, is capped at four hours/week; no cash, purchases or new paid accounts are available.
Exit evidence: Reproducible CPU/GPU component results and a workload envelope, within available time. Local functional checks do not replace AWS/CUDA provider measurements.

After benchmarks · before canary | Submit a sized ACCESS CPU + GPU request
Use benchmark measurements and course demand to justify the large CPU/GPU allocation, storage, concurrency and resource exchanges. Disclose campus AWS test access. Select the appropriate ACCESS tier and approved educational project structure. Check CloudBank only as a managed alternative if capacity and scope fit; provider review may extend preparation.
Exit evidence: Complete PI/course/term attachments and approved CPU/GPU resource configuration; request submission and award remain human/provider actions.

After award · preparation weeks 3–4 | Run a ten-person component canary
After approved access, recruit up to ten consenting volunteers, five per course concept. Run one DS notebook and one metadata/database/export workflow with synthetic inputs. Measure setup, package/memory fit, save/restart/export and support effort. No real grades or private library data are needed.
Exit evidence: Both workflows succeed; actual service limits and unresolved defects are recorded. Stop or revise if core fit fails.

After canary · preparation weeks 5–6 | Rehearse the whole class and recovery
With provider approval, rehearse 80 student workspaces plus agreed staff use. Test account isolation, grading receipts, accessible instructions, independent restore and the CPU fallback. Update the usage and effort forecast from observed runs and actual weekly hours. Keep Greg’s total within four hours; TA/lead support is separate.
Exit evidence: All thirteen applicable checks have evidence, term support and any needed grant-funded costs confirmed; otherwise narrow or defer the classroom scope.

Weeks 1–15 | Teach the two-course pilot
Teach on the awarded ACCESS CPU/GPU environment after readiness sign-off. Review quotas, queue/session behavior, usage, storage, tickets and backups weekly. GPU activities use the benchmarked workload and a CPU-equivalent assessed route; MESA/OSPool extensions have separate checks. Campus AWS remains a component-testing route. Do not admit a course with unfunded necessary expenses or missing backup/support coverage.
Exit evidence: Record aggregate completion/access outcomes and actual costs; pause a failing component without removing the CPU course route.

Term end + two weeks | Export, close and decide
Provide learner exports and reconcile grades before closure. Preserve approved public outputs with suitable metadata; apply the institutional retention/deletion schedule to private records. Do not assume educational allocation extension. Decide whether next term needs a new project or confirmed renewal.
Exit evidence: Verified exports, measured restore, closed accounts, final report and a costed continuation decision.

HOURS AND GRANT DEPENDENCIES

Hours only. Greg has four hours/week total across this work and EduCloud. Over the illustrative six preparation + fifteen teaching + two close weeks, 92 hours is an upper bound, not reserved project time. The earlier role estimates still total 230 hours, a 138-hour gap before other commitments. They are unrevised demand estimates, not a feasible four-hour plan or committed staffing. Narrow the work or confirm distinct support before proceeding. No salary math, cash envelope or finance role.
Allocation and coordination (Greg): 22.0 potential hours over the modeled period. ACCESS request, provider scope, course dates and demand review.
Benchmark and component work (Greg): 34.0 potential hours over the modeled period. CPU/GPU runs, package/environment checks and reproducible result review.
Service operations (Greg): 78 potential hours over the modeled period. Accounts, monitoring, backups, export and issue triage; hours must be measured.
Instructional design and accessibility (Greg): 14.5 potential hours over the modeled period. Accessible instructions and equivalent CPU activities; institutional approval is separate.
Data, rights and recovery review (Greg): 25 potential hours over the modeled period. Coordinate rights/privacy destinations, recovery rehearsal and closeout; no authority to self-approve institutional requirements.
EduCloud grant preparation (Greg): 23 potential hours over the modeled period. Distinct stewardship/training/evaluation work packages; no grant submission or award implied.
Planning and incident buffer (Greg): 33.5 potential hours over the modeled period. Earlier incident/planning demand estimate; reduce scope or confirm distinct support when the four-hour envelope is exceeded.
Two course support TAs (Not appointed; grant-supported if funded): 102 potential hours over the modeled period. Per TA: 4 prep + 3/week × 15 + 2 close = 51 hours. Outside Greg’s four hours. No salary/rate assumed.
Two course leads (Course leads; named commitments pending): 70 potential hours over the modeled period. Per lead: 16 prep + 1/week × 15 + 4 close = 35 additional pilot hours. Outside Greg’s four hours. No salary requested; regular teaching/grading excluded.
Available cash budget is zero. Work needing paid support, storage, hosting, development or recovery must have a confirmed eligible EduCloud grant and allowable work package before spending. ACCESS is CPU/GPU resource allocation, not payroll. No grant award is asserted. Existing campus test access and free GPU resources must stay within their authorized no-purchase scope.
The earlier 230-hour demand exceeds the 92-hour upper bound by 138 hours across the modeled 23 weeks. Greg cannot be his own independent backup. The earlier separate backup estimate is 27 hours; no distinct person is committed. TA/course-lead hours are separate and unconfirmed. Institutional privacy/accessibility approval remains separate from Greg’s coordination.

PRE-CLASS READINESS (ALL PLANNED / NOT RUN)

scope | Greg + course leads | Before request
Confirm eligible PI, actual courses/leads, Greg’s four-hour/week total envelope, separate TA/lead hours, distinct backup and full-term coverage. No cash budget; fund any necessary expenses only from a confirmed eligible grant.
Evidence: Named owners, realistic hours log, separate support commitments and confirmed grant/allowable-cost evidence if paid resources are needed.
Stop if: Counting four hours per role, assuming grant award, missing backup, or unfunded necessary spending.

benchmark | Greg (operator) + course leads | Before student canary / request sizing
Complete campus AWS CPU component tests and free-resource GPU benchmarks; retain failures, correctness, measured memory/runtime, checkpoint/export results and workload scope. Reproduce representative GPU work on awarded ACCESS hardware before class.
Evidence: Versioned workload/environment manifest, dataset checksums, dated result rows, actual GPU/account limits and target-resource comparison. No measurements recorded yet.
Stop if: Unmeasured GPU amounts, treating free quota as guaranteed classroom capacity, or assuming benchmark timings transfer unchanged to ACCESS.

provider | Allocation lead + selected ACCESS provider | Before request / gate to class
Confirm ACCESS CPU/GPU allocation, separate resource exchanges, actual quotas/storage, course dates and project structure; campus AWS stays test-only. If CloudBank is selected, confirm service type, CPU/GPU availability and accounting.
Evidence: Provider response and approved award/resource configuration, recorded privately.
Stop if: Assuming unspecified limits, general broker terms or automatic renewal.

accounts | Operator + course leads | Canary; repeat before week 1
Every approved student/staff test account authenticates; student A cannot read/write student B files or instructor grading areas; removal/revocation works.
Evidence: Access matrix and dated test results; no passwords or roster identifiers in public reports.
Stop if: Access leakage, shared credentials or unverified removal.

software | Each course lead | Canary
Both complete representative assignments run on the approved CPU image from fresh workspaces; no paid account or GPU is required. Pin the approved environment and input checksums.
Evidence: Clean-run outputs, environment manifest, resource measurements and a known-good baseline.
Stop if: Missing packages, memory failure, unapproved app or required GPU dependency.

capacity | Operator + provider | 2–4 weeks before term
With provider permission, rehearse 80 simultaneous students plus agreed staff use in three representative sessions. Proposed p95 login-to-workspace ≤5 minutes; no unresolved assignment-blocking launch failure.
Evidence: Dated latency distribution, workspace success count, quota/usage forecast and provider-agreed concurrency.
Stop if: No permission/capacity evidence; peak spec exceeds awarded limits.

save | Course leads + TAs | Canary; repeat after image update
Edit, save, stop/restart and recover a notebook/data package; verify filesystem location and retention. Export and re-import it into the CPU fallback.
Evidence: Saved-file checksums, restart/export receipt and fresh-environment reopen.
Stop if: Student work depends on an unsaved session or cannot be exported.

grades | Course leads | Before graded use
Distribute a versioned assignment, collect it, reconcile all test submissions, preserve student authorship and instructor judgment, and import/export a test grade receipt through the approved LMS workflow. If Classroom 50 is selected, verify Team/Enterprise organization eligibility, permissions, billing controls and an independent export; Codespaces and Actions quotas remain separate.
Evidence: Submission manifest and grade reconciliation results in the approved institutional destination. Classroom 50 canary and quota/fallback records if selected; no additional Codespaces allocation assumed.
Stop if: A leaderboard/auto-score substitutes for the authoritative grade, or a missing receipt goes undetected.

data | IT/privacy reviewer + Libraries | Before student data
Approve provider and backup data destinations, lawful/appropriate datasets, access roles and retention. Keep grades/rosters in the approved LMS/institutional systems; publish only aggregate results.
Evidence: Approved data map, rights notes, retention schedule and service/accessibility review.
Stop if: Assuming research storage or this public site is approved for private student records.

accessibility | Greg (design coordination) + course leads | Before course admission
Rehearse keyboard and screen-reader access, readable instructions and equivalent small-data CPU/offline activity; resolve barriers in essential workflows.
Evidence: User/task review and course-lead sign-off, with accommodations and fallback instructions.
Stop if: An essential assessed activity is inaccessible without an equivalent route.

recovery | Primary + backup operators | Before course admission
Make independent copies in approved destinations and restore onto a different host/environment. Proposed RPO ≤24 hours and RTO ≤one business day; measure both.
Evidence: Restore logs, independent file checksums, recovery timing and backup-operator runbook rehearsal.
Stop if: No independent copy or unmeasured recovery; relying only on snapshots or cold archival retrieval.

support | Owner + TAs + operators | Before week 1; weekly
Publish actual staffed help windows and escalation route; rehearse an outage with CPU/small-data fallback. Proposed first response within one staffed business day; do not promise 24/7 support. Keep actual Greg hours within four/week across all duties; reduce scope when demand exceeds coverage.
Evidence: Coverage schedule, ticket routing, outage exercise and fallback delivery proof.
Stop if: Unfunded coverage, unreachable operator or missed class deadline without substitution.

exit | Service owner + course leads + Libraries | Before start; execute near term end
Schedule alerts 60/30/14/7 days before expiry; decide continuation at least 30 days before. Rehearse learner/grade export, retention and deletion; verify closure on the approved dates.
Evidence: End-of-term runbook, sample exports, provider confirmation of exit window and deletion/renewal decision.
Stop if: Relying on grace periods, unconfirmed education extension or archival deposits of private coursework.

EVALUATION

Access: login/spawn success and latency, plus interruptions that blocked coursework.
Teaching: clean-run assignment success, reproducible outputs, export/grade-receipt completeness and completion barriers.
Operations: actual staff-hours, ticket categories, service/storage consumption, recovery timings and cash charges.
Continuity: working CPU fallback, independent restore, learner exports and verified end-of-term closure.
Decision: compare results with the approved gates and local alternatives before adding courses or optional GPUs; improvement in educational outcomes is a question to evaluate, not a finding.

REQUEST DRAFT

STATUS
Draft for review — not submitted

PROJECT TITLE

UArizona Information Science CPU + GPU Teaching Allocation — [APPROVED TERM / YEAR]

OPPORTUNITY / RESOURCE

ACCESS allocation; tier selected from measured CPU/GPU request (Discover/Accelerate/Maximize as justified) / ACCESS CPU and GPU resources — exact providers/exchanges to confirm; CloudBank conditional

INTENDED USE

Classroom / Training

INSTITUTION

University of Arizona · College of Information Science

PI

Greg Chism (proposed PI; confirm ACCESS profile, affiliation and eligibility before submission)

CO-PIS

[APPROVED COURSE LEAD(S), IF CO-PIs]

PROJECT DATES

[PROJECT START: SIX WEEKS BEFORE COURSE] through [PROJECT END: TWO WEEKS AFTER FINAL COURSE DATE]

COURSE TITLES

INFO 521: Introduction to Machine Learning — proposed pilot candidate; LIS 671: Digital Curation and Digital Preservation — proposed pilot candidate

ENROLLMENT

80 planned students: 40 data science and 40 MLIS; confirm actual enrollments

STAFF ACCOUNTS

Up to six instructional/technical staff accounts; confirm role mapping and whether these count against provider limits

KEYWORDS

classroom computing; data science; library and information science; metadata; reproducibility; CPU notebooks

FIELD OF SCIENCE

Select the applicable education/information-science fields in the live ACCESS form.

SUPPORTING GRANT

No supporting research grant is asserted by this draft. Add a grant only if the PI confirms that the pilot falls within that award’s authorized scope. MESA/IDSS funding is not assumed to fund instruction or local operations.

PUBLIC OVERVIEW

The University of Arizona College of Information Science seeks an ACCESS CPU and GPU allocation to support reproducible data science and digital-curation teaching in [TERM / YEAR]. The initial proposed pilot includes INFO 521 and LIS 671, approximately 80 students, with later expansion contingent on measured demand and approval. Students will analyze data, evaluate appropriately sized models, normalize collection metadata, query catalogs and export documented outputs. Before piloting, we will test CPU components through campus UITS/AWS and benchmark GPU workloads on free resources. The classroom pilot will use approved ACCESS resources, with named local support, accessible CPU-equivalent activities, independent recovery and end-of-term exports. GPU amounts and provider fit will be justified by measurements rather than free-tier quotas.

PLANNED WORK SUMMARY

We propose a large CPU + GPU ACCESS allocation, beginning with a bounded two-course pilot and expanding only within an approved scope. Campus UITS/AWS is available to Greg Chism for CPU component testing only; free Kaggle/Colab GPU resources will provide pre-pilot benchmark measurements. Neither test route is the semester classroom hosting plan. All benchmark results are currently pending.

Proposed CPU workloads include small-model data analysis and metadata/SQLite exercises. Proposed GPU workloads include bounded small neural-network training and inference/evaluation; course leads must select the actual model, datasets and instructional need before benchmarking. Use synthetic or rights-cleared public inputs. Measure setup/run times, memory, correctness, checkpoints, failures and export. Reproduce a representative GPU run on the target ACCESS architecture before assuming performance transfers.

After the award, test up to ten volunteers, then provider-approved class concurrency and recovery. ACCESS is the planned CPU/GPU classroom route. Keep approved rosters/grades in institutional systems, independently restore files and close educational accounts at agreed dates. No supporting research grant, staff appointment or budget is asserted. CloudBank through ACCESS is an optional managed implementation only if scope, CPU/GPU capacity, accounting and course dates are confirmed. Do not combine its managed Classroom terms with general broker pricing.

OPERATING CONSTRAINT: Greg has four hours/week total for allocation, component testing, operations and grant preparation. There is zero cash budget. TA and course-lead effort is separate (course leads need no salary). Necessary paid support/storage/hosting awaits confirmed eligible EduCloud grant funding; no award or finance role is assumed.

RESOURCE JUSTIFICATION / AMOUNT

INITIAL PILOT CPU BASELINE: 80 students × 8 active workspace-hours/week × 15 weeks = 9,600 workspace-hours / 19,200 CPU core-hours at 2 vCPU per workspace; 25% allowance gives 12,000 workspace-hours / 24,000 CPU core-hours before staff, idle billing and orchestration. Preferred 6 GB RAM/student; initial homes 5 GB/student + 20 GB/course shared data = 440 GB before staff/overhead. These are workload descriptions, not universal ACCESS units.

GPU REQUEST: quantity pending pre-pilot free GPU benchmarks and target-resource verification. For each approved GPU workload, calculate measured charged run-hours × planned runs/student or group × participants/groups × repetitions, then add separately justified rerun/checkpoint allowance, staff tests and measured overhead. Record GPU model, VRAM, precision, software and any device fraction; session time is not automatically full-device GPU time. Convert with the selected provider’s current accounting/exchange rate. Do not request zero GPU by default: CPU and GPU both belong in the intended allocation.

LARGE ALLOCATION: confirm actual courses/terms/cohorts beyond the 80-seat pilot before extrapolating. Sum distinct CPU, GPU and storage demands across approved cohorts and subtract workloads already covered elsewhere. Do not double count campus AWS component tests as classroom CPU demand. Existing Jetstream2 scenarios (36,600 / 516,600 / 617,400 CPU SUs and an illustrative 1,920 fractional GPU-resource SUs) are comparison models, not this final request. The talk’s 480-seat calculator is also illustrative. Tier, numeric credits/resource units and concurrency/storage quotas remain incomplete until measured and provider-reviewed.

SOFTWARE AND ASSIGNMENTS

Python/JupyterLab with approved pandas, scikit-learn, matplotlib, CSV/JSON/XML parsing and SQLite; optional R/RStudio and MARC parsing packages only if needed and supported. Request version pinning and notebook distribution (for example, nbgitpuller) where the provider supports them. Confirm the actual grading extensions, assignment export and permissions; no LMS integration is presumed.

OTHER AVAILABLE RESOURCES

Campus UITS/AWS: Greg confirms access via requests, restricted in this plan to CPU component testing; exact limits/charges/dates need confirmation. Free Kaggle and Colab GPU resources: staff pre-pilot benchmarks only, subject to actual account eligibility, quotas and hardware availability. ACCESS provides the intended CPU and GPU classroom allocation. CloudBank is conditional through ACCESS. CyVerse/MESA, NRP and OSPool remain optional separate components; MESA funding is not automatically an instructional allocation or operations budget.

REQUIRED COMPLETION / ATTACHMENTS

- Actual course/term/enrollment and any additional cohorts for the large request — incomplete.
- Eligible designated PI/co-PI profiles and current required CV PDFs — incomplete.
- Tier-appropriate education/resource plan and required course syllabi; CloudBank specifically requires syllabus PDFs if selected — incomplete.
- Dated CPU component tests and free GPU benchmarks with target-resource accounting/scaling justification — not run.
- Provider-confirmed CPU/GPU units, storage/concurrency and educational project structure — missing.
- Named operators, confirmed term coverage and any eligible grant support, support/data/closure plan — pending.

REVIEW AND SUBMISSION STEPS

1. Complete CPU component tests and free GPU benchmarks before any student pilot; retain failed controls and reproducible artifacts.
2. Confirm the classroom/education scope and whether multiple courses/terms require separate projects. Keep unrelated MESA research work separate unless explicitly approved.
3. Choose the ACCESS tier from measured demand: Discover explicitly supports large classes; Accelerate or Maximize requires the relevant justification. “Large” alone does not select Maximize.
4. Complete the appropriate resource plan, course attachments and PI/co-PI CV PDFs using current portal guidance; this PDF is a supporting draft, not the final tier-specific submission.
5. Submit for separate CPU/GPU resource exchanges and needed quota/storage. If CloudBank proves feasible, use its documented ACCESS Classroom route and actual accounting instead.
6. Before piloting, reproduce benchmark workloads on the awarded resources and pass applicable classroom readiness checks. No award or reserved capacity is presumed.

PROVIDER QUESTIONS (NOT SENT)

- Which ACCESS tier and education project structure fit the confirmed multi-course CPU/GPU workload and term dates?
- Which CPU and GPU providers, device fractions, unit/exchange rates, storage and concurrency quotas can support the measured demand?
- Can the GPU benchmark workload be reproduced on the target architecture, and what queue/session/checkpoint constraints apply?
- How should the application disclose campus AWS CPU component tests and free GPU benchmarks without double counting classroom use?
- If CloudBank is feasible, which managed/broker service is offered, with what CPU/GPU capacity, accounting, staffing responsibilities and course dates?
- What expiry, next-term request, warning, export and deletion arrangements apply to this educational project?

BENCHMARK PROTOCOL (NOT RUN)

Download classroom-benchmarks.zip. On an already-authorized campus AWS CPU instance, run cpu_benchmarks.py for DS and MLIS; do not provision a new paid instance. Start at 1k/10k rows, then 100k if permitted.
Upload the self-contained DS or MLIS GPU notebook to Kaggle/free Colab, select GPU, enter actual quota/provider and run in order. One warm-up plus three measured runs use bounded synthetic inputs; missing CUDA is recorded as blocked and CPU fallback is disabled.
Retain environment/version/input hashes, wall/compute/setup times, CPU/RSS or CUDA allocator memory, correctness, checkpoint/reopen evidence and failures. Export the result ZIP before ending the notebook; independently record quota/session/billed units.
Set approved course/group/job multipliers and measured result paths in demand.json; run size_access.py. It rejects local CPU controls as provider/GPU evidence by default and leaves provider conversion blank until supplied from verified accounting.
Keep component maxima distinct from complete assignment/session time, idle/provisioning overhead, class concurrency, staff/reruns and storage. Avoid double counting components inside allocated sessions; replay on the target ACCESS architecture.
Greg has four hours/week across all preparation and operations, including grant work. These artifacts do not claim a course is ready, a grant is awarded or AWS/Kaggle/Colab/ACCESS measurements have been completed.

OPTIONAL CLOUDBANK CONCEPT

STATUS
Conditional alternative draft — not submitted; proceed only if managed Classroom fits the approved CPU/GPU strategy.

PROJECT TITLE

UArizona INFO 521 and LIS 671 CPU Classroom Pilot — [APPROVED TERM / YEAR]

OPPORTUNITY / RESOURCE

Explore ACCESS / CloudBank Classroom

INTENDED USE

Classroom / Training

INSTITUTION

University of Arizona · College of Information Science

PI

Greg Chism (proposed PI; confirm ACCESS profile, affiliation and eligibility before submission)

CO-PIS

[APPROVED COURSE LEAD(S), IF CO-PIs]

PROJECT DATES

[PROJECT START: SIX WEEKS BEFORE COURSE] through [PROJECT END: TWO WEEKS AFTER FINAL COURSE DATE]

COURSE TITLES

INFO 521: Introduction to Machine Learning — proposed pilot candidate; LIS 671: Digital Curation and Digital Preservation — proposed pilot candidate

ENROLLMENT

80 planned students: 40 data science and 40 MLIS; confirm actual enrollments

STAFF ACCOUNTS

Up to six instructional/technical staff accounts; confirm role mapping and whether these count against provider limits

KEYWORDS

classroom computing; data science; library and information science; metadata; reproducibility; CPU notebooks

FIELD OF SCIENCE

Select the closest available education/information-science field(s) in the live form; CloudBank gives Science and Engineering Education as an example.

SUPPORTING GRANT

No supporting research grant is asserted by this draft. Add a grant only if the PI confirms that the pilot falls within that award’s authorized scope. MESA/IDSS funding is not assumed to fund instruction or local operations.

PUBLIC OVERVIEW

The University of Arizona College of Information Science requests CloudBank Classroom access through ACCESS for a two-course pilot in [TERM / YEAR]: INFO 521: Introduction to Machine Learning (proposed) and LIS 671: Digital Curation and Digital Preservation (proposed). Approximately 80 students would use browser-based CPU workspaces for reproducible data analysis, small-model evaluation, metadata normalization, collection queries and portable research outputs. The pilot aims to reduce software setup barriers and improve continuity of access across different student devices. We will evaluate workspace access, assignment reproducibility, export/recovery and staff effort using aggregate results. Both courses will retain an equivalent small-data CPU fallback, with institution-supported oversight, data handling and end-of-term exports.

PLANNED WORK SUMMARY

We propose one 15-week teaching pilot preceded by six weeks of configuration/canary testing and followed by a two-week export/close period, subject to provider and ACCESS approval. The proposed INFO 521 component will use Python notebooks to clean synthetic tabular data, visualize patterns and validate small CPU models. The proposed LIS 671 component will normalize synthetic collection records, document metadata crosswalks, query an embedded SQLite catalog and export structured records with provenance. No GPU, external managed database or paid student account is necessary for required coursework.

We request persistent individual CPU workspaces for 80 students plus up to six course/technical staff accounts, institutional authentication, approved assignment distribution and a reproducible Python environment. The preferred student configuration is 2 vCPU, 6 GB RAM and an initial 5 GB home, or a provider-approved equivalent shown by rehearsal to run the assignments. Initial shared course data are modeled at 20 GB per course. Expand only after the canary demonstrates a justified need and the provider approves it. The college will designate course leads, primary/backup operators and support TAs, and will seek written operating commitments before classroom use; this draft does not claim those appointments or funds already exist.

A ten-volunteer canary will precede provider-approved concurrency testing, account isolation, assignment execution, saved-file restart/export, grading-receipt reconciliation, accessibility review and a restore to a different environment. We will maintain CPU/small-data alternatives and independently restorable copies in institution-approved destinations. Rosters and grades will remain in approved institutional/LMS systems. The educational project will have explicit closure/export dates; continuation requires a confirmed provider/ACCESS process rather than assumed extension.

Please confirm that the managed Classroom resource, rather than a general CloudBank commercial-cloud award, is appropriate; specify its accounting and credit/resource request amount. We can split the two courses into separate educational projects if ACCESS or the provider requires it.

CURRENT ROUTE DECISION: ACCESS is intended to cover CPU and GPU for the classroom. Campus AWS is for CPU component testing only; free GPU benchmarks precede piloting. This older CPU-only managed-Classroom concept is conditional and cannot replace the CPU/GPU plan without explicit confirmation of GPU coverage or an approved split implementation.

OPERATING CONSTRAINT: Greg has four hours/week total for allocation, component testing, operations and grant preparation. There is zero cash budget. TA and course-lead effort is separate (course leads need no salary). Necessary paid support/storage/hosting awaits confirmed eligible EduCloud grant funding; no award or finance role is assumed.

RESOURCE JUSTIFICATION / AMOUNT

Planning workload: 80 students × 8 active workspace-hours/week × 15 weeks = 9,600 student workspace-hours; 2 vCPU each implies 19,200 CPU core-hours of active demand. A 25% usage allowance gives 12,000 workspace-hours / 24,000 CPU core-hours before provider orchestration/idle billing and staff use. These are workload descriptions, not CloudBank SUs or ACCESS credit conversion. Request an initial 5 GB home per student plus 20 GB shared data per course: 80 × 5 + 2 × 20 = 440 GB before staff homes and provider overhead. Core tabular/catalog inputs are bounded below 250 MB each; the home/shared allowance covers notebooks, multiple assignment copies, outputs and approved small projects. Measure usage in the canary and grow only for justified semester needs with provider approval. The earlier 20 GB-home / 2 TB Jetstream2 assessment is a larger planning scenario, not a minimum CloudBank requirement. This conditional managed-CPU concept excludes GPU. The intended ACCESS allocation includes GPU separately; this concept is usable only if the CPU/GPU implementation and coverage are explicitly confirmed. Numeric CloudBank credit/resource amount remains to be supplied from the provider’s actual managed-Classroom accounting; do not enter the Jetstream2 VM model as CloudBank credits.

SOFTWARE AND ASSIGNMENTS

Python/JupyterLab with approved pandas, scikit-learn, matplotlib, CSV/JSON/XML parsing and SQLite; optional R/RStudio and MARC parsing packages only if needed and supported. Request version pinning and notebook distribution (for example, nbgitpuller) where the provider supports them. Confirm the actual grading extensions, assignment export and permissions; no LMS integration is presumed.

OTHER AVAILABLE RESOURCES

Campus UITS/AWS: Greg confirms access via requests, restricted in this plan to CPU component testing; exact limits/charges/dates need confirmation. Free Kaggle and Colab GPU resources: staff pre-pilot benchmarks only, subject to actual account eligibility, quotas and hardware availability. ACCESS provides the intended CPU and GPU classroom allocation. CloudBank is conditional through ACCESS. CyVerse/MESA, NRP and OSPool remain optional separate components; MESA funding is not automatically an instructional allocation or operations budget.

REQUIRED COMPLETION / ATTACHMENTS

- Final approved syllabus PDF for the data science course — missing.
- Final approved syllabus PDF for the MLIS course — missing.
- PI CV/résumé PDF and co-PI CVs if applicable — missing.
- Confirm INFO 521 and LIS 671 selection/offering, instructor consent, course sections, enrollment, class dates and project preparation/export dates — missing.
- Provider-confirmed resource configuration, accounting/request amount and one-versus-two-project structure — missing.
- Named operator/backup, course leads, data/support approvals and budget/workload commitments — pending.

REVIEW AND SUBMISSION STEPS

1. Designated eligible PI checks/creates their own ACCESS profile with matching institutional affiliation/email. No account has been created by this draft.
2. In the allocations portal, choose Explore ACCESS, Classroom / Training and CloudBank Classroom; confirm the current form and any course-specific project separation.
3. Paste the reviewed title, public overview, keywords, summary and provider-confirmed configuration/amount; supply the actual course dates/enrollment.
4. Attach the final approved syllabus PDFs and required CV/résumé PDFs, using the current portal/provider guidance. This generated request PDF is supporting draft text, not a substitute for either syllabus.
5. The human PI reviews scope, eligibility, disclosures, attachments and contact details before submitting. This site has no submission action.

PROVIDER QUESTIONS (NOT SENT)

- Can this general ACCESS Classroom route host two courses/80 students plus six staff, or do you require separate projects? What student CPU/RAM/home storage and shared storage can you provide?
- What units/credits should we request for the described workload, and what orchestration, idle use, storage and support are included? Are any uncovered charges possible?
- Can you pin the requested environment and support assignment distribution, grading permissions and complete student/instructor exports?
- What actual institutional login/roster roles, support windows, accessibility documentation, concurrency and maintenance arrangements apply?
- Can we automate or schedule independent file exports to approved destinations without shared credentials? What is the session/persistence behavior?
- Which project start/end, canary, export, deletion and next-term process applies? Please reconcile the one-year renewal description with ACCESS education-period/extension policy.

PRIMARY SOURCES FOR THIS PACKET

CloudBank Classroom · general ACCESS teaching route
U.S. educators can request a managed CPU classroom through Explore ACCESS with a syllabus, roster count and course dates. The provider configures institutional login, persistent student workspaces, Python/R/C++ and notebook/RStudio/VSCode tools.
Scope: This route does not state an AI-course requirement. It is distinct from AI-focused NAIRR Classroom and from general commercial-cloud dollar allocations. Per-student limits and 80-seat capacity are not published here. Its one-year renewal description needs reconciliation with ACCESS education-period policy.
https://www.cloudbank.org/training/access-cloudbank-classroom

ACCESS · Explore request contents
Explore requests need a work summary, PI/co-PI CV or résumé PDFs and project metadata. CloudBank’s provider guide additionally asks for course syllabi, enrollments and dates.
Scope: Use the current Explore/provider checklist, not the separate Maximize document requirements. The generated request PDF does not substitute for final syllabus or CV attachments.
https://allocations.access-ci.org/prepare-requests

ACCESS · eligibility, educational periods, review, renewal
Eligible U.S.-based educators may lead allocations. Educational projects align with individual courses or training periods; they are typically not extended. ACCESS accepts educational uses at all scales with suitable justification. Smaller project requests are reviewed continually; Maximize requests use semiannual review and renewal.
Scope: A pooled teaching-service proposal needs program/provider agreement about structure and eligible uses. An award does not guarantee future approval, permanent student accounts, synchronous GPU availability, or local support staffing.
https://allocations.access-ci.org/allocations-policy

CloudBank Classroom · current GPU capacity record
The resource registry updated September 28, 2026 states that the fall 2026 GPU pilot is at capacity and additional requests will be considered beginning in 2027.
Scope: Production status is not an available seat. Consideration in 2027 is not approval or guaranteed GPU availability. The registry rendered an as-of October 4 timestamp when checked; this is a documented capacity notice, not an independent real-time utilization measurement.
https://operations-api.access-ci.org/wh2/cider/v1/cider_resource_id/3739/?format=html

CloudBank Classroom · support-document scope conflict
The opening sections describe managed Classroom without batch queues; later storage/account sections describe user-created commercial-cloud storage and dollar awards.
Scope: The page contains mixed service scopes. Use the dedicated provider Classroom guide for the pilot design; confirm budget, storage, account and support mechanics for the actual requested service. Do not apply all broker billing terms to the managed hub.
https://support.access-ci.org/documentation/resources/cloudbank-classroom

UArizona HPC · instruction policy
Campus HPC documents Puma class groups, shared faculty research/class time allocations, unpredictable queues and instructor-led student help. Consultants can assist instructors but do not provide individual support to all students.
Scope: A documented local alternative, not confirmed account/time quota or reserved classroom capacity. Assess local access honestly before requesting national resources; GPU and deadline priorities are not guaranteed.
https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/

UArizona · rental storage rate and lifecycle
Rental storage lists $47.35/TB/year, billed for the fiscal-year maximum without proration. It is not backed up, though nightly snapshots may allow recent-file recovery. Controlled data is excluded.
Scope: The 3 TB/$142.05 example is capacity rent only, not an approved classroom backup service. Verify eligibility, billing and classification; student work/grades are not authorized for this destination by this report.
https://hpcdocs.hpc.arizona.edu/storage_and_transfers/storage/rental_storage/

UArizona · R-DAS no-cost group storage
R-DAS provides up to 5 TB per PI group for open research data, with campus/VPN access and PI/group setup. It is separate from HPC-mounted filesystems.
Scope: Potential no-cost location to verify, not a student-by-student entitlement, regulated/private-record destination or independent backup strategy. The site does not request an allocation or approve data placement.
https://hpcdocs.hpc.arizona.edu/storage_and_transfers/storage/rdas_storage/

UArizona · Tier 2 storage billing and restore
Tier 2 lists a subsidized first TB of active data, $23/TB/month above that, subsidized transfer, and cold storage/restore stages after inactivity. It excludes controlled data and requires a PI/billing account.
Scope: The $220.80 six-month comparison assumes 1.6 TB of billed active overage; actual object tiers/charges vary. Cold restores may delay access, so keep a warm independent copy. No classroom data authorization or billing setup is verified.
https://hpcdocs.hpc.arizona.edu/storage_and_transfers/storage/tier2_storage/

UArizona Libraries · backup and archival boundaries
Libraries distinguishes general working storage from preservation and recommends multiple copies, independent media/location, integrity checks and restore tests. Research storage destinations have data-classification limits.
Scope: The pilot needs its own approved data map and retention schedule. Institutional documentation is not evidence that any pilot backup, grade export or repository deposit has succeeded.
https://lib.arizona.edu/research/data/data-management/best-practices/storage

CyVerse · federal funding transition and UArizona state support
CyVerse states that core NSF award support ended in 2024. Basic offers 200 normalized compute units/year, 5 GB storage and one concurrent job; free sharing/public links ended June 3, 2025. UArizona users can receive Pro through state TRIF support.
Scope: CyVerse is federally developed and used by federally funded projects, but current account subsidies are mixed; TRIF is state, not federal funding. Pro lists 25,000 units/year, 4 TB and four concurrent jobs, with GPU access by consultation. Published eligibility is not an account or whole-class provisioning test.
https://cyverse.org/subscribe

UArizona · INFO 521 course candidate
The institutional course description identifies INFO 521: Introduction to Machine Learning as a three-unit course in machine-learning methods and their application.
Scope: Supports the public course title and conceptual fit only. It does not establish a future offering, enrollment, assigned instructor, syllabus approval or consent to the computing pilot. No private syllabus or intranet content is reproduced.
https://infosci.arizona.edu/course/info-521-introduction-machine-learning

UArizona · LIS 671 course candidate
The institutional course description identifies LIS 671: Digital Curation and Digital Preservation as a three-unit course addressing digital-information work in libraries, archives and records management.
Scope: Supports the public course title and conceptual fit only. It does not establish a future offering, enrollment, assigned instructor, syllabus approval or consent to the computing pilot. No private syllabus or intranet content is reproduced.
https://infosci.arizona.edu/course/lis/671

9. Classroom 50 assessment

CLASSROOM 50 SUCCESSOR ASSESSMENT | October 13, 2026

Classroom 50 is a workable successor for assignment management. It is not something we own, and it does not increase GitHub Codespaces free compute.
Workable successor to assess; no signed-in canary or adoption completed

ASSIGNMENT WORKFLOW

Individual/group assignments, starter repositories, submission tracking, feedback and autograding.
Rehearse a complete DS and MLIS assignment, including manual feedback and LMS grade reconciliation.

OWNERSHIP AND CONTROL

Fifty Foundation maintains the project and hosted app. Course repositories and configuration can be in our own GitHub organization.
Name two organization owners; export course configuration, rosters, submissions and scores to approved destinations.

HOSTING AND UPKEEP

Hosted app + GitHub dependencies; the CLI runs locally. GPL-3.0 permits a self-hosted option.
Self-hosting still needs authentication/proxy review, updates and recovery. No UArizona deployment or funded operator is assumed.

CODESPACES COMPUTE

Personal Free: 120 core-hours / 15 GB-month; Pro: 180 core-hours / 20 GB-month each month.
At two cores, approximately 60 or 90 active hours before storage or other limits. Organization plans have no included Codespaces quota.

GRADING COMPUTE

GitHub Actions is a separate service and allowance.
Confirm billing owner and zero-spend controls; test quota exhaustion and a non-Actions submission/grading fallback.

ACCESS RELATIONSHIP

ACCESS remains the proposed CPU + GPU classroom compute route.
Use portable Git/notebook assignments on approved ACCESS environments. An automated Classroom 50-to-ACCESS grading connection remains unbuilt and unverified.

BEFORE REQUIRED USE (NOT RUN)

1. Confirm the specific organization has Team/Enterprise coverage through an approved existing or education benefit; do not buy an upgrade.
2. With synthetic identities and data, rehearse invitation, assignment creation, student submission, autograding, instructor override and LMS grade reconciliation.
3. Review GitHub app permissions, browser tokens, default external proxy traffic, private repository visibility and roster/score retention before student data.
4. Exercise Codespaces quota exhaustion and Actions allowance exhaustion separately; demonstrate a portable local/ACCESS workflow without requiring student payment.
5. Export and restore repositories, configuration and submission/grade receipts; document distinct owners, maintainer outage and end-of-term removal.
6. Measure setup and support time inside Greg’s existing ten-hour weekly envelope, with TA/course-lead time separate. Defer if support cannot fit.

CLASSROOM 50 PRIMARY SOURCES

Classroom 50: project and license
https://github.com/foundation50/classroom50
Classroom 50: operation and course data
https://github.com/foundation50/classroom50/wiki/How-Classroom-50-Works
Classroom 50: prerequisites and education eligibility
https://github.com/foundation50/classroom50/wiki/Prerequisites-and-GitHub-Education
Classroom 50 web app: hosting and authentication
https://github.com/foundation50/classroom50/blob/main/web/README.md
Classroom 50: managing Actions cost
https://github.com/foundation50/classroom50/wiki/Managing-Actions-Cost
Codespaces · free personal-account quotas
https://docs.github.com/en/billing/concepts/product-billing/github-codespaces
Codespaces · verified student benefit
https://docs.github.com/en/education/about-github-education/github-education-for-students/about-github-education-for-students

10. Modal and commercial alternatives

MODAL AND SIMILAR COMPUTE PLATFORMS | October 16, 2026

Modal is a promising conditional instructor benchmark option, but its payment requirement and three-seat Starter workspace do not fit a no-card, zero-cash class default. Keep Kaggle/free Colab as the existing pre-pilot GPU routes, then replay on ACCESS CPU + GPU.
Documentation reviewed; no account, card, cloud workload, credit redemption, grant application or provider message performed.

MODAL | Conditional recurring credit
$30/workspace/month; three Starter seats
Python/container GPU jobs, controlled inference, fine-tuning and notebooks
DS: a small pinned training/inference run. MLIS: public-corpus OCR, embeddings or retrieval experiments.
Boundary: Payment method required; GPU, CPU and memory share credits. Set explicit usage and net-spend limits. Shared Endpoints tokens cost extra. Academic grant is an application, not funding in hand.

BEAM | Paid / historical free claim
$20/month Developer includes $20 credits; one seat
Python serverless GPU jobs, sandboxes and endpoints
DS/MLIS component hosting if funded; open-source runtime may warrant later engineering assessment.
Boundary: June free-$30 comparison is stale against current direct plan table. Prepaid deployments need credits; warm/idle settings can bill. BYOC is not free compute.

CEREBRIUM | Paid usage / possible trial
Free Hobby subscription; no recurring compute credit verified
Containerized CPU/GPU inference and batch processing
DS model serving; MLIS public-corpus embeddings or transcription.
Boundary: Free plan fee and included storage do not make execution free. Trials are discretionary/time-limited and may transition to paid billing.

PAPERSPACE GRADIENT | Bounded free machines
Free CPU / M4000 GPU subject to availability; 5 GB
Browser notebook experiments on an older GPU
Small DS training and public/synthetic MLIS corpus notebooks.
Boundary: Six-hour free-session maximum, one-hour idle stop, one free notebook at once; free notebooks are public. Check old GPU/runtime fit and actual signup/payment requirements.

LIGHTNING AI | Promotional / account-dependent
One free CPU Studio; GPU credit amount and expiry vary
CPU development followed by a short credited GPU run
DS/MLIS notebook preparation and small tests within actual credit balance.
Boundary: Four-hour CPU restart boundary; first 10 GB storage free. Do not promise a fixed monthly GPU grant or count paid academic discounts as free compute.

SATURN CLOUD | Unconfirmed free lead
Landing page advertises 150 compute hours/month, no card
Notebook/GPU environment if current free eligibility is confirmed
Potential DS and MLIS notebook alternative, pending an authorized account check.
Boundary: 150 compute hours is not verified as 150 GPU-hours. Current pricing emphasizes paid hosted resources; reconcile device allowance, storage, inactivity and new-account access.

RUNPOD | Paid comparison
Prepaid compute; no recurring free allocation verified
GPU Pods, containers and serverless endpoints
Funded DS/MLIS jobs with explicit checkpoint and external export.
Boundary: Pod launch needs credit; stopped storage still bills and can be deleted when funds run out. Not a zero-cash fallback or preservation repository.

REPLICATE | Limited model trial
Select-model demonstrations, then billing
Managed model inference rather than a general GPU notebook
DS model-behavior comparison; MLIS controlled metadata/transcription demonstrations.
Boundary: No stable free monthly grant verified. Private deployments can bill setup and idle time. A model API does not replace arbitrary CUDA training.

HUGGING FACE INFERENCE PROVIDERS | Paid API on Free accounts
No included monthly API credits for Free users
Routed model APIs; paid credits/subscriptions
DS inference evaluation and MLIS embeddings/metadata tasks when funded.
Boundary: Separate from ZeroGPU/Spaces. Current API pricing overrides older free-credit snippets; no historical change date established.

MODAL RATE ILLUSTRATION (NOT MEASURED)

Standard Functions, 2 physical CPU cores and 8 GiB memory; the full $30 monthly allowance is available. Excludes startup/warm overhead, other usage, storage/egress and region/execution multipliers. Not the Sandbox/Notebook CPU rate.
T4: $0.748656/hour; approximately 40.1 hours from $30 before excluded costs.
H100: $4.107456/hour; approximately 7.3 hours from $30 before excluded costs.

BEFORE AN AUTHORIZED CLOUD CANARY (NOT RUN)

1. Use only an approved institutional payment arrangement or explicitly confirmed grant exception; require no personal/student card. No spending is authorized.
2. Confirm current grant/credit eligibility, duration, three-seat workspace fit, allowed products, data destinations and provider-reviewed class/account terms. Never multiply one workspace allowance by 80 seats.
3. Before any authorized run, review usage budget and net-charge spend limit separately; disable excluded paid APIs, unneeded schedules, warm containers and automatic purchasing. Verify the actual stop behavior.
4. Pin code/image/data; measure build/start/warm time, CPU, GPU, memory, device/VRAM, preemption, checkpoints, outputs and charged units. API results do not measure a custom CUDA training workload.
5. Export code, environments and results outside the vendor; retain authoritative grades/rosters in approved institutional systems. Replay representative CPU/GPU workloads on awarded ACCESS resources before class.
6. Keep all added setup/support inside Greg’s ten-hour weekly envelope, with TA/lead effort separate. Defer the option if funding, support or privacy conditions fail.

RESEARCH METHOD AND CONFLICTS

Eight Exa searches requested 55 result slots across serverless credits, notebook alternatives and inference billing. These are not 55 independent validated sources. Direct primary pages were checked; extraction omissions and conflicting older marketing are retained in the local audit.
Beam direct pricing overrides the earlier free-$30 blog; do not invent an effective change date. Saturn device-specific free entitlement and new-account access remain unconfirmed. Paperspace free machine session guidance overrides the generic marketing timer. HF API pricing does not describe ZeroGPU.

PRIMARY SOURCES FOR THE COMMERCIAL COMPUTE EXTENSION

Modal Starter pricing and Shared Endpoints boundary
$30 of compute per workspace per month on Starter; up to three seats and ten concurrent GPUs. Functions, Sandboxes and Notebooks use CPU/memory/GPU billing; Shared Endpoints tokens are excluded from included compute, effective September 1, 2026.
Scope: Free subscription does not mean unlimited compute. GPU, CPU and memory share the allowance; startup/warm time, region/execution multipliers and other charges matter. Workspace concurrency is not reserved capacity or a class roster.
https://modal.com/pricing

Modal billing: payment method required
A payment method is required to use Modal. Usage above applicable credits and subscription fees can be automatically charged.
Scope: Not a no-card classroom default for this zero-cash program. An approved institutional payment arrangement or confirmed grant exception must precede any canary; no personal or student card requirement is proposed.
https://modal.com/docs/guide/billing

Modal budgets and out-of-pocket spend limits
Workspace budgets cap usage before credits; a separate workspace spend limit caps net charges after credits. Without a custom spend limit, the default is the usage limit less credits. Environment budgets require Team/Enterprise.
Scope: Explicitly review both limits and excluded services. A default usage limit is not a zero-out-of-pocket setting. Verify actual stop behavior and billing attribution in an authorized synthetic canary; documentation is not a tested billing guarantee.
https://modal.com/docs/guide/budgets

Modal academic credit grants
Modal offers an academic application route; its pricing page advertises up to $10,000 in credits for graduate students, labs and researchers.
Scope: Application-based credits, not an ACCESS award, received funding, or a promised class-wide entitlement. Confirm course eligibility, seats, duration, payment requirements and allowed products in writing before counting any grant.
https://modal.com/academics

Beam current plan table
Direct current plan table lists Developer at $20/month with $20 in credits each month and one seat; Team is $89/month plus usage. Monthly included credits expire at renewal.
Scope: This is a paid subscription, not free $20 compute. The extracted page omitted the plan table; the direct HTML was checked. Earlier free-credit blog language does not establish current eligibility.
https://www.beam.cloud/pricing

Beam runtime and prepaid credit billing
Prepaid workspaces require credits to build/deploy. Active container execution, initialization and configured warm time are billed; reserved machines bill until released.
Scope: Free included storage does not provide free GPU execution. Open-source Beta9/BYOC still needs a funded host and operator; no ACCESS integration or no-cost campus deployment has been demonstrated.
https://docs.beam.cloud/v2/resources/pricing-and-billing

Beam earlier free Developer comparison (historical)
The June 27, 2026 provider comparison described a free Developer plan and $30/month of credits.
Scope: Historical marketing conflicts with the current $20/month Developer plan table checked October 16. Current direct pricing takes precedence; effective change date and account grandfathering are unknown. Do not use competitor price judgments as independent evidence.
https://www.beam.cloud/blog/modal-pricing-explained

Cerebrium Hobby subscription versus metered compute
Hobby has a free subscription with three seats and three deployed apps; GPU/CPU/memory remain metered. Current pricing includes the first 100 GB of storage.
Scope: No recurring free GPU compute allowance was established. Earlier $30 promotional-credit copy is not a current monthly grant. No subscription fee is different from no usage charge.
https://cerebrium.ai/pricing

Cerebrium trial terms
Trials are discretionary, time-limited and may require billing details; subscription billing can start at trial end if not cancelled.
Scope: Do not count a possible trial as semester capacity. Confirm the actual offer, expiration and payment transition before use; no trial was activated.
https://cerebrium.ai/terms-of-service

DigitalOcean Paperspace: free machine and storage eligibility
Free CPU and M4000 Free GPU machines are listed for the Free Gradient plan, with 5 GB included storage. Paid GPU machine types and higher subscription tiers are separate.
Scope: Only explicitly free machine types qualify. Shared availability, old GPU/software compatibility, storage overages and actual account/payment setup need checking; no free seat or private class service is reserved.
https://docs.digitalocean.com/products/paperspace/pricing/

Paperspace notebook free-session duration
Free-machine notebooks have a maximum six-hour auto-shutdown timeout.
Scope: Do not apply the marketing page generic 12-hour timer to free GPUs. Work must checkpoint/export within the free machine limit; availability is not guaranteed.
https://docs.digitalocean.com/products/paperspace/notebooks/details/features/

Paperspace free machines: visibility and inactivity
Provider documentation says free-plan free-machine notebooks are public, one free notebook can run at a time, and a one-hour idle interval can shut it down.
Scope: Use only approved public/synthetic teaching content. A private workspace account label does not mean the notebook is private. New-account provisioning and payment requirements remain untested.
https://docs.digitalocean.com/products/paperspace/machines/details/features/

Lightning AI · billing and storage scope
Eligible free users receive promotional credits, with eligibility, amount and expiration subject to change. One CPU Studio and the first 10 GB of Drive storage are free; other compute and storage can consume credits.
Scope: No fixed recurring GPU allowance is promised by current billing terms. Academic discounts are paid. Check actual account credit expiry and the four-hour CPU session/restart boundary before class.
https://lightning.ai/docs/platform/overview/faq/billing.md

Lightning AI student documentation and free CPU workflow
Students can start with a CPU Studio; free CPU sessions have a four-hour restart boundary. Eligible academic discounts are paid, not an unlimited free GPU grant.
Scope: Read promotional GPU hours and signup-credit examples alongside billing terms: eligibility, grants and expiration can change. No new-account GPU allowance was tested; avoid promising a fixed monthly credit value.
https://lightning.ai/docs/platform/overview/setups/academia/students

Saturn Cloud free-compute landing claim
The accessible landing page advertises 150 hours/month with GPU access and no credit card.
Scope: Do not interpret this as 150 dedicated GPU-hours. Device split, current new-account access, storage, retention and concurrency were not confirmed. The current pricing route emphasizes metered hosted resources; this remains an unverified lead.
https://saturncloud.io/try/

Saturn Cloud current hosted pricing
Current hosted pricing lists hourly CPU/GPU resources and storage charges, alongside contract enterprise/operator offerings.
Scope: Reconcile the separate 150-hour landing claim before recommending a free class route. No signup, current free entitlement or provider reservation was tested.
https://saturncloud.io/plans/saturn_cloud_plans/

Runpod credit balance and storage lifecycle
Runpod uses prepaid credits; a new Pod needs at least an hour of credit for its configuration. Stopped Pod storage still costs money, and depleted balances can lead to deletion.
Scope: Paid comparison only; no generally available recurring free allocation was verified. Storage supports active workloads, not archival preservation. Optional promotions are not an institutional award.
https://docs.runpod.io/get-started/billing-information

Replicate limited free models and billing scope
Select models can be tried without payment for a limited amount before billing is required. Public model inference is distinct from private models/deployments, whose setup, active and idle time can be billed.
Scope: A short model demonstration is not a fixed monthly grant or arbitrary GPU notebook/training entitlement. No stable free allowance was established for required class work.
https://replicate.com/docs/topics/billing

Hugging Face Inference Providers: current free-account credits
Current pricing lists no monthly Inference Providers credits for Free users; purchased credits or a paid subscription are required. Paid Pro/Team/Enterprise plans include separate credits.
Scope: This is the routed inference API, not the ZeroGPU/Spaces daily allowance. Do not infer a historical withdrawal date or universal closure from this current quota. General marketing and older snippets still describe free-tier access.
https://huggingface.co/docs/inference-providers/pricing

11. Publishing and guide assessment

CONCISE COMPUTE GUIDE AND PUBLISHING ASSESSMENT | October 19, 2026
The guide now uses pinned Zensical 0.0.71 on the existing GitHub Pages host. Short task-based pages, client-side search, resource/evidence filters and collapsed audit detail preserve the original URLs, five-slide talk and downloads. MESA's public landing page informed direct headings, spacing and simple actions; its code/private content was not copied.

Publishing alternatives: Zensical fits the Python/static documentation workflow with search and custom CSS/JavaScript. Astro Starlight is a strong component-oriented alternative but adds a Node/Astro workflow. Quarto is useful when notebook/report authoring becomes central. Custom HTML retains maximum control but requires maintaining navigation/search. These are authoring engines, not compute resources. Version pinning and upgrade compatibility checks remain necessary.

needs.html provides local classroom/research planning examples: runs x wall hours x configured cores or GPU devices x allowance. Peak resources and logical storage/copies are separate. It exports all assumptions to text/JSON, flags sensitive-data permissions, support over Greg’s four-hour total weekly capacity and missing backups, and does not infer provider credits or approve readiness. Different groups/courses require separate scenarios; continuous-service uptime needs separate sizing. Input evidence is self-reported. Every export remains ineligible for submission. Use actual benchmark results and target replay next.

All 13 classroom checks remain planned. No provider job, award, account, purchase, grant submission or classroom deployment is established. ACCESS remains the intended CPU/GPU classroom route; campus AWS is only component testing; free GPUs support preliminary benchmarks. Zero cash and four total Greg hours/week still apply; TA/lead effort is separate.

Publishing/design primary references reviewed October 19, separate from the 181-record compute ledger:
https://idss-mesa.github.io/
https://zensical.org/docs/
https://zensical.org/docs/customization/
https://zensical.org/docs/setup/search/
https://zensical.org/docs/publish-your-site/
https://zensical.org/docs/compatibility/mkdocs/migration/
https://zensical.org/docs/compatibility/mkdocs/plugins/
https://starlight.astro.build/
https://quarto.org/docs/websites/
https://pypi.org/pypi/zensical/json

12. Working-group packet and campus inventory

COMPUTING RESOURCES WORKING GROUP | October 19, 2026
College of Information Science
Computing Resources Working Group
DRAFT WORKING PACKET | October 19, 2026
Point people: Barney Maccabe | maccabe@arizona.edu; Greg Chism, Faculty Director of Instructional Computing | gchism@arizona.edu

College of Information Science: computing for research and instruction, including AI, data science, digital scholarship, games and extended reality, software, data and the people who support them.
Working resource and draft deliverables; not endorsed recommendations or a completed college assessment.

OBJECTIVES

Understand the current landscape
Identify needs and opportunities
Explore alternative approaches

DELIVERABLES

Resource inventory | Seeded draft; college entries and service-owner verification pending
Preliminary draft: End of Fall 2026 semester
inventory.html

Needs and gaps assessment | Assessment structure ready; faculty/student inputs not collected here
Preliminary draft: End of Fall 2026 semester
needs-assessment.html

Portfolio of approaches | Candidate approaches for comparison; no selection or commitment
Preliminary draft: End of Fall 2026 semester
approaches.html

Recommendations | Draft action framework; group review and priorities pending
Preliminary draft: End of Fall 2026 semester
recommendations.html

MILESTONES

October–November 2026 | Build the baseline
Confirm scope and resource owners; review campus routes; gather research, teaching and student perspectives.
Output: Versioned inventory, agreed input process and a list of unknowns.

November–end of Fall 2026 semester | Draft all four deliverables
Validate significant barriers; compare approaches; separate college actions from university dependencies.
Output: Preliminary inventory, needs assessment, portfolio and recommendations.

Early Spring 2027 | Refine and circulate within the college
Review drafts with faculty, students and resource owners; resolve corrections and agree priorities.
Output: Revised intra-college drafts with evidence, owners and unresolved questions.

As university discussions develop | Carry college priorities forward
Prepare the shared-service, policy, staffing and infrastructure questions that require university participation.
Output: College briefing for anticipated university-wide planning; timing not yet set.

USE AND REVIEW

The resource tool offers explicit submission of a reviewed public/synthetic brief and contact details to a private pilot queue for Barney and Greg. Optional Luna drafting is separate and does not persist briefs in the drafting service. The queue stores submissions and review notes until reviewers delete them; it is outside university Microsoft 365 and is not for sensitive data. Agree deliverable owner roles and the review process. No group endorsements, college-wide needs totals, staff availability or funding are assumed. The separate pilot retains its own zero-cash/four-hour constraints.

SEEDED RESOURCE INVENTORY

UITS Support | University | Available
Access: University faculty, staff and students can contact the UITS 24/7 Support Center by phone, chat or online ticket.
Cost: Basic diagnostics and fixes are available at no cost to campus community members. Repair services and specialist resources may have separate terms; confirm before use.
Contact: UITS 24/7 Support Center · 520-626-8324 · service.arizona.edu | https://it.arizona.edu/support/247-support-center
Support: Campus applications, accounts, connectivity, software installation and basic device troubleshooting; specialist needs are routed for confirmation.
Limits: General support does not guarantee RSE time, research workflow development, hardware capacity or an allocation. Repair and specialist service terms need confirmation.
Funding: University support service; specialist capacity and separate charges require confirmation.
Sources: https://it.arizona.edu/support/247-support-center
Review: 2026-10-20
Support channels and no-cost basic diagnostics verified on the UITS support page October 20, 2026. College-specific service ownership corrected at Greg Chism’s request.

College hardware, labs and loan equipment | College | Inventory pending
Access: Ask Barney Maccabe or Greg Chism to coordinate a roster of machines, locations, owners, access rules and any loan pool.
Cost: Unknown; inventory existing commitments and hours before proposing funding.
Contact: Barney Maccabe or Greg Chism — working-group point people | program.html
Support: Barney Maccabe or Greg Chism — working-group point people
Limits: No shared college CPU/GPU pool, equipment checkout entitlement or spare capacity is verified.
Funding: To document; no new funding, staff time or loan inventory assumed.
Sources: https://infosci.arizona.edu/people/barney-maccabe
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Inventory question, not a verified service entitlement. Routing contact designated by the user; profile confirms role/email.

College software, datasets and agreements | College | Inventory pending
Access: Ask the working group to identify license/data owners, storage, renewals and permitted research/classroom use.
Cost: Unknown; inventory existing commitments and hours before proposing funding.
Contact: Barney Maccabe or Greg Chism — working-group point people | program.html
Support: Barney Maccabe or Greg Chism — working-group point people
Limits: No college license roster, API allowance or training/distribution rights verified.
Funding: To document; no new funding, staff time or loan inventory assumed.
Sources: https://infosci.arizona.edu/people/barney-maccabe
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Inventory question, not a verified service entitlement. Routing contact designated by the user; profile confirms role/email.

College research labs and collaborators | College | Documented route
Access: Explore the college research-labs directory; approach the relevant lab lead for a research collaboration.
Cost: No general-use fee schedule or guaranteed shared access published.
Contact: College research-labs directory; Barney Maccabe or Greg Chism for working-group coordination | https://infosci.arizona.edu/research-faculty/research-labs
Support: College research-labs directory; Barney Maccabe or Greg Chism for working-group coordination
Limits: A lab listing establishes research capability, not open compute, staff availability or a classroom reservation.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://infosci.arizona.edu/research-faculty/research-labs
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

co/lab: Critical Archives & Curation Collaborative | College | Documented route
Access: Discuss digital curation, obsolete media/computers and digital-forensics collaborations with the co-directors.
Cost: Shared equipment access, project charges and supervision not published.
Contact: Co-directors Jamie A. Lee and Zack Lischer-Katz — lab page | https://infosci.arizona.edu/colab-critical-archives-curation-collaborative
Support: Co-directors Jamie A. Lee and Zack Lischer-Katz — lab page
Limits: Research collaboration and preservation capability; no public equipment checkout policy, GPU entitlement or staffed digitization service.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://infosci.arizona.edu/colab-critical-archives-curation-collaborative
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

XRG: Extended Reality & Games Lab | College | Documented route
Access: Discuss XR, virtual/augmented reality and interaction research with the lab leads.
Cost: No general-use equipment rate or access entitlement published.
Contact: Lila Boz and Ren Boz — lab leads listed on XRG page | https://infosci.arizona.edu/xrg-lab
Support: Lila Boz and Ren Boz — lab leads listed on XRG page
Limits: Research lab, not a documented open GPU lab or college equipment-loan service; confirm scheduling and participation.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://infosci.arizona.edu/xrg-lab
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

College course technology requirements | College | Documented route
Access: Check the program-specific minimum hardware and operating-system requirements before designing an activity.
Cost: Student-owned device requirements; no provided machine or subsidy established.
Contact: Course lead or faculty adviser; college office for routing | mailto:infosci@arizona.edu
Support: Course lead or faculty adviser; college office for routing
Limits: Requirements vary by degree. Device specifications do not establish college-owned inventory or access to loan equipment.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://infosci.arizona.edu/technology-requirements
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Campus HPC: Puma CPU and GPU | University | Documented shared allocation
Access: Registered faculty PI groups receive 150,000 CPU core-hours per PI group each month, shared by research and class groups. CPU, GPU and high-memory jobs debit the same CPU-based pool; this is not 150,000 GPU-hours. Unused hours expire at month end.
Cost: Standard allocation and HPC consulting have no charge. High-priority access requires a separate buy-in; windfall jobs are lower-priority and preemptible.
Contact: HPC Consult — ServiceNow ticket | https://uarizona.service-now.com/sp?id=sc_cat_item&sys_id=12eaba153bf9ba5017be8a8a25e45a7d
Support: HPC Consult via ServiceNow; published hours 8 am-5 pm Monday-Friday, excluding university holidays.
Limits: Published standard concurrency ceiling: four GPUs and 3,290 CPUs per group, shared across users; this is a limit, not a reservation. Shared queues give no guaranteed start time or priority for assignment deadlines. Instructors provide student support; HPC Consult helps instructors on weekdays, not weekends or university holidays. Confirm remaining PI balance, resource limits and course fit; no class reservation is established. Lynx/H200 is explicitly not available yet. Published Puma MIG memory figures differ between the table and narrative; confirm the requested device.
Funding: University standard allocation; buy-in and special-project awards have separate conditions. Local support capacity is not implied.
Sources: https://hpcdocs.hpc.arizona.edu/resources/allocations/ | https://hpcdocs.hpc.arizona.edu/resources/compute_resources/ | https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/running_jobs/job_limits/
Review: 2026-10-20 — current public allocation, teaching, hardware and support documentation; no signed-in balance or workload test
Current published Puma allocation and classroom permission verified directly. This does not verify Greg’s remaining balance, a course reservation, allocation renewal or staffing. A Jeremy Frumkin (UITS) slide in supplied October 14–15 briefing notes adds hardware context, not a classroom allocation or reservation; the slide lists 40 GB A100 MIG slices on Puma.

Campus HPC: Puma classroom computing | University | Class groups permitted
Access: Faculty PIs may create class groups for instruction on Puma. 150,000 CPU core-hours per PI group each month, shared by research and class groups. CPU, GPU and high-memory jobs debit the same CPU-based pool; this is not 150,000 GPU-hours. Unused hours expire at month end.
Cost: No added class allocation or dedicated class storage. Standard allocation and consulting have no charge; research and teaching share the PI pool.
Contact: HPC Consult — instructor should open a ticket | https://uarizona.service-now.com/sp?id=sc_cat_item&sys_id=12eaba153bf9ba5017be8a8a25e45a7d
Support: HPC Consult helps instructors set up class groups and troubleshoot infrastructure. Students get course support from their instructor/team; no individual student consulting is promised.
Limits: Published standard concurrency ceiling: four GPUs and 3,290 CPUs per group, shared across users; this is a limit, not a reservation. Shared queues give no guaranteed start time or priority for assignment deadlines. Instructors provide student support; HPC Consult helps instructors on weekdays, not weekends or university holidays. Confirm remaining PI balance, resource limits and course fit; no class reservation is established.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/ | https://hpcdocs.hpc.arizona.edu/resources/allocations/ | https://hpcdocs.hpc.arizona.edu/registration_and_access/group_management/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/resources/compute_resources/ | https://hpcdocs.hpc.arizona.edu/running_jobs/job_limits/
Review: 2026-10-20 — current public teaching and allocation policies; no signed-in balance, reservation or class-load test
The current teaching policy explicitly permits Puma class groups, superseding the earlier Ocelote-only uncertainty. Specific course capacity, remaining balance, supported data and readiness still need validation. A Jeremy Frumkin (UITS) slide in supplied October 14–15 briefing notes adds hardware context, not a classroom allocation or reservation; the slide lists 40 GB A100 MIG slices on Puma.

HPC active storage and transfers | University | Documented route
Access: HPC account: 50 GB home; PI group: 500 GB communal space. Temporary xdisk on request: 200 GB–20 TB, up to 300 days.
Cost: Standard spaces supplied with account/group; rental is a separate priced service.
Contact: HPC Consult — ServiceNow ticket | https://uarizona.service-now.com/sp?id=sc_cat_item&sys_id=12eaba153bf9ba5017be8a8a25e45a7d
Support: HPC Consult — ServiceNow ticket
Limits: HPC data are not backed up; xdisk is temporary and node /tmp is cleared after a job. Storage quotas do not provide preservation or regulated-data approval.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://hpcdocs.hpc.arizona.edu/storage_and_transfers/storage/hpc_storage/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

HPC software, containers and shared model data | University | Documented route
Access: Use HPC modules, user environments and containers; shared datasets include Llama 2 and AlphaFold inputs.
Cost: Open-source tools may have no license charge; licensed products and model terms still apply. Compute uses the allocation.
Contact: HPC Consult — software/setup questions | https://uarizona.service-now.com/sp?id=sc_cat_item&sys_id=12eaba153bf9ba5017be8a8a25e45a7d
Support: HPC Consult — software/setup questions
Limits: Availability varies by module/version. Llama 2 has its own community license; model memory/storage requirements can be substantial. A software listing is not permission for every use.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://hpcdocs.hpc.arizona.edu/software/common_datasets/ | https://hpcdocs.hpc.arizona.edu/software/overview/ | https://hpcdocs.hpc.arizona.edu/software/popular_software/ollama/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

HPC consulting and visualization support | University | Documented route
Access: Open a ServiceNow ticket for onboarding, queue issues, code optimization and resource advice; request visualization help through its team.
Cost: HPC consulting is published as free of cost.
Contact: HPC Consult ticket; visualization: vislab-consult@list.arizona.edu | https://uarizona.service-now.com/sp?id=sc_cat_item&sys_id=12eaba153bf9ba5017be8a8a25e45a7d
Support: HPC Consult ticket; visualization: vislab-consult@list.arizona.edu
Limits: HPC team support hours: weekdays 8 a.m.–5 p.m., excluding university holidays. Consultation is not an assigned engineer or individualized student homework support.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

AI Verde → Arizona AI Assistant: planned transition | University | ORAI transition update; timing to confirm
Access: Wolfgang Jentner at the Office of Responsible AI (ORAI), via Greg Chism, reports AI Verde will be sunset in favor of Arizona AI Assistant. Use the new portal to check sign-in, API access and enrollment; migration timing and eligibility need confirmation.
Cost: Planned $200/month of AWS Bedrock credit, reported by Wolfgang Jentner at ORAI and relayed by Greg Chism on October 19, 2026. Confirm who receives the allowance, renewal, covered usage and overage controls; not an unlimited compute or GPU-training allocation.
Contact: Wolfgang Jentner · Office of Responsible AI (ORAI) · wjentner@arizona.edu | mailto:wjentner@arizona.edu
Support: Wolfgang Jentner · Office of Responsible AI (ORAI) · wjentner@arizona.edu
Limits: Supplied ORAI pricing screenshot lists 12 hosted models and per-token prices. These campus gateway rates differ from direct-provider rates. Credit is not transferred to this site’s OpenAI API; API compatibility, data rules, class concurrency and migration/export still need confirmation.
Funding: Campus Bedrock credit reported by Wolfgang Jentner at ORAI, via Greg Chism; allocation level and renewal terms to confirm.
Sources: https://ai-assistant.responsibleai.arizona.edu/ | https://news.arizona.edu/employee-news/guide-ai-tools-u | https://cyverse.org/ai-verde | https://responsibleai.arizona.edu/about-orai/directory
Review: 2026-10-19 — ORAI transition/credit update and pricing screenshot from Wolfgang Jentner, relayed by Greg Chism; portal HTTP 200, no signed-in entitlement test
Public university news describes Arizona AI Assistant as a fall pilot and AI Verde separately. The transition and $200/month credit come from Wolfgang Jentner at ORAI, relayed by Greg Chism; individual entitlements have not been tested. Pricing screenshot received October 19; its capture/effective date is unconfirmed. Confirm live account rates. Primary contact corrected at Greg Chism’s request October 20. ORAI directory confirms the spelling Wolfgang Jentner and wjentner@arizona.edu; primary service responsibility is user-confirmed.

U of A GenAI | University | Documented route
Access: Active UArizona NetID; published FAQ describes limited early access. Check genai.arizona.edu for availability.
Cost: Published no-cost campus use.
Contact: Responsible AI tools page and campus 24/7 IT support: 520-626-8324 | https://responsibleai.arizona.edu/tools-support/u-gen-ai
Support: Responsible AI tools page and campus 24/7 IT support: 520-626-8324
Limits: Models/features may rotate; no guaranteed API, classroom concurrency or GPU-training allocation. Early-access conditions and data-specific exclusions apply; this differs from AI Verde.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://responsibleai.arizona.edu/tools-support/u-gen-ai | https://it.arizona.edu/student-resources | https://responsibleai.arizona.edu/ai-tools-guide
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Campus software licensing | University | Documented route
Access: Use the UITS software catalog and student/faculty service routes; check each product and affiliation.
Cost: Student page lists Microsoft 365, Google Apps and Adobe Creative Cloud without added software charge while enrolled; other products are free or discounted. Student services are supported by the IT & Library Fee.
Contact: UITS 24/7 support — 520-626-8324 | https://it.arizona.edu/student-resources
Support: UITS 24/7 support — 520-626-8324
Limits: Eligibility, device counts, renewal and commercial/research use vary. Listed MATLAB/Autodesk etc. do not imply every license or API credit is included.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://it.arizona.edu/student-resources | https://it.arizona.edu/node/616
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

VCAT and Tech Zone software access | University | Documented route
Access: VCAT supplies virtual applications through a browser; Tech Zone labs provide installed software. Instructors can request a lab software installation.
Cost: Campus student-service route; fee-supported. Product-specific access and installation charges, if any, must be checked.
Contact: UITS 24/7 support — 520-626-8324 | https://it.arizona.edu/tech-zone-software
Support: UITS 24/7 support — 520-626-8324
Limits: App/version and lab availability vary; not a general-purpose GPU allocation, unrestricted server or always-on research host.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://it.arizona.edu/tech-zone-software | https://it.arizona.edu/news/finding-resources-faculty | https://it.arizona.edu/student-resources
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Libraries Data Cooperative: Python, R and ML support | University | Documented route
Access: Faculty, staff and students can consult library specialists on data science, visualization, programming and data management.
Cost: No project-specific fee or dedicated engineering allowance established by these pages.
Contact: Sarah Stueve — sarahstueve@arizona.edu (Python/ML); Jeff Oliver — jcoliver@arizona.edu (R/Git/visualization) | https://lib.arizona.edu/research/data
Support: Sarah Stueve — sarahstueve@arizona.edu (Python/ML); Jeff Oliver — jcoliver@arizona.edu (R/Git/visualization)
Limits: Consultation, instruction and referrals; no dedicated developer hours, turnaround or ongoing operations commitment.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/research/data | https://lib.arizona.edu/research/data/data-science
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Digital scholarship and text/data mining | University | Documented route
Access: Consult about corpora, text analysis, humanities data, metadata and digital editing; listed open tools include OpenRefine, Voyant, AntConc and CollectionBuilder.
Cost: Listed tools are free to use; sustained project implementation/support not priced here.
Contact: Heather Froehlich — froehlich@arizona.edu | mailto:froehlich@arizona.edu
Support: Heather Froehlich — froehlich@arizona.edu
Limits: Tool availability does not clear copyright, dataset licensing, hosting, compute or staff time.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/research/data/digital-scholarship | https://lib.arizona.edu/research/plan/tdm-llm
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Library datasets, databases and reuse rights | University | Documented route
Access: Use licensed resources under current UA affiliation and the specific agreement. Contact Collections before TDM or use with AI.
Cost: Institutional subscriptions cover authorized access; additional TDM/API rights or fees depend on the agreement.
Contact: Library Collections — LBRY-collectionmanagement@email.arizona.edu | mailto:LBRY-collectionmanagement@email.arizona.edu
Support: Library Collections — LBRY-collectionmanagement@email.arizona.edu
Limits: Reading access does not authorize bulk download, sharing, training or uploading to public AI tools. Each publisher agreement differs.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/research/plan/tdm-llm
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

GIS software, geospatial data and consultation | University | Documented route
Access: Use the Libraries GIS/data guides and repository; discuss ArcGIS, QGIS, R and spatial analysis with a specialist.
Cost: QGIS is open source; ArcGIS eligibility and project-specific data/service terms require checking. No universal paid-product entitlement inferred.
Contact: Garrett Smith — garrettsmith@arizona.edu | mailto:garrettsmith@arizona.edu
Support: Garrett Smith — garrettsmith@arizona.edu
Limits: Data licenses, service quotas and support capacity differ. A geospatial repository is not a general GPU or database-hosting award.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/research/data/geospatial | https://lib.arizona.edu/research/data
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

ReDATA: research data and code preservation | University | Documented route
Access: Active faculty/staff, enrolled students and certain DCCs with valid NetID/library privileges can submit eligible final research materials for curatorial review.
Cost: FAQ: no cost to individual UArizona researchers; quota increases depend on need and availability.
Contact: ReDATA team — data-management@arizona.edu | mailto:data-management@arizona.edu
Support: ReDATA team — data-management@arizona.edu
Limits: Non-sensitive research materials and rights required; curatorial review mandatory. Not an active database/backup service. Published notice reports intermittent traffic-related errors and automated download restrictions; not a breach.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/research/data/redata | https://lib.arizona.edu/research/data/redata/faqs | https://lib.arizona.edu/research/data/redata/deposit
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

Data Science Institute / CyVerse research software expertise | University | Contact reconfirmation needed
Access: Indexed official DSI pages describe project/proposal consultation and cross-college teams; their live hostnames did not resolve during this review. Reconfirm the current route before relying on it.
Cost: No blanket free engineering-hour entitlement or public project rate established; scope and funding must be agreed.
Contact: Published DSI contact — RII-datascienceinstitute@arizona.edu (current operation to reconfirm) | mailto:RII-datascienceinstitute@arizona.edu
Support: DSI — RII-datascienceinstitute@arizona.edu
Limits: Named engineering expertise is not an available appointment or staffed help desk for every course. Confirm capacity, deliverables, maintenance and funding.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://data7.arizona.edu/contact-us | https://datascience.arizona.edu/directory
Review: 2026-10-19 — indexed official text retrieved; direct live verification unsuccessful
Official-source search/fetch text supplied the contact and engineering roles, but direct checks of data7.arizona.edu and datascience.arizona.edu failed DNS resolution. This is an availability limitation, not evidence of service closure. No available staff hours verified.

CCT Data Science: consultation and research software | University | Documented route
Access: Drop-in/workshop routes and grant collaboration documented. The 80-hour Data Science Incubator is limited to ALVSCE faculty, staff and students.
Cost: Longer collaboration can use hired effort or a co-PI grant arrangement; Information Science eligibility for other services and rates must be confirmed.
Contact: CCT Data Science team — current contact/consultation routes | https://datascience.cct.arizona.edu/
Support: CCT Data Science team — current contact/consultation routes
Limits: The ALVSCE incubator is not an 80-hour entitlement for Information Science. Training/drop-in help differs from funded long-term engineering.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://datascience.cct.arizona.edu/
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

CATalyst Studios: XR, making and class partnerships | University | Documented route
Access: Use Main Library makerspace hours, reserve eligible spaces/VR equipment, or plan a class visit with the team.
Cost: Free workshops are advertised; material/equipment-specific charges and eligibility must be checked.
Contact: CATalyst Studios — contact and consultation booking | https://lib.arizona.edu/catalyst/contact
Support: CATalyst Studios — contact and consultation booking
Limits: Some machines require authorization classes. Reservations, supervision and supplies constrain access; no general-purpose compute/GPU reservation inferred.
Funding: Institutional or project service; dedicated college capacity/funding not established.
Sources: https://lib.arizona.edu/catalyst | https://lib.arizona.edu/catalyst/contact
Review: 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Access route, published cost basis and contact checked in public sources. Unpublished quotas, staffing and college capacity remain unknown.

AI tools and data-use guidance | University | Documented route
Access: Review the current university decision table before selecting a tool.
Cost: Public guidance; project review effort must be scoped.
Contact: Responsible AI campus support and current training organizers | https://responsibleai.arizona.edu/
Support: University AI, privacy and relevant data owners.
Limits: Data categories and account types matter; do not infer authorization from a vendor privacy claim.
Funding: University guidance; not a compute or staff allocation.
Sources: https://responsibleai.arizona.edu/ai-tools-guide
Review: 2026-10-19
Published guidance/training route only; not a compute or staff allocation.

Campus AI learning and events | University | Documented route
Access: Follow the university AI resources page for training and event routes.
Cost: Check each offering; staff learning time is still required.
Contact: Responsible AI campus support and current training organizers | https://responsibleai.arizona.edu/
Support: University AI learning and event organizers.
Limits: A course/event is not staffed project support or a reserved technical service.
Funding: University initiative; event availability varies.
Sources: https://it.arizona.edu/news/new-u-ai-resources
Review: 2026-10-19
Published guidance/training route only; not a compute or staff allocation.

NSF ACCESS | National / external | Application / approval
Access: Match the project and teaching/research use to a resource and request.
Cost: Allocated resource access is conditional; operations/support remain separate.
Contact: ACCESS support and selected resource provider | https://access-ci.org/
Support: ACCESS support plus the selected resource provider.
Limits: No award, class reservation or provider benchmark established.
Funding: Federally supported allocation route.
Sources: https://access-ci.org/
Review: Earlier compute-ledger review; not newly rechecked
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

NAIRR Classroom | National / external | Application / approval
Access: Check the current instructor/course call and resource terms.
Cost: Conditional award/resource terms; not funding in hand.
Contact: NAIRR program / current Classroom call | https://nairrpilot.org/
Support: Program and resource-specific support.
Limits: An eligible AI pilot does not supply every course or its ongoing staff support.
Funding: Federal pilot opportunity.
Sources: https://nairrpilot.org/
Review: Earlier compute-ledger review; recheck call before use
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

OSPool / throughput computing | National / external | Documented route
Access: Assess independent, checkpointed research jobs and facilitated onboarding.
Cost: Opportunistic use subject to policy and available capacity.
Contact: OSPool facilitation / support | https://osg-htc.org/ospool/
Support: OSG/OSPool support route.
Limits: Interruptions and queue behavior differ from live classroom sessions.
Funding: Federally supported/shared infrastructure.
Sources: https://osg-htc.org/ospool/
Review: Earlier compute-ledger review; recheck before use
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

MESA / CyVerse collaboration | National / external | Project / service terms
Access: Explore public service and collaboration routes; confirm underlying access.
Cost: Service-specific; no free college compute entitlement inferred.
Contact: MESA project team / underlying service provider | https://idss-mesa.github.io/
Support: Project/platform maintainers; commitments to confirm.
Limits: Grant participation and advertised products do not establish approved class capacity.
Funding: IDSS/project and underlying service support differ.
Sources: https://idss-mesa.github.io/
Review: Earlier compute-ledger review; recheck before use
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

Free GPU and cloud-credit experiments | National / external | Bounded / conditional
Access: Compare Kaggle, free Colab and credit-based platforms in the existing directory.
Cost: Quotas, cards and paid conversion vary.
Contact: Provider-specific help routes in comparison | classroom-resources.html
Support: Provider/community support; no class support commitment.
Limits: Useful for bounded experiments; not a guaranteed full-term GPU reservation.
Funding: Provider-sponsored tiers or promotional credits.
Sources: classroom-resources.html
Review: Earlier compute-ledger review; recheck before use
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

Repositories, databases and preservation | National / external | Service-specific
Access: Match code, active databases, research deposits and archival needs separately.
Cost: Storage, activity and hosting limits vary.
Contact: Service-specific contacts in continuity plan | repository-plan.html
Support: Institutional librarians, data owners and hosting operators.
Limits: Compute allocations do not automatically provide durable databases or preservation.
Funding: Institutional and provider arrangements differ.
Sources: repository-plan.html
Review: Earlier compute-ledger review; recheck before use
Earlier source-ledger review; current resource-owner access, cost and contact not newly verified in this campus expansion.

Needs and gaps assessment

**Draft framework — no college-wide findings established.** The resource inventory and historical provider changes identify questions to examine; they do not establish the size or distribution of college needs.

[Prepare and optionally submit a need](needs.html) · [Download blank needs register](computing-needs-register.csv)

Questions to investigate

| Area | What we need to learn | Useful evidence |
| --- | --- | --- |
| Compute and cloud | Which activities need local devices, interactive sessions, batch jobs, GPUs or hosted models? | Small measured workloads, access delays and required concurrency |
| Software and models | Which licenses, APIs, environments and accessible interfaces are required? | Current agreements, use cases, compatibility and renewal terms |
| Data | Which datasets, rights, metadata, storage and preservation services are missing? | Data inventories, permissions, stewardship and export/restore needs |
| RSEs and support | Which skills and support windows are required, and what capacity is actually available? | Task estimates, existing commitments and service-owner confirmation |
| Research and instruction | How do research schedules, class deadlines and student access differ? | Course/project scenarios and faculty/student perspectives |
| Collaboration | What can be shared or improved before adding infrastructure? | Underused resources, compatible workflows and willing partners |

Assess a reported gap

Distinguish **not available**, **not accessible**, **not known about**, **not supported**, **not suitable** and **not affordable**. They require different responses.

For each need, capture who is affected, the activity being blocked, current workaround, timing and evidence. Compare it with a verified resource route. A technical shortage should be distinguished from permissions, onboarding, skills or support barriers.

Summarize responsibly

Report which parts of the college and which roles contributed, the number of usable inputs and important missing perspectives. Keep measured demand, self-reported needs, estimates and unanswered questions separate. Do not scale a few examples into college-wide GPU, spending or staffing totals.

Ready for a preliminary draft when…

The group has a versioned needs register, a documented account of participation, significant gaps linked to evidence, and a clear list of remaining unknowns. Refine these with faculty, students and resource owners early in Spring 2027.

Review submitted briefs

Barney Maccabe and Greg Chism can use the [private pilot queue](https://infosci-compute-drafter.vercel.app/review/) to review explicitly submitted public/synthetic briefs, add a status and notes, and export or delete requests. Contact addresses are self-reported. Submission does not imply approval, capacity or an allocation; internal and restricted information needs an agreed university channel.

Primers for the working group

Six starting points for discussing computing resources across the **College of Information Science**. Use the questions to identify evidence and a useful next step.

1. Start with the activity

An interactive class, a batch research job, a hosted model and a public website need different services. A GPU is one component; memory, software, storage, accounts and support can be the actual constraint.

**Discuss:** What must people be able to do, when, and with how many simultaneous users?

[Develop a brief](needs.html) · [Optional technical estimate](compute-estimator.html)

2. Separate availability from dependable access

A free account or published machine specification does not reserve capacity or authorize classroom use. Research tolerates some queues; a scheduled class may not. Puma now permits class groups, but teaching and research share the PI allocation. Jobs may queue without deadline priority, and instructors support students.

**Discuss:** Who is eligible, what is guaranteed, and what happens when access fails?

[Resource inventory](inventory.html) · [Classroom checks](readiness.html)

3. Count the people and recurring work

Allocations and credits do not automatically supply research software engineers (RSEs), onboarding, accessible interfaces, course support or a backup operator. Estimate tasks and hours before proposing a staffing or funding model.

**Discuss:** Who maintains the service, supports users and handles renewals and recovery?

[Candidate approaches](approaches.html) · [Pilot hours and grant dependencies](budget.html)

4. Treat data, software and preservation separately

Code repositories, licensed datasets, active storage, databases and preservation repositories have different purposes. Check rights, permitted data, exports and restore. A working copy is not an independent backup or a scholarly archive.

**Discuss:** What may be stored or shared, who owns it, and how will it outlast the account?

[Repositories, hosting and data](repository-plan.html) · [Campus data and software services](inventory.html)

5. Compare routes by the whole commitment

Use existing campus services, shared infrastructure, efficient workflows and national allocations where they fit. Free tiers and promotional credits can support bounded experiments; an operating service also needs ownership, support and continuity.

**Discuss:** What small, reversible test would distinguish the promising options?

[Federal platforms](federal-compute.html) · [Cloud credits and limits](serverless-compute.html) · [Classroom 50](classroom50.html)

6. Keep the evidence proportional

A self-reported need, an estimate, a benchmark and an owner-confirmed commitment are different evidence. A few examples cannot establish college-wide demand, savings or available staffing.

**Discuss:** Whose perspective is missing, what is measured, and which claims still need confirmation?

[Needs assessment framework](needs-assessment.html) · [Report and limitations](report.html#evidence-and-limitations)

A useful output from a discussion

Record **the activity → the barrier → a route to investigate → a person who can confirm it → the next useful test**. Keep unknowns visible. The [working materials](supplemental.html#working-group-materials) provide the registers and review framework.

Portfolio of approaches

**Candidates for investigation, not selected investments.** Combine approaches when useful; compare their support and recurring obligations as carefully as their technical benefits.

| Approach | Opportunity | First useful test | Main dependency |
| --- | --- | --- | --- |
| Improve use of campus resources | Reduce duplicate purchases and onboarding friction | Map one research and one teaching workflow to documented campus routes | Eligibility, headroom, support and class-use terms |
| Shared RSE and technical support | Pool scarce expertise and reusable environments | Estimate a few tasks and trial a bounded support window | Named staff, existing commitments and funding; no new appointment assumed |
| Shared data and software stewardship | Reuse datasets, metadata and environments safely | Review a dataset/license and test a portable workflow | Rights, permissions, accessibility and renewal ownership |
| Allocation-backed compute service | Support larger CPU/GPU work without relying only on free tiers | Benchmark components and validate a target route | An award, operations capacity and provider terms; ACCESS pilot remains conditional |
| Efficient models and workflows | Lower unnecessary compute and improve reproducibility | Compare a smaller model, retrieval approach or checkpointed job against a quality baseline | Task-specific evaluation; savings must be measured |
| Partnerships and shared infrastructure | Connect compatible college, campus and external efforts | Define a small joint use case with an interested partner | Agreed responsibilities, access and sustainable support |
| Reusable teaching and evaluation tools | Avoid rebuilding assignment environments and grading workflows | Test exports and a synthetic class before adoption | Maintainer continuity, account terms and separate compute quotas |

Planned ORAI proposal

Greg will draft a bounded [AI Innovation Pilot](https://responsibleai.arizona.edu/tools-support/ai-innovation-pilots) next, showcasing ORAI tools alongside his infrastructure components in an **AI-native classroom**. A separate proposal will be drafted next. His capacity is **four hours/week total**. The program offers a potential eight-week proof-of-concept route after assessment; acceptance, RSE assignments and infrastructure must be confirmed. Ongoing maintenance and classroom operations need their own plan.

Use one comparison standard

For each candidate, document instructional/research benefit, users served, accessibility, data suitability, required effort, recurring costs, funding status, ownership and a reversible test. Do not rank options using invented cost savings or unmeasured capacity.

[Draft recommendations](recommendations.html) · [Resource inventory](inventory.html) · [Supporting compute pilot](pilot-plan.html)

Drafting support

The [resource tool](needs.html) prepares a local brief and sourced request template. Optional Luna drafting needs explicit consent for public/synthetic material. [Technical assessment, limits and model trials](drafting-notes.html) are supplementary.

Resource-request drafting notes

Supporting assessment of the request tool. Start with the [resource tool](needs.html) for use, or the [report](report.html) for the main findings.

Help prepare resource requests

The [needs tool](needs.html) offers a source-backed local template and an optional **GPT-6 Luna** rewrite after explicit consent for public/synthetic information. Luna uses a server-side credential and a shared allowance: 20 attempts/day, 200/month, five/network/day, up to 1,000 output tokens each. Attempts reserve $0.005 of the application allowance before calling the model, limiting this service to $1/month in reservations at current verified rates. This is separate from account-wide billing and hosting. Failed or timed-out calls are not retried automatically.

For a manual campus route, use [Arizona AI Assistant](https://ai-assistant.responsibleai.arizona.edu/). Wolfgang Jentner at ORAI reports an AI Verde transition and $200/month of Bedrock credit, relayed by Greg Chism; [review the credit boundaries and supplied model rates](campus-ai.html). [U of A GenAI](https://responsibleai.arizona.edu/tools-support/u-gen-ai) remains another documented route. Campus API integration and credit use have not been tested here.

Browser-model assessment

Browser inference works without API keys or per-request inference fees. We tested two quantized SmolLM2 models on synthetic examples in Chromium on this machine. The 135M model invented student-record details; a 360M model produced short drafts in about 9–13 seconds, but an integrated example added an unsupported participant condition and weakened unknown-hours language. Its initial model/runtime download was about 390 MB. These examples are a small feasibility check, not a general ranking of browser models.

The integrated 360M worker generated with networking blocked after loading. That establishes local execution for that test; it does not establish reliable drafting. Browser inference remains disabled on the public site. The local template, optional hosted Luna draft and manual campus prompt are separate routes. The [SmolLM2 model card](https://huggingface.co/HuggingFaceTB/SmolLM2-360M-Instruct) also advises checking generated content. Preserve original quantities, source facts and unknowns in every draft.

GPT-6 Luna drafting test

On October 19, 2026, **GPT-6 Luna** completed three synthetic requests—data science instruction, MLIS data work and research software support—in **5.6–6.0 seconds each**. Review against supplied briefs and dated inventory facts found that all three preserved unknown costs, staffing, permissions and capacity. Drafts were 135–163 words and kept questions for resource owners separate.

**Assessment: useful first drafts with human review.** This was three examples with facts supplied, not a reliability guarantee or a matched comparison with browser models. Total usage was 4,157 input and 1,032 output tokens; estimated token charges were **about $0.001**, including reported cache writes, using [published standard rates](https://developers.openai.com/api/docs/models/gpt-6-luna). This is an estimate, not a verified invoice. That initial test established no institutional approval or college operating budget. The subsequent optional integration has its own usage limits and deployment checks.

Optional submission and review

The resource tool now has a separate, explicit submission step. Public/synthetic briefs and contact details can be stored in a private pilot queue for Barney and Greg, using the existing hosting. Luna drafting never submits automatically and contact details are not sent to the model. Reviewers use a shared passphrase, update status and notes, export requests, and delete entries when no longer needed. This is not NetID, a sensitive-data intake or an allocation application.

Arizona AI Assistant transition

**AI Verde → [Arizona AI Assistant](https://ai-assistant.responsibleai.arizona.edu/).** **Wolfgang Jentner at the Office of Responsible AI (ORAI)** is the source of this planned transition and **$200/month of AWS Bedrock credit**, relayed by Greg Chism. Transition date, who receives the credit, eligibility, renewal and overage controls need confirmation. This is an October 19, 2026 working-group update, not a verified entitlement for every faculty member or student.

Public [university news](https://news.arizona.edu/employee-news/guide-ai-tools-u) describes Arizona AI Assistant as a fall pilot and AI Verde separately. The new portal returned HTTP 200; we have not tested a signed-in account or campus API. Contact **[Wolfgang Jentner at ORAI](mailto:wjentner@arizona.edu)** for AI Verde, Arizona AI Assistant and Bedrock for current enrollment, migration and credit terms.

Models and prices in the supplied screenshot

USD per **one million tokens**. These are campus gateway prices in the ORAI screenshot from Wolfgang Jentner, relayed by Greg Chism, not direct OpenAI prices or measured bills. Check current account rates before use.

| Model ID | Input | Output |
| --- | ---: | ---: |
| `gpt-5.6-luna` | $0.22 | $1.32 |
| `gpt-5.6-sol` | $4.40 | $22.00 |
| `gpt-6.1-sol` | $2.20 | $11.00 |
| `claude-haiku-4-5-20251001` | $1.10 | $5.50 |
| `claude-opus-5` | $5.50 | $27.50 |
| `claude-opus-5-5` | $4.40 | $22.00 |
| `claude-sonnet-5` | $2.20 | $11.00 |
| `gpt-5.6-terra` | $2.20 | $13.20 |
| `gpt-6-luna` | $0.11 | $0.55 |
| `claude-haiku-5-5` | $0.11 | $0.55 |
| `claude-sonnet-5-5` | $2.20 | $11.00 |
| `google.gemma-4-31b` | $0.14 | $0.40 |

[View supplied pricing screenshot](guide-assets/campus-ai-pricing-2026-10-19.png) · Received October 19, 2026; capture and effective dates are unconfirmed.

For example, at the listed campus Luna rate, **10,000 input + 1,000 output tokens = $0.00165** before any other charges. This is illustrative arithmetic, not an observed bill or promised credit balance. Credit provides model inference, not a reserved GPU, training cluster or guaranteed class concurrency.

Before relying on the replacement

- Confirm migration timing, existing team/workspace exports, API compatibility and the correct API base URL.
- Confirm whether $200/month is per person, team or another allocation; determine reset, expiry and overage behavior.
- Review allowed data, retention, model availability and throughput under campus terms.
- Test one public/synthetic workflow and a classroom rehearsal before required use.

The [resource request tool](needs.html) currently uses the separate direct OpenAI Luna pilot. Its $1 monthly application allowance does not draw from campus Bedrock credit. Campus integration needs a campus-issued credential and confirmed API terms.

[Resource inventory](inventory.html) · [Drafting assessment](approaches.html)

Primary contact confirmed by Greg Chism on October 20, 2026; spelling and email verified in the [university directory](https://responsibleai.arizona.edu/about-orai/directory).

Recommendations for review

**Draft action framework — priorities and endorsement pending.** The working group should refine these using the inventory and faculty/student needs, rather than assume a single platform solves the problem.

Actions the college can pursue

1. **Maintain a concise resource inventory.** Identify an owner role for each entry and a review process. Publish access routes and limitations that resource owners confirm.
2. **Document needs across research and instruction.** Use consistent briefs and an agreed university channel; include faculty, students, RSEs and technical staff. Summarize participation and unknowns.
3. **Improve discoverability and reuse.** Test clear onboarding, reusable environments, shared documentation and relevant training before expanding infrastructure.
4. **Scope bounded pilots.** Match a small activity to a confirmed route and support window. Measure benefit, access, effort and recovery before making it required.

Opportunities for university participation

| Shared question | College contribution | What needs university participation |
| --- | --- | --- |
| Campus compute and hosted AI access | Concrete research/classroom scenarios and measured demand | Capacity, course access, account structure and service commitments |
| Software, APIs and data agreements | Priority tools, datasets, rights and renewal needs | Institutional agreements, permitted use and sustainable funding |
| RSE and technical support models | Skill/task estimates and existing college commitments | Shared staffing, escalation, training and long-term operations |
| Data governance and shared infrastructure | Workflow, preservation and collaboration requirements | Appropriate review, interoperability and institutional services |

Before prioritizing an action

Attach the problem and evidence, users served, owner role, dependencies, effort, funding status, success measure and a review date. Explicitly distinguish an application, exploratory partnership or proposed role from a confirmed commitment.

The existing pilot’s **$0 cash and Greg’s 10 total hours/week** apply to that pilot. They are not a measured college budget or staffing ceiling. Do not assume funding or available staff for these broader recommendations.

[Recommendation template](computing-recommendations-template.csv) · [Needs assessment](needs-assessment.html) · [Milestones](timeline.html)

Run a working session

Use a short, repeatable review. This is a suggested meeting format, not a scheduled event or an assigned set of roles.

Before the session

Choose a deliverable and review its current draft. Bring a public or appropriately shareable resource correction or needs brief. Use the group’s agreed university channel for internal material; the resource tool’s separate submission step accepts only reviewed public/synthetic briefs into the private pilot queue.

Suggested 45-minute agenda

| Minutes | Activity | Record |
| --- | --- | --- |
| 0–5 | Confirm the decision or question | Scope and intended outcome |
| 5–15 | Review resources and access | Verified facts, owners and unknowns |
| 15–25 | Discuss needs and barriers | Research/teaching differences and missing perspectives |
| 25–35 | Compare promising approaches | Evidence, prerequisites and a useful small test |
| 35–45 | Agree next steps | Action, owner role, dependencies and review point |

After the session

Update the draft’s date and status. Separate a decision from an open question or suggested action. Record who needs to confirm access, costs, support or permissions; do not list an unconfirmed resource as ready.

Questions for the group to settle first

- Who maintains each deliverable and confirms factual corrections?
- Which approved university channel will receive needs briefs and internal notes?
- How will faculty, students and technical staff contribute, and how will missing perspectives be recorded?
- Who will review the preliminary drafts before early Spring 2027 circulation?

[Four deliverables](deliverables.html) · [Working packet](computing-working-group-packet.txt)

CAMPUS INVENTORY SOURCES

UITS Support | https://it.arizona.edu/support/247-support-center | 2026-10-20
College hardware, labs and loan equipment | https://infosci.arizona.edu/people/barney-maccabe | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
College software, datasets and agreements | https://infosci.arizona.edu/people/barney-maccabe | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
College research labs and collaborators | https://infosci.arizona.edu/research-faculty/research-labs | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
co/lab: Critical Archives & Curation Collaborative | https://infosci.arizona.edu/colab-critical-archives-curation-collaborative | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
XRG: Extended Reality & Games Lab | https://infosci.arizona.edu/xrg-lab | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
College course technology requirements | https://infosci.arizona.edu/technology-requirements | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Campus HPC: Puma CPU and GPU | https://hpcdocs.hpc.arizona.edu/resources/allocations/ | https://hpcdocs.hpc.arizona.edu/resources/compute_resources/ | https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/running_jobs/job_limits/ | 2026-10-20 — current public allocation, teaching, hardware and support documentation; no signed-in balance or workload test
Campus HPC: Puma classroom computing | https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/ | https://hpcdocs.hpc.arizona.edu/resources/allocations/ | https://hpcdocs.hpc.arizona.edu/registration_and_access/group_management/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/resources/compute_resources/ | https://hpcdocs.hpc.arizona.edu/running_jobs/job_limits/ | 2026-10-20 — current public teaching and allocation policies; no signed-in balance, reservation or class-load test
HPC active storage and transfers | https://hpcdocs.hpc.arizona.edu/storage_and_transfers/storage/hpc_storage/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
HPC software, containers and shared model data | https://hpcdocs.hpc.arizona.edu/software/common_datasets/ | https://hpcdocs.hpc.arizona.edu/software/overview/ | https://hpcdocs.hpc.arizona.edu/software/popular_software/ollama/ | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
HPC consulting and visualization support | https://hpcdocs.hpc.arizona.edu/support_and_training/consulting_services/ | https://hpcdocs.hpc.arizona.edu/policies/hpc_for_instruction/ | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
AI Verde → Arizona AI Assistant: planned transition | https://ai-assistant.responsibleai.arizona.edu/ | https://news.arizona.edu/employee-news/guide-ai-tools-u | https://cyverse.org/ai-verde | https://responsibleai.arizona.edu/about-orai/directory | 2026-10-19 — ORAI transition/credit update and pricing screenshot from Wolfgang Jentner, relayed by Greg Chism; portal HTTP 200, no signed-in entitlement test
U of A GenAI | https://responsibleai.arizona.edu/tools-support/u-gen-ai | https://it.arizona.edu/student-resources | https://responsibleai.arizona.edu/ai-tools-guide | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Campus software licensing | https://it.arizona.edu/student-resources | https://it.arizona.edu/node/616 | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
VCAT and Tech Zone software access | https://it.arizona.edu/tech-zone-software | https://it.arizona.edu/news/finding-resources-faculty | https://it.arizona.edu/student-resources | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Libraries Data Cooperative: Python, R and ML support | https://lib.arizona.edu/research/data | https://lib.arizona.edu/research/data/data-science | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Digital scholarship and text/data mining | https://lib.arizona.edu/research/data/digital-scholarship | https://lib.arizona.edu/research/plan/tdm-llm | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Library datasets, databases and reuse rights | https://lib.arizona.edu/research/plan/tdm-llm | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
GIS software, geospatial data and consultation | https://lib.arizona.edu/research/data/geospatial | https://lib.arizona.edu/research/data | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
ReDATA: research data and code preservation | https://lib.arizona.edu/research/data/redata | https://lib.arizona.edu/research/data/redata/faqs | https://lib.arizona.edu/research/data/redata/deposit | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
Data Science Institute / CyVerse research software expertise | https://data7.arizona.edu/contact-us | https://datascience.arizona.edu/directory | 2026-10-19 — indexed official text retrieved; direct live verification unsuccessful
CCT Data Science: consultation and research software | https://datascience.cct.arizona.edu/ | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
CATalyst Studios: XR, making and class partnerships | https://lib.arizona.edu/catalyst | https://lib.arizona.edu/catalyst/contact | 2026-10-19 — public documentation; no signed-in entitlement or owner confirmation
AI tools and data-use guidance | https://responsibleai.arizona.edu/ai-tools-guide | 2026-10-19
Campus AI learning and events | https://it.arizona.edu/news/new-u-ai-resources | 2026-10-19