xMars

[Cortensor @cortensor]

🛠️ DevLog – Portal Multi-Model Routing Prep Starts Next Week

A quick follow-up on the recent API Gateway capacity / reliability work.

🔹 Current direction
Now that the first minimal layer of capacity-aware tracking / load balancing is in place, the next step is to start testing the Portal path with more than just the current `oss-20b` route underneath.

🔹 What’s next
Next week, we’ll begin the prep work to switch/add more models into the current hosted path.

The next models we want to bring in are:
- gemma4 e4b
- qwen 3.5 9b

🔹 Why this matters
This is important because the next Portal check is not only about load protection anymore.

It is also about making sure the API Gateway can:
- route different models correctly
- behave cleanly once more than one model path exists
- handle a broader hosted flow instead of staying centered on only oss-20b

🔹 Current takeaway
So the next step is:
- prepare the model switch/additions next week
- expand beyond the single-model path
- test multi-model routing more directly at the API Gateway level

#Cortensor #DevLog #Portal #APIGateway #Routing #Reliability

[Cortensor @cortensor]

Cortensor is not just one product or one surface.

It is increasingly becoming one stack:

- Network & Infra as the foundation
- Dashboard for visibility and operations
- Portal for hosted access
- Corgent for infra-native agent execution
- Bardiel and PyClaw as higher-level product and agent layers

That is the bigger picture:

One stack that people can build on, operate on, access through products, and turn into real applications.

#Cortensor #AIInfra #AgenticAI #Portal #Dashboard #Corgent #Bardiel #PyClaw

[Cortensor @cortensor]

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

[Cortensor @cortensor]

Mainnet Lite is the controlled first step for bringing the Cortensor stack onto real mainnet conditions.

The point is not to do everything at once. It is to start with a simpler, more productized L2 path first at @Arbitrum, validate the stack under real conditions, and then build outward from there.

Q3 2026.

#Cortensor #MainnetLite #Mainnet #Arbitrum

[Cortensor @cortensor]

🛠️ DevLog – Gateway Session Load Protection Is Now Live

A follow-up on the capacity-aware gateway work from the last devlog.

🔹 Current progress
We added session-capacity aware load protection to the API Gateway.

The gateway can now track shared Cortensor session occupancy across multiple gateway instances using Redis, while keeping the routing flow simple and predictable.

🔹 What changed
Core gateway updates:
- Redis-backed shared session tracking
- round-robin routing preserved, but full sessions are skipped
- per-session in-flight limits
- automatic capacity release after requests finish
- short bounded-wait window during bursts

Ops/admin updates:
- capacity mode, Redis status, tracked sessions, limits, lease TTL, and wait timeout are now exposed
- admin surfaces can show plain mode vs Redis-backed tracking mode
- wait timeout can be tuned through env vars

🔹 Why this matters
This helps the hosted API path behave more safely during traffic spikes.

Multiple gateway instances can now coordinate against the same shared router pool instead of blindly sending more traffic to sessions that are already busy.

This gives us:
- smoother burst handling
- better shared-session protection
- clearer capacity visibility
- safer multi-instance gateway behavior

🔹 Important note
Plain/default mode still works as before.

The new coordination behavior only activates when Redis-backed session tracking is enabled.

This is not a full queue system yet, but the bounded-wait window gives requests a short chance to find open capacity before failing.

#Cortensor #AIInfrastructure #DevLog #Inference #Gateway #DecentralizedAI

[Cortensor @cortensor]

🛠️ DevLog – Stress Tests Are Surfacing the Next API Gateway Improvement

A quick follow-up on the current Portal / API Gateway stress tests.

🔹 What we’re seeing
As we push the hosted path harder, one of the clearer gaps showing up is around how the API Gateway should handle load when multiple requests arrive faster than shared router sessions can process them.

When that happens:
- some router sessions can get overloaded
- response times become less predictable
- failures increase more easily under bursts

🔹 What we plan to add
The next improvement we’re planning is capacity-aware routing inside the API Gateway.

The idea is simple:
- keep the current round-robin routing shape
- but make it aware of whether a router session is already busy
- skip sessions that are already at capacity
- move to the next available one instead of sending too much work to the same node

🔹 Why this matters
This should help with:
- smoother request handling
- better stability during spikes
- more predictable performance
- safer behavior when multiple gateway instances share the same router pool

🔹 Current status
This is the direction we’re moving toward based on what the stress tests are surfacing, but it is not implemented yet.

#Cortensor #DevLog #Portal #APIGateway #StressTest #Reliability

[Cortensor @cortensor]

🛠️ DevLog – Gateway Capacity Tracking Is Now in Testing

A quick update on the capacity-aware gateway work from the last devlog.

🔹 Current progress
The first version is now implemented and being tested across the hosted API path.

The gateway can now coordinate shared router-session usage through Redis, so multiple gateway instances have better awareness of which sessions are already busy before routing more traffic.

🔹 What changed
Core gateway updates:
- Redis-backed session capacity tracking
- per-session concurrency limits
- existing routing flow preserved
- capacity/runtime status exposed through management endpoints

Ops UI updates:
- admin view for capacity mode, tracked sessions, lease TTL, and Redis state
- dedicated Sessions view for live Cortensor session usage
- visibility into live occupancy, recent traffic, labels, latency, token usage, and gateway hit distribution

🔹 Why this matters
This helps the hosted API path handle bursts more safely.

With multiple gateway replicas, traffic can now be coordinated against the same shared session pool instead of blindly overloading the same router session.

This gives us:
- better load protection
- clearer real-time session visibility
- easier debugging during stress tests
- more predictable hosted inference traffic distribution

🔹 What comes next
This is not full queue-based admission control yet.

Next, we’ll also be looking into the queue layer so overload behavior is safer when sessions are busy or all sessions are at capacity.

The goal is:
- stronger backpressure
- clearer overload handling
- more predictable burst behavior

#Cortensor #AIInfrastructure #DevLog #Inference #Gateway #DecentralizedAI

[Cortensor @cortensor]

🛠️ DevLog – Small Ops UI/UX Refinements While Stress Tests Continue

A quick follow-up on the Portal admin / ops side.

🔹 Ops UI/UX refinement
We’ve been adding a number of smaller refinements to the ops/admin surface while doing the current stress tests:
- more small graphics / visual cues
- clearer metric blocks
- cleaner request / fleet / event views
- better readability for operational monitoring

So this is mostly a polish pass, but it helps the admin/ops side feel more usable as the Portal path gets more real.

🔹 Stress-test constraint
One thing we also realized during testing is that the current testnet1a router pool only has 8 nodes behind it.

That means even something like 3 parallel tests can already start to overwhelm the pool.

🔹 What this means
So from here, we’ll decide whether:
- we can keep pushing with more stress tests on the current pool
or
- it makes more sense to pause/postpone until the pool is better populated

🔹 Current takeaway
So this is both:
- a small admin/ops UI refinement pass
- and a useful signal that the current router-pool size is still a limiting factor for heavier stress testing

#Cortensor #DevLog #Portal #Observability #StressTest #UIUX

[Cortensor @cortensor]

🔎 Recap: Mainnet Lite Is Coming in Q3 2026

A quick recap on what Mainnet Lite is and why it matters.

🔹 What Mainnet Lite is
Mainnet Lite is the more practical and controlled #L2 rollout path for Cortensor.

It is taking shape around:
- @Arbitrum L2
- more dedicated-node-heavy serving in the earlier stage
- a simpler and more productized rollout shape
- the earlier hosted / demonstration-style path before broader expansion

🔹 Why it matters
Mainnet Lite is important because it is the more controlled first step for bringing the Cortensor stack onto real mainnet conditions.

It gives us a path to validate:
- execution
- routing
- sessions
- dashboard / infra visibility
- product-facing surfaces on top

without treating the fuller long-term path as the first rollout step.

🔹 How to think about it
The simple framing is:

- Mainnet Lite = L2-first, simpler rollout, more dedicated-node-heavy path
- Mainnet Full = fuller L3-native Cortensor path later

🔹 Timing
The current direction is that Mainnet Lite is coming in Q3 2026.

#Cortensor #MainnetLite #Mainnet #Arbitrum

[Cortensor @cortensor]

This is directionally why we think execution infrastructure matters.

As AI access becomes more metered and less subsidized, the winning stack is not just "best model."
It is:
- which model runs where
- at what cost
- with what trust level
- on what execution layer

That is exactly the kind of future Cortensor is built for.

[Cortensor @cortensor]

🛠️ DevLog – Portal Stress Tests Are Now Starting

A quick follow-up on the Portal V1 stress-testing path.

🔹 Current progress
We’ve now started running the first round of:
- parallel API calls
- repeated request patterns
- broader hosted-path checks through the Portal + API Gateway flow

🔹 What this means
This is the next step beyond simple single-request validation. The goal is to see how the hosted path behaves under:
- more realistic usage
- concurrent requests
- multi-account / multi-key activity
- longer-running API calls

🔹 What’s next
We’ll keep running more of these tests today and use them to surface:
- weaker points in the hosted path
- routing / pool behavior under load
- request/accounting consistency
- areas that still need hardening before broader usage

🔹 Current direction
So this stress-test phase is now in motion, and it should give us a clearer signal on how the Portal path behaves under more realistic usage patterns.

#Cortensor #DevLog #Portal #Gateway #API #StressTest

[Cortensor @cortensor]

🛠️ DevLog – Portal Usage Heatmap Got a Small UI/UX Refinement Pass

A quick Portal UI/UX follow-up.

🔹 What improved
We refined the usage heatmap experience a bit more so the section reads more cleanly and feels more intentional.

That includes:
- filling future heatmap cells farther out so the calendar grid looks more complete
- adding a small reading guide for:
- date coverage
- successful requests only
- dashed cells = future days
- adding matching light/dark mode styling for those guide chips

🔹 Why this matters
This is a small refinement, but it makes the usage-trend area easier to read at a glance and helps the heatmap feel less ambiguous.

#Cortensor #DevLog #Portal #UIUX #ProductDesign

[Cortensor @cortensor]

🛠️ DevLog – Dashboard → Explorer Verification Links Are Now Live on Testnet0 and Testnet1a

A quick follow-up on the earlier dashboard verification update.

🔹 Current progress
We’ve now pushed this feature into both:
- testnet0
- testnet1a

🔹 What changed
Task/session views can now link more directly into the explorer, so actions and state changes are easier to verify without doing manual lookup first.

Example flow:
- Dashboard task view → https://t.co/umJhF42DwM
- Explorer tx view → https://t.co/zURqD8BqIq

🔹 Why this matters
This makes it much easier to:
- inspect what happened from the dashboard
- jump straight into the underlying transaction/state change
- verify task/session activity with less friction

🔹 Current takeaway
So this is a useful refinement for both dashboard usability and verification flow:
- less manual explorer searching
- more direct traceability from dashboard views
- cleaner inspection of task/session state changes

#Cortensor #DevLog #Dashboard #Verification #Explorer

[Cortensor @cortensor]

This is directionally why Cortensor matters.

If more of the market is moving toward cheaper models, then the real challenge is no longer just model quality by itself. It becomes:
- routing workloads to the right cost/quality tier
- using lower-cost capacity where it is good enough
- reserving premium capacity where it actually matters
- making that whole path observable, verifiable, and programmable

That is exactly the layer Cortensor is building.

[Cortensor @cortensor]

🛠️ DevLog – Why We’ll Revisit Base Flashblocks Later

A quick note on how we currently think about @base in relation to Mainnet Full and the broader Cortensor stack.

🔹 Why we leaned toward Arbitrum first
When we evaluated the L2 path last year, one of the main reasons we leaned more heavily toward @arbitrum for the current #L2 / #L3 direction was practical response time and execution responsiveness. That made it a better fit for the kind of session behavior and infra shape we cared about.

🔹 Why Base was not the priority then
At the time, Base Flashblocks was still not something we wanted to depend on yet, so we did not push further there.

🔹 Why Base is worth revisiting now
That situation looks different now. Base Flashblocks now makes the Base path more interesting again, because it improves the user-perceived latency / preconfirmation path enough that it becomes worth taking another look.

🔹 Important distinction
That does not mean Base suddenly becomes the same thing as the current Arbitrum path overnight.

The way to think about it is:
- Arbitrum still explains why the current L2 / L3 stack exists the way it does today
- Base Flashblocks is the reason we should revisit whether a stronger Base path becomes viable later

🔹 Current direction
So the direction is still:
- Arbitrum L2 / Orbit L3 first for the main Cortensor path
- then revisit Base + Flashblocks after the Mainnet Full Arbitrum Orbit L3 path is deployed and usable

🔹 Current takeaway
This is less about changing the current stack direction, and more about reopening a path that previously was not mature enough to justify the same level of attention.

#Cortensor #Base #Arbitrum #Flashblocks #Mainnet

[Cortensor @cortensor]

🔎 Recap: Mainnet Lite vs Mainnet Full

A quick recap on how we currently think about Mainnet Lite versus Mainnet Full.

🔹 Mainnet Lite

Mainnet Lite is the more practical and controlled L2 path.

The current direction is:
- built around the @Arbitrum L2 path
- more heavily backed by dedicated nodes in the earlier stage
- simpler and more productized as an initial rollout shape
- useful as the earlier hosted / demonstration-style path before broader expansion

Reference path:
- Testnet0 → https://t.co/hZmk5qWT8V

🔹 Mainnet Full

Mainnet Full is the fuller Cortensor-native path.

The current direction is:
- built around the @Arbitrum Orbit L3 setup
- closer to the broader long-term Cortensor network shape
- more aligned with the fuller infra / protocol direction beyond the lighter L2 rollout path

Reference path:
- Testnet1a → https://t.co/8gjkMvzfAt

🔹 Why both matter

These two tracks are related, but they are not trying to do the exact same thing at the exact same stage.

The rough framing is:
- Mainnet Lite = L2-first, simpler rollout, more dedicated-node-heavy path
- Mainnet Full = fuller L3-native Cortensor path

🔹 Current takeaway

So Mainnet Lite is the more controlled first step, while Mainnet Full remains the broader long-term network direction.

#Cortensor #MainnetLite #Mainnet #L2 #L3

[Cortensor @cortensor]

🛠️ DevLog – Mainnet Lite Follow-Up: Remaining Critical Baseline Checks

A quick follow-up on the Mainnet Lite baseline path.

🔹 Current status
The ephemeral-node path for network tasks is now working, so that part of the baseline has been checked.

🔹 What still matters most now
The main focus is on the remaining critical pass checks before next month’s prep:

- Ephemeral node + user task path
Even though L2 / Mainnet Lite is not expected to rely on ephemeral nodes for user tasks as the main path, we still want to check it because it matters for the later L3 prep direction.

- Staking-as-payment E2E
This path should work, but it is still one of the critical checklist items we want to reconfirm end to end.

🔹 Why this matters
So the focus now is less about adding new paths and more about making sure the remaining critical baseline checks are covered cleanly:
- network-task ephemeral path ✅
- user-task ephemeral path ⏳
- staking/payment E2E ⏳

🔹 Current takeaway
The main remaining work is now clearer: finish the last critical baseline pass checks so the Mainnet Lite prep path is more complete going into the next stretch.

#Cortensor #DevLog #MainnetLite #L2 #Infra #EphemeralNodes

[Cortensor @cortensor]

🛠️ 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: https://t.co/rntKpDuuju
- Payment tx: https://t.co/7rsm2iB9nv

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

[Cortensor @cortensor]

🛠️ DevLog – Ephemeral-Node Network Task E2E Also Worked on Mainnet Lite Baseline

A quick follow-up on the Mainnet Lite baseline path.

🔹 Current result
We’ve now also gotten an ephemeral-node E2E working on the Mainnet Lite side, specifically around the interaction between the ephemeral node and the network task oracle for network tasks.

That path also created a few network-task sessions, which gives us another useful baseline signal on the L2/Mainnet Lite setup.

🔹 Why this matters
At this point, the main critical baseline paths have now been checked on Mainnet Lite for:
- ephemeral node + network task
- dedicated node + user task

So the baseline is no longer only infra prep or dry configuration. We now have working E2E checks across both of those important paths.

🔹 What still remains
The main remaining area is still the ephemeral node + user task path.

That one will require a bit more setup, mainly because the node pool needs to be populated more before we can test it properly.

🔹 What’s next
So the next step is to bring up a few more node instances and keep filling out the pool so we can test that remaining path more directly.

#Cortensor #DevLog #MainnetLite #L2 #EphemeralNodes #Infra

[xMars @IvanMoskov3]

@itzKronuzz dune fedaykin clears imo