TronXVI Platform

What You Are Looking At

TronXVI Platform is the separate control center for working with TronXVI beyond the main app.

The main app is where users chat, prompt, and work directly with TronXVI. The Platform is where users manage the deeper system around it: dashboards, projects, API keys, billing, docs, text testing, voice testing, and support actions.

The real Platform app currently opens with a dark console layout. A left sidebar stays consistent across the product and includes:

• Dashboard
• Playground
• Projects
• API Keys
• Billing
• Docs
• TRONXVI User quick actions

This page matches that actual Platform structure.

The Platform Sidebar

The sidebar is the anchor of the whole Platform experience.

It gives users the main map:

• Dashboard is for monitoring activity and usage.
• Playground is for testing Web Search and voice integrations.
• Projects is for organizing workspaces.
• API Keys is for creating and controlling access.
• Billing is for balance, plans, payment methods, history, grants, preferences, and promotions.
• Docs is for integration guidance.
• TRONXVI User opens quick actions for Support, Report a bug, and Build TronXVI.

The Platform does not behave like a marketing page. It behaves like an operating console.

Dashboard

Dashboard is the overview screen.

In the current live Platform view, the Dashboard shows:

• Total Requests
• Success Rate
• Active API Keys
• Estimated Spend
• Health
• Timeframe selector: Day, Week, Month
• API key filter
• usage chart area
• table switch between API Keys and Recent Traffic

When there is no traffic yet, the Dashboard says:

No usage data for this filter yet.
No API keys yet.

That empty state matters. It tells a new user exactly what the workspace has and has not done yet.

Once requests start running through the Platform, this same screen becomes the place to confirm:

• whether traffic is being recorded
• whether requests are succeeding
• which keys are active
• how much usage is attached to the workspace
• what estimated spend looks like
• when the last request happened

Dashboard is the Platform's pulse check.

Playground

Playground is where users test the Platform.

The live Platform currently shows:

• TRONXVI_MODE=
• a mode selector
• TRONXVI_API_KEY=
• an API key input
• an assistant starter message
• a message composer
• a Send button
• status chips for key, mode, selected project, and total logged requests

The starter message says:

Create a project in API Key, generate a key, then paste it into TRONXVI_API_KEY to test the platform route here.

That is the real Platform onboarding loop:

1. Create a project.
2. Generate a key.
3. Paste the key into Playground.
4. Send a request.
5. Check Dashboard for usage.

The Playground is not just a demo box. It is the place where users verify that their Platform key actually works.

Voice Playground

The same Playground can switch into voice mode.

The voice view shows the selected integration values:

• TRONXVI_MODE= atlas voice
• TRONXVI_VOICE= adrian
• TRONXVI_API_KEY=
• a secure server-integration status
• Atlas Voice

It is intentionally not a browser-side provider testing surface.

Instead of a text composer, the screen becomes a focused voice integration stage. Users choose a voice tier and a voice personality, then configure their customer backend to request an authenticated short-lived session through /api/platform/v1/realtime/sessions.

The visible voice name is friendly, such as Adrian, while the underlying provider voice and model are resolved by Platform. The customer backend keeps TRONXVI_API_KEY private and returns only the short-lived realtime client secret to its browser/app.

Projects

Projects organize Platform work.

The live Projects screen currently shows:

• search projects input
• total project count
• filtered project count
• selected project status
• Export button
• Create button
• project table

The project table columns are:

• Name
• ID
• API Keys
• Active Keys
• Created
• Status

When no projects exist, the live empty state says:

No projects yet. Create one to start linking API keys.

That is exactly what Projects are for. A project becomes the container that links API keys, usage, billing visibility, and integration work.

For a real user, projects might represent:

• one app
• one integration
• one customer
• one environment
• one experiment
• one internal workflow

API Keys

API Keys controls access to TronXVI Platform.

The live API Keys screen currently shows:

• search keys input
• total key count
• filtered key count
• selected project status
• Create key button
• keys table

The keys table columns are:

• Label
• Key Prefix
• Spend
• Status
• Project
• Created
• Expiry
• Last Used

When no project is selected, the live empty state says:

Pick a project in Projects first, then create a key here.

That tells users the real order of operations. Keys belong to projects. The Platform wants users to create or select a project before creating access credentials.

When a key is created, the Platform is designed to show the full key once so the user can copy it and store it safely. After that, the key should be treated as sensitive.

Why API Keys Matter

API keys are how external tools connect to TronXVI.

They help answer:

• which project made this request?
• which key was used?
• is this key active?
• should this request be allowed?
• how much spend is attached to this access point?
• when was the key last used?

For a single user, keys create control.

For a team, keys create accountability.

Billing

Billing is one of the most complete-looking screens in the current Platform.

The live Billing view contains tabs:

• Overview
• Plans
• Payment methods
• Billing history
• Credit grants
• Preferences
• Promotions

The Overview tab currently shows:

• Available balance
• Add credits
• Recharge settings
• Spending controls
• Auto recharge
• Monthly cap
• Current plan
• Payment methods card
• Billing history card
• Preferences card
• Usage limits card
• Pricing card

The live balance message says:

Ready to serve live traffic
Available balance
$0.89
Enough for light testing right now. Add funds or enable recharge before production usage grows.

The live auto recharge state says:

Auto recharge is off
Manual top-ups only

The current Platform UI presents balance, recharge, and limit controls, but the local Platform backend does not yet enforce prepaid credit shutdown. Today it records estimated usage after each request completes or fails. It does not stop an in-flight integration when estimated balance reaches zero, and it does not return an insufficient-credit or payment-required error for the next request.

That makes Billing a product direction and account-management surface today, not yet a live reliability enforcement surface. A production billing gate still needs persisted balances, recharge state, cap checks, and documented zero-balance error contracts before users can rely on balance exhaustion stopping traffic.

Billing Tabs

The Billing tabs describe the full billing direction of the product.

Plans gives users a place to understand the current plan and future plan options.

Payment methods is where cards or payment sources belong.

Billing history is where invoices and past payments belong.

Credit grants shows earned credits and milestones.

Preferences is where billing identity, invoice details, purchase order numbers, billing email, address, and tax information belong.

Promotions is where credit codes and applied promotions belong.

Together, these tabs make Billing feel like a complete account-management area instead of a single checkout button.

Docs

Docs is the integration guide inside the real Platform.

The live Docs screen starts with:

Build on TronXVI Platform

It explains that TronXVI Platform exposes Web Search and realtime voice integrations.

The Docs page includes:

• project setup
• API key setup
• environment variables
• Web Search and voice tier selection
• core routes
• Web Search request examples
• authenticated realtime session examples
• integration flow
• gateway scope
• runtime and storage notes
• auth failures
• validation and permission failures
• usage, cost, and status semantics

The Docs page tells users to store the API key server-side and avoid exposing it in browser bundles.

It also shows example environment variables:

TRONXVI_API_KEY=trx_live_xxxxxxxxx
TRONXVI_VOICE_MODEL=atlas_voice
TRONXVI_VOICE_NAME=adrian

Docs is where a user moves from clicking around the Platform to actually building with it.

Quick Actions

The TRONXVI User profile area opens a quick-actions menu.

The live quick-actions menu includes:

• Support
• Report a bug
• Build TronXVI

This makes the Platform feel connected to support and feedback instead of isolated. If something is confusing, broken, or needs to become a custom workflow, the user has a direct place to act.

Support And Admin Surface

The Platform codebase also contains a support and admin workspace.

That workspace is designed around:

• admin dashboard
• support messages
• support conversation overlay
• admin replies
• account snapshots
• tracked user message count
• plan period
• current plan
• recent purchases
• cost tracker settings
• provider call tracking
• Brave call tracking
• exact spend estimates
• request volume
• every logged question

This is more internal-facing than the public Platform console, but it belongs to the same overall Platform story: TronXVI is meant to be monitored, supported, and operated from a real control surface.

Real Platform Journey

A real user journey looks like this:

1. Open Platform.
2. Go to Projects.
3. Create a project.
4. Go to API Keys.
5. Create a key for the project.
6. Copy the key.
7. Go to Playground.
8. Paste the key into TRONXVI_API_KEY.
9. Choose atlas, scout, sentinel, or a voice tier.
10. Send a request or start voice.
11. Go to Dashboard.
12. Confirm activity and usage.
13. Go to Billing.
14. Check balance, recharge, limits, and plan state.
15. Go to Docs when ready to integrate.

That is the complete loop: organize, secure, test, monitor, pay, and build.

What The Platform Helps Users Understand

The Platform makes hidden system behavior visible.

It helps users understand:

• what they have created
• what is active
• what is empty
• what needs setup
• what can be tested
• what is being billed
• what documentation applies
• where to get support

That is the difference between a simple app and a real platform.

What Must Stay Clear

The Platform should always make these things obvious:

• Projects come before keys.
• Keys are sensitive.
• The full key is only shown once.
• Playground testing requires a key.
• Dashboard becomes useful after traffic exists.
• Billing matters before production usage grows.
• Docs explain the integration path.
• Support actions are always nearby.

If those ideas stay clear, users can understand the Platform even if they are not developers.

Final Product View

TronXVI Platform is the control room for the wider TronXVI system.

It has the actual screens a serious user expects:

• a usage dashboard
• a real request playground
• a voice playground
• project management
• API key management
• billing controls
• integration docs
• support actions
• admin/support direction

The website Platform page should reflect that complete experience, not just describe the folder behind it.

That is the right public framing:

TronXVI Platform is where users go when they need deeper control over TronXVI.