Try a model in the playground

Nothing to install and nothing to create: the playground is a web page. You pick a model that is already deployed, write the prompt, read the response. It is the quickest way to find out whether a model can do what you hope.

Five minutes

1. Open the labs Foundry project. If the portal asks you to sign in, use your Qim info account.

2. Check the active project at the top of the page: proj-azurefoundry-lab-szn, the shared project. The selector lets you switch to one of your own projects if you already have one.

3. Open the playground. It is the portal’s testing area, reachable from the project home page as well as from the left-hand pane.

4. Pick a deployment from the model list. What you select is an existing deployment, not a catalog model: if the list is empty, no model is deployed in this project, which is what create my project is for.

5. Write a system prompt before touching any other setting: it sets the role, the tone and the limits. Then ask your question. The same question with no system prompt and with two different system prompts will teach you more than any temperature setting.

6. Grab the code for the call. The playground shows the equivalent of your session in Python, C#, TypeScript or cURL, with the endpoint and deployment name already filled in. That is the reference to copy, rather than an example found elsewhere.

Portal labels move around from one version to the next, and the same screen has a different name in French and in English. The path itself doesn’t change: a project, a model deployment, a playground to try it. Look for those three things, not for the exact words on a screenshot.

Compare rather than tune

A small, fast model and a large, expensive one can’t be told apart on gut feeling: ask them the same question, with the same system prompt, and look at the two responses side by side. The playground shows the number of tokens used in each exchange, which puts numbers on the comparison.

Three settings cover most tests.

The setting	What it changes
The system prompt	The model’s role and constraints. By far the most powerful lever.
The temperature	How much responses vary. Low for extraction or classification, high for writing.
The maximum number of tokens	The length of the response, and therefore its cost and latency. A low limit cuts the response off mid-sentence, which looks like a bug but isn’t.

The playground keeps a record

Conversations and their attachments are stored in the Foundry resource, not in your browser: a colleague opening the shared project can find what you tried there. Delete what is no longer needed, and don’t assume a test session is private.

What goes wrong the first time

The symptom	What is happening
The model list is empty	No deployment in the displayed project. Check the active project, or deploy the model you want: create my project.
The portal shows another tenant, or no project	Your browser is signed in with another Microsoft account. Sign out of the portal, or open it in a private window with your Qim info account.
“You don’t have permission”	Authentication succeeded; it is authorization that refuses. Write to lab@qiminfo.ch stating the project you are trying to open.
429 or “too many requests”	The tokens-per-minute quota is shared among all users of the resource. Wait, lower the maximum number of tokens, or space out your calls.
The response is blocked or emptied	The content filters caught the prompt or the response. Rephrase: on a legitimate test, it is almost always an ambiguous wording.
The model you want is missing from the catalog	Not every model exists in every region, and Switzerland is one of the narrowest. The catalog shows availability by region.
The response stops mid-sentence	The maximum number of tokens was reached. Raise it, or ask for a shorter response.

Next

The playground is enough to put a prompt to the test. As soon as you need to call the model from code, choose its deployment type or work without getting in your colleagues’ way: create my project and call the API.