Project setup
Establish the project, credentials, and spending boundary before making model calls.
A project owns its API keys, subjects, adapter versions, requests, credit ledger, and monthly spending limit. Start by deciding which application should share those resources. A separate project is appropriate when you need a separate balance or a separate set of credentials.
Enter the console
Open the console, enter your email, and verify the code sent by Clerk. The same flow creates a new account or signs you into an existing one. No password or separate signup form is needed.
Your verified account owns its projects. Signing out ends the browser session without deleting project state. Paid execution and payment collection have separate launch gates; see availability.
Name the project
Enter a short, recognizable name, such as Support assistant. The name can contain up to 80 characters and can be changed later. It is a label, not a public API identifier. Copy the immutable project ID from Settings when you need to correlate operational records.
New projects start with zero credits and a $100 monthly spending limit. The limit is a ceiling, not a balance or an automatic purchase. Accounts can create up to ten projects. Team invitations and role administration are not part of the current console.
Complete the setup path
The Overview workspace leads through three tasks:
- Create an API key. Name it after the application that will use it. Choose only the scopes needed for its work, and save the secret immediately.
- Add credits. Live purchases start at $10. The current billing preview demonstrates the flow without taking payment or creating spendable credits.
- Make an API call. Once execution is enabled and the project is funded, follow the quickstart and inspect the resulting job.
These steps represent real state. Visiting a page does not complete a model request, and returning from checkout does not itself prove a payment succeeded.
Choose the first subject
The project is your access and spending boundary. The subject is the knowledge boundary inside it. Use a stable ID for an assistant, customer, or knowledge domain, for example support-policy or customer_42. A new subject begins with clean base weights.
You do not create subjects in a separate form. The first admitted inference or internalization request establishes the identity. For multi-customer applications, set tenant_id from your authenticated customer mapping and use subject_id for the memory name inside that tenant. Reusing the same pair within the same project returns to its existing knowledge state; changing the ID starts a different subject.
Verify readiness
Before live use, confirm that your credentials are server-side, the key has the intended inference or learning access, the project has enough available balance, and the spending limit permits the reservation. Then submit one small known passage and evaluate its result. See Authentication, Spending limits, and Make your first call.