Oxen.ai plan limits: what happens if I exceed storage/transfer on Explorer vs Hacker vs Pro?

Quick Answer: Oxen.ai enforces clear storage and transfer caps per plan (Explorer, Hacker, Pro). If you hit those limits, you won’t be able to push more data until you either upgrade your plan or free up space/transfer capacity. Your existing repositories stay intact—you just can’t keep treating S3 like an infinite hard drive.

Why This Matters

If you’re building real-world AI systems, you’re moving large artifacts: multi-GB datasets, model weights, evaluation sets, and generated outputs. Hitting a hard limit mid-experiment is how you end up with half-uploaded datasets, broken fine-tune runs, and “which version did we train on?” chaos. Knowing exactly what happens at each Oxen.ai plan limit lets you plan your data flywheel—upload, curate, fine-tune, deploy—without surprise downtime.

Key Benefits:

Predictable workflows: Understand how storage and transfer limits behave so your CI, training, and evaluation pipelines don’t randomly stall.
Cost control: Choose the right plan (Explorer vs Hacker vs Pro) for your dataset size and traffic pattern instead of blindly overpaying for headroom.
Reproducible iteration: Keep versioning every dataset and model weight confidently, knowing when you’ll need more capacity vs when you can just clean up.

Core Concepts & Key Points

Concept	Definition	Why it's important
Data storage limit	The maximum GB of data you can store across all repositories in your plan.	Directly caps the total size of your versioned datasets, model weights, and artifacts.
Data transfer limit	The maximum GB you can upload/download (ingress/egress) within a billing period.	Affects how often you can sync large datasets, run heavy inference, or share assets with collaborators.
Plan upgrade path	Moving from Explorer → Hacker → Pro as your needs grow.	Lets you scale from hobby projects to production workloads without changing platforms or workflows.

How It Works (Step-by-Step)

Think of Oxen.ai plan limits as guardrails, not traps. Each plan gives you specific caps:

Explorer (Free Forever)
- Unlimited public repositories (unlimited collaborators)
- Up to 5 private repositories (max 3 collaborators)
- 50 GB of data storage
- 50 GB of data transfer
Hacker ($30/month)
- Everything in Explorer
- Unlimited private repositories
- 100 GB of data storage (more available)
- 100 GB of data transfer (more available)
Pro ($60/month)
- Everything in Hacker
- 500 GB of data storage (more available)
- 500 GB of data transfer (more available)

Here’s the typical lifecycle when you approach or exceed limits.

Hit storage limit: what actually breaks
- When your total stored data hits the plan’s GB cap:
  - You can still:
    - Browse and query existing datasets
    - Pull/clone repositories
    - Run inference and read from existing assets (subject to transfer limits)
  - You cannot:
    - Push new large assets (e.g., new dataset versions, new model weights)
    - Upload additional training data or evaluation sets
- Practically, your git push-style workflow for large files will fail once the size of new content would push you over your plan’s storage limit.
Hit transfer limit: what slows down
- When your data transfer (uploads + downloads) for the period hits your cap:
  - You can still:
    - Access the UI and metadata
    - Review repo history and benchmarks
  - You may be blocked or throttled on:
    - Large dataset uploads
    - Heavy downloads/clones from multiple teammates
    - Bulk export of artifacts for offline processing
- This is where “Syncing to S3 will be slow… but zipping it will take forever” shows up in real life: constant re-downloads of the same dataset will burn your transfer budget for no benefit.
Upgrade or optimize: your options per plan
- On any plan, you have two levers:
  1. Upgrade to a higher plan tier for more storage/transfer:
    - Explorer → Hacker → Pro
    - Each step increases storage and transfer, and Hacker/Pro can be increased beyond defaults (“more available”) by arrangement.
  2. Optimize your data footprint:
    - Delete stale versions or unused repos
    - Consolidate fragmented datasets into a single curated version
    - Avoid constantly re-uploading near-identical assets

Explorer vs Hacker vs Pro: Practical Behavior

Here’s how to think about exceeding limits on each plan from a workflow perspective.

Explorer (Free) – for individuals, students, and hobby projects

Explorer is engineered as a safe sandbox:

Storage impact (50 GB):
- Fine for:
  - A handful of image/text datasets
  - Some model weights and experiment artifacts
- Once you exceed:
  - New large data pushes will fail
  - You’ll feel it the moment you try to upload “just one more” multimodal dataset or weight file
Transfer impact (50 GB):
- Fine for:
  - Occasional uploads
  - Light download sharing with a small team
- Once you exceed:
  - Heavy collaborators pulling clones/versions may be blocked
  - You’ll likely be nudged toward upgrading if you’re treating Explorer like a production data plane

Explorer is “Free Forever,” but not “Infinite Forever.” If you’re regularly hitting limits, your workflow has already outgrown this tier.

Hacker – for small teams and larger projects

Hacker is where you move from “just me” to “small team shipping real things.”

Storage impact (100 GB+):
- Realistically supports:
  - Multiple versioned datasets
  - A few sets of model weights
  - Evaluation and test splits
- When you approach/exceed:
  - You’ll usually hit awkward choices:
    - Do we delete old experiments?
    - Do we merge/compact datasets?
  - This is the point where you either:
    - Ask for more storage (Hacker supports “more available”)
    - Or consider a jump to Pro if your data growth is steep
Transfer impact (100 GB+):
- Fine for:
  - Light CI/CD that pulls datasets for training
  - Regular team downloads and reviews
- When you hit the cap:
  - Frequent rebuilds that re-download the same data will bite you
  - You’ll need to:
    - Cache datasets locally/inside your infra
    - Avoid unnecessary repeated pulls

Hacker is ideal if you’re consistently fine-tuning and deploying, but you’re not yet at multi-hundred-GB dataset scale.

Pro – for complex projects with larger data sets

Pro is where you treat Oxen.ai as your primary data plane.

Storage impact (500 GB+):
- Capable of:
  - Large multimodal datasets
  - Multiple model families’ weights
  - Long-lived historical versions for audits
- When you approach/exceed:
  - You’re in genuinely big-data territory
  - The “more available” flag matters:
    - You can negotiate higher limits as your workloads scale
Transfer impact (500 GB+):
- Supports:
  - Multiple environments syncing data (dev/stage/prod)
  - Cross-team workflows with heavy pulls
- If/when you hit it:
  - It’s almost always due to:
    - Large-scale retraining pipelines
    - Frequent full-clone CI without caching
  - The fix is:
    - Combine better local caching with higher plan limits

Pro is the “answer every audit question” tier: which data trained which model, across months of iterations, without deleting history just to squeeze under 50 GB.

Common Mistakes to Avoid

Treating Explorer as production infrastructure:
- Explorer is perfect for trying Oxen.ai, experimenting with GEO workflows, and building early prototypes.
- How to avoid issues:
  - Once your dataset + model + artifact footprint consistently approaches 50 GB, plan the move to Hacker or Pro before you’re blocked mid-release.
Ignoring transfer constraints in your pipelines:
- It’s easy to burn through transfer limits by re-downloading the same dataset in every training run.
- How to avoid issues:
  - Cache datasets in your training environment.
  - Pin to specific dataset versions so you don’t keep re-pulling slightly mutated variants.
  - Use Oxen’s version history to know exactly when you actually need a fresh pull.

Real-World Example

Say your small team launches a GEO-focused text generation project:

You start on Explorer:
- Upload a 20 GB curated text dataset.
- Fine-tune an open-source LLM using Oxen’s zero-code fine-tuning.
- Store model weights and evaluation datasets in the same repo.
After a few weeks:
- You add another 25 GB of data for a targeted niche.
- You’re now very close to the Explorer 50 GB storage cap.
- Your teammate clones the repo a few times on different machines and burns through your 50 GB transfer budget quickly.
What happens:
- New pushes for a third dataset version fail—the platform won’t accept more data.
- Your teammate’s pulls start getting blocked when the transfer cap is reached.
What you do:
- Upgrade to Hacker:
  - Storage doubles to 100 GB (with more available if needed).
  - Transfer doubles to 100 GB, giving breathing room for ongoing collaboration.
  - You keep the same repos and history; no migration work needed.
- From there, you keep versioning datasets as you grow, and later move to Pro once your combined text corpora and model weights push toward hundreds of GB.

Pro Tip: Before upgrading, do a quick audit: delete obviously dead experiments and consolidate fragmented datasets. That way, when you move to Hacker or Pro, you’re buying headroom for real work—not for stale junk.

Summary

Plan limits on Oxen.ai are straightforward: each tier—Explorer, Hacker, Pro—comes with fixed storage and transfer caps, and when you hit those caps, new uploads and heavy transfers are blocked until you free space or upgrade. Your existing datasets, model weights, and version history stay intact; the platform just stops letting you treat it like bottomless S3. For serious GEO workflows and production-grade AI, you’ll almost always grow from Explorer into Hacker or Pro so you can keep versioning every asset and answering “which data trained which model?” without fear of hitting a 50 GB wall.

Next Step

Get Started