JSO AI quick start
Start with your own OpenAI or Claude key. JSO AI uses that key for live guidance, while provider billing stays in your provider account. If you only want to preview the experience, use the browser previews first; no key is required for those.
1. Save your AI provider key
Open AI key settings, choose OpenAI or Claude, paste the provider key, and use Save and test. The key is encrypted before storage and is never shown again after save.
- OpenAI or Claude bills your provider account. JSO does not become the AI provider when you use BYO keys.
- JSO still tracks usage. The usage page shows guided checks, review capacity, and AI key health for your account.
- Keep the key healthy. Test stored key every 30 days, and rotate or review provider access every 90 days or after team, provider, or billing-owner changes.
- You can remove the key later. Removing it returns the account to preview or managed-plan behavior.
2. Check your AI status
Open AI usage. The page shows whether a provider key is configured, whether the stored-key test is current, whether a managed plan is active, and how much AI usage is available for the month.
If managed AI checkout is disabled for the account, use BYO key setup. Contact support only when the account needs a manually activated managed AI plan. The order page should not be treated as a required step.
3. Try the previews
The preview pages are useful before touching a production project. They show the answer shape and the kind of guidance JSO AI gives.
4. Use AI during protection work
Most users should start in the dashboard or with the CLI, not by writing direct HTTP calls.
- Choosing settings: use the preset assistant to get a safer starting point for the online tool, desktop app, or API workflow.
- Before a release: run compatibility checks on important code paths and public entry points.
- After a problem: paste the runtime error into the explainer and review the suggested setting change.
5. Optional: add the CLI precheck
Release teams can add AI compatibility review before protection runs. This catches risky patterns before obfuscation quota is spent.
jso-protector --config jso.config.json --ai-precheck --ai-precheck-fail-on error
Use --ai-precheck-fail-on warning for stricter release gates, or never when you want advisory output only.
6. Optional: call the API directly
Use direct API calls when AI guidance needs to be part of internal tools or CI. Your normal JavaScript Obfuscator API key identifies the account; the saved provider key pays OpenAI or Claude for live model calls.
curl -fsS -X POST https://javascriptobfuscator.com/v1/ai/preset-suggest.ashx \
-H "Content-Type: application/json" \
-d "{
\"APIKey\": \"$JSO_API_KEY\",
\"APIPwd\": \"$JSO_API_PASSWORD\",
\"description\": \"React SaaS frontend, balanced performance, lock to example.com\"
}"
For full request and response details, use the JSO AI API reference. For language examples, use AI client examples.
Limits and billing
JSO AI uses capped monthly limits. When a limit is reached, the request pauses and the dashboard points to the next setup or upgrade path. BYO-key calls still count against JSO AI usage limits, but AI provider charges stay with your OpenAI or Claude account.
Managed JSO AI plans are separate from the core obfuscation plans and appear on the pricing page. Managed checkout is available only when billing is enabled for the account.
Frequently asked questions
Do we need our own provider key to use the AI features?
For live guidance, yes. The feature is built around bringing your own key from a supported provider, and provider billing stays in your own provider account rather than passing through this service. The browser previews are the exception and need no key at all, which makes them the right place to start if you want to see what the experience does before deciding whether to configure anything.
Why is a bring-your-own-key arrangement the default?
Because it keeps two things separate that are awkward to combine: your relationship with the model provider, and your relationship with this service. You keep direct visibility of what is being spent and direct control of the key, including revoking it. It also means the provider's terms about your data apply between you and them, which is a materially simpler position to describe when someone asks where prompts go.
What can we try without configuring anything?
The browser previews. They demonstrate the shape of the assistance without a key, which is enough to decide whether it is worth setting up for your workflow. Start there, confirm the behaviour is useful for the kind of build you run, and configure a key only once you have decided it is.
Where should the key be stored for a build server?
In whatever your continuous integration system provides for secrets, never in the repository or in a configuration file that is committed alongside it. Treat it exactly as you would any other provider credential with billable privilege: scoped as narrowly as the provider allows, rotated on a schedule, and revocable without a code change. A key that ends up in a build log is a key you have to rotate.
Does any of this send our source code somewhere?
That depends on which feature you use, and it is the right question to ask before enabling anything. Read the description of the specific capability before turning it on, and if your policy is that source must not leave your environment, treat that policy as the constraint that decides which features are available to you rather than something to work around. The account status view tells you what is enabled for your account.
Can we use these features from the API or command line?
Yes, once an account has been set up they are reachable outside the dashboard, which is what makes them usable in an automated pipeline rather than only interactively. Confirm the account status first, because a feature that appears absent from the command line is more often an account state issue than a client one.