How do you control Crab object-storage cost?

A cheaper storage class does not guarantee a cheaper repository.

Suppose a Crab repository stores 10 TB and reads 2 TB from origin each month. Storage is only one line on the bill:

storage + requests + retrieval + transfer + early-deletion charges

Move the wrong 8 TB into archive and the storage line falls while restore delay and other charges rise.

The receipt uses Crab’s embedded S3 us-east-1 rates as an illustration. Use your current region, negotiated contract, and provider calculator for a real decision.

Measure four inputs

Start with repository inventory and Crab’s cost report:

crab du --remote
crab doctor --cost --json > before.json
crab optimize repo --json

Then add evidence the object listing cannot provide:

• Origin bytes read by workflow.
• GET, PUT, LIST, and restore request counts.
• Cache-served versus origin-served bytes.
• Required time to first readable byte.

Crab’s live inventory may infer Standard class when provider listings do not expose storage class consistently. Retrieval estimates are incomplete without access telemetry. Keep the pricing-table version from the report so the model is reproducible.

Use at least one full release, training, and recovery cycle. A quiet week can make monthly data look archival.

Match the control to the bill term

Do not change all controls together. The next bill will not show which change worked.

Reduce bytes before moving bytes

Use this order:

1. Measure unique chunk growth and deduplication.
2. Review recovery roots and collect unreachable objects.
3. Optimize the live xorb layout.
4. Tier only the cold, reachable tail.
5. Cache repeat reads close to the workload.

Tiering first can archive objects GC would remove. Repacking first can rewrite objects that retention policy will release.

Preview layout work before changing remote objects:

crab gc --scope repo --dry-run
crab optimize plan --include-xorbs --profile ml --json
crab optimize xorbs --profile ml --dry-run

Larger xorbs can reduce requests, but sparse reads may fetch extra range bytes. Record both sides of that trade.

Tier xorbs, not repository metadata

Crab lifecycle plans target .crab/xorbs/ only. Refs, manifests, shards, file indexes, and Git packs stay directly readable.

Why? A 4 KiB shard may unlock a 40 GB model. Archiving that metadata saves almost nothing and can block every hydration plan that needs it.

The opt-in defaults transition xorbs to a warm class after 30 days and a deep-cold class after 180 days. Those numbers are starting points, not proof that the data is cold.

Build separate age and access rows:

Shared xorbs follow object age and lifecycle prefix, not the branch that first uploaded them. Confirm that every workflow using a shared object can tolerate the destination class.

Plan now; do not assume apply is supported

Generate the provider policy without mutation:

crab tier plan

crab tier plan --apply currently fails closed for S3, GCS, and Azure because Crab does not yet have a qualified conditional, prefix-preserving lifecycle write path. S3’s lifecycle API has no conditional write.

That distinction matters: the plan is useful evidence, but it is not proof that Crab changed the bucket. Manage the reviewed lifecycle policy through your qualified infrastructure workflow until safe apply support exists.

When a provider adapter becomes qualified, --merge will preserve unrelated rules and replace Crab-managed rules. Still inspect broader Terraform or bucket rules that overlap .crab/xorbs/.

Treat restore time as a cost

Some classes remain directly readable with a retrieval fee. Other archive classes require a provider restore before Crab can hydrate their xorbs.

Choose behavior per workload:

• CI can use --no-restore and fail instead of waiting.
• Scheduled jobs can request a lower-cost bulk restore.
• Incident recovery can request the fastest supported tier.
• Warm data should stay directly readable.

Restored copies are temporary. Model restore-request charges, retrieved GB, the restored-copy duration, and the complete wait until hydration finishes.

Run a recovery drill before relying on an archive objective. Record:

1. Time to request all restores.
2. Time until every xorb is readable.
3. Retrieval and transfer bytes.
4. Hydration duration after restore.

A cheap class fails the policy if the release or incident cannot wait.

Watch minimum retention

In Crab’s embedded S3 table, Standard-IA has a 30-day minimum, Glacier Instant and Flexible Retrieval have 90-day minimums, and Deep Archive has 180 days. Other providers differ.

Deleting or rewriting earlier can create a charge for the remaining period. Class-aware crab gc blocks early deletion by default and estimates the penalty.

Include migration cost in payback:

payback months =
  transition requests + temporary storage + retrieval + operator time
  ------------------------------------------------------------------
                    expected monthly savings

Reject a migration whose payback exceeds the repository or policy lifetime.

Cache the repeated path

A local cache avoids repeat origin reads on one machine. A shared cache can do the same across developers and CI.

Caching does not reduce origin storage. Count cache compute, disk, and cross-zone traffic, then subtract avoided origin retrieval and transfer.

Use byte-weighted hit rate. A 95% object hit rate is weak evidence if the largest xorbs are the misses.

Review one change per billing window

Keep a compact record:

• Baseline dates and pricing-table version.
• Workflow access and restore evidence.
• One control changed.
• Expected bill and availability effect.
• Rollback or infrastructure revert path.
• First complete billing window for review.

End with one decision: keep the policy, adjust one measured threshold, or collect more evidence.

Review the crab tier, crab optimize, and pricing tables before changing provider policy.