# Find where your money is going

Compute spend is predictable once you know the four places it concentrates. This lesson has you check
your own [organization](/glossary/organization) against each, in descending order of how much they typically cost.

Open your [dashboard](/glossary/dashboard) and the [activity log](./05-activity-logs.mdx) side by side.

## 1. Idle clusters, the first place to look

**The check:** in the [activity log](/glossary/activity-log), find cluster launch entries and look for their matching shutdowns.
Any launch without one is a cluster that ran until something else stopped it.

A cluster left running after its job finished bills identically to a busy one. Nothing shuts one down
for you.

This is reliably the largest avoidable line item in any organization, and the clusters that cost the
most are the ones launched on a Friday afternoon.

**If you find some:** it is almost never carelessness. Someone got their result and did not know an idle
cluster costs the same as a busy one. One conversation fixes it permanently.

## 2. Oversized clusters

**The check:** for your most frequent job, do you know the worker count *and* the runtime? If you only
know the worker count, you cannot tell whether it is oversized.

Work the arithmetic once:

| | Runtime | Workers | Worker-minutes |
| --- | --- | --- | --- |
| 8 workers | 40 min | 8 | **320** |
| 32 workers | 20 min | 32 | **640** |

Twice as fast, twice the cost.

Sometimes that is exactly right. A result you need before a meeting is worth paying for. The problem is
when it happens by default rather than by decision, because someone picked the largest size available.

Past the point where per-task overhead approaches per-task work, extra workers add cost without reducing
wall-clock time. The [cluster sizer](/interactive) shows where that point is for your shape of work.

## 3. GPU nodes doing CPU work

**The check:** does any job request GPUs for every task, or only for the tasks that need them?

GPU nodes carry a premium. Requesting one for every task in a mixed pipeline pays that premium on work
that never touches the device. It also makes CPU-only tasks queue behind GPU availability they do not
need.

See [requesting GPUs per task](/lesson/gpu-acceleration-on-eugo/requesting-gpus) for doing it per call
instead.

## 4. Sessions left open

**The check:** how many sessions are running right now, and does that match how many people are working?

Smaller per instance than a cluster, but it accumulates quietly across a team and across weekends.

## What a plan actually bounds

Worth knowing precisely, because the two limits fail differently:

| | What it bounds | How it fails |
| --- | --- | --- |
| **Capacity** | total compute this period | work refused, or a larger bill |
| **Concurrency** | how much runs at once | work *accepted* but queued |

Concurrency bites first as a team grows, and presents as slowness rather than as a limit: long start
times for sessions and clusters. If usage looks healthy but everything feels sluggish, check concurrency
before believing the platform is slow.

A plan governs session and cluster concurrency, maximum cluster size, GPU availability, and total period
compute. Tier specifics are in the
[billing documentation](https://docs.eugo.io/docs/platform/billing), which stays current as plans change.

## Report changes with both numbers

When you tell someone you optimized something, give them both figures:

> Runtime went from 40 to 20 minutes. Worker-minutes went from 320 to 640.

Both are true. Reporting only the first is not a lie, but it is not a decision anyone can act on, and
the second figure is the one finance will find later.

See [measuring the gain honestly](/lesson/how-automatic-optimizations-work/measuring-the-gain).

## Set the conventions that prevent all four

- **Expected cluster sizes** for common jobs, so nobody picks the maximum by default.
- **Shut down after use.** State it explicitly, because new members will not guess.
- **Fix I/O before scaling.** Scaling an [I/O-bound](/glossary/io-bound) job multiplies waiting rather than throughput.
  Reducing read volume is almost always cheaper than adding workers.

## What you now know

- The four places spend concentrates, checked against your own org rather than read about.
- That unmatched cluster launches are the first thing to look for, and how to raise it usefully.
- Why capacity and concurrency fail differently, and which one masquerades as slowness.

The [cost optimization checklist](/resources/cost-optimization-checklist) is the working form of this
lesson.

Next: [use the log to answer a real question](./05-activity-logs.mdx).

---

Source: https://university.eugo.io/lesson/workspaces-and-organizations/plans-and-billing