🛠️ DevLog – Portal Usage Metering Will Shift from Request Count to Token Count A quick follow-up on the Portal usage side. 🔹 Current direction So far, Cortensor Portal and the API Gateway have mostly tracked usage by request count. That was useful for getting the hosted path working early, but it also means one small request and one much larger request can look the same from the quota side even if they consume very different amounts of model work. 🔹 What changes next The next step is to move usage metering more toward actual model consumption: - input tokens - output tokens - total token usage So Portal quotas and usage reporting can align more closely with the real workload. 🔹 Why this matters This should make the Portal path: - more fair, since small and large requests no longer cost the same - more accurate, since usage reflects actual inference work - a better foundation for future quota, reporting, and billing controls - easier to understand, since users can see how prompt size and response size affect usage 🔹 Current takeaway So the direction is simple: Portal usage metering is moving from request-based accounting toward token-based accounting, so quota and reporting reflect real inference usage instead of just raw request volume. #Cortensor #DevLog #Portal #API #UsageTracking

🛠️ DevLog – Portal API Gateway Focus for the Coming Weeks A quick recap on what the next Portal/API Gateway focus looks like for the coming weeks and the rest of this phase. 🔹 Multiple model routing One of the next main areas is moving beyond a single-model hosted path. The goal is to keep testing how the Portal API Gateway behaves once more than one model path exists underneath, including: - model routing at the gateway level - cleaner handling across different backend session paths - making sure the hosted flow still stays predictable as the model mix becomes broader 🔹 API Gateway reliability refinement The other big area is reliability refinement around the hosted execution path itself, especially: - API Gateway behavior under shared load - router-node pool behavior underneath - safer routing when sessions/nodes are busy - better stability as traffic and concurrency increase 🔹 Why these 2 matter now The first layer of capacity-aware routing is already there in rough form. So the next step is not just “make requests pass,” but: - make routing smarter across multiple models - make the API Gateway and router-pool path more resilient - reduce weaker points as the hosted path gets used more heavily 🔹 Current takeaway So for the coming weeks, a big part of the Portal/API Gateway work is centered around: - multiple model routing - API Gateway reliability - router-node pool refinement That is where a lot of the remaining hardening work sits for this phase. #Cortensor #DevLog #Portal #APIGateway #Routing #Reliability

🔎 Recap: What is Mainnet Lite vs Mainnet Full? Mainnet Lite is the more practical and controlled L2 path. It is taking shape around: - @Arbitrum L2 - Dedicated-node-heavy serving - Simpler rollout - Earlier hosted / demonstration-style path Mainnet Full is the fuller Cortensor-native path. It is taking shape around: - @Arbitrum Orbit L3 - Broader long-term network shape - Fuller infra / protocol direction - More complete Cortensor stack The goal is simple: use Mainnet Lite as the more controlled first step, while Mainnet Full remains the broader long-term network direction. Mainnet Lite is the earlier rollout path. Mainnet Full is the fuller Cortensor-native path. #Cortensor #MainnetLite #Mainnet #Arbitrum

🗓️ Weekly Recap – Phase #4 Portal Progress, Mainnet Lite Validation & Infra Hardening This week was again heavily focused on Portal V1, with meaningful progress across product flows, API Gateway behavior, observability, and hosted inference readiness. 🔹 Phase #4 – Monitoring, Support & Stats - Continued monitoring across routing, miners, validators, dashboards, indexers, and L3 stats. - Phase #4 remained stable while Portal and Mainnet Lite workstreams continued to mature. 🔹 Portal V1 – Product Flow Maturing - Portal moved from rough MVP toward a more usable hosted product surface with cleaner auth, API keys, usage visibility, request logs, and UI/UX refinement. - Data consistency between web app, database, and API-key systems improved significantly. 🔹 Portal V1 – API Gateway & Quota Work - Sliding-window quota logic received deeper testing and fixes, including weekly-limit accounting improvements. - Usage counting became more accurate with better separation between successful requests, quota events, and real failures. 🔹 Portal V1 – Request Visibility & Analytics - Request visibility improved with better logs, filters, totals, and detailed request views. - Added richer usage analytics including trends, activity heatmaps, and token-level visibility. 🔹 Portal V1 – Reliability, Observability & Operations - Dual API Gateway setup is now operating behind a shared entry path, reducing single-point dependency. - Admin/ops visibility expanded with metrics around gateway health, latency, routing distribution, and user activity. 🔹 Portal V1 – API Compatibility & Streaming - OpenAI-style and Anthropic-style REST compatibility continued to improve. - SSE/streaming MVP is now working, with deeper reliability work shifting toward backend/router behavior. 🔹 Portal V1 – Stress Testing & Router Pools - Stress testing expanded using multiple accounts, keys, parallel requests, and longer-running workloads. - This surfaced the next bottlenecks and drove further work on capacity-aware routing and router-pool behavior. 🔹 Mainnet Lite – Baseline Validation - Mainnet Lite dedicated-node E2E was re-run successfully, including payment distribution behavior. - Ephemeral-node network-task E2E also worked, confirming another critical baseline path. 🔹 RPC & Infrastructure Hardening - Internal RPC infrastructure is now live across both testnet and mainnet-related environments. - Early stability looks good and provides better operational control than previous external dependencies. 🔹 Payment Staking – Regression & Hardening - Progress was lighter than planned while Portal took priority this week. - Additional validation and regression testing remain on the upcoming work list. 🔹 PyClaw – Dev Path Progress - Continued incremental progress on PyClaw workflows, tooling, and repository structure. - Focus remains on preparing for the first public development release and open iteration cycle. A productive Phase #4 week overall - Portal V1 made the largest jump forward, Mainnet Lite baseline checks continued to pass, and the hosted inference path is increasingly shifting from concept into an operational product. #Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #L3