# GitHub Storage Limits: Account Quotas, Package Caps, and Workarounds

GitHub storage limits are plan-level quotas governing combined storage for GitHub Actions artifacts, GitHub Packages, and Git LFS, providing 500 MB on GitHub Free, 2 GB on GitHub Team, and 50 GB on GitHub Enterprise. Exceeding your included quota without metered billing blocks package publishing and stops pipelines from saving build artifacts. Understanding these boundaries helps engineering teams optimize retention policies and offload large build outputs to dedicated cloud workspaces.

Source: https://fast.io/resources/github-storage-limit/
Author: [Derek Labian](https://fast.io/authors/derek-labian/)
Last reviewed: 2026-09-28

## What Are GitHub Storage Limits Across Account Plans

GitHub allocates 500 MB of shared storage on GitHub Free, 2 GB on GitHub Team, and 50 GB on GitHub Enterprise Cloud for GitHub Actions artifacts and GitHub Packages combined, while enforcing a 100 MB hard limit on individual Git objects and a 2 GB ceiling per Git push.

GitHub storage limits are plan-level quotas governing combined storage for GitHub Actions artifacts, GitHub Packages, and Git LFS, providing 500 MB on GitHub Free, 2 GB on GitHub Team, and 50 GB on GitHub Enterprise.

Git was built to track line-by-line differences in source code, not to act as an unbounded binary repository or build artifact archive. When automated CI/CD runners and AI agents push large test outputs, compiled binaries, container images, or evaluation traces into GitHub, storage consumption accelerates across multiple distinct platform layers. Understanding where GitHub enforces hard ceilings versus soft recommendations is essential for keeping build systems operational and preventing unexpected service interruptions.

GitHub divides storage governance into two broad domains: repository operational limits and account-level cloud product storage.

### Repository Operational Limits

Every Git repository hosted on GitHub operates under structural constraints intended to preserve platform stability and ensure fast Git network operations:

* **Recommended On-Disk Size**: GitHub repository limits recommend staying under 10 GB on-disk size for the compressed `.git` folder. While repositories can technically grow larger, excessive repository history degrades fetch performance and inflates clone durations for human contributors and CI runners. GitHub documentation advises keeping total repository size under 1 GB, with larger repositories representing an operational concern where GitHub Support may contact repository administrators to request repository reduction.
* **Single Object Limit**: GitHub repository limits trigger a push warning when an individual file exceeds 50 MB, and strictly enforce a 100 MB single object limit that blocks any commit containing a larger file. Files that exceed this threshold must be tracked using Git Large File Storage (Git LFS) or stored outside Git entirely.
* **Push Size Limit**: A single `git push` operation cannot exceed 2 GB in total data payload. Commits exceeding this size must be broken down and pushed in smaller batches.
* **Directory Breadth and Depth**: GitHub recommends limiting any single directory to 3,000 entries and maintaining directory nesting depth to 50 levels to prevent slow tree traversals.
* **Branch Capacity**: Organizations should keep total active branches below 5,000 per repository to avoid slow reference advertisements during fetch operations.
* **Web Upload Boundary**: Files added directly through the GitHub web browser interface are restricted to smaller payloads, requiring command-line Git pushes or Git LFS for larger binary files.

### Account-Level Shared Storage Quotas

Beyond standard Git tree boundaries, GitHub provisions account-level cloud storage pools for automated workflows and package registries. GitHub Actions build artifacts and GitHub Packages share a unified storage quota that scales with your organization subscription plan.

The following comparison table details included storage allocations, compute allowances, and overage behavior across GitHub plan tiers:

| GitHub Plan Tier | Included Shared Storage (Actions & Packages) | Included Actions Minutes | Actions Cache Limit (Per Repo) | Single Object / Push Limit | Overage Billing Behavior |
| :--- | :--- | :--- | :--- | :--- | :--- |
| GitHub Free (Personal) | 500 MB | 2,000 mins/mo | 10 GB | 100 MB object / 2 GB push | Blocked without payment method; $0.25/GB-mo metered |
| GitHub Free (Organizations) | 500 MB | 2,000 mins/mo | 10 GB | 100 MB object / 2 GB push | Blocked without payment method; $0.25/GB-mo metered |
| GitHub Pro | 1 GB | 3,000 mins/mo | 10 GB | 100 MB object / 2 GB push | Blocked without payment method; $0.25/GB-mo metered |
| GitHub Team | 2 GB | 3,000 mins/mo | 10 GB | 100 MB object / 2 GB push | Blocked without payment method; $0.25/GB-mo metered |
| GitHub Enterprise Cloud | 50 GB | 50,000 mins/mo | 10 GB | 100 MB object / 2 GB push | Blocked without payment method; $0.25/GB-mo metered |

Public repositories benefit from an important structural exemption: standard GitHub-hosted runner minutes and public package downloads are free. However, storage allowances for private repositories and organization assets remain strictly metered against your plan quota.

## How Shared Storage Pools Interact with Repository Artifact Caps

The most common architectural misunderstanding regarding GitHub storage involves the interaction between account-level shared storage pools, per-repository artifact retentions, and separate cache allocations. Many engineering teams mistakenly assume that each repository receives an independent GitHub Actions artifact storage quota rather than drawing from a shared account pool.

In reality, GitHub uses three distinct storage buckets with completely separate operational rules:

### 1. The Shared Account Storage Pool

Artifact storage for GitHub Actions and package storage for GitHub Packages share a single combined storage pool. This pool belongs to the organization or individual user account that owns the repositories, rather than to the repositories themselves.

If an organization on GitHub Team maintains thirty private repositories, all thirty repositories share the same single 2 GB allowance. A single automated workflow in one repository that generates heavy uncompressed test bundles or container images can consume most of the organization shared storage capacity, leaving minimal headroom for other repositories, automated pull request builds, and package releases across the company.

GitHub Packages draws from this exact same pool. Storing container images in GitHub Container Registry (GHCR), publishing internal npm packages, or uploading Maven dependencies all decrement the same megabyte counter that Actions artifacts use.

### 2. The Per-Repository Actions Cache

In contrast to shared artifacts, GitHub Actions cache storage operates under a dedicated, per-repository allowance:

* **Dedicated 10 GB Cap**: Every repository receives a default cache storage allowance of 10 GB.
* **Separation from Artifacts**: Data stored via `actions/cache` does not count against your plan 500 MB, 2 GB, or 50 GB shared artifact and package storage pool.
* **Automatic Eviction**: If cache storage for a repository exceeds 10 GB, GitHub automatically evicts older cache entries based on a least-recently-used algorithm until total usage falls within the 10 GB threshold.
* **Time-Based Eviction**: Any cache entry that has not been accessed in seven calendar days is deleted automatically, regardless of total size.

This architectural separation means caching node modules, compiled object files, or Python virtual environments in `actions/cache` is safe from a billing perspective, whereas uploading those same files via `actions/upload-artifact` directly consumes your paid account storage.

### 3. The Hourly Accrual Accounting Model

GitHub measures and bills artifact storage using an hourly accrual model based on gigabyte-hours (GB-Hours). One GB-Hour represents one gigabyte of data stored for one hour. GitHub calculates your monthly storage charges by accumulating GB-Hours throughout your billing cycle and dividing by the total number of hours in that month (typically 720 hours for a 30-day month).

This billing mechanism has critical operational implications when cleaning up storage:

```text
Current Storage vs. Accrued Storage:
- Day 1 to Day 10: Store 10 GB of artifacts (10 GB x 24 hours x 10 days = 2,400 GB-Hours)
- Day 11: Developer deletes all artifacts (Current Storage drops to 0 GB)
- Day 11 to Day 30: Accrue 0 GB-Hours
- Monthly Bill: 2,400 GB-Hours / 720 hours = 3.33 GB-Months billed
```

Deleting large artifacts immediately restores current storage capacity and prevents future hourly accruals. However, deleting an artifact does not retroactively refund or remove the GB-Hours that accrued while that artifact existed earlier in the month.

## What Happens When You Hit Your GitHub Storage Limit

Exceeding your included GitHub storage limit triggers immediate operational failures or unexpected billing charges depending on your account payment configuration.

### Failure Mode 1: No Payment Method or Zero Spending Budget

If your account has no payment method or operates under a spending limit set to zero, GitHub strictly enforces your plan quota. Once accumulated usage reaches your tier threshold (500 MB on Free, 2 GB on Team, or 50 GB on Enterprise), GitHub blocks all write operations to the shared storage pool:

* **Artifact Upload Failures**: Workflow steps executing `actions/upload-artifact` terminate with fatal HTTP 403 Forbidden errors or explicit quota exhaustion messages:

```text
Starting upload-artifact 4.x
Uploading 1 file(s)
Error: Failed to upload artifact: Storage quota exceeded for this account.
Error: Process completed with exit code 1.
```

When this happens, entire CI/CD pipelines fail. Downstream deployment jobs that depend on compiled build outputs, test reports, or container tarballs fail to trigger, halting production releases.

* **Package Publishing Rejections**: Developers and automated deployment bots attempting to push new packages to GitHub Packages receive rejection errors. Running `npm publish` returns `403 Forbidden - Storage limit exceeded`, while `docker push ghcr.io/org/image:tag` fails during layer upload with `denied: requested access to the resource is denied`.
* **Git LFS Smudge Errors**: If your Git LFS download bandwidth or storage quota is exhausted without a payment method on file, GitHub disables Git LFS downloads entirely across the account until the next calendar month. Developers attempting to clone repositories receive broken pointer files, and CI runners fail with `fatal: smudge filter lfs failed`.

### Failure Mode 2: Metered Overages

If your organization has an active payment method and an open spending limit, GitHub automatically transitions your account into metered billing. Additional shared storage for actions artifacts and packages accrues at a rate of $0.25 USD per gigabyte per month. Additional cache storage beyond the 10 GB repository allowance, when explicitly enabled, accrues at $0.07 USD per gigabyte per month.

While metered storage rates appear nominal on paper, automated pipelines can cause rapid cost spikes:

* **Matrix Build Multipliers**: A continuous integration workflow configured with a matrix across multiple operating systems and runtime versions runs parallel jobs per commit. If each job uploads diagnostic archives, a single pull request with a wide test matrix generates substantial storage. Running multiple pull requests per day quickly consumes available account capacity.
* **The 90-Day Retention Multiplier**: By default, GitHub Actions retains artifacts for 90 days on both public and private repositories. Without explicit intervention, build outputs remain on disk for three months, turning an included plan storage allowance on GitHub Team into an ongoing monthly overage fee.
* **The Fork Attribution Rule**: Workflows triggered by pull requests from external forks consume the actions minutes and artifact storage of the root repository owner. If external contributors or automated security scanners generate high-volume build outputs, your organization absorbs both the storage consumption and any resulting financial overage.

## How to Audit, Reduce, and Clean Up Repository Storage

Preventing pipeline halts and controlling billing expenses requires active storage auditing, aggressive retention pruning, and disciplined cache management.

### Step 1: Audit Current Storage Consumption

Before deleting assets, identify which repositories and workflows generate the highest storage volume.

1. Navigate to your GitHub account or organization settings.
2. Under **Billing and plans**, select **Plans and usage**.
3. Scroll to the **Storage for Actions and Packages** section to view current gigabytes consumed against your plan quota.
4. Click **Get usage report** to generate a detailed CSV report. The CSV breaks down storage usage by repository, artifact name, SKU, and date, revealing which projects drive costs.

You can also inspect repository storage programmatically using the GitHub CLI:

```shell
gh api repos/OWNER/REPO/actions/artifacts --jq '.artifacts[] | {id: .id, name: .name, size_in_bytes: .size_in_bytes, created_at: .created_at}'
```

### Step 2: Shorten Workflow Artifact Retention

The single most effective way to eliminate storage bloat is reducing the default 90-day retention period. Most continuous integration artifacts (such as unit test reports, linting logs, and temporary build outputs) are irrelevant after a pull request merges.

Explicitly set `retention-days` in your workflow definitions:

```yaml
name: Continuous Integration
on: [push, pull_request]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Application
        run: npm run build
      - name: Upload Test Results
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: coverage/
          retention-days: 1
```

You can also adjust the maximum retention policy organization-wide. In organization settings, navigate to **Actions** > **General** > **Artifact and log retention**, and configure the default retention to 3 or 7 days.

### Step 3: Automate Artifact Deletion

For repositories with heavy commit volume, create an automated workflow that prunes obsolete artifacts when pull requests close:

```yaml
name: Clean Obsolete Artifacts
on:
  pull_request:
    types: [closed]

jobs:
  delete-artifacts:
    runs-on: ubuntu-latest
    permissions:
      actions: write
    steps:
      - name: Delete Artifacts for Merged PR
        uses: actions/github-script@v7
        with:
          script: |
            const artifacts = await github.rest.actions.listArtifactsForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
            });
            for (const artifact of artifacts.data.artifacts) {
              if (artifact.workflow_run.head_branch === context.payload.pull_request.head.ref) {
                console.log(`Deleting artifact: ${artifact.name} (${artifact.id})`);
                await github.rest.actions.deleteArtifact({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  artifact_id: artifact.id,
                });
              }
            }
```

### Step 4: Manage Actions Cache Efficiently

While Actions cache does not draw from your shared artifact storage, hitting the 10 GB per-repository limit triggers aggressive LRU evictions that can slow down build times by evicting critical dependencies.

Inspect and prune repository caches using the GitHub CLI:

```shell
gh cache list --repo OWNER/REPO --sort size_in_bytes --order desc
```

Delete a specific obsolete cache entry by key:

```shell
gh cache delete "Linux-node-modules-sha256-abcdef" --repo OWNER/REPO
```

Delete all caches for a repository to resolve corrupted build states:

```shell
gh cache delete --all --repo OWNER/REPO
```

### Step 5: Clean Committed Binaries from Git History

If developers accidentally committed large binaries directly into the Git repository tree, simply deleting the file in a subsequent commit does not reduce repository size. The file remains embedded in historical commit packfiles.

Use the `git-filter-repo` utility to purge the file from repository history:

```shell
git filter-repo --invert-paths --path path/to/large-binary.tar.gz
git push origin --force --all
git push origin --force --tags
```

## Architectural Workarounds for Heavy CI Artifacts and Agent Outputs

While configuring retention policies mitigates immediate quota lockouts, software engineering has fundamentally evolved. Modern engineering teams run autonomous AI coding agents (such as Claude Code, Cursor, Codex, and OpenClaw), automated model evaluation suites, end-to-end video captures, and complex dataset pipelines.

These modern workflows generate gigabytes of multi-modal outputs: structured JSON telemetry, full-fidelity DOM snapshots, test video recordings, PDF documentation runs, and machine learning weights. Attempting to force these assets through shared GitHub Actions artifact storage limits creates an ongoing maintenance burden.

Engineering organizations resolve this constraint using two primary architectural alternatives.

### Option 1: Raw Cloud Object Storage

The traditional cloud infrastructure pattern decouples heavy artifacts from GitHub entirely by uploading build outputs to cloud object storage buckets. Workflows use the AWS CLI or Google Cloud SDK within GitHub Actions to transfer files directly to S3 or GCS buckets, outputting a signed URL or object reference back to the CI log.

Object storage provides virtually unlimited durability and low storage tariffs. However, this approach introduces noticeable operational complexity:

* **Infrastructure Overhead**: Engineering teams must provision cloud buckets, configure lifecycle expiration rules, manage IAM service accounts, and rotate authentication credentials inside GitHub Secrets.
* **No Collaboration Layer**: Raw buckets lack a clean, interactive user interface for non-technical stakeholders, quality assurance engineers, or product managers who need to inspect build outputs.
* **No Built-In Document Intelligence**: Raw cloud storage buckets cannot parse, index, or answer questions about document contents. If an autonomous agent needs to retrieve context from a 500-page test output stored in S3, it must download the entire object into local memory before performing search.

### Option 2: Intelligent Cloud Workspaces (Fast.io)

For engineering teams coordinating autonomous agents, developers, and external stakeholders around persistent assets, intelligent cloud workspaces provide a collaborative persistence layer alongside code repositories. Learn more about [Fast.io workspaces](/product/workspaces/) to see how collaborative file management and versioned storage work in practice.

Fast.io decouples large assets from GitHub quotas while making them instantly accessible to humans and automated agents. Rather than choking GitHub Actions artifact quotas, CI runners and AI agents stream build outputs directly into shared, organization-owned workspaces equipped with per-file version history, granular access permissions (organization, workspace, folder, and file level), and an append-only audit log. For organizations deploying autonomous agent workflows, [storage for agents](/storage-for-agents/) provides dedicated persistence for agent reads and writes.

Key technical advantages for developer and agent workflows include:

* **Native Model Context Protocol (MCP) Connectivity**: Autonomous AI agents connect to Fast.io workspaces via the Model Context Protocol. Fast.io hosts a remote MCP server over Streamable HTTP: coding agents such as Claude Code and Cursor connect at `https://mcp.fast.io/mcp/code`, ChatGPT and Codex connect through the Fastio plugin with the custom MCP server at `https://mcp.fast.io/mcp/operations` as an alternative, and Claude apps and general MCP clients connect at `https://mcp.fast.io/mcp/tools`. Interactive clients sign in with OAuth in the browser and carry no API key, while headless code sends an `Authorization: Bearer <api key>` header on the connection. Agents read, write, and organize persistent outputs directly without drawing down Git storage or CI minutes. Detailed setup steps are documented in the [Fast.io documentation](https://mcp.fast.io/docs).
* **Built-in Intelligence and Hybrid Search**: When Intelligence Mode is enabled on a workspace, files are indexed automatically upon arrival. Agents query historical build logs, test captures, and documentation using hybrid search (combining full-text, semantic similarity, and metadata values) and retrieve answers backed by citations, eliminating the need to maintain an external vector database.
* **Metadata Views for Structured Extraction**: Fast.io Metadata Views turn unstructured build documents into typed databases (supporting Text, Integer, Decimal, Boolean, URL, JSON, and Date schemas) across PDFs, images, and spreadsheets without manual OCR templates. Explore [document data extraction](/product/document-data-extraction/) to see how structured views simplify automated inspection.
* **Frictionless External Sharing**: Stakeholders, clients, and QA reviewers access build deliverables through branded share links (Send, Receive, and Exchange) that can disable file downloads. External guests open shares without consuming team seats.

Fast.io plans include a fixed storage allowance, and bandwidth is billed by use. Review the current [Fast.io pricing](/pricing/) options for organization tiers:

| Plan Tier | Monthly Billing | Annual Billing | Included Seats | Included Storage | Included AI Credits |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Starter | $29/mo | $290 annually | 5 seats | 1 TB | 300,000 credits/mo |
| Business | $99/mo | $990 annually | 20 seats | 10 TB | 1,200,000 credits/mo |
| Enterprise | $299/mo | $2,990 annually | 50 seats | 50 TB | 4,500,000 credits/mo |

Every organization starts with a 14-day free trial, which requires a credit card. Credits meter AI operations, and organizations can add additional credit blocks whenever automated agent workflows scale up.

## Decoupling Source Code Repositories from Workspace Storage

Implementing a clean separation of concerns between code repositories and binary asset storage stabilizes developer velocity and isolates infrastructure from unexpected GitHub storage overages.

To implement this architecture in production, establish clear boundaries regarding where files live:

* **Keep in Git**: Source code, test scripts, infrastructure manifests, Dockerfiles, GitHub Actions workflow definitions, documentation markdown, and configuration schemas.
* **Move to Workspace Storage**: Compiled application packages, end-to-end browser test video recordings, dataset archives, AI model checkpoints, evaluation run traces, and generated PDF reports.

### Implementing Fast.io Offloading in GitHub Actions

Instead of executing `actions/upload-artifact` in your workflow, configure your runner to offload build assets directly to a Fast.io workspace using a lightweight API or MCP tool call.

Store your `FASTIO_API_TOKEN` and `FASTIO_WORKSPACE_ID` in your GitHub repository secrets. In your workflow file, invoke the Fast.io MCP endpoint:

```yaml
name: Build and Offload Deliverables
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
      - name: Compile Application and Generate Deliverables
        run: |
          npm ci
          npm run build
          tar -czf release-${{ github.sha }}.tar.gz dist/
      - name: Offload Asset to Fast.io Workspace
        run: |
          curl -s -X POST https://mcp.fast.io/mcp/tools \
            -H "Authorization: Bearer ${{ secrets.FASTIO_API_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "jsonrpc": "2.0",
              "method": "tools/call",
              "params": {
                "name": "storage_manage",
                "arguments": {
                  "action": "write",
                  "workspace_id": "'"${{ secrets.FASTIO_WORKSPACE_ID }}"'",
                  "path": "builds/release-${{ github.sha }}.tar.gz"
                }
              },
              "id": 1
            }'
```

Autonomous agents operating downstream can immediately interact with this uploaded archive by querying the workspace through the Fast.io MCP interface:

```json
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "storage",
    "arguments": {
      "action": "search",
      "search": "builds release production archive"
    }
  },
  "id": 2
}
```

### Tangible Operational Benefits

Decoupling repository history from binary asset delivery produces four immediate advantages:

1. **Sub-Second Clones**: Keeping repository history free from large binaries and ephemeral build dumps ensures lightweight checkouts. New developers and ephemeral CI runners clone repositories in seconds rather than minutes.
2. **Elimination of Quota Lockouts**: Moving heavy assets out of GitHub Actions prevents unexpected artifact limit exhaustion, guaranteeing that critical pull request checks and deployments never halt due to storage caps.
3. **Auditability and Version Control**: Fast.io maintains per-file version history and a detailed activity log. If a pipeline generates a new build or an AI agent updates a dataset, previous versions remain intact and recoverable.
4. **Persistent Knowledge and Team Retrieval**: Rather than disappearing after an aggressive 1-day or 3-day GitHub Actions retention window, important build deliverables, design assets, and benchmark reports remain permanently discoverable and searchable for both human engineers and AI assistants.

## Frequently asked questions

### How much free storage do you get on GitHub?

GitHub Free provides 500 MB of included shared storage per account, which is pooled between GitHub Actions artifacts and GitHub Packages. In addition, each repository receives a separate 10 GB cache allowance for GitHub Actions. For Git repository history, GitHub repository limits recommend keeping the on-disk repository size under 10 GB, with individual files strictly limited to 100 MB.

### What happens when you hit your GitHub storage limit?

If an account reaches its storage limit without a payment method on file or with a zero dollar spending limit, GitHub blocks new Actions artifact uploads with HTTP 403 errors and rejects new GitHub Packages publishes. If a payment method is attached, GitHub automatically bills additional shared storage at $0.25 USD per gigabyte per month.

### How do I check my GitHub storage usage?

To check storage usage, navigate to your GitHub User or Organization Settings, select Billing and plans, and review the Plans and usage section under Storage for Actions and Packages. You can also click Get usage report to download a comprehensive CSV breaking down storage by repository and date.

### Is GitHub Actions cache included in the shared storage limit?

GitHub Actions cache storage is completely separate from the shared artifact and package storage pool. Each repository receives an included cache allowance of 10 GB. If cache storage for a repository exceeds 10 GB, GitHub automatically evicts older cache entries based on a least-recently-used algorithm.

### How can teams reduce GitHub Actions artifact storage consumption?

Teams can reduce storage by lowering the default retention period from 90 days to 1 or 3 days using the retention-days parameter in workflow files, automating artifact deletion upon pull request merges, and offloading heavy build deliverables to external cloud workspaces.

## Sources

- [GitHub Docs: GitHub Actions billing](https://docs.github.com/en/billing/concepts/product-billing/github-actions): GitHub plans provide shared storage for Actions artifacts and Packages across Free, Team, and Enterprise accounts, alongside a separate 10 GB cache allowance per repository, with overage fees incurred when exceeding included plan storage allowances.
- [GitHub Docs: Repository limits](https://docs.github.com/en/repositories/creating-and-managing-repositories/repository-limits): GitHub repository limits recommend staying under 10 GB on-disk size, enforcing a 100 MB single object limit and a 2 GB push limit.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.