Quickstart

This quickstart takes you from a verified Ethen entry point to a reviewable first model task without inventing account, workspace, or role controls. Use it when you want to learn the product flow before committing to a specific provider or automation path. Exact onboarding labels are not established by the supplied sources, and the surfaces involved can have different maturity states, so each step includes a checkpoint and an expected result.

Prerequisites

Before beginning, confirm that you can reach the Ethen environment and at least one approved starting route:

• /console for the shared workspace entry point
• /model-library for the read-only model catalog and provider overlay
• /model-intelligence/models for normalized research profiles
• /ai-gateway for the Gateway overview

For a task that may call a hosted model, you may also need a provider configuration or key. The Gateway exposes an approved API-key route, but this batch does not verify the exact key-creation procedure, available providers, account requirements, or regional access. Do not paste credentials into a prompt or documentation example.

Choose a small, reversible task. A good first task asks for analysis, comparison, drafting, or explanation and does not require an external state change. Avoid using the first run to test sensitive data, production systems, or an unverified tool integration.

Expected result: you know which surface you can access, whether model execution is required, and which facts still need verification before a run.

This quickstart assumes you can reach the verified Ethen console and at least one model-related surface. It does not assume that self-service signup, workspace creation, provider credentials, or every model lane is already available.

Before starting, confirm that you are authorized to use the environment, know whether a provider key is required, and understand that the UI may label a surface live, preview, mock, or setup-required. Keep sensitive data out of a first test unless its handling has been separately approved.

Before leaving the “Prerequisites” section, confirm the visible outcome. Record the current route, selected model status, and any setup message instead of assuming hidden configuration succeeded.

• Confirm the current surface and visible status for Prerequisites.
• Use only an approved route and an authorized context for this Quickstart step.
• Preserve the exact model or provider identifier when Prerequisites involves one.
• Stop when the expected Prerequisites result or permission boundary is unclear.

Create a workspace

The repository recognizes workspace-oriented concepts and routes, but the source pack does not establish the exact sequence for account creation, workspace creation, invitations, or roles. Use the currently visible onboarding controls in your environment rather than relying on a label copied from this guide.

If a workspace already exists, select the one intended for the test. Keep the first task isolated from unrelated projects or sensitive context. Add only the prompt, file, artifact, decision, evidence, or review note needed for the exercise when the chosen surface supports those context types.

If no workspace control is visible, do not infer that a hidden button, command, or direct URL exists. You can still learn the catalog and research surfaces without completing workspace setup:

1. Open Model Library and inspect a model record.
2. Open Model Intelligence and examine a normalized profile.
3. Return to the console or Gateway only after the environment provides a supported path.

Expected result: either a visible workspace context is selected, or you have deliberately limited the quickstart to read-only research while onboarding remains unresolved.

The supplied current product surfaces do not verify an exact account or workspace creation workflow. Do not rely on undocumented button names or role behavior.

Use an existing authorized workspace or console context when one is already provisioned. If no workspace is available, ask the environment administrator for the current onboarding path. Record the missing procedure rather than improvising a route, role, invitation, or account step.

Keep the first workspace exercise narrow and reversible. A small test makes product-state problems easier to separate from model-quality problems and reduces the chance of introducing sensitive context before the environment is understood.

Choose a model

Start in Model Library when you need current catalog and runtime-oriented status. The explorer can search text, select a capability family, filter by provider or status, sort results, show selected columns, and inspect a chosen model. Relevant status values include catalog-only, provider-configured, runnable, unsupported-modality, and missing-key.

Use these checks in order:

1. Capability match. Confirm that the record’s capability family fits the task. Verified families include text, code, image, video, embedding, rerank, realtime, speech, transcription, reasoning, long-context, and unknown.
2. Status. Prefer a record that the current environment marks runnable for an execution test. A provider-configured record still requires confirmation that the intended request can run. catalog-only means the record exists without execution readiness.
3. Provider and credentials. Check the provider shown by the catalog and whether the current environment reports a missing key.
4. Limits and evidence. Review context window, maximum output, pricing, latency, throughput, source files, confidence, or notes when present. Missing values are unknown, not zero.
5. Research context. Open Model Intelligence when you need benchmarks, comparisons, charts, specifications, FAQs, quality flags, or provider context before choosing.

Do not select a model solely because it ranks highly in one chart. The quickstart is about a supported first run, not declaring a universal winner.

Expected result: you have a candidate whose capability and current status fit the task, plus a short list of unknowns that could still affect execution.

Open Model Library to inspect models by capability family, provider, status, pricing presence, context presence, and other verified attributes. Select a record whose status and capability match the task.

Catalog-only records are research entries, not runnable models. Provider-configured and runnable are distinct statuses. Missing values such as pricing or context should be treated as unavailable rather than zero.

When the current model surface differs from this guide, follow the interface you can verify and record the discrepancy. A familiar label from another product is not evidence that the same control or route exists here.

• Confirm the current surface and visible status for Choose a model.
• Use only an approved route and an authorized context for this Quickstart step.
• Preserve the exact model or provider identifier when Choose a model involves one.
• Stop when the expected Choose a model result or permission boundary is unclear.

Run your first task

Use the console or the approved Gateway playground only when the selected model and environment support execution. The exact composer labels and run controls may differ, so follow the visible interface rather than expecting a specific button name.

A safe first task has four parts:

1. State the outcome. Explain what you want the model to produce.
2. Provide bounded context. Include only the material needed for that outcome.
3. Set review criteria. Name what a useful response should cover, such as accuracy, clarity, format, or traceable use of supplied context.
4. Keep the action read-only. Ask for a response or draft rather than an external change.

For example, you might ask the model to compare two supplied approaches, summarize a document you are permitted to use, explain code already provided in the workspace, or draft a plan for later review. The example should rely on your own context and should not introduce model-specific API syntax that the supplied sources do not verify.

Before submitting, recheck the selected model, provider, and visible status. If the product displays a route decision, evidence source, or warning, capture it as part of the review rather than dismissing it as interface noise.

Expected result: the surface accepts the request or clearly reports why it cannot proceed. A blocked run is still useful when the status identifies a missing key, unsupported modality, or configuration gap.

For a conservative first result, use the console composer or the approved AI Gateway playground route. Enter a small, non-sensitive task that has an easily reviewed outcome.

Before leaving the “Run your first task” section, confirm the visible outcome. Record the current route, selected model status, and any setup message instead of assuming hidden configuration succeeded.

Review the result

Review the output at three levels.

Content

Does the response address the requested outcome and use only the supplied context? Check for unsupported assumptions, missing constraints, or conclusions that should remain uncertain.

Execution truth

Identify what actually happened. A generated answer proves that a model response was returned through the selected surface. It does not prove that every listed provider is available, that a workflow executed, or that an external system changed.

Evidence

Look for the information the surface makes inspectable: selected model, provider, status, route decision, source evidence, request history, receipt, artifact, tool output, or verification note. Not every surface exposes every item. Record what is present and name what is absent.

If the result is poor, separate model quality from configuration failure. A weak answer calls for a prompt, context, or model comparison. A missing-key or unsupported-modality status calls for configuration or selection changes instead.

Expected result: you can explain the result, the route that produced it where visible, and any boundary that prevents a stronger conclusion.

Review the output as evidence-informed work rather than automatic truth. Confirm that the selected model, provider status, visible inputs, and result match what you expected.

Look for missing or contradictory information, verify important claims independently, and retain any visible request history, source evidence, or route details the surface provides. A successful quickstart proves that the current path produced a result; it does not prove every model or workflow is available.

Review the first response before expanding the task. Repeating a small, bounded test with one controlled change can show whether the issue comes from context, model selection, provider state, or the wording of the request.

• Confirm the current surface and visible status for Review the result.
• Use only an approved route and an authorized context for this Quickstart step.
• Preserve the exact model or provider identifier when Review the result involves one.
• Stop when the expected Review the result result or permission boundary is unclear.

Next steps

Once the first task is understood, choose the next path based on evidence:

• Refine selection with Choosing a model when quality, cost, latency, context, or risk requires a more deliberate tradeoff.
• Use Searching and filtering to reproduce a Model Library view through its URL-synchronized state.
• Read Model detail pages to understand the difference between gateway detail routes and normalized Model Intelligence profiles.
• Open Benchmarks and scores before relying on a composite metric or derived verdict.
• Review Providers and availability when execution depends on configuration, credentials, or modality support.

Do not scale the task, add sensitive context, or move into state-changing work until the current product provides the necessary approval and evidence controls.

After the first result, choose a deeper path: compare model evidence, inspect provider availability, learn model-selection tradeoffs, or study the platform control model.

Do not scale a first test into production traffic until credentials, costs, limits, data handling, and operational status have been reviewed in the appropriate product documentation.

Choose the next step from the evidence shown by the current surface. When the interface has changed, record the new route or status and avoid borrowing an unverified control from a different product.

Troubleshooting

When a problem remains unresolved, preserve the exact status, route, and visible evidence. Those details are more useful for support or later review than a guessed diagnosis.

Most first-use problems in this batch fall into four categories: no verified workspace, no configured provider, a model that is not runnable, or a mismatch between the task and selected capability.

Return to Model Library and inspect the status truth. If the provider is missing a key, use the approved API-key destination. If the surface is preview or setup-required, treat that state as the explanation rather than repeatedly retrying. Escalate onboarding and role questions to the environment administrator because the exact controls are not verified here.

Before leaving the “Troubleshooting” section, confirm the visible outcome. Record the current route, selected model status, and any setup message instead of assuming hidden configuration succeeded.

• Confirm the current surface and visible status for Troubleshooting.
• Use only an approved route and an authorized context for this Quickstart step.
• Preserve the exact model or provider identifier when Troubleshooting involves one.
• Stop when the expected Troubleshooting result or permission boundary is unclear.