Use cases you can evaluate

Choose one repeatable task and collect a small set of representative inputs, including ambiguous requests and missing information. Define who reviews the output and what makes an answer acceptable.

Use these scenarios to define your own acceptance criteria. Read how it works, check the FAQ and review data handling before introducing sensitive material. Check service status before running a workload.

AI access requires sign-in, one confirmed top-up of at least USD 100, an authorized API key and enough available credit for the request. Each later top-up also has a USD 100 minimum; smaller remaining balances stay usable when they cover the request. Credit requires transaction verification. Check service status for model availability before sending traffic.

For a support team or internal help desk, provide approved facts, the recent conversation and a clear writing style; the useful result is a reviewable reply.

If a workshop lists collection hours from Tuesday to Friday and a customer asks about Sunday, the reply should explain that Sunday is not among the supplied hours and recommend confirming availability. It should not promise an appointment.

Quality check: verify each factual claim, preserve relevant conversation context and flag missing information. Keep sending or booking behind your own review step. Start with the chatbot recipe and Open WebUI guide, then validate the selected deployment before use.

For an inventory helper, supply the relevant code, task and permitted tool definitions. Ask for the stock level of SKU keyboard, and check how the application handles a missing SKU.

Expected behavior: propose an allowed get_stock call with validated arguments, use its returned data in the answer and explain the missing-input check. Your application decides whether a call runs; require permission checks and explicit review before file edits, commands or external actions.

Quality check: reject unknown tools, unexpected arguments and unauthorized actions, and test missing or malformed inputs. Follow the bounded tool recipe and Cline configuration; verify deployment capabilities before enabling tools.

For an internal knowledge assistant, your application supplies the document collection and retriever, then passes selected excerpts with stable source IDs to the model. WeightsAPI does not currently provide embeddings; the RAG recipe uses a small lexical ranking example.

If source S1 requires manager approval and source S2 says urgent requests follow the same process, an answer about urgent access should cite both sources and preserve the approval requirement. It should not invent an approval deadline.

Quality check: confirm the relevant excerpts were retrieved, each citation supports its claim, and missing evidence produces an explicit limitation. Enforce document permissions in your retrieval layer and test questions the collection cannot answer.

Use an available deployment to compare candidate models with the same inputs and comparable settings. Score factual accuracy, instruction following, citations and valid tool arguments; record input and output tokens alongside time to first token and completion time.

Use the current pricing table with actual usage, including repeated context and retries. Set key budgets, bound retries and retain a rollback path. Move traffic only after your own acceptance criteria pass.