DenkOps meters usage per project on two axes: requests served and RAM-hours consumed, rolled up into hourly buckets. Requests tell you how much work a project is asked to do, RAM-hours tell you how much memory it holds and for how long. Because the rollup is per project, "which of my agent backends is the expensive one" is a question the Usage page answers directly, not something you reconstruct from a monthly invoice.
What exactly is counted?
Two meters, both scoped to a single project:
- Requests. Every request your app serves, HTTP endpoints and MCP tool calls alike. Each one is attributed to the hour it started in, so a traffic spike shows up in the right bucket even if metering runs a little behind.
- RAM-hours. Your project's memory allocation multiplied by the time it runs. An always-on slot with 512 MB allocated accrues 512 MB-hours per hour, whether it served ten thousand requests or none.
That second meter is worth internalizing: RAM-hours are a steady baseline that comes from keeping a process warm, which is exactly what buys you no cold starts and working in-process schedulers. Requests are the variable part that tracks real traffic.
How do I find the expensive agent?
The metering is per project, so your project layout is your cost report. If three agents share one project, their usage arrives as one line. Give each agent backend, connector, and bot its own project and the Usage page becomes a ranked answer:
- Sort by requests. A connector doing 50x the tool calls of its siblings is either popular or being hammered by a runaway agent loop. Both are worth knowing today, not at month end.
- Look at the shape, not just the total. Hourly buckets show whether load is a business-hours curve, a nightly scheduled-job spike, or a flat line of retries from a stuck client.
- Cross-reference with traces. Metering says which project is busy, request traces say why each request is slow and whether time goes to your code or an external API. High requests plus high external-I/O time usually means an agent is calling a tool in a loop it should not be in.
RAM-hours rarely surprise you within one project, they move only when you change the memory allocation. Across a workspace they matter more: five forgotten prototype projects each holding a slot around the clock add up, and the per-project rollup is how you spot them.
How does this relate to what I pay?
Slots and metered usage are the two halves of the picture. Your plan determines the slots you run; the meters show what each project does with them. The same per-project numbers you see on the Usage page are the numbers billing uses, one source of truth, so what you see is what you are charged against. Plans and what they include are on the pricing page, the point here is that nothing about your bill is derived from data you cannot inspect yourself, hour by hour, project by project.
A practical monthly habit: open Usage, sort projects by requests, and ask two questions. Does the busiest project deserve to be the busiest? And is anything consuming RAM-hours that nobody has deployed to in a month? The first finds runaway agents, the second finds forgotten ones.