Projects
Projects are the main isolation boundary in Olyx. Use them to separate environments, applications, teams, or model-routing policies.
Every project owns its own:
- API keys
- model registry entries
- routing settings
- trace history
- replay jobs
- governance evidence
- usage and spend views
When To Create A Project
Create a separate project whenever two workloads should not share the same policy, keys, or trace history.
| Pattern | Recommended project shape |
|---|---|
| Staging and production | One project per environment |
| Multiple products | One project per product or service |
| Customer-isolated workloads | One project per customer segment or deployment |
| Private deployment evaluation | One project for the private deployment path and one for cloud comparison |
Create A Project
In the dashboard, open Projects and choose New Project.
Use a name that will still make sense in traces and usage reports later.
Good names:
support-prod
claims-worker-staging
legal-review-vpc
Avoid names that encode secrets, customer PII, or temporary incident details.
Project Settings
Project settings control the behavior that downstream requests inherit. The exact dashboard fields can evolve during closed beta, but the same operating principle applies: configure the project first, then create scoped keys and route traffic through that project.
| Setting area | What it affects |
|---|---|
| Status | Whether the project is active, inactive, or archived |
| Routing | Which model path runs for simple, medium, complex, and secure work |
| Guardrails | PII, injection, and secret handling behavior |
| Trace policy | What is captured for observability and replay |
| Spend controls | Monthly budget and operational limits |
Project-Scoped Workflow
Use this order for a clean rollout:
- Create the project.
- Register the models the project is allowed to use.
- Configure routing and guardrails.
- Create one API key per service or environment.
- Send traffic through the Olyx base URL.
- Review traces, replays, usage, and governance output.
API Key Boundary
An API key should belong to the project that owns the workload. Do not reuse one key across unrelated services just because they share a provider.
export OLYX_API_KEY=ak_...
export OLYX_BASE_URL=https://app.olyxai.io
olyx inspect
olyx config
olyx config returns the project policy attached to that key.
What To Check After Setup
After creating a project, confirm:
- the project appears in the project switcher
- at least one model is registered for the project
- the routing page shows the expected model identifiers
- the keys page has a project-scoped key for the workload
- a first trace appears after a request runs
- governance entries are created for completed decisions
Next Steps
- Use API Keys to create scoped credentials.
- Use Model Registry to register provider and private models.
- Use Routing to control model selection.
- Use Traces and Replays to inspect execution.