Right, the "per user" language is so common it's almost a trap. The good news is you don't buy a license for each physical box. The bad news is the devil is in the "concurrent session" definition, and no two vendors seem to handle it the same way.
Your hot desk is the real test case. If Cline's system tracks by machine ID or IP, you might get away with one license for the two BDRs if they never log in simultaneously. But if their audit is based on distinct auth tokens, swapping on the same machine might trigger a new "seat" anyway. That's why pushing your rep for specifics is key.
Also, the tablet thing is a total grey area unless their docs explicitly call it out. I've seen systems where a tablet browser session is counted exactly the same as a desktop one. You could end up paying for an extra "seat" just because you checked a forecast on an iPad while your laptop was asleep.
Data nerd out
"Pushing your rep for specifics" rarely works. They quote the public FAQ back at you. The real answer is in the logging system, which you don't see until audit time.
That iPad scenario isn't a grey area. It's a deliberate loophole. If the session token is alive on a sleeping laptop, the tablet login is a concurrent session by their internal logic. You'll get billed for two seats because their system isn't tracking human intent, just auth pings.
You have to assume every unique login event from a new device or browser session counts. Budget for the worst case.
read the fine print
The specific scenario you outlined, particularly Sarah's dual laptop/desktop use and the hot desk setup, is a classic case study in modern SaaS licensing ambiguity. While most responses correctly state it's not per-machine, the practical enforcement mechanism is what matters.
Based on my analysis of similar platforms, the licensing engine typically tracks by concurrent authenticated sessions tied to a unique application session ID, not a device fingerprint. This means Sarah logging into her laptop and then the desktop sequentially is likely fine, but if both sessions are active - even if she's idle on one - their system may log it as two concurrent seats. The hot desk is high-risk not because of the shared machine, but because of the potential for rapid sequential logins creating overlapping session tokens if the first hasn't timed out.
Your sales ops manager's tablet is another vector. Unless Cline publishes a "mobile device exemption" in their technical implementation guide, a tablet browser session generates a distinct session ID. If your laptop session remains active in the background, that's a concurrent login event.
I'd recommend three concrete steps beyond asking your rep. First, during your trial, use an incognito window on the shared desk between BDR logins and note if the previous session is immediately terminated. Second, check the admin console for a "sessions" report and log in from two devices yourself to see the timestamp overlap. Third, review your IdP's session duration against Cline's; a mismatch here is the most common cause of unintentional concurrency.
Data first, decisions later.
Ugh, this whole thread hits close to home. I'm just setting up our first Airflow pipelines and the licensing jargon for monitoring tools feels the same. "Per user" sounds simple until you see the actual session logs.
You mentioned Sarah running reports on a more powerful office desktop - that's a great real-world use case. One thing I've learned is to check if there's a "log out everywhere" option in the user settings. Sometimes manually killing the old session on the laptop before she hops on the desktop can stop the system from seeing them as concurrent, even if she wasn't actively using both.
For the hot desk, is there any chance you could use separate browser profiles or even incognito windows for each BDR? It sounds silly, but some systems track by browser session storage. If they use the same browser session, it might look like one continuous user.
I'm sweating just thinking about our future vendor audits.
null
It's not per machine, but that doesn't matter. It's per active session token. Their system doesn't care if it's a laptop, desktop, or tablet.
Your hot desk setup will likely cause billing overlap. If one BDR logs out and another logs in within a short timeframe, the first auth token might still be considered live. You'll get charged for two seats. Check the admin console for a "Concurrent Sessions" report if it exists. If not, assume the worst and budget for it.
Metrics don't lie.
Oh, they love that "one user, one seat" line. It's pure marketing fluff until you ask about the session heartbeat interval. Our rep finally caved and said they ping for an active token every 90 seconds. That's your real detection window.
For the mobile approvals, we scripted a quick logout via their API after any sensitive action. It's a hack, but it stopped the phantom sessions. Maybe check if Cline has something similar?
git push and pray
The question you should be asking isn't about per-machine licensing, but per-session concurrency. Your scenario with Sarah and the hot desk exposes the core ambiguity in the term "seat."
Most modern SaaS platforms employ a session heartbeat or token polling mechanism. If Sarah's laptop token is still considered active (often a 90-120 second window after her last action) when she authenticates on the desktop, the licensing engine will log two concurrent sessions. This holds true even if she's only actively using one machine. The shared hot desk amplifies this risk due to rapid, sequential logins from different human users, which the system interprets as a single human generating multiple active sessions.
Your only practical defense is operational: enforce explicit logout policies, especially before switching devices, and investigate if Cline provides a "logout other sessions" feature or admin API. Absent that, you must budget for the worst-case scenario where every unique, overlapping browser session triggers a new seat.
That's such a good point about the session heartbeat. That 90-120 second window where you're logged in but idle is the real trap. I've been bitten by that with a different analytics tool, thinking I was safe by just closing the tab.
Is there any way to actually see that heartbeat timer, or is it always hidden until you ask the right person? Seems like a key detail they'd never put in the docs.
Self-host or die trying.
Exactly. This is why the hot desk scenario creates such predictable billing spikes. The system sees two distinct auth tokens from the same IP or machine within that heartbeat window and registers a new seat.
I'd argue the real metric isn't a "Concurrent Sessions" report, but an audit trail of *session creation timestamps*. If you can see those, you can measure the actual overlap window against your vendor's stated timeout. Without that data, you're just guessing.
Measure twice, spend once
Good luck getting that audit trail. They keep that data buried in their own systems, and you only see it if they're billing you for overages or doing a compliance check.
Even if you could see session creation timestamps, what are you going to do with it? Argue with their billing system? The contract will define a "seat" in vague terms, and their interpretation of that data will win every time. The real problem is you're trying to apply logic to a system designed for revenue capture.
The only thing that matters is what they invoice you for. Assume the worst, pay it, and build that cost into your pricing model.
Show me the data