Rivya AI Docs

Rivya Public Pages vs Signed-In Workflows

Understand which Rivya pages are public, which require sign-in, and how prompts, models, uploads, credits, and history move into Studio.

Last reviewed on 2026/04/28

This guide helps avoid one common misunderstanding: public pages are the start of the workflow, not the whole saved workspace.

The simplest way to understand Rivya is this:

  • use the public pages to choose the right path
  • use the signed-in product to actually run and continue the work

Once that boundary is clear, model pages, prompt pages, tool pages, uploads, credits, and Studio handoffs become much easier to understand.

What The Public Pages Are For

The public pages help people answer questions like:

  • what kind of job am I really doing
  • which path fits this task
  • which model or tool is worth trying first
  • is Rivya even the right product for this workflow

That is why the public paths include things like:

Those pages are not decorative. They help users compare options and choose the first path before sign-in.

What The Signed-In Product Is For

The signed-in product is where the work stops being a possibility and becomes saved product state.

That is where Rivya carries:

  • real execution
  • uploads
  • wallet-backed usage
  • saved chat sessions
  • generation history
  • notifications
  • billing and account settings

The main paths here are:

  • /dashboard
  • /studio/*
  • /history/*
  • /notifications
  • /settings/*
  • /payment

If the question is no longer “what should I try?” but “how do I keep this moving?”, this is the layer that matters.

Where The Login Boundary Really Sits

The most important thing to say plainly is this:

public does not mean fully anonymous execution.

Right now:

  • public pages can help you browse and compare
  • public start pages can preserve task intent and quick-use context
  • prompt and showcase pages can feed you into the right next step

But actual execution, uploads, and saved continuity still depend on sign-in.

So the accurate description of Rivya is:

  • public for discovery and guided starts

not:

  • fully anonymous for full workflow execution

What A Normal Handoff Looks Like

The handoff between public and authenticated layers is not a fallback. In most cases, it is the intended path.

Common examples include:

  • landing on /ai-models/gpt-image-1-5, then signing in before the first real run
  • browsing a prompt page while signed out, then using that prompt through the right start page
  • comparing models publicly, then moving into /studio/* once saved continuity matters
  • starting from a tool page, then continuing the work inside saved chat

That is why callback and returnTo behavior matter. The product is trying to carry the user’s original intent forward instead of making them start over.

Prompt, Showcase, And Public Start Pages Work Together

Prompt pages, showcase pages, and start pages are different surfaces, but they solve the same larger problem:

  • helping you start from something more informed than a blank screen

Prompt pages work best when you want a reusable template.

Showcase pages work best when you want examples or inspiration.

Public start pages work best when the path, model, or task shape is already fairly clear and the next step should feel immediate.

If the output type is already clear, start from Chat, Image, Video, or Audio. If the main question is model fit or a live tool, start from AI Models or Tools instead.

Taken together, these pages are what make the public experience feel like a real starting layer instead of a marketing shell.

The Simplest Rule

Use the public pages when the main question is:

what is the right path?

Use the signed-in side when the main question is:

now that I know the path, how do I actually run and continue the work?

That is still the simplest way to understand Rivya.

Handoff Checklist

When a public start should become real saved work, check:

  • Keep public pages for discovery, first framing, and low-friction starts.
  • Move into Studio when the task needs saved context, uploads, history, billing, or follow-up.
  • Carry the model, prompt, tool, reference intent, and return context across the sign-in boundary.
  • Do not promise anonymous long-running execution from public pages.
  • Check credits and account state before turning a public draft into a billable run.

Recheck The Handoff When

Recheck when uploads, saved history, notifications, or paid generation are expected before sign-in. That is where public browsing ends and authenticated product behavior starts.

Table of Contents