🗓️ 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

🔎 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

🔎 Recap: What Cortensor Dashboard Is and Why It Matters A quick recap on what Cortensor Dashboard is in the broader Cortensor stack. 🔹 What the Dashboard is At the simplest level, Cortensor Dashboard is the main visibility and operations surface for the network. It is not just a block explorer or a stats page. It is the place where users, node operators, and admins can inspect how the network is behaving across: - sessions - tasks - nodes - stats - rewards - config - contract/runtime state So from the outside, the Dashboard is how Cortensor becomes more observable and easier to operate. 🔹 What the Dashboard can do today The current Dashboard already has the shape for: - Network and user task views - inspect task flow - view session tasks - open task details and results - check hashes, timing, ack/precommit/commit state, and resolved outputs - Stats and ranking surfaces - network stats - heatmaps - rank/reward views - task-focused views - config/runtime visibility - Node/operator views - all nodes - node performance - pool membership - version - level/spec - validator-related views - Contract/config visibility - runtime/config overview - contract/module addresses - system parameters - network configuration pages - Ops/debug visibility - session-level inspection - task/result drilldowns - performance and reward visibility - more readable task/result surfaces across desktop, tablet, and mobile 🔹 Why this matters The Dashboard matters because a network is not very useful if people cannot clearly see: - what is happening - what is healthy - what is failing - how work is flowing - how nodes are performing - how rewards/config/runtime state are changing So the Dashboard is one of the key layers that turns Cortensor from raw infrastructure into something: - observable - operable - debuggable - easier to trust and participate in 🔹 Current direction The Dashboard is also continuing to improve on the UI/UX side, especially around: - task tables - task details - result views - mobile and responsive layouts - cleaner operational visibility 🔹 Simple framing - Cortensor Network = the execution / routing / trust infrastructure - Cortensor Dashboard = the visibility and operations surface on top of it That is why the Dashboard matters: it gives the network a usable control/inspection layer, not just raw backend activity. #Cortensor #Dashboard #AIInfra #DePIN

🔎 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

The US government, citing national security authorities, has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States, including foreign national Anthropic employees. The net effect of this order is that we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance. Access to all other Claude models is not affected. We apologize for this disruption to our customers. We believe this is a misunderstanding and are working to restore access as soon as possible. Read our full statement: anthropic.com/news/fable-myt…

🛠️ DevLog – Gateway Capacity Follow-Up: Next Focus Is Multi-Model Routing A quick follow-up on the recent API Gateway capacity / reliability work. 🔹 Current progress We’ve now added the first minimal layer of capacity-aware tracking / load balancing on the API Gateway side so the hosted path behaves a bit more safely under shared load. 🔹 What comes next From here, we’ll shift gears a bit and start reconfiguring the existing sessions so they can support more than just the current oss-20b path. The goal is to test: - model routing at the API Gateway level - how the gateway behaves when multiple model paths exist underneath - whether the current hosted flow still routes cleanly once the model mix becomes broader 🔹 Why this matters So the next step is not only “protect the gateway under load,” but also make sure the gateway can route correctly once the backend is no longer centered around just one model/session path. 🔹 Current takeaway The first capacity/reliability layer is in place. Next, we use that foundation to test the multi-model routing side more directly. #Cortensor #DevLog #Portal #APIGateway #Routing #Reliability

Recently, we purchased one of each Anthropic/OpenAI subscription plan and randomly ran long horizon coding tasks until we exhausted the weekly limit. It's widely believed that a $200/month plan maxes out at ~$2000/month worth of tokens (assuming API pricing). However, we found that the subscriptions are actually far more generous. (2/4)

🛠️ DevLog – Portal Usage Trend UI Got Another Refinement Pass A quick follow-up on the Portal usage-trend area we added last Friday. 🔹 What we refined We did another UI/UX pass on the token-usage and trend surfaces, especially around: - the activity heatmap - heatmap cell styling / readability - how token activity is shown over time - how trend cards and supporting stats are grouped 🔹 Why this matters This area is meant to do more than just show a number. It should help users understand: - when usage happened - how activity is distributed across days - whether usage is concentrated or gradual - how token flow is trending over time So the refinement work here is mostly about making that information easier to read at a glance. 🔹 Heatmap focus A lot of the recent polish was specifically around the activity heatmap implementation: - improving the visual weight of cells - making the scale easier to understand - making lower vs higher activity feel clearer - helping the whole section look cleaner in both light and dark mode 🔹 Current takeaway This is still a refinement pass, but the usage-trend area is starting to feel more useful and more polished as a real product surface rather than just a raw stats widget. #Cortensor #DevLog #Portal #UIUX #ProductDesign

🛠️ DevLog – Dashboard Verification Links Are Coming A quick follow-up on the Dashboard side. We’ll likely release a small dashboard update later today focused on verification and traceability. 🔹 What’s changing The main improvement is that each: - action - session - state change will start linking more directly to the explorer, so people can verify the underlying tx / state transition more easily. 🔹 Why this matters Right now, some of this still requires manual lookup through the explorer. With these links added directly into the dashboard, it should become easier to: - verify what happened - inspect state transitions - trace actions more quickly - connect dashboard views to onchain/explorer data with less friction 🔹 Current direction So this is mainly a dashboard verification refinement pass: - less manual explorer lookup - more direct verification from the dashboard - cleaner traceability for sessions and state changes #Cortensor #DevLog #Dashboard #Verification #Explorer

🔎 Recap: What’s in Cortensor Portal V1 So Far A quick recap on what is already going into Cortensor Portal V1 as the current iteration continues. 🔹 What Portal is At the simplest level, Portal is the hosted product/access layer for using Cortensor more easily. Instead of asking users to deal directly with raw router nodes, sessions, or backend topology, Portal gives a cleaner surface where someone can: - sign in - create and revoke API keys - view usage and limits - access hosted inference through a stable API - use managed router pools underneath without touching the raw infra directly So from the outside, Portal means: less infra friction, more direct product access. 🔹 What’s in Portal V1 so far The current Portal V1 iteration already includes: - auth/account access - sign in / account flow - environment-aware dev/prod setup - moving toward cleaner provider-based auth paths - API key management - create keys - list keys - revoke keys - free-plan key-limit enforcement - safer sync between Portal, database, and key-management layer - usage and quota visibility - session and weekly quota windows - sliding-window usage by default - reset / recovery timing - near-limit state visibility - clearer handling of quota-limited vs real failed requests - request / log visibility - request log views - request details - status, latency, token, and route visibility - clearer separation between completed, failed, and quota-limited requests - hosted API path - Portal API Gateway in front of managed router pools - product-facing model aliases - compatibility work for OpenAI-style and Anthropic-style API paths - ongoing SSE/stream compatibility work - usage trends / analytics - token activity trend - daily usage views - heatmap-style usage visualization - model usage breakdowns - admin / ops surface - environment health - request traffic - user/account visibility - key visibility - gateway and router-pool visibility - early metrics / events / operational monitoring 🔹 Why this matters Portal matters because it helps Cortensor move from being understood mainly as infrastructure to being used more directly as a product. That is important because it: - lowers the barrier to entry - makes integration easier for outside developers and teams - gives Cortensor a clearer hosted API surface - turns raw network capability into something easier to adopt and actually use 🔹 Current direction The current V1 direction is still intentionally practical: - hosted inference first - stable key/usage/account flow first - cleaner request path first - better observability/admin support over time - more compatibility and smoother developer experience over time So the simple framing is: - Cortensor Network = the underlying execution / routing / trust infrastructure - Portal = the hosted product/access layer on top of it That is what is in Portal V1 so far, and we’ll keep iterating from here. #Cortensor #Portal #API #AIInfra #ProductDesign

🛠️ DevLog – Dedicated-Node Mainnet Lite E2E Worked Including Payment Distribution A quick follow-up on the Mainnet Lite dedicated-node path. 🔹 Current result We ran another dedicated-node E2E check, and this time the full lifecycle worked out, including the part that looked failed or unclear in the earlier test. 🔹 What was revalidated The main thing we wanted to reconfirm was the last part of the node lifecycle: - payment distribution / execution reward It looks like the earlier issue was likely a false positive / one-off, because this time that part also worked. 🔹 References - Session/task: dashboard-lite.cortensor.net… - Payment tx: arbiscan.io/tx/0x569571a9f69… Pending payment observed: - 0.00007 COR 🔹 Why this matters This means the dedicated-node Mainnet Lite baseline path is not only doing the task execution side, but also reaching the payment/reward distribution part correctly as well. 🔹 Current takeaway So from this latest dedicated-node E2E pass, the full path worked: - task execution - session flow - and the payment distribution step too That gives us a cleaner signal that the earlier payment-side issue was not a broader blocker. #Cortensor #DevLog #MainnetLite #DedicatedNodes #L2 #Infra

Good take My guess is - demand for intelligence is near infinite - but 80% of workloads will be running on 99% cheaper models within 12-18 months - 20% of workloads will still run on latest gen models where IQ maxing is important (scientific breakthroughs, higher level ochestrator agents?) - rough analogy might be what % of macbooks or gaming PCs sold have the maxed out specs for CPU/GPU, prices are falling much faster than Moore's law here though - this leads me to think the limiting factor will be energy and compute, not better models At Coinbase we're working hard on routing prompts to cheaper models where appropriate, and in some cases have been able to keep costs roughly flat, while token usage continues to grow exponentially.

🗓️ Weekly Recap – Phase #4 Portal Progress & Mainnet Lite Baseline This week was heavily focused on Portal V1, with most of the effort going into turning the hosted inference path from a rough concept into something much closer to a real product. 🔹 Phase #4 – Monitoring, Support & Stats - Continued monitoring across routing, miners, validators, dashboards, indexers, and L3 stats. - Phase #4 remained stable while Portal V1 work became the primary focus. 🔹 Portal V1 – Baseline Infrastructure Established - Portal V1 now has working baseline infrastructure across dev and prod environments. - API Gateway, router-pool path, auth flow, data model sync, and API key issuance/consumption are all in place in rough form. 🔹 Portal V1 – API Gateway & Product Flow Progress - Portal request flow improved significantly with usage visibility, request logs, quota handling, and API key lifecycle work. - Gateway compatibility with OpenAI/Anthropic-style REST paths improved, and SSE/stream MVP is now working. 🔹 Portal V1 – Router Pools, Observability & Operations - Router-pool testing expanded with additional routing and load-balancing scenarios. - Early admin, observability, and operational surfaces are taking shape to support the hosted path. 🔹 Portal V1 – Quota & Rate-Limit Testing - Sliding-window quota logic received deeper testing and fixes. - Weekly counting issues were resolved and groundwork was laid for future fixed-window experiments. 🔹 RPC Infrastructure Migration • Testnet and Mainnet Lite environments were moved toward newer Cortensor-managed RPC infrastructure. • This gives better control over reliability, observability, and long-term operational costs. 🔹 Mainnet Lite – Baseline Progress - Some progress was made on Mainnet Lite, but it was not a major focus area this week. - Base infra, RPC, contracts/modules, and a rough dedicated-node E2E path are now in place for future iteration. 🔹 Payment Staking – Regression & Hardening - Limited progress this week as focus shifted heavily toward Portal V1. - Additional regression and validation work remains planned in upcoming weeks. 🔹 PyClaw – Dev Path Progress - PyClaw continued moving forward, but only incrementally while Portal V1 took priority. - Side packages, tooling, and repository structure continue to evolve toward the first public development release. A productive Phase #4 week overall - Portal V1 made the biggest leap forward, while Mainnet Lite, Payment Staking, and PyClaw all continued moving forward at a slower pace behind the scenes. #Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #L3

🗓️ Weekly Focus – Portal Refinement, Mainnet Lite Baseline & PyClaw Phase #4 continues with Portal V1 as the primary focus, while Mainnet Lite baseline work, Payment Staking validation, and PyClaw development continue alongside it. 🔹 Phase #4 – Monitoring, Support & Stats - Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats. - Track stability as Portal V1 and Mainnet Lite workstreams continue to evolve. 🔹 Portal V1 – Product Refinement - Continue refining the Portal MVP now that the core path is in place (auth, API keys, usage visibility, gateway, router pools, hosted requests). - Focus on improving usability, operational flow, and product readiness. 🔹 Portal V1 – Gateway & Router Pool Hardening - Continue hardening Gateway → router-pool behavior, observability, and request handling. - Focus on reliability, operational visibility, and preparing the hosted path for broader usage. 🔹 Portal V1 – API / Usage / Quota Refinement - Continue refining API-key lifecycle, usage visibility, logging, and quota/rate-limit behavior. - Build on last week's testing and fixes around sliding-window accounting and request tracking. 🔹 Mainnet Lite – Baseline & Prerequisite Checks - Spend more time validating the Mainnet Lite baseline setup and prerequisite components. - Continue checking infra, RPC, contracts/modules, indexer, oracle, and dedicated-node paths. 🔹 Payment Staking – Regression & Hardening Tests - Continue the postponed regression pass following the recent security-hardening rollout. - Goal remains validating the full staking/usage flow and confirming no regressions. 🔹 PyClaw – Dev Path Progress - Continue PyClaw iteration across workflow, side packages, tools, and repository structure. - Target remains a rough public development release next month so iteration can continue openly. This week is about continuing to refine the Portal baseline, validating Mainnet Lite foundations, and tightening the supporting systems that sit underneath both. #Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #L3