The inference console is the operator surface for the ClutchCall inference fabric. It is a separate single-page app from the portal: its own sidebar, its own top bar, and its own route table. The sidebar footer labels it Inference portal · OpenAI-compatible · QUIC; the lockup in the top-left reads the brand name with an inference fabric sub-label. The most important thing to know before you look for a control that is not there: this console has no tenant switcher. The section below explains why.

​
Operator-global by default: what the top bar pills mean

The inference.* tRPC procedures are public / operator-scoped. There is no per-tenant inference data plane, so the shell has nothing to switch between and the tenant switcher from the design handoff was deliberately removed. The top bar renders the fabric’s single global identity instead, as two pills: The host pill is not decorative. Screens reuse the same value as the OpenAI-compatible base URL they show you, so the pill is the authoritative answer to “which host do my requests go to from this console’s point of view”. Practical consequence: numbers on Overview, Models, Providers, Analytics, Fleet & latency and Runtime are not scoped to whoever you are signed in as. They describe the fabric. Two operators signed in from different organisations see the same figures.

​
Which screens are tenant-scoped, and where the org comes from

Exactly one screen in this shell departs from the operator-global rule: Compute, under the Console group. Compute is per-tenant. It does not ask you to pick an organisation — it reads the org that you selected on the portal, and carries that selection over via the shared session. If no organisation is selected, Compute says so rather than showing you fabric-wide data or an empty table with no explanation. So when Compute tells you there is no organisation:
  1. Go back to the portal (account menu → Back to portal).
  2. Select the organisation there.
  3. Return to /compute.
Everything else in the sidebar ignores the org selection entirely.

​
Signing in: the portal SSO session and what the gate blocks

Access is a portal login. The console does not have its own credential form.
  • The portal login writes an SSO session; a cookie bridge hydrates that session inside the inference console, so opening the console after signing in on the portal just works.
  • A cold visitor is redirected to the portal login before the console paints.
  • The shell also runs its own session gate. While the session is being checked it renders an empty shell frame. With no session it renders a Sign in to open the inference console card — “This console is operator-only. Sign in on the portal — the session is shared with fabric” — with a single Go to portal action pointing at the portal’s /login.
The gate exists because of the scope described above. The inference.* reads are operator-global and carry no auth header, so without the shell gate the console would render fleet topology and vendor pricing to anyone who opened the URL. The gate is the access-control boundary for this surface; do not treat the procedures themselves as the boundary.

​
The account menu

The avatar button in the top bar opens the account menu, which reflects the session it found: The menu also offers Back to portal and Sign out. Sign out ends the session best-effort and then sends you to the portal’s /login. Because the No active session state is reachable in the menu’s own rendering logic while the gate is what actually blocks the screens, treat the account menu as informational only. If it says No active session and you are still looking at a screen, reload — the gate will re-evaluate. The sidebar has four groups. Each entry maps to a stable URL path you can bookmark or deep-link: Notes on the entries whose label and path disagree:
  • Get started is the guided onboarding screen for the inference modality. It is a shared component, not an inference-specific dashboard.
  • Request builder is the screen that older material calls the “Playground”. The label changed; the route is still /playground. It renders at full height, so it is the one screen that fills the viewport rather than scrolling the main column.
  • Compute is the tenant-scoped screen described above.
  • Fleet & latency is the fleet topology and latency view. Together with Providers it is the reason the sign-in gate exists.
  • Usage & billing mounts at /usage, not /billing, to match the sibling Streams portal. A bookmark to /billing will not resolve.
Any unrecognised path redirects to / (Overview), so a stale or mistyped deep link lands you on the dashboard rather than a 404.

​
Shell affordances that are not screens

These live in the chrome and are available from every route:
  • Docs in the top bar deep-links the documentation entry for the current modality.
  • Theme toggle switches between dark and light.
  • Guided tour is available in-app and is anchored to the sidebar entries by their route keys.
  • Assist dock and the tweaks panel are shell-level overlays.
  • Version check notifies you when the loaded console build is stale.
  • Error monitoring is tagged with vertical='inference', and is inert unless the deployment sets a Sentry DSN.
The layout is responsive: at narrow widths the sidebar becomes a drawer, grids reflow, and tables scroll horizontally rather than squeezing.

​
White-label deployments

White-labelled deployments replace the mark and the wordmark from the portal’s Settings → Branding. The inference fabric sub-label under the wordmark does not change — it names the surface you are on, not the vendor who ships it. Deployments with no branding configured render the built-in lockup. The fabric host pill follows the deployment’s brand domain, so the base URL you copy out of this console is always the one for your deployment.