> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usechamber.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> How Chamber manages GPU capacity across your organization

Chamber is a GPU capacity control plane designed to maximize utilization while ensuring teams have guaranteed access to the resources they need.

## Architecture

Chamber operates as a SaaS platform with lightweight agents deployed in your Kubernetes clusters:

```mermaid theme={null}
flowchart TB
    subgraph control["Chamber (Cloud)"]
        Dashboard["Dashboard"]
    end

    control <-->|Secure connection| A
    control <-->|Secure connection| B
    control <-->|Secure connection| C

    subgraph A["Cluster A"]
        AgentA["Agent"]
        GPUA["GPU Nodes"]
    end

    subgraph B["Cluster B"]
        AgentB["Agent"]
        GPUB["GPU Nodes"]
    end

    subgraph C["Cluster C"]
        AgentC["Agent"]
        GPUC["GPU Nodes"]
    end
```

## How It Works

1. **Agents report capacity**: Lightweight agents in each cluster report available GPU resources
2. **Chamber schedules workloads**: When teams submit workloads, Chamber decides where to run them
3. **Agents execute locally**: Agents create and manage workloads on your clusters
4. **Dashboard provides visibility**: View utilization, manage teams, and track workloads

<Info>
  The agent only makes **outbound** connections to Chamber. No inbound firewall rules are required.
</Info>

## Data Model

Chamber's data model reflects enterprise organizational structures:

```mermaid theme={null}
flowchart TD
    Org["Organization"]
    Org --> Pools["Capacity Pools\n (GPU clusters)"]
    Org --> Teams["Teams"]

    Teams --> Child Teams["Child Teams"]
    Teams --> Res2["Reservations"]
    Pools --> Res1["Reservations"]

    Res1 <--> Res2
    Res2 --> Workloads["Workloads"]
```

### Key Relationships

| Relationship | Description |
| - | - |
| Organization → Teams | An org contains a hierarchy of teams |
| Organization → Pools | An org can have multiple capacity pools |
| Team ↔ Pool | Many-to-many via reservations |
| Team → Workloads | Workloads belong to exactly one team |

## Workload Classes

| Class | Capacity Source | Preemptible | Use Case |
| - | - | - | - |
| **Reserved** | Team's reservation | No | Production training, SLA workloads |
| **Elastic** | Reserved capacity first, then idle pool | Yes | Experiments, batch processing, dev work |

<Info>
  Elastic workloads maximize cluster utilization by using capacity that would otherwise sit idle, while still guaranteeing reserved workloads always have resources.
</Info>

## Next Steps

<CardGroup cols={2}>
  <Card title="Teams" icon="sitemap" href="/concepts/teams">
    Understand the organizational hierarchy
  </Card>

  <Card title="Capacity Pools" icon="server" href="/concepts/capacity-pools">
    Learn about GPU resource pools
  </Card>

  <Card title="Reservations" icon="bookmark" href="/concepts/reservations">
    How capacity is allocated to teams
  </Card>

  <Card title="Scheduling" icon="clock" href="/concepts/scheduling">
    Deep dive into the scheduler
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.