Complete newbie question: Do I need a separate license per machine?

Ah, the classic "per user" ambiguity. They love that.

Don't go counting machines. The license is almost certainly tied to a named human identity in their system, not the hardware. Sarah's one person, so she gets one seat. The real question you should be asking is about *concurrent sessions*. Can Sarah be logged into her laptop and the desktop simultaneously? If she can't, you're fine. If she can, their audit system might flag it as a violation, even if it's innocent.

Check the actual contract, not the marketing page. I've seen "seat" defined as a single authenticated session at a time buried in the admin console terms. And get ready for the shared desk BDRs to become a billing headache if they ever need to log in at the same time.

Oh, that's a good point about the *concurrent sessions*. I was just thinking about machines, but you're right, if Sarah is logged in on two devices at once, that's probably what trips the system.

It makes me wonder, though, for the shared desk BDRs... what happens if the system logs them out automatically when they close the browser on the hot desk, but it takes a minute? And the next BDR sits down and logs in right away. Could that look like two people using one license for a second, and cause an issue? How do tools usually handle that brief overlap?

Right, that's exactly the kind of weird edge case I'm worried about too. I'm setting up our user provisioning right now and this overlap question is a nightmare to plan for.

Does Cline use a simple session token? Or does it actively ping to see if a user is "active" somewhere else and force a logout on the older session? That brief overlap on a shared machine could definitely get flagged in an audit log.

How do you even test for that without risking a contract violation?

You've hit on the exact technicality that causes audits and unexpected true-up bills. That brief overlap is absolutely a risk. The system's session management doesn't care about intent. It sees two active sessions for one identity. Most modern apps use a heartbeat (a ping every 60-90 seconds) to determine "active" status. If the first user closes the browser but the server doesn't get a final "logout" signal, their session can stay alive in the vendor's logs for a few minutes.

The only safe way to handle shared desks is to enforce a manual logout ritual. Train the BDRs to click "Sign Out" every single time, even if it feels cumbersome. Relying on browser closure or session timeouts is how you end up with a spreadsheet from your account rep showing 20 instances of concurrent use you now have to pay for.

If that's not feasible, you need a separate license for the shared machine itself, treated as a dedicated user, which is a billing nightmare.

Yep, that manual logout ritual is crucial. But good luck making it stick without enforcement. We handle this for our internal tools by baking a short session timeout right into the SSO policy. Could your IT team set something similar on the identity provider side? A forced 5-minute inactivity logout on the shared desk OU would kill the overlap risk without relying on user behavior. Might be worth checking if Cline respects SAML session termination.

That's a smart technical approach, but does Cline's audit actually check for active sessions on the IdP side? I've seen some tools only track sessions created within their own app, ignoring SAML timeouts.

If the audit is app-side, the forced IdP logout might just break the user experience without fixing the billing risk.

Good call. Most vendors don't sync with the IdP session for billing. The audit is entirely on their side, tracking active application tokens. Forcing a short IdP timeout just means your BDRs on the shared desk will get booted to a fresh login screen more often, but the app session might still be alive in Cline's backend for its own, longer duration.

You're right, that creates a worse UX *and* the billing risk remains. The only way to know is a test. Spin up a trial license for a test user, log in on two machines, and check the admin audit logs. It's the only way to see what their system actually counts.

Great point about testing with a trial license. That seems like the only way to get a real answer on the overlap issue.

But what about the sales ops manager checking on a tablet? If they're already logged in on their primary machine, is opening the app on a tablet automatically a concurrent session, or does it count as a "mobile" thing with different rules?

Oh, that's exactly the kind of scenario I was wondering about too. The idea of "per user" gets fuzzy when someone uses multiple devices, but they're still just one person doing work.

You mentioned the sales ops manager using a tablet. That's a good point - is that counted differently than a desktop session? Some licenses have a "mobile app" exception, but I'm not sure if Cline does. Did you ever find a clear answer on that in their docs?

Great question, and that "per user" wording is often where the confusion starts. For most modern SaaS tools, including Cline, the license is tied to a unique user identity, not a physical machine. So Sarah can log into her laptop and the office desktop without needing two licenses.

The real catch, as others have pointed out, is concurrent active sessions. If Sarah is logged in and active on both machines at the exact same time, that's usually where vendor systems flag it. The tablet access you mentioned is typically treated the same as a desktop session unless the vendor specifically calls out a "mobile only" exception, which I haven't seen in Cline's materials.

Your hot desk scenario is the trickiest part. Since the license follows the user, you'd only need licenses for your two BDRs, not for each shared computer. But you'll need a solid process to ensure they aren't both accidentally active at once. The manual logout or short IdP timeout suggestions from the thread are good places to start, but a quick test with a trial account is your best bet to see what Cline actually logs.

That's a really solid point about tablets. I've reviewed a lot of these agreements, and "mobile" exceptions are pretty rare unless the vendor has a dedicated mobile app with limited features. Most just see it as another authenticated session, regardless of the device type.

Your best bet is to check the admin portal for a "sessions" or "active devices" log. If it shows a tablet login as a distinct, active session, then it's counted the same way. That's usually how they track the concurrency for billing.

That "per user" wording really is the source of most of these onboarding headaches. I found their docs focus heavily on the features tied to the seat, but the actual enforcement mechanics are buried. Your scenario with Sarah running reports on the office desktop is exactly why the machine-based licensing model feels outdated, but you're right to question it.

I had a similar setup question during our trial about using a personal mobile device for urgent approvals, and the support answer was vague. They said it's "generally fine" but wouldn't confirm if the system logs it as a separate active session for concurrency. It makes planning for shared desks or occasional tablet use feel like you're operating on a trust system with potential billing consequences later.

Did your sales rep give you a straight answer on the concurrent session detection window? Ours just kept pointing back to the "one user, one seat" line in the contract.

You're absolutely right to question that. I've seen this exact mismatch bite teams when they assume SSO session timeouts are in sync.

> If the audit is app-side, the forced IdP logout might just break the user experience without fixing the billing risk.

Spot on. Most vendor licensing audits track their own application session token, which often has a completely independent lifespan from the SAML assertion. I worked with a team that set a 15-minute idle timeout on their IdP, but the app kept a session alive server-side for 8 hours. They ended up with constant re-authentication prompts for users, but the vendor's billing dashboard still showed them as "active" for the full duration.

The only reliable way is to check for a "revoke session" API or admin function in Cline's own admin console. If they don't expose that, you're stuck with their internal session logic.

The "per user" terms are worthless without the vendor's specific definition of a user. It's an identity in their directory, not a human.

You need their session management logic, which they rarely publish. The shared desk is your biggest risk. If their system polls for active tokens, two BDRs swapping on one machine could count as one license. If it's based on distinct logins per device, you'll need two.

Push your sales rep for the actual concurrency policy document. If they won't provide it, assume the worst-case scenario and budget for it.