A valid KocakZ key can still reach a device or session limit. These checks describe different parts of access: the key supplies the credential, an HWID identifies a bound device, and a session records an active run. Knowing which one failed helps you choose the right response.
Three parts of one access attempt
| Part | What it represents | What copying or reopening does |
|---|---|---|
| Key | The credential stored for an account, with a tier and expiry | Copying it does not create another license or extend its lifetime. |
| HWID binding | A device identifier accepted during loader use | Opening the website does not add a binding. |
| Session | A server-tracked script run | Another run may require another available session slot. |
Generating a key starts with empty device bindings. During an accepted loader start, the application checks the key, the supplied HWID, and session capacity before recording the run. A rejected allocation does not simply become a successful binding because you pressed a button.
Device capacity and session capacity are separate
Free access allows one HWID and up to five sessions. Premium allows up to five HWIDs and 50 sessions. The device allowance is not a promise that every browser tab or executor appears as the same identifier; the server evaluates the identifier submitted by the client.
Consider a hypothetical free user with three active runs on one accepted HWID. They have used three session slots but only one device binding. Trying a different HWID can reach the device limit even though two session slots remain.
This distinction matters when planning multiple script runs. Count the devices that will identify themselves to the service separately from the runs you intend to keep active. More session capacity does not increase the number of permitted HWIDs.
Why a recently closed run can still occupy a slot
Sessions record their latest accepted activity. The application uses a 45-minute stale window and filters stale entries when allocating a new session. A local window disappearing is therefore not, by itself, proof that its server record was immediately removed.
If a session-limit message appears, close runs you no longer need and avoid launching repeated replacements while investigating. When asking support to inspect an unexpected count, include when the earlier runs ended. That timing helps distinguish a recent abandoned session from another issue.
Follow the error that was actually returned
An HWID-limit error concerns device bindings. A session-limit error concerns available run capacity. An expired, revoked, or invalid-key error means the credential did not pass validation. Treating all three as a request for another claim skips the useful distinction.
Use the key troubleshooting guide if you need a diagnostic sequence. Keep the error text intact while removing the credential itself from anything you share.
Follow an accepted run from credential to session
The application first needs a valid stored key. It then checks the device identifier and session capacity before recording an accepted run. These checks occur within one access attempt, but each asks a different question and can produce a different rejection.
A key that has passed its expiry cannot authorize a new session simply because the device was accepted earlier. Likewise, a valid key does not guarantee room for another HWID. Previous success is useful context, but current state determines whether the next allocation is allowed.
When the request succeeds, the server records a session associated with the key and tracks its activity. The session has its own identity for later checks. Treating it as just another copy of the key misses why a running session can end separately from the act of generating access.
Compare two capacity situations
Consider a hypothetical free key with one bound HWID and two active sessions. Another run using that accepted identifier may fit within the session allowance. A request presenting a different identifier can instead hit the HWID limit, even though the count of active runs remains below five.
Now consider the same key with five active sessions on its one device. The HWID is already recognized, but another run can hit the session limit. Switching to a new claim while the existing key is valid does not turn those runs into a separate pool of capacity.
These examples show why a report should include the error category and relevant counts rather than only the tier. "Free access" alone does not tell support whether you are investigating device association, active runs, or an invalid credential.
Understand how stale activity affects the next request
The application treats sessions outside its stale window differently from recently active sessions. Allocation filters stale entries before checking room for a new run. A session that was abandoned moments ago may therefore still occupy capacity until the server has enough evidence that it is no longer active.
Do not assume that repeatedly launching replacements will force cleanup to happen sooner. It can add more attempts and messages without changing the time since the earlier session's last accepted activity. Record when the run ended and what the next request reports.
If the count remains unexpected beyond the relevant window, ask support to inspect the state. Keep the report specific: the time of the earlier run, whether it ended normally, and the message from the new attempt. Avoid claiming that every locally closed window must already be absent from the server.
Treat device identity as what the client submits
The server evaluates the HWID string supplied by the loader workflow. A physical computer, a browser profile, and the submitted identifier are not interchangeable concepts. Changes in the client environment can affect the identifier it presents.
If a device you previously used now receives an HWID-limit error, describe any relevant environment change instead of assuming the website bound your browser during key generation. Support may need to inspect the existing association and the new request context.
Do not edit identifiers as a workaround for capacity rules. It can obscure the original state and introduce another mismatch. The useful path is to understand why the current request differs and use legitimate account support when a binding requires attention.
Keep upgrades and current access state distinct
Premium provides larger configured allowances, but an upgrade does not explain every rejected request. A revoked key, expired access, or a connectivity failure still needs its own diagnosis. Compare the actual error with the state that a tier change is meant to affect.
When payment extends an active, non-revoked key in the current implementation, the key's tier and expiry are updated without automatically discarding its bindings. This preserves continuity, but it also means you should not think of the purchase as an unrelated clean slate for every access record.
Before asking for an administrative change, gather the facts needed to describe the issue. The account, tier, error category, and timing usually explain more than another copy of the credential. A clear distinction between key, device, and session makes that conversation shorter and more accurate.
Before launching again, count the device identifiers you expect to use and the runs that may still be active. Compare those counts with the free and premium allowances. This makes it easier to see whether the limit fits your current use or needs investigation.
If the message still conflicts with that picture, record the tier, the failed action, and the timing of recent runs for support. Those details explain the capacity question without exposing your key or repeatedly creating new claim links.