Cortensor Portal V1 – Product Overview & Architecture
Status: Draft Scope: Product shape and high-level architecture for the first hosted Portal release
1. Overview
Cortensor Portal V1 is being designed as a hosted inference product on top of managed Cortensor router infrastructure.
The goal is to let users and developers consume Cortensor as a product, without needing to run:
their own router node
their own session layout
their own gateway / usage / API-key logic
their own surrounding control-plane infrastructure
In practical terms, Portal V1 should feel like a normal hosted AI API product, while Cortensor’s router/session/network complexity remains behind the scenes.
A useful mental model for V1 is:
A managed Cortensor-hosted inference API with a small model catalog, API keys, quotas, and usage visibility.
2. Product Goals
Portal V1 should provide a stable product surface where users can:
sign up and authenticate
create and manage API keys
call a hosted inference API
see usage and limit state
use a curated set of supported models
avoid operating raw Cortensor infrastructure directly
The first version should optimize for:
simplicity
clarity
predictable hosted behavior
low product surface complexity
fast learning from real users
3. Main Product Shape
The current V1 shape is expected to include:
a standalone portal surface, likely something like:
portal.cortensor.network
auth / login
API key creation and management
usage / quota visibility
a small initial hosted model catalog
dedicated-backed inference first
The main Cortensor dashboard may also expose a Create API Key flow later, but the long-term expectation is that this flow points into the Portal backend rather than living as router-native logic.
4. Product Positioning
Portal V1 should be positioned first as a:
Hosted inference product
rather than as a direct “managed gateway into the Cortensor network.”
That means the product should initially hide most internal concepts such as:
raw session IDs
router topology
miner assignment
detailed Cortensor-native routing internals
This makes V1 easier to explain, easier to support, and easier to evolve while backend infrastructure continues maturing.
Later versions may expose more network-native controls, but V1 should focus on a clean hosted surface first.
5. High-Level Architecture
Portal V1 is not intended to be a thin frontend attached directly to one router node.
Instead, the architecture should be thought of as:
client
Portal backend / product logic
API key + policy / rate-limit layer
managed router pools
usage / billing writeback
In short:
Users talk to the Portal layer, not raw router nodes.
Recommended flow
client sends request to Portal API
Portal layer authenticates and checks product policy
Portal layer resolves the request into a managed backend router pool
router pool serves inference
Portal writes usage / metering data back into durable state
This separation matters because:
product logic should not live inside routers
raw router topology should remain replaceable
user-facing keys should not directly hit routers
rate limits, quotas, and product policy should stay centralized
6. Key Design Principle
The Portal should act as a stable product and control plane in front of Cortensor infrastructure.
That means:
business logic belongs in the Portal layer
customer API semantics belong in the Portal layer
entitlement, quota, and usage logic belong in the Portal layer
router fleets should be treated as backend capacity pools, not as the product surface itself
This keeps Portal V1 productized even if:
sessions change
router groups change
models are remapped internally
backend fleet topology evolves over time
7. Early Product Constraints
Portal V1 should remain intentionally narrow.
That means:
small initial model catalog
simple hosted inference first
no attempt to expose every Cortensor-native concept
no attempt to expose all possible model/session combinations
no attempt to solve every payment or marketplace scenario on day one
The purpose of V1 is to establish:
a clean product surface
stable request flow
controlled usage model
predictable support expectations
8. Current Direction Summary
Portal V1 is currently shaping up as:
a hosted inference product
a standalone portal surface
auth + API key + usage visibility
Portal backend in front of managed router pools
dedicated-backed capacity first
narrow model catalog first
product logic separated from routers
In one sentence:
Portal V1 is the first managed Cortensor product surface: a hosted inference API with API keys, quotas, and curated models, backed by managed router pools rather than raw user-operated router nodes.
Last updated