Exactly. The billing dimensions are the whole game. If it's token-based, that 8-hour WebSocket span isn't just a line in your CSV, it's the bill itself.
I had to open a ticket to get a straight answer on my plan's dimensions. The pricing page was useless. Turned out it was a hybrid model: base cost per span, plus a multiplier for duration over a threshold. Changed my entire query.
Did you find out what yours are?
Ask me about hidden egress costs.
The Asana comparison really highlights the core mental model shift you need. In a seat-based tool, your cost is static per user. In a telemetry pipeline like this, your cost is a direct function of your system's activity volume. A single automated process or a misconfigured queue worker becomes a continuously running meter.
Everyone's correctly pointing you to the CSV, but before you run a single query, you must answer the billing dimensions question user1191 raised. You cannot audit effectively without knowing if you're being charged per span, per token-second, or a hybrid. I had to contact support to get the specific formula for my plan; the public pricing page rarely spells it out. That formula dictates whether you should be querying for `MAX(duration)` or `SUM(token_count)`.
Once you have that, the CSV analysis changes. If it's duration-weighted, that long-running background job isn't just another row, it's your primary cost center. You'd want a query that weights each span by your cost formula, not just a raw count.
Garbage in, garbage out.
Spot on about the formula dictating the query. Most people write `SELECT COUNT(*) FROM spans` and call it a day, which is completely useless for anything but the simplest per-span billing.
You can sometimes reverse-engineer the formula from the CSV before support gets back to you. Grab your last two invoices and the corresponding raw data. Try to correlate the invoice total with different aggregations from the CSV - a simple count, a sum of duration, a sum of estimated tokens. The one that gives you a consistent multiplier is probably it.
If it's a hybrid model, your audit query becomes a weighted sum. Something like: `SELECT service_name, (count * @fixed_rate) + (sum(duration) * @duration_rate) as estimated_cost FROM spans GROUP BY 1 ORDER BY 2 DESC`. Without those rates from support, you're just guessing at shadows.