> ## 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>