Key facts
| Tools shape | OpenAI-compatible tools array on /v1/chat/completions with tool_calls responses (live) |
| Tenancy | One project and scoped key set per client; keys are project-scoped and rotatable |
| Tool reuse | Define tool schemas once in a registry and reuse them across client workspaces |
| Cost model | Flat self-serve plans with unlimited fair-use usage; no per-token charges |
| Observability | Token usage returns in every response for reporting even though it does not drive billing |
| White-label | Run AI under your own brand and resell access to clients |
| Residency | Pin each client workspace to the region their contract requires |
| Roadmap | Assistants and responses endpoints are coming soon; the chat completions tool loop is live |
TL;DR
- Give each client its own project, keys and retrieval collections.
- Reuse one tool registry so schemas stay consistent across clients.
- Route routine tickets to free models and escalate hard ones to stronger tiers.
- Report per-client token telemetry even though billing is flat-rate.
- Deliver under your own brand without operating inference infrastructure.
How it works, step by step
- Standardise a small tool set first — ticket lookup, device inventory, license count, backup status — with strict schemas.
- Create one Plugsky project per client and issue scoped keys that only reach that client's data.
- Build the loop once and parameterise it per client rather than forking code.
- Route triage and extraction to plugsky-micro or plugsky-lite, and escalate complex diagnostics to stronger tiers.
- Set retention and PII handling per client contract, and pin each workspace to the required region.
- Expose per-client usage and routing decisions in your portal so clients see the value in their own terms.
Try it yourself
Open the tool registry builder →
One tenant structure per client
Multi-tenant AI fails when client data, limits and logs share the same bucket. In Plugsky, projects and scoped keys give you the separation boundary: a key can be scoped to chat and embeddings writes for one project, rotated without downtime, and revoked the day a contract ends.
Pair each project with its own retrieval collection so a client assistant answers from that client's runbooks and asset data. Onboarding a new client then becomes a repeatable checklist — create project, issue keys, import documents, attach the shared tool registry — not a new deployment.
Protecting margin with flat pricing
Per-token billing is the enemy of managed-service margin, because a runaway agent loop turns into an invoice you cannot re-bill. Plugsky self-serve plans are flat monthly with unlimited fair-use usage; the only limit is the per-minute request rate for your tier, and token counts still return in each response for observability.
Keep the cost side healthy with model tiering: plugsky-micro and plugsky-lite handle classification, extraction and routine triage, while plugsky-pro and frontier tiers take diagnostics that need real reasoning. Routing rules can send an entire client's traffic down the cheap path by default.
White-label delivery and client audit
Clients buy outcomes, not inference. Run the assistant under your brand, expose your own portal, and let Plugsky stay behind the API. Each client workspace can be pinned to the region their contract requires, whether that is the GCC, EU, US or APAC.
- Audit: key lifecycle events and inference metadata are logged and exportable to your SIEM for incident reviews.
- Approvals: keep actions that change client systems — disabling an account, closing a ticket — behind your own approval workflow.
- Roadmap: assistants-style stateful endpoints are coming soon; today's tool loop on chat completions covers most managed workflows.
Honest comparison
| Concern | Plugsky | Per-seat AI reseller | Self-hosted stack |
|---|---|---|---|
| Tenancy | Project-scoped keys per client | Shared tenant with labels | You build isolation |
| Billing model | Flat monthly, unlimited fair use | Per-seat or per-token | GPU and ops cost |
| Tool reuse | Shared registry across clients | Vendor-specific | Internal framework |
| Branding | White-label delivery | Vendor-branded | Fully yours |
| Ops burden | No inference infrastructure to run | None, but limited control | You run everything |
Frequently asked questions
Can each client have a separate region?
Yes. Pin each client workspace to the region their contract requires, and use VPC, on-prem or air-gapped deployment for clients that cannot use multi-tenant cloud.
How do we bill clients when usage is unlimited?
Sell outcomes or seats on top of your flat Plugsky plan. Because self-serve plans carry no per-token charges, tool-heavy workflows do not create variable cost you must pass through.
Can we reuse the same tools for every client?
Yes. Keep one tool registry with versioned schemas and bind it per client project, so improvements ship to every tenant at once.
Is client data isolated from other clients?
Projects and scoped keys keep retrieval collections, logs and limits separate, and keys are rotatable without downtime.
Do we need to run GPUs ourselves?
No. Plugsky handles inference on its cloud; VPC and on-prem options exist only where a client contract requires in-environment processing.
What can the assistant change on client systems?
Whatever you allow in your own tool implementations. Keep actions that modify client systems behind your approval workflow and log them.
How fast can we onboard a new client?
Create a project, issue scoped keys, import their runbooks into a retrieval collection and attach the shared tool registry — an afternoon, not a deployment project.