Choose your first product

Choose an Ethen surface by the decision you need to make, not by which page looks most familiar. This guide helps first-time users separate research, catalog inspection, configured model access, agent or workflow concepts, media-oriented products, and local paths. Only the console, Model Library, Model Intelligence model routes, and the approved AI Gateway routes are verified for direct Batch 01 links; other products may be recognized by the shell without having their complete implementation or availability established here.

Decision guide

Use the first surface that can answer the current question. Do not move into execution merely because research or catalog evidence looks favorable.

Choose a starting product by the decision you need to make. Use Model Library for catalog and runtime status, Model Intelligence for normalized research, AI Gateway for configured access, and the console for general model work.

Do not choose by product name alone. Start by asking whether you need to discover, compare, access, compose, or execute. Then check the current maturity and setup state of the selected surface.

Use Gateway when

Start with AI Gateway when your main objective is to access a model through a provider-aware path and you are prepared to check configuration. The current Gateway page identifies the Managed Gateway as beta and links to its playground, documentation, and API-key area.

Gateway is appropriate when you need to answer questions such as:

• Is there a configured access path for the selected model?
• Does the environment have the required credential?
• Is the requested modality supported?
• Can the task be tested in the current playground or documented interface?

Use Model Library before Gateway when model status is unclear. A catalog-only entry is not execution-ready; provider-configured still requires a task-specific check; missing-key identifies a credential gap; unsupported-modality means the selected route does not match the requested type; runnable is the strongest current status but should still be tested with the intended request.

Use AI Gateway when the task requires a managed proxy layer for provider access, model catalog visibility, API keys, playground requests, usage, logs, or provider status.

The current page labels AI Gateway as Managed Gateway Beta. Confirm provider configuration and model status before treating a catalog entry as executable. Full authentication, routing, fallback, and error contracts belong in the Gateway documentation batch.

Use Agents or Workflows when

Choose an agent or workflow path when the work contains multiple stages, tools, approvals, or evidence that must remain reviewable. Batch 01 supports only the platform-level concepts: an agent can be discussed as a bounded actor, a workflow as a structured sequence, and sensitive work as moving through Read → Propose → Approve → Execute.

This is not enough evidence to claim a specific runtime, connector, tool contract, automatic trigger, or external action. Begin by defining the stages and the approval boundary. Move to the later Agents and Workflows documentation before implementing detailed behavior.

A good early outcome is a reviewable plan that identifies required context, proposed actions, approval points, expected artifacts, and unresolved integrations. That outcome is useful even when live execution is not yet verified.

Choose an agent or workflow path when work needs named steps, reviewable proposals, tools, approvals, or repeated execution patterns.

The inspected Batch 01 sources do not verify detailed agent runtime contracts or live automation guarantees. Treat these surfaces as later reading destinations and preserve the Read → Propose → Approve → Execute boundary for state-changing work.

Use Studio or Voice when

Use a media-oriented product when the intended output is image, video, speech, transcription, or another supported creative modality rather than general text or code. The gateway catalog recognizes capability families including image, video, realtime, speech, and transcription, but capability vocabulary does not prove that Studio or Voice supports every listed model.

This Batch 01 route map does not approve direct Studio or Voice links. Treat these as product-selection concepts and defer exact controls, input formats, editing features, and availability to their dedicated documentation batch.

When exploring a media task, first verify the required modality in Model Library, then check the owning product’s current state. Do not assume that a multimodal model supports every combination of text, image, audio, or video input and output.

Studio and Voice are recognized product categories for media-oriented or spoken interaction work.

Their detailed controls, supported formats, provider requirements, and release states are outside this batch. Do not infer capability from route recognition. Choose them only after checking their product-specific documentation and visible status.

Use Local or Desktop when

A local or desktop path is relevant when control of the runtime location is central to the task. Approved positioning includes local lanes where supported, but this batch does not establish universal local-model support, hardware requirements, installation steps, persistence behavior, or privacy guarantees.

Begin with a requirements note rather than a hardware assumption. Identify the desired model type, modality, context needs, expected workload, and the reason a local lane is being considered. Then use the later Local and Desktop documentation to verify runtime and device constraints.

Local should not be treated as a synonym for private, free, offline, or operationally simple. Each of those claims requires its own evidence.

A local or desktop lane is relevant when the work requires a local model path or an installed application surface and the environment supports it.

Approved positioning allows local lanes where supported; it does not establish universal hardware compatibility, offline operation, or privacy guarantees. Detailed setup belongs in the Local and Desktop batch.

Recommended starting paths

For a model-research task, begin in Model Intelligence, check the source and quality information, then confirm catalog status in Model Library.

For a first hosted-model test, start in Model Library, select a capability-compatible record, verify status and provider requirements, then move to the Gateway playground or console if the route is supported.

For a controlled workflow idea, write the read, propose, approve, and execute stages before selecting tools. Keep the first deliverable as a proposal or simulation until the later product documentation verifies live behavior.

For a media or local requirement, use catalog capability families to narrow the need, but postpone product-specific setup until the relevant batch confirms routes and controls.

The right first product is the one that can answer the next verifiable question with the least unsupported assumption.

For model discovery, begin with Model Library and continue to a detail page. For evidence-based comparison, begin with Model Intelligence. For a configured request path, begin with AI Gateway. For general task composition, begin with the console.

Move from research to use deliberately: inspect status, compare evidence, confirm provider configuration, run a small test, and review the result before increasing scope.