oxygen: Skill for Claude Code

.claude/skills/oxy-scaling-design/SKILL.md

oxy-scaling-design is a skill for Claude Code from oxy-hq/oxygen. It costs 156 tokens per session (2,382 once invoked), scanned A, original, Apache-2.0.

An architecture guide for running Oxy as separate services: one stateful editing service, multiple stateless request servers, and a background worker. It also describes the planned removal of the server-side working copy.

In plain words
What is it for?
Use it when planning horizontal scaling, high availability, service roles, or changes that must work without a server-side copy of the code.
Why use it?
It explains how work is divided when Oxy runs across multiple instances and prevents new designs from depending on the editing service that is being retired.

Skill for Claude Code

Written for Claude Code: installed under .claude/.

This is oxy-hq/oxygen's own configuration. It tells Claude Code how to work on oxygen itself, so it is not a mod to install elsewhere. Copy it as a starting point and replace the rules that are about this project. Everything oxygen configures →

Reuse

Borrowing it

Nothing to install: this file belongs to oxy-hq/oxygen. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file
curl -O https://raw.githubusercontent.com/oxy-hq/oxygen/main/.claude/skills/oxy-scaling-design/SKILL.md
Clone the repo
git clone --depth 1 https://github.com/oxy-hq/oxygen

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for oxy-scaling-design

README.md
[![agentmods](https://agentmods.dev/badge/skills/oxy-hq/oxygen/oxy-scaling-design/github.svg)](https://agentmods.dev/skills/oxy-hq/oxygen/oxy-scaling-design)
Your own site
<a href="https://agentmods.dev/skills/oxy-hq/oxygen/oxy-scaling-design"><img src="https://agentmods.dev/badge/skills/oxy-hq/oxygen/oxy-scaling-design/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for oxy-scaling-design

Your own site · 80×15
<a href="https://agentmods.dev/skills/oxy-hq/oxygen/oxy-scaling-design"><img src="https://agentmods.dev/badge/skills/oxy-hq/oxygen/oxy-scaling-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 156 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,382 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00156 $0.02382
Opus 5.5 $0.00062 $0.00953
Sonnet 5.5 $0.00031 $0.00476
Haiku 4.5 $0.00016 $0.00238

Measured 2d ago against content hash 6a13db12c79d, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

oxy-scaling-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/oxy-scaling-design/SKILL.md · 76 lines

How it starts

The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Oxy multi-instance scaling — quick reference

The current architecture in one line: Oxy runs as a split fleet keyed by OXY_ROLE — a single stateful ide (the Factory: working copy + .git + compile + chat-run execution), a horizontally-scaled stateless serve fleet (reads Postgres + S3 only), and a worker queue drainer. This is a Postgres primary/read-replica shape: the ide is the primary, the serve fleet is the read replicas, and the compile boundary (compiled *_definitions rows + S3 blobs, keyed by revision_id) is the replicated read model.

The direction (decided 2026-10-05): the Factory is being retired, not scaled. No IDE; content is authored in git and pushed; compile becomes its own service that fetches a commit and serves previews and sandboxes; chat and every other surface read the compiled revision only; workspaces with no git remote go. Design new work so it needs no server-side working copy — a change that adds a reason to keep the Factory is going the wrong way. Plan, production data and open decisions: internal-docs/factory-retirement.md.

Read these first when grounding a decision:

  • internal-docs/multi-instance-fleet.md — how the fleet works today (roles, the stateful-vs-HA matrix, route classification, the super_read_only guard, graceful degradation, code map). The primary reference.
  • internal-docs/factory-retirement.md — the forward plan: phases, exit tests, and the existing statements it overturns.
  • internal-docs/multi-instance-fleet.md — the original phase ledger + the rejected-alternatives list.
  • internal-docs/compile-boundary.md — operator runbook.

What is built (the current reality)

  • Split fleet via OXY_ROLE (ide | serve | worker | all). One knob selects the topology; everything else derives from it. A serve replica derives in-process workers + the periodic global driver OFF; every other role ON. The legacy flags (OXY_DISABLE_INPROCESS_WORKERS, OXY_INPROC_GLOBAL_WORKER, --no-workers) survive only as two-directional overrides.
  • Compile boundary (compile-complete stateless serving). The ide compiles the working copy → Postgres *_definitions rows + S3 blobs per revision_id → promotes via workspaces.current_revision_id. The serve fleet reads the promoted revision and never walks the workspace FS. This is why the read path needs no working copy — and therefore no per-request clone.
  • Self-routing. role_manifest::classify is the single routing authority; a serve replica reverse-proxies IdeOnly requests to OXY_IDE_UPSTREAM (ide_proxy). Replaces the drift-prone external route table that caused three outages.
  • Route classification + HA carve-out. Every route states its pod at the mount — route_ide (FS/exec/live-stream) or route_fleet (Postgres/S3 reads stay HA) — and the two take differently-typed handlers, so a working-copy handler cannot compile onto a fleet route. Plus drift tests and the super_read_only runtime guard. See the oxy-route-classification skill.
  • Runtime-artifact S3 mirror (runtime_artifact.rs) — charts/results/app-data mirror to the compile-boundary bucket so any replica serves them; ide-down charts degrade to the S3 mirror.
  • Schedules/monitors fire without a leader. The periodic global driver runs on every eligible node; tick_schedules/tick_monitor_schedules CAS-advance next_run_at so firing is exactly-once across replicas. (Leader election was tried and removed — the CAS already guarantees it, and running on all eligible nodes is better HA.)
  • Backpressure — admission control (global ceiling + per-tenant fairness, 503 + Retry-After), worker HPA on outstanding work (queued + claimed) against capacity — see the recipe in internal-docs/worker-fleet.md; queue depth alone goes absent when the fleet keeps up.
  • Migrations — a dedicated migrate Job owns the schema; serve/compile/worker honour OXY_SKIP_MIGRATIONS; a startup advisory lock serialises co-booting nodes.
  • Main traffic off the Factory (October 2026). Custom-app function calls run on any replica, with a handler-level replay to the Factory for a workspace with nothing compiled or a database that is a file in the checkout. Airway start, single-window backfill, cancel, live stream and both resets are served by any replica. Custom-app procedure runs execute on the task queue, at most once, with an execution heartbeat. OXY_IDE_DEFER_QUEUE_WORK (off by default) makes the Factory drive only compiles and take anything else after 30 s unclaimed.

Read the full file on GitHub · 76 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 76 lines · 156 tokens per session scan A 6a13db12c79d

Subscribe to this mod's changes

oxy-scaling-design is a skill published in the GitHub repository oxy-hq/oxygen (203 stars, last pushed yesterday), licensed Apache-2.0. It adds 156 tokens to every session and 2,382 once invoked, about $0.0006 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-14.

Related

Other skills, from other repositories

gke-compute-classes

Configures, optimizes, and troubleshoots GKE ComputeClasses. Use when configuring Spot VMs with on-demand fallback, targeting specific accelerators (GPUs/TPUs) or machine families, restricting ComputeClass access, or debugging pending pods related to node pool auto-creation. Do not use for cluster-level Node Auto…

google/skills · 83 tokens

gke-reliability

Improves GKE workload reliability, using PDBs, health probes, and topology spread constraints. Use when configuring GKE workload reliability, setting up PDBs, or configuring GKE health probes (liveness, readiness, startup). Don't use for generating K8s YAML manifests (use gke-manifest-generation) or disaster recovery…

google/skills · 85 tokens

gke-workload-security

Audits, configures, and hardens workload-level security controls for Google Kubernetes Engine (GKE) applications and namespaces. Covers running security audits (auditcluster.sh), enforcing Network Policies (default-deny and Dataplane V2 logging), isolating high-risk pods inside GKE Sandbox (gVisor), enforcing Pod…

google/skills · 171 tokens

cloud-architect

Designs cloud architectures, creates migration plans, generates cost optimization recommendations, and produces disaster recovery strategies across AWS, Azure, and GCP. Use when designing cloud architectures, planning migrations, or optimizing multi-cloud deployments. Invoke for Well-Architected Framework, cost…

Jeffallan/claude-skills · 71 tokens

nemo-automodel-launcher-config

Configure NeMo AutoModel job launches for interactive runs, Slurm clusters, and SkyPilot cloud execution.

NVIDIA/skills · 30 tokens

azure-mgmt-botservice-dotnet

Azure Resource Manager SDK for Bot Service in .NET. Management plane operations for creating and managing Azure Bot resources, channels (Teams, DirectLine, Slack), and connection settings. Triggers: "Bot Service", "BotResource", "Azure Bot", "DirectLine channel", "Teams channel", "bot management .NET", "create bot".

microsoft/skills · 78 tokens