# Console overview

Source: https://convergingthought.com/docs/product/overview

> Find setup, credentials, requests, adapters, usage, and spending controls in one project workspace.



The [Internalize console](/internalize/app) is the operational view of your project. It uses the same durable state as the public API: a job submitted by your backend appears in Activity, and an adapter activated through the API appears in Memory.

## Workspaces [#workspaces]

| Workspace                                 | Use it for                                                         |
| ----------------------------------------- | ------------------------------------------------------------------ |
| [Overview](/internalize/app)              | Create a key, prepare credits, and make the first call             |
| [API keys](/internalize/app/keys)         | Create, inspect, and revoke server credentials                     |
| [Activity](/internalize/app/requests)     | Follow admitted operations and inspect their results               |
| [Memory](/internalize/app/memory)         | Inspect subjects, validation, versions, and retention              |
| [Playground](/internalize/app/playground) | Teach a passage and ask a question using the same subject          |
| [Usage](/internalize/app/usage)           | Review settled tokens, calls, and spend over the recent period     |
| [Billing](/internalize/app/billing)       | Review available credit, reservations, and credit activity         |
| [Settings](/internalize/app/settings)     | Change the project label and hard spending limit; inspect activity |

## Project context [#project-context]

Check the selected project before creating a key, funding a balance, or changing an adapter. Project keys automatically select their owning project in the public API; the browser's project selector does not change a key already installed in another service.

Project names are human-readable labels. Use the immutable project ID from Settings when matching a console issue to an application deployment. Changing the name does not rename subjects or invalidate credentials.

## Empty and pending states [#empty-and-pending-states]

A new project has no model jobs, no adapters, and no settled usage. These empty states are expected. The dashboard displays your actual requests and usage; the first purchase funds the project.

A pending request can reduce available balance before any settled usage appears. Activity tracks the operation; Billing shows its reservation; Usage reflects it only once settlement is known. Those views answer different questions rather than refreshing at the same accounting moment.

## Move from inspection to integration [#move-from-inspection-to-integration]

Start in the playground to understand the sequence, then reproduce it with [the quickstart](/docs/getting-started/quickstart). Keep the same project and subject when you expect continuity. Use a separate subject when you intentionally want a clean base comparison.

The console is not an alternate source of model behavior or an implicit chat-memory system. It submits the same kinds of jobs and obeys the same funding, validation, and activation rules. See [availability](/docs/getting-started/availability) for the current hosted gates.