A personal developer instance is yours, and on it you are the admin. So the whole setup is yours to do in an afternoon: no change request, no CAB, nobody to convince yet. Register the instance at kaddiya.com/start, and the first stretch of model spend is on us. Here is the path, what the trial covers, and the one thing you will never buy from us.
You register your developer instance at kaddiya.com/start and sign in on it as yourself. The free plan's model turns run on a trial key we hold, named as such on the usage line under every answer, up to a fixed allowance: a set number of turns a month and a set amount of model spend over the life of the org, both shown on your org's admin page as they are used. When it is spent, you add your own key under Admin → Model and keep going. For that stretch, and only that stretch, we hold a model credential and Anthropic is our subprocessor for the traffic. Everything on this page is this path.
You run the console locally against your developer instance with an Anthropic key of your own. The model bill is between you and Anthropic, at their published rates, and it is small: the figure sits under every answer, in cents. Nothing is hosted and nothing is shared. The four lines it takes are at the foot of this page.
ServiceNow issues one free to anyone with a Developer Program account, at developer.servicenow.com. It arrives with demo data already loaded: incidents, a service catalog, a knowledge base, users and groups. That is enough to ask real questions of, which is the point of starting here rather than with an empty instance.
Two habits worth knowing. An idle instance hibernates; wake it from the developer site before you sign in, or the sign-in will stall on a sleeping host. And an instance nobody has woken for ten days is reclaimed and reset, taking the OAuth record from step 03 with it, so you would redo that step and verify again from your org's admin page. ServiceNow describes both in their own words.
There is no Kaddiya account to create. Your org is your ServiceNow instance: you register an instance you administer, prove it by signing in on it as an admin, and everyone who can sign in to that instance can ask to join. The setup page asks for one thing first, a name for the org, and then shows you the redirect URL the next step needs, exactly as it has to be entered.
The setup page is the only place you type anything into Kaddiya. Your instance credentials never come here; the sign-in in step 03 happens on your instance's own login page.
This is the step an admin does for you on a real instance. On a developer instance the admin is you. In the instance: All → System OAuth → Application Registry → New → Create an OAuth API endpoint for external clients. Name it, set the Redirect URL to exactly the value the setup page shows you (https://kaddiya.com/auth/callback), leave public client unchecked, and save. The instance generates the client ID and the client secret; copy both back into the setup page. ServiceNow's documentation for the grant covers the form field by field.
Then Save and verify as an admin. You are sent to your instance's own login page, not to a form of ours, and come back with a token scoped to you. With that token, and only that token, Kaddiya reads the registry record back. System OAuth records are admin-only on the instance, so one read proves three things at once: that you administer it, that you control this record, and that its redirect URL is the one above. The instance is bound by its instance_id property, not its hostname, and you become the org's owner.
Your org starts on the free plan. Its model turns run on a trial key we hold, and the usage line under every answer says so beside the cost. The allowance has two ceilings: a number of turns a month, and an amount of model spend over the life of the org. Both, with how much of each you have used, are on your org's admin page; the exact figures live there, not here, so this page can never be out of date about them. The free plan also covers one instance and a few seats.
When the allowance is spent, add your own Anthropic key or gateway under Admin → Model and carry on, on the same plan, with the model bill between you and your provider. On a developer instance you are the admin, so the agent sees everything. That is the one way this afternoon is unlike production, where it sees exactly what the signed-in person can see and nothing more. Three questions the demo data can answer, if you want somewhere to start: which open incidents have no assignment group; draft a reply to the requester on the oldest one; and what a new starter can request from the catalog. Every query it runs is on screen as it runs, and every draft waits for your click.
Most trials are a smaller product with a timer on it. This one is the same build a paying organisation runs, pointed at an instance you can afford to be wrong on. The limits below are the honest ones.
The console is one Node service. Create the same OAuth record as step 03, except that the redirect URL is the console on your own machine, http://localhost:3000/auth/callback, exactly. This is the one situation where plain http is fine: the request never leaves your machine. Put the instance host, the client ID and secret, and your own Anthropic key in its .env, install, and start it. Nothing here phones home, and nothing runs after you close it.
Pick the model with the same file. The cheapest one is fine for a first afternoon and the cost of each turn is printed under the answer, so you will know before the day is out whether the number surprises you. The sign-in button sends you to your instance's own login page, the same as the hosted path.