Cortensor

Pioneering Decentralized AI Inference, Democratizing Universal Access. #AI #DePIN
🔗

[Cortensor @cortensor]

PSA: There are NO official tokens for Bardiel or Corgent.

No #BARDIEL token
No #CORGENT token

Any token claiming to be “Bardiel” or “Corgent” is not launched or endorsed by us – treat it as a scam.

Always verify via official @Cortensor channels before interacting with anything on-chain.

#Cortensor #Bardiel #Corgent #ScamAlert #AgenticAI

[Cortensor @cortensor]

🛠️ DevLog – Portal Auth Follow-Up

A quick follow-up on the Portal auth side.

🔹 Current read
The current auth setup is working, so we’ll likely look more closely at the auth separation side later this week rather than treat it as an immediate blocker.

🔹 Current auth direction
For now, the likely direction is to simplify the login surface and reduce spam vectors:
- keep Google
- keep X
- keep Discord

and remove or avoid:
- wallet login
- Coinbase / Base / MetaMask login paths
- custom email sign-up flow

🔹 Why this matters
Wallet login is useful in some contexts, but for Portal it is also a much easier spam/bot vector since users can create many wallet addresses quickly even if we add rate limits.

So the cleaner near-term path is to lean on more identity-tied login methods first.

🔹 Current preference
The strongest default here is still Google login, since it gives a cleaner mainstream path and comes with better built-in anti-spam / anti-bot friction than a near-anonymous wallet path.

🔹 Current takeaway
So the likely near-term Portal auth shape is:
- Google / X / Discord
- no wallet login for now
- no custom email sign-up for now
- auth-env separation checked a bit later this week

#Cortensor #DevLog #Portal #Auth #UIUX

[Cortensor @cortensor]

🛠️ DevLog – Portal UI Dark Mode Is Now Live on Account Areas

A quick Portal V1 UI/UX follow-up.

🔹 Current update
Dark mode has now been added across the main user account areas in Portal and pushed to both environments:
- dev0
- prod

🔹 Where this applies
This covers the core account-facing Portal surfaces such as:
- usage
- API keys
- billing
- profile
- related account views

🔹 Why this matters
This is mostly a UI/UX refinement, but it helps make the Portal feel cleaner and more comfortable for longer use, especially as more of the product surface becomes active and people spend more time inside the dashboard.

🔹 Current direction
So this is part of the broader Portal polish path:
- cleaner account experience
- better visual consistency
- more complete light/dark support across the main user-facing surfaces

We’ll keep iterating further from here.

#Cortensor #DevLog #Portal #UIUX #ProductDesign

[Cortensor @cortensor]

🛠️ DevLog – Portal UI Dark Mode Is Now Live on Account Areas

A quick Portal V1 UI/UX follow-up.

🔹 Current update
Dark mode has now been added across the main user account areas in Portal and pushed to both environments:
- dev0
- prod

🔹 Where this applies
This covers the core account-facing Portal surfaces such as:
- usage
- API keys
- billing
- profile
- related account views

🔹 Why this matters
This is mostly a UI/UX refinement, but it helps make the Portal feel cleaner and more comfortable for longer use, especially as more of the product surface becomes active and people spend more time inside the dashboard.

🔹 Current direction
So this is part of the broader Portal polish path:
- cleaner account experience
- better visual consistency
- more complete light/dark support across the main user-facing surfaces

We’ll keep iterating further from here.

#Cortensor #DevLog #Portal #UIUX #ProductDesign

[Cortensor @cortensor]

🛠️ DevLog – Remaining Focus for the Rest of This Week

For the rest of this week, the main focus is on 2 areas:

🔹 Portal + API Gateway MVP hardening
We made a lot of smaller but important improvements recently around the Portal/API Gateway path, including:
- cleaner API key lifecycle through the gateway
- safer key creation / revoke behavior
- stronger request logging and usage visibility
- better quota counting and future-proofed usage summaries
- cleaner separation between real usage and quota-limited attempts
- sliding-window quota working better, with fixed-window readiness added for later tests

From here, we’ll keep running more tests on the sliding-window path first, then move into fixed-window tests after that.

🔹 Mainnet Lite baseline setup
The node/infra instances are now there, but the Mainnet Lite baseline path is still not fully ready for broader testing yet.

So over the next few days, we’ll keep working on:
- setup/configuration
- oracle / indexer / dashboard-related readiness
- dedicated + ephemeral baseline checks
- getting the environment into a better state for actual baseline tests

🔹 Current takeaway
So the rest of this week is mostly:
- more Portal/API Gateway hardening and quota/rate-limit tests
- more Mainnet Lite setup until the baseline path is ready enough for fuller testing

#Cortensor #DevLog #Portal #Gateway #MainnetLite #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Portal Operations + Admin Functionality Is Taking Shape

A quick follow-up on the Portal side around operations and admin functionality.

🔹 Current ops direction
We’ve started shaping a more useful operational/admin surface so we can view the Portal more clearly from the backend side:
- environment health
- request traffic
- user/account visibility
- basic operational status across dev0 and prod

🔹 Auth note
As mentioned earlier, auth is still shared between dev0 and prod for now.

Because wallet login is closer to near-anonymous access and can make spam easier, we’ll likely disable wallet login and keep Google / social login paths first. Then, sometime next week, we’ll work toward isolating auth by environment more cleanly.

🔹 Admin functionality next
We’ll also start adding more admin-side functionality, such as:
- resetting quota
- basic user/account operational actions
- cleaner controls for managing Portal-side state

🔹 Why this matters
As the Portal path gets more real, it is not enough for the user-facing flow to work. We also need stronger operational visibility and basic admin controls so the system is easier to run and support in practice.

#Cortensor #DevLog #Portal #Admin #Observability #API

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Portal Testing, Mainnet Lite Baseline & PyClaw Dev Path

This week continues Phase #4 execution, with Portal V1 moving into deeper quota/rate-limit testing, Mainnet Lite expanding baseline node tests, and PyClaw continuing toward public dev iteration.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Portal V1, Mainnet Lite, and related Phase #4 workstreams keep moving forward.

🔹 Portal V1 – API Gateway Stress + Quota Testing
- Run simple stress tests on the Portal API Gateway and continue quota/rate-limit validation.
- Compare current sliding-window behavior vs fixed-window quota/rate-limit options.

🔹 Portal V1 – Model Pool + Flow Testing
- Configure different model pools and test how requests route through each pool.
- Run flow tests across auth, API keys, gateway, router pool, quota checks, and usage logging.

🔹 Mainnet Lite – Ephemeral + Dedicated Node Baseline
- Set up at least one ephemeral node and one dedicated node for Mainnet Lite baseline testing.
- Use them to continue validating basic routing, session, oracle/indexer, and dashboard behavior.

🔹 Testnet RPC Migration – Internal Infrastructure
- Begin switching Testnet-0 and Testnet-1a over to Cortensor-managed RPC infrastructure.
- Goal is to reduce external dependencies and gain better control over reliability, monitoring, and costs.

🔹 Payment Staking – Regression & Hardening Tests
- Continue the postponed regression pass on Payment Staking after the recent security hardening rollout.
- Goal is to confirm no flow regressions across staking, usage, and related payment paths.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw dev-path iteration across workflow, side packages, tools, and repo structure.
- Additional side packages were released over the weekend, helping define the open-source development flow.

This week is about pushing Portal V1 from baseline into real usage testing, expanding Mainnet Lite node coverage, migrating testnets to internal RPC infrastructure, and continuing PyClaw’s public development path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🛠️ DevLog – Remaining Focus for the Rest of This Week

For the rest of this week, the main focus is on 2 areas:

🔹 Portal + API Gateway MVP hardening
We made a lot of smaller but important improvements recently around the Portal/API Gateway path, including:
- cleaner API key lifecycle through the gateway
- safer key creation / revoke behavior
- stronger request logging and usage visibility
- better quota counting and future-proofed usage summaries
- cleaner separation between real usage and quota-limited attempts
- sliding-window quota working better, with fixed-window readiness added for later tests

From here, we’ll keep running more tests on the sliding-window path first, then move into fixed-window tests after that.

🔹 Mainnet Lite baseline setup
The node/infra instances are now there, but the Mainnet Lite baseline path is still not fully ready for broader testing yet.

So over the next few days, we’ll keep working on:
- setup/configuration
- oracle / indexer / dashboard-related readiness
- dedicated + ephemeral baseline checks
- getting the environment into a better state for actual baseline tests

🔹 Current takeaway
So the rest of this week is mostly:
- more Portal/API Gateway hardening and quota/rate-limit tests
- more Mainnet Lite setup until the baseline path is ready enough for fuller testing

#Cortensor #DevLog #Portal #Gateway #MainnetLite #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Portal API Gateway Got More Future-Proof Today

A quick follow-up on some Portal/API Gateway improvements we made today.

🔹 What improved
We tightened a few important areas around:
- usage counting
- quota handling
- request logging
- future-proofing for higher traffic

🔹 Quota vs real failures
Quota-limited requests are now treated more cleanly:
- 429 quota hits still show up in request logs
- but they do not count toward actual session/weekly usage

That gives us a cleaner separation between:
- real request usage
- quota-limited attempts
- actual gateway/model failures

🔹 Usage counting is more accurate
We also fixed the usage-counting path so weekly/session totals do not get stuck around partial or paginated totals.

The gateway can now rely on database-side aggregate support for usage summaries, with older fallback behavior still kept in place if needed.

🔹 Sliding / fixed window readiness
We also added readiness for both:
- sliding windows
- fixed windows

Sliding remains the default for now, but the quota path is now shaped so we can test fixed-window variants later more easily.

🔹 Better quota error detail
Quota 429 responses now include more useful state:
- session and weekly usage
- limits
- exceeded flags
- window mode
- recovery timing

That should make it easier for the Portal to explain what is happening instead of just saying “rate limited.”

🔹 Why this matters
So today’s work was less about adding a new visible feature and more about making the Portal/API Gateway path:
- more correct
- easier to reason about
- easier to debug
- better prepared for future traffic and quota-model changes

We’ll keep iterating from here.

#Cortensor #DevLog #Portal #Gateway #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Portal API Gateway Got More Future-Proof Today

A quick follow-up on some Portal/API Gateway improvements we made today.

🔹 What improved
We tightened a few important areas around:
- usage counting
- quota handling
- request logging
- future-proofing for higher traffic

🔹 Quota vs real failures
Quota-limited requests are now treated more cleanly:
- 429 quota hits still show up in request logs
- but they do not count toward actual session/weekly usage

That gives us a cleaner separation between:
- real request usage
- quota-limited attempts
- actual gateway/model failures

🔹 Usage counting is more accurate
We also fixed the usage-counting path so weekly/session totals do not get stuck around partial or paginated totals.

The gateway can now rely on database-side aggregate support for usage summaries, with older fallback behavior still kept in place if needed.

🔹 Sliding / fixed window readiness
We also added readiness for both:
- sliding windows
- fixed windows

Sliding remains the default for now, but the quota path is now shaped so we can test fixed-window variants later more easily.

🔹 Better quota error detail
Quota 429 responses now include more useful state:
- session and weekly usage
- limits
- exceeded flags
- window mode
- recovery timing

That should make it easier for the Portal to explain what is happening instead of just saying “rate limited.”

🔹 Why this matters
So today’s work was less about adding a new visible feature and more about making the Portal/API Gateway path:
- more correct
- easier to reason about
- easier to debug
- better prepared for future traffic and quota-model changes

We’ll keep iterating from here.

#Cortensor #DevLog #Portal #Gateway #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – A Small Future-Proofing Improvement Area on Portal Usage Counting

A quick note on one area we already understand for future improvement on the Portal quota / usage side.

🔹 Current state
The latest fix works for the current traffic shape, especially around the free-plan path and today’s general usage level.

🔹 Where the future gap is
Right now, the usage scan still has a practical cap and can get heavier as traffic grows:
- high-volume users could eventually hit the scan ceiling
- session / weekly checks become more expensive as more usage events accumulate

🔹 Why this matters
So this is not a current blocker, but it is a clear future-proofing area:
- today’s row/page scanning is okay for current traffic
- later, higher-volume usage will want something more exact and more efficient

🔹 Likely future direction
The cleaner long-term path is moving more of this into:
- database-side exact counts / aggregates
- RPC-style count queries
- or cached counters where it makes sense

🔹 Current takeaway
So the current fix is good enough for now, but we already know where the next scaling improvement should go once Portal traffic gets meaningfully higher.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Mainnet Lite Baseline: More Node / Infra Testing Next

A quick follow-up on one of this week’s focus items around the Mainnet Lite baseline.

🔹 Current progress
A few node instances are now ready for the next round of baseline testing, including the setup path for:
- ephemeral nodes
- dedicated nodes

🔹 What this means
The next step is to use these setups to keep testing the core Mainnet Lite baseline around:
- routing
- sessions
- oracle / indexer behavior
- dashboard visibility
- overall infra readiness

🔹 RPC / infra context
We already tested the newer testnet L2 / L3 RPC infra path and it looks good so far. Now the focus shifts more toward testing the mainnet L2 RPC infra further using these node setups.

🔹 Current direction
So this is mainly about continuing the Mainnet Lite baseline checks:
- a few instances are ready
- setup is continuing
- more node/infra tests come next on top of those nodes

#Cortensor #DevLog #MainnetLite #L2 #Infra #DedicatedNodes

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Portal Testing, Mainnet Lite Baseline & PyClaw Dev Path

This week continues Phase #4 execution, with Portal V1 moving into deeper quota/rate-limit testing, Mainnet Lite expanding baseline node tests, and PyClaw continuing toward public dev iteration.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Portal V1, Mainnet Lite, and related Phase #4 workstreams keep moving forward.

🔹 Portal V1 – API Gateway Stress + Quota Testing
- Run simple stress tests on the Portal API Gateway and continue quota/rate-limit validation.
- Compare current sliding-window behavior vs fixed-window quota/rate-limit options.

🔹 Portal V1 – Model Pool + Flow Testing
- Configure different model pools and test how requests route through each pool.
- Run flow tests across auth, API keys, gateway, router pool, quota checks, and usage logging.

🔹 Mainnet Lite – Ephemeral + Dedicated Node Baseline
- Set up at least one ephemeral node and one dedicated node for Mainnet Lite baseline testing.
- Use them to continue validating basic routing, session, oracle/indexer, and dashboard behavior.

🔹 Testnet RPC Migration – Internal Infrastructure
- Begin switching Testnet-0 and Testnet-1a over to Cortensor-managed RPC infrastructure.
- Goal is to reduce external dependencies and gain better control over reliability, monitoring, and costs.

🔹 Payment Staking – Regression & Hardening Tests
- Continue the postponed regression pass on Payment Staking after the recent security hardening rollout.
- Goal is to confirm no flow regressions across staking, usage, and related payment paths.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw dev-path iteration across workflow, side packages, tools, and repo structure.
- Additional side packages were released over the weekend, helping define the open-source development flow.

This week is about pushing Portal V1 from baseline into real usage testing, expanding Mainnet Lite node coverage, migrating testnets to internal RPC infrastructure, and continuing PyClaw’s public development path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🛠️ DevLog – A Small Future-Proofing Improvement Area on Portal Usage Counting

A quick note on one area we already understand for future improvement on the Portal quota / usage side.

🔹 Current state
The latest fix works for the current traffic shape, especially around the free-plan path and today’s general usage level.

🔹 Where the future gap is
Right now, the usage scan still has a practical cap and can get heavier as traffic grows:
- high-volume users could eventually hit the scan ceiling
- session / weekly checks become more expensive as more usage events accumulate

🔹 Why this matters
So this is not a current blocker, but it is a clear future-proofing area:
- today’s row/page scanning is okay for current traffic
- later, higher-volume usage will want something more exact and more efficient

🔹 Likely future direction
The cleaner long-term path is moving more of this into:
- database-side exact counts / aggregates
- RPC-style count queries
- or cached counters where it makes sense

🔹 Current takeaway
So the current fix is good enough for now, but we already know where the next scaling improvement should go once Portal traffic gets meaningfully higher.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Weekly Quota Counting Issue Is Fixed

A quick follow-up on the recent Portal quota investigation.

🔹 What was happening
The weekly usage counter could appear stuck below the actual quota limit because the Portal API Gateway was only reading the first page of usage events from the database.

So once an account had more than 1,000 recent events, the weekly usage view could undercount the real rolling-window total.

🔹 What changed
The gateway now paginates through the usage ledger when calculating:
- session quota windows
- weekly quota windows

So the Portal usage page should now reflect the full rolling/sliding window more correctly.

🔹 Behavior clarification
We also clarified how usage is counted:
- successful requests count toward usage
- non-quota gateway failures also count toward usage
- quota-denied requests are tracked separately as quota-limited activity

🔹 Current direction
Sliding / rolling windows still remain the default behavior for now.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Weekly Quota Counting Issue Is Fixed

A quick follow-up on the recent Portal quota investigation.

🔹 What was happening
The weekly usage counter could appear stuck below the actual quota limit because the Portal API Gateway was only reading the first page of usage events from the database.

So once an account had more than 1,000 recent events, the weekly usage view could undercount the real rolling-window total.

🔹 What changed
The gateway now paginates through the usage ledger when calculating:
- session quota windows
- weekly quota windows

So the Portal usage page should now reflect the full rolling/sliding window more correctly.

🔹 Behavior clarification
We also clarified how usage is counted:
- successful requests count toward usage
- non-quota gateway failures also count toward usage
- quota-denied requests are tracked separately as quota-limited activity

🔹 Current direction
Sliding / rolling windows still remain the default behavior for now.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Weekly Quota Path Still Being Investigated

A quick follow-up on the current Portal quota tests.

🔹 Current status
We’re still testing the quota path, and so far the shorter / hourly sliding-window behavior looks to be working fine.

🔹 Current issue
We did find a bug around the weekly quota side, though.

Right now, the weekly path appears to get stuck around ~95%, so that part is still under investigation.

🔹 What this means
So at the moment:
- shorter sliding-window quota behavior looks okay
- weekly quota behavior still has a bug
- the weekly path is still a WIP until we understand what is causing it

🔹 Current direction
We’re continuing to investigate this now and will keep testing once the weekly-quota issue is understood and patched.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Weekly Quota Path Still Being Investigated

A quick follow-up on the current Portal quota tests.

🔹 Current status
We’re still testing the quota path, and so far the shorter / hourly sliding-window behavior looks to be working fine.

🔹 Current issue
We did find a bug around the weekly quota side, though.

Right now, the weekly path appears to get stuck around ~95%, so that part is still under investigation.

🔹 What this means
So at the moment:
- shorter sliding-window quota behavior looks okay
- weekly quota behavior still has a bug
- the weekly path is still a WIP until we understand what is causing it

🔹 Current direction
We’re continuing to investigate this now and will keep testing once the weekly-quota issue is understood and patched.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Continuing Portal Quota Tests on Weekly Limits + Sliding Windows

We’re continuing the Portal quota / rate-limit tests, with more focus now on the weekly limit path and how the current sliding window behavior holds up over time.

🔹 Current focus
Right now, the main thing we’re checking is:
- weekly quota behavior
- rolling/sliding window behavior
- how usage/UI/admin views stay in sync as limits get closer
- how the Gateway responds once the quota boundary is reached

🔹 Why this matters
The shorter/session-side checks already look much better now, so the next useful step is making sure the longer weekly path behaves cleanly too, especially under continued usage over time.

🔹 What’s next
After this round, we’ll also test the fixed-window version so we can compare:
- smoother rolling/sliding behavior
vs
- clearer fixed reset behavior

🔹 Current takeaway
So for now, the Portal is still on the sliding-window path, and we’re continuing to test that more deeply before moving into fixed-window comparisons next.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Testnet0 and Testnet1a Are Now Using Cortensor Internal RPC Infra

A quick infra follow-up.

We’ve now switched testnet0 and testnet1a over to the latest internal RPC infrastructure backed by community RPC nodes.

🔹 What changed
For now, both testnet environments are using the Cortensor-side internal RPC path instead of relying on the previous external/default setup.

🔹 Why this matters
This gives us a better way to:
- control and monitor the RPC path ourselves
- reduce dependency on outside RPC behavior
- test the stack against the same infra style we want to rely on longer term

🔹 Broader direction
This is also important because the same internal RPC approach is what we plan to use for:
- Mainnet Lite
- Mainnet Full

So this is not just a testnet cleanup item — it is part of aligning the environments more closely with the infra direction we want going forward.

🔹 Current status
The switch is now in place, and we’ll keep monitoring how it behaves from here.

#Cortensor #DevLog #RPC #Testnet #Infra

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Portal Testing, Mainnet Lite Baseline & PyClaw Dev Path

This week continues Phase #4 execution, with Portal V1 moving into deeper quota/rate-limit testing, Mainnet Lite expanding baseline node tests, and PyClaw continuing toward public dev iteration.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Portal V1, Mainnet Lite, and related Phase #4 workstreams keep moving forward.

🔹 Portal V1 – API Gateway Stress + Quota Testing
- Run simple stress tests on the Portal API Gateway and continue quota/rate-limit validation.
- Compare current sliding-window behavior vs fixed-window quota/rate-limit options.

🔹 Portal V1 – Model Pool + Flow Testing
- Configure different model pools and test how requests route through each pool.
- Run flow tests across auth, API keys, gateway, router pool, quota checks, and usage logging.

🔹 Mainnet Lite – Ephemeral + Dedicated Node Baseline
- Set up at least one ephemeral node and one dedicated node for Mainnet Lite baseline testing.
- Use them to continue validating basic routing, session, oracle/indexer, and dashboard behavior.

🔹 Testnet RPC Migration – Internal Infrastructure
- Begin switching Testnet-0 and Testnet-1a over to Cortensor-managed RPC infrastructure.
- Goal is to reduce external dependencies and gain better control over reliability, monitoring, and costs.

🔹 Payment Staking – Regression & Hardening Tests
- Continue the postponed regression pass on Payment Staking after the recent security hardening rollout.
- Goal is to confirm no flow regressions across staking, usage, and related payment paths.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw dev-path iteration across workflow, side packages, tools, and repo structure.
- Additional side packages were released over the weekend, helping define the open-source development flow.

This week is about pushing Portal V1 from baseline into real usage testing, expanding Mainnet Lite node coverage, migrating testnets to internal RPC infrastructure, and continuing PyClaw’s public development path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🛠️ DevLog – Continuing Portal Quota Tests on Weekly Limits + Sliding Windows

We’re continuing the Portal quota / rate-limit tests, with more focus now on the weekly limit path and how the current sliding window behavior holds up over time.

🔹 Current focus
Right now, the main thing we’re checking is:
- weekly quota behavior
- rolling/sliding window behavior
- how usage/UI/admin views stay in sync as limits get closer
- how the Gateway responds once the quota boundary is reached

🔹 Why this matters
The shorter/session-side checks already look much better now, so the next useful step is making sure the longer weekly path behaves cleanly too, especially under continued usage over time.

🔹 What’s next
After this round, we’ll also test the fixed-window version so we can compare:
- smoother rolling/sliding behavior
vs
- clearer fixed reset behavior

🔹 Current takeaway
So for now, the Portal is still on the sliding-window path, and we’re continuing to test that more deeply before moving into fixed-window comparisons next.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Portal Testing, Mainnet Lite Baseline & PyClaw Dev Path

This week continues Phase #4 execution, with Portal V1 moving into deeper quota/rate-limit testing, Mainnet Lite expanding baseline node tests, and PyClaw continuing toward public dev iteration.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Portal V1, Mainnet Lite, and related Phase #4 workstreams keep moving forward.

🔹 Portal V1 – API Gateway Stress + Quota Testing
- Run simple stress tests on the Portal API Gateway and continue quota/rate-limit validation.
- Compare current sliding-window behavior vs fixed-window quota/rate-limit options.

🔹 Portal V1 – Model Pool + Flow Testing
- Configure different model pools and test how requests route through each pool.
- Run flow tests across auth, API keys, gateway, router pool, quota checks, and usage logging.

🔹 Mainnet Lite – Ephemeral + Dedicated Node Baseline
- Set up at least one ephemeral node and one dedicated node for Mainnet Lite baseline testing.
- Use them to continue validating basic routing, session, oracle/indexer, and dashboard behavior.

🔹 Testnet RPC Migration – Internal Infrastructure
- Begin switching Testnet-0 and Testnet-1a over to Cortensor-managed RPC infrastructure.
- Goal is to reduce external dependencies and gain better control over reliability, monitoring, and costs.

🔹 Payment Staking – Regression & Hardening Tests
- Continue the postponed regression pass on Payment Staking after the recent security hardening rollout.
- Goal is to confirm no flow regressions across staking, usage, and related payment paths.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw dev-path iteration across workflow, side packages, tools, and repo structure.
- Additional side packages were released over the weekend, helping define the open-source development flow.

This week is about pushing Portal V1 from baseline into real usage testing, expanding Mainnet Lite node coverage, migrating testnets to internal RPC infrastructure, and continuing PyClaw’s public development path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🔎 Recap: How Portal and PyClaw Fit Together

A quick recap on the relationship between Cortensor Portal and PyClaw.

🔹 What Portal is
At the simplest level, Portal is one of the main infrastructure/product access surfaces for Cortensor.

It gives a cleaner way to access the network through things like:
- hosted API access
- API keys
- usage visibility
- managed router pools
- simpler developer-facing entry points

So Portal is the layer that helps turn raw Cortensor infra into something easier to consume as a product.

🔹 What PyClaw is
PyClaw is one of the products/app layers that can sit on top of that infrastructure.

In other words:
- Portal = the access / infra surface
- PyClaw = one of the consumers of that surface

PyClaw can use the same underlying Cortensor capabilities around:
- inference
- routing
- agent workflows
- validation
- execution primitives

without needing every user to think about the lower-level infra directly.

🔹 Why this matters
This relationship is important because it shows how Cortensor can support its own product ecosystem.

If Portal becomes the cleaner entry point into the network, then products like PyClaw can focus more on:
- user workflow
- agent behavior
- product experience
- actual use cases

instead of rebuilding all the infra access paths themselves.

🔹 Why PyClaw success helps Cortensor
If PyClaw succeeds or drives more usage, that indirectly benefits the Cortensor Network through Portal.

Why:
- more PyClaw usage means more consumption of Cortensor-backed infra
- more usage through Portal helps validate the hosted product path
- more real product demand helps stress and improve the network
- more external/product activity can translate into more useful demand for Cortensor capacity underneath

So even if PyClaw is “just one product,” it can still help strengthen the broader Cortensor ecosystem by driving actual usage into the underlying infra.

🔹 Current takeaway
So the simple framing is:

- Cortensor Network = the underlying infra and execution layer
- Portal = the infrastructure / product-access surface
- PyClaw = one of the products that can consume that surface

That is why Portal and PyClaw are connected: one makes access easier, the other can turn that access into real usage.

#Cortensor #Portal #PyClaw #AIInfra #AgenticAI

[Cortensor @cortensor]

🔎 Recap: What Cortensor Portal Is and Why It Matters

At the simplest level, Cortensor Portal is the hosted product layer for using Cortensor more easily.

Instead of asking users to deal with raw infrastructure directly, Portal is meant to give a cleaner surface where someone can:
- sign in
- create and manage API keys
- view usage and limits
- call hosted inference through a stable API
- use curated model access in a more productized way

So from the outside, Portal means:
less infra friction, more direct product access.

That matters because not everyone wants to run router nodes, manage sessions, or think about backend topology just to use Cortensor.

What Portal can do
Portal is meant to make Cortensor easier to use for:
- developers who want hosted inference quickly
- teams that want API-key-based access
- apps that want stable model aliases and cleaner request flows
- users who want usage visibility and simpler account management

### What Portal can enable over time
Portal can also become the entry point for broader product experiences on top of the network:
- richer hosted inference plans
- better usage and request visibility
- more managed model/routing options
- smoother onboarding for external developers
- product layers that sit on top of Cortensor without exposing all of the raw infra underneath

Why this is important for Cortensor
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
- it makes integration easier for outside developers and teams
- it gives Cortensor a clearer product surface people can adopt faster
- it helps translate network capability into real usage and distribution

So the main idea is simple:

Cortensor Portal is how Cortensor becomes easier to consume as a product, not just as infrastructure.

#Cortensor #Portal #API #AIInfra

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Portal Testing, Mainnet Lite Baseline & PyClaw Dev Path

This week continues Phase #4 execution, with Portal V1 moving into deeper quota/rate-limit testing, Mainnet Lite expanding baseline node tests, and PyClaw continuing toward public dev iteration.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Portal V1, Mainnet Lite, and related Phase #4 workstreams keep moving forward.

🔹 Portal V1 – API Gateway Stress + Quota Testing
- Run simple stress tests on the Portal API Gateway and continue quota/rate-limit validation.
- Compare current sliding-window behavior vs fixed-window quota/rate-limit options.

🔹 Portal V1 – Model Pool + Flow Testing
- Configure different model pools and test how requests route through each pool.
- Run flow tests across auth, API keys, gateway, router pool, quota checks, and usage logging.

🔹 Mainnet Lite – Ephemeral + Dedicated Node Baseline
- Set up at least one ephemeral node and one dedicated node for Mainnet Lite baseline testing.
- Use them to continue validating basic routing, session, oracle/indexer, and dashboard behavior.

🔹 Testnet RPC Migration – Internal Infrastructure
- Begin switching Testnet-0 and Testnet-1a over to Cortensor-managed RPC infrastructure.
- Goal is to reduce external dependencies and gain better control over reliability, monitoring, and costs.

🔹 Payment Staking – Regression & Hardening Tests
- Continue the postponed regression pass on Payment Staking after the recent security hardening rollout.
- Goal is to confirm no flow regressions across staking, usage, and related payment paths.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw dev-path iteration across workflow, side packages, tools, and repo structure.
- Additional side packages were released over the weekend, helping define the open-source development flow.

This week is about pushing Portal V1 from baseline into real usage testing, expanding Mainnet Lite node coverage, migrating testnets to internal RPC infrastructure, and continuing PyClaw’s public development path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🗓️ Weekly Recap – Phase #4 Portal Progress, Mainnet Lite E2E & PyClaw Iteration

This week focused heavily on Portal V1, while continuing Mainnet Lite preparation, Payment Staking validation, and PyClaw development work.

🔹 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 work moved deeper into implementation.

🔹 Portal V1 – Auth / API / Logging Progress
- Portal request visibility, API-key flow, usage tracking, and request-log surfaces received multiple rounds of refinement.
- Data consistency across web app ↔ Supabase ↔ Unkey improved significantly, making the hosted flow feel much closer to a real product.

🔹 Portal V1 – Gateway & Router Pool Progress
- Gateway → router-pool integration moved from planning into actual implementation and testing.
- API-key issuance/consumption, request tracking, and backend execution paths were proven in rough form.

🔹 Portal V1 – Infra & Environment Setup
- Baseline Portal infrastructure is now established with separate dev and prod environments.
- Current focus is hardening Gateway → router-pool behavior and improving operational visibility.

🔹 Mainnet Lite – Dedicated Session E2E
- Mainnet Lite baseline became more concrete with dashboard, indexer, oracle, and supporting infra coming online.
- First rough dedicated-session E2E flow on Arbitrum mainnet baseline was exercised, surfacing the next set of gas, payment, and ops gaps.

🔹 Payment Staking – Regression & Hardening
- Payment Staking security hardening remains deployed on Testnet-0 and Testnet-1a.
- Additional E2E validation was performed to confirm the recent hardening changes did not introduce regressions.

🔹 PyClaw – Dev Path Progress
- Continued PyClaw iteration around workflow, tooling, side libraries, and repository structure.
- Open-source workflow definition is taking shape as we move toward a rough public dev release next month.

A productive Phase #4 week overall - Portal V1 is now moving from concept toward implementation, Mainnet Lite has its first meaningful E2E path, and PyClaw continues progressing toward its initial public development cycle.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🛠️ DevLog – Portal Quota Window Direction: Sliding First, Fixed Later

A quick note on how we’re currently thinking about quota windows in Cortensor Portal.

🔹 Current default
For now, Portal uses sliding quota windows by default.

That means usage is measured over the most recent period of time, not from one fixed calendar reset point.

Examples:
- session quota → measured over the recent session window
- weekly quota → measured over the last 7 days

So capacity returns gradually as older requests fall out of the window.

🔹 Why start with sliding
Sliding windows are a strong default for shared API infrastructure because they are:
- smoother under sustained traffic
- fairer for shared capacity
- better at reducing reset-boundary bursts

So from the infra side, this is the safer starting point for protecting the hosted path.

🔹 What we may test later
Over time, we also want to test fixed quota windows.

That would mean a clearer reset schedule, such as:
- weekly quota resetting at a predictable time
- easier-to-understand reset points for users

🔹 Tradeoff
The tradeoff is fairly simple:

- sliding windows are better for smoother shared-capacity protection
- fixed windows are easier for users to understand

So this is partly an infra choice, but also a product/UX choice.

🔹 Current direction
For now, we’ll keep sliding windows as the main default, while testing fixed-window variants over time to compare clarity, behavior, and user experience.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Portal Observability + Admin Functionality Will Be Another Focus in the Coming Weeks

Another Portal V1 area we’ll spend more time on in the coming weeks is observability and the early admin / operational surface.

🔹 Current direction
The goal here is to improve how we view and reason about the Portal operationally, not just from the user-facing side.

That includes things like:
- request visibility
- environment health/status
- gateway and router-pool visibility
- more operational debugging context
- cleaner admin-side monitoring of what is happening underneath

🔹 Data-model side
Part of this work also means adding more Portal-side data model around:
- observability
- stats
- operational metadata

so the system is not only functioning, but also easier to inspect and operate.

🔹 Why this matters
As the Portal path becomes more real, it is not enough for requests to simply go through. We also need better ways to understand:
- what is healthy
- what is failing
- what changed
- where requests went
- what the current environment is actually doing

🔹 Current takeaway
So over the coming weeks, part of the Portal work will also go into making the system easier to observe, debug, and operate from the admin/ops side.

#Cortensor #DevLog #Portal #Observability #Admin #API

[Cortensor @cortensor]

🛠️ DevLog – Portal Visibility Around Hosted Requests Has Improved

We improved Cortensor Portal’s visibility into hosted model requests.

🔹 What improved
The Usage page now gives a clearer view of request activity, including:
- total weekly requests
- completed and failed calls
- latency
- pagination
- request details

Each request can now surface more useful context as well, such as:
- which model was used
- whether it succeeded
- timing information
- routing status

🔹 Model availability view
We also updated the model-availability display so users can see that oss-20b is currently live, while other supported models are shown as waiting for capacity.

🔹 Operator-side visibility
On the admin/ops side, the monitoring view is also stronger now across:
- gateway health
- request traffic
- model routing
- errors
- user activity

That makes it easier to understand what happened during a request and respond faster when something needs attention.

🔹 Behind the scenes
We also added better tracking underneath so future requests can be audited more reliably without changing the user-facing API flow.

#Cortensor #DevLog #Portal #API #Observability

[Cortensor @cortensor]

🛠️ DevLog – Portal Observability + Admin Functionality Will Be Another Focus in the Coming Weeks

Another Portal V1 area we’ll spend more time on in the coming weeks is observability and the early admin / operational surface.

🔹 Current direction
The goal here is to improve how we view and reason about the Portal operationally, not just from the user-facing side.

That includes things like:
- request visibility
- environment health/status
- gateway and router-pool visibility
- more operational debugging context
- cleaner admin-side monitoring of what is happening underneath

🔹 Data-model side
Part of this work also means adding more Portal-side data model around:
- observability
- stats
- operational metadata

so the system is not only functioning, but also easier to inspect and operate.

🔹 Why this matters
As the Portal path becomes more real, it is not enough for requests to simply go through. We also need better ways to understand:
- what is healthy
- what is failing
- what changed
- where requests went
- what the current environment is actually doing

🔹 Current takeaway
So over the coming weeks, part of the Portal work will also go into making the system easier to observe, debug, and operate from the admin/ops side.

#Cortensor #DevLog #Portal #Observability #Admin #API

[Cortensor @cortensor]

🛠️ DevLog – Portal Observability + Admin Functionality Will Be Another Focus in the Coming Weeks

Another Portal V1 area we’ll spend more time on in the coming weeks is observability and the early admin / operational surface.

🔹 Current direction
The goal here is to improve how we view and reason about the Portal operationally, not just from the user-facing side.

That includes things like:
- request visibility
- environment health/status
- gateway and router-pool visibility
- more operational debugging context
- cleaner admin-side monitoring of what is happening underneath

🔹 Data-model side
Part of this work also means adding more Portal-side data model around:
- observability
- stats
- operational metadata

so the system is not only functioning, but also easier to inspect and operate.

🔹 Why this matters
As the Portal path becomes more real, it is not enough for requests to simply go through. We also need better ways to understand:
- what is healthy
- what is failing
- what changed
- where requests went
- what the current environment is actually doing

🔹 Current takeaway
So over the coming weeks, part of the Portal work will also go into making the system easier to observe, debug, and operate from the admin/ops side.

#Cortensor #DevLog #Portal #Observability #Admin #API

[Cortensor @cortensor]

🛠️ DevLog – Follow-Up on Portal Quota / Rate-Limit Testing

A quick follow-up on the Portal side.

🔹 Current read
So far, the quota / rate-limit path seems to be working as expected in the current Portal flow.

🔹 What’s next
From here, we’ll keep running more tests, especially around the weekly limit path, to make sure:
- usage keeps rolling up correctly
- reset timing behaves properly
- the Portal UI stays in sync
- nothing breaks as the counters move higher

🔹 Why this matters
The session/window limit path already looks better now, so the next useful check is making sure the broader weekly usage path also holds up cleanly under continued usage.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Follow-Up on Portal Quota / Rate-Limit Testing

A quick follow-up on the Portal side.

🔹 Current read
So far, the quota / rate-limit path seems to be working as expected in the current Portal flow.

🔹 What’s next
From here, we’ll keep running more tests, especially around the weekly limit path, to make sure:
- usage keeps rolling up correctly
- reset timing behaves properly
- the Portal UI stays in sync
- nothing breaks as the counters move higher

🔹 Why this matters
The session/window limit path already looks better now, so the next useful check is making sure the broader weekly usage path also holds up cleanly under continued usage.

#Cortensor #DevLog #Portal #API #RateLimit

[Cortensor @cortensor]

🛠️ DevLog – Portal Quota / Rate-Limit Checks Look Working in Rough Form

A quick follow-up on the Portal + API Gateway path.

🔹 Current result
From the current tests, the quota / rate-limit path looks to be working in rough form:
- session quota is being enforced
- the API Gateway is returning the expected limit-exceeded behavior
- usage/accounting looks consistent on the Portal side
- the data also matches on the Unkey side

🔹 Why this matters
This is one of the more important checks for the hosted path, because it shows the Portal is not only forwarding requests — it is also applying product-side limits in a way that is actually trackable and consistent.

🔹 Verifiable path
The current behavior is also more verifiable through the underlying network path and node/session activity:
- Explorer: https://t.co/J7xw1vyxGd
- Node level view: https://t.co/RCjDa4hPWb

🔹 Current takeaway
So at least from the current round of testing, the Portal-side quota / rate-limit flow looks to be holding up, with request/accounting state lining up across the main layers underneath.

#Cortensor #DevLog #Portal #Gateway #API #Unkey

[Cortensor @cortensor]

🛠️ DevLog – Portal Quota / Rate-Limit Checks Look Working in Rough Form

A quick follow-up on the Portal + API Gateway path.

🔹 Current result
From the current tests, the quota / rate-limit path looks to be working in rough form:
- session quota is being enforced
- the API Gateway is returning the expected limit-exceeded behavior
- usage/accounting looks consistent on the Portal side
- the data also matches on the Unkey side

🔹 Why this matters
This is one of the more important checks for the hosted path, because it shows the Portal is not only forwarding requests — it is also applying product-side limits in a way that is actually trackable and consistent.

🔹 Verifiable path
The current behavior is also more verifiable through the underlying network path and node/session activity:
- Explorer: https://t.co/J7xw1vyxGd
- Node level view: https://t.co/RCjDa4hPWb

🔹 Current takeaway
So at least from the current round of testing, the Portal-side quota / rate-limit flow looks to be holding up, with request/accounting state lining up across the main layers underneath.

#Cortensor #DevLog #Portal #Gateway #API #Unkey

[Cortensor @cortensor]

🛠️ DevLog – Basic Periodic E2E Checks Are Now Running on the Portal Path

We’ve started running some basic periodic E2E checks on the Portal path.

🔹 What these checks are for
The goal is to keep testing the core path at a simple/regular level:

- API key → API Gateway
- API Gateway → router pool
- router pool → session-backed execution
- request / usage / log visibility back into the Portal

🔹 What we’re seeing so far
At the basic level, the path is behaving as expected:
- requests are going through
- usage counters are updating
- request logs are being populated
- session-backed execution is showing up
- router-pool/session rotation is visible from the request path

🔹 Why this matters
This is not meant to be a heavy stress test yet.

It is more of a basic periodic health/E2E check so we can:
- catch regressions earlier
- confirm the main product path still holds
- surface weak spots before pushing harder on scale/latency work

🔹 Current direction
We’ll keep running these lighter periodic checks while continuing to refine the Portal path underneath.

#Cortensor #DevLog #Portal #Gateway #RouterPool #API

[Cortensor @cortensor]

🗓️ Weekly Recap – Phase #4 Portal Progress, Mainnet Lite E2E & PyClaw Iteration

This week focused heavily on Portal V1, while continuing Mainnet Lite preparation, Payment Staking validation, and PyClaw development work.

🔹 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 work moved deeper into implementation.

🔹 Portal V1 – Auth / API / Logging Progress
- Portal request visibility, API-key flow, usage tracking, and request-log surfaces received multiple rounds of refinement.
- Data consistency across web app ↔ Supabase ↔ Unkey improved significantly, making the hosted flow feel much closer to a real product.

🔹 Portal V1 – Gateway & Router Pool Progress
- Gateway → router-pool integration moved from planning into actual implementation and testing.
- API-key issuance/consumption, request tracking, and backend execution paths were proven in rough form.

🔹 Portal V1 – Infra & Environment Setup
- Baseline Portal infrastructure is now established with separate dev and prod environments.
- Current focus is hardening Gateway → router-pool behavior and improving operational visibility.

🔹 Mainnet Lite – Dedicated Session E2E
- Mainnet Lite baseline became more concrete with dashboard, indexer, oracle, and supporting infra coming online.
- First rough dedicated-session E2E flow on Arbitrum mainnet baseline was exercised, surfacing the next set of gas, payment, and ops gaps.

🔹 Payment Staking – Regression & Hardening
- Payment Staking security hardening remains deployed on Testnet-0 and Testnet-1a.
- Additional E2E validation was performed to confirm the recent hardening changes did not introduce regressions.

🔹 PyClaw – Dev Path Progress
- Continued PyClaw iteration around workflow, tooling, side libraries, and repository structure.
- Open-source workflow definition is taking shape as we move toward a rough public dev release next month.

A productive Phase #4 week overall - Portal V1 is now moving from concept toward implementation, Mainnet Lite has its first meaningful E2E path, and PyClaw continues progressing toward its initial public development cycle.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🗓️ Weekly Focus – Phase #4 Support, Portal V1 Iteration & Mainnet Lite E2E

This week continues Phase #4 execution, with focus on Portal V1 product/API flows, Mainnet Lite dedicated-session testing, Payment Staking regression, and PyClaw’s public dev path.

🔹 Phase #4 – Monitoring, Support & Stats
- Continue monitoring routing, miners, validators, dashboards, indexers, and L3 stats.
- Track stability as Phase #4 workstreams move from baseline setup into deeper testing.

🔹 Portal V1 – Auth / API / Logging Iteration
- Iterate on Portal V1 auth and API-side flows now that baseline infra is set up.
- Focus on access logs, request logs, API usage visibility, and refinement around the product/backend path.

🔹 Portal V1 – Gateway & Router Pool Refinement
- Continue improving the Gateway → router pool flow for managed inference.
- Tighten request routing, access control, and early operational behavior across dev/prod environments.

🔹 Mainnet Lite – Dedicated Session E2E
- Build on last week’s Mainnet Lite baseline infra setup.
- Start setting up and testing an E2E dedicated-session flow across contracts, oracle/indexer, dashboard, and router path.

🔹 Payment Staking – Regression Testing
- Payment Staking security hardening is now rolled out on Testnet-0 and Testnet-1a.
- Run another E2E pass on the Payment Staking flow to confirm no regression after the hardening updates.

🔹 PyClaw – Dev Path Progress
- Continue PyClaw iteration with side libraries/tools and GitHub workflow experiments.
- Target remains a rough initial dev release around mid next month, even if not fully ready, so public iteration can begin.

This week is about moving Phase #4 from baseline setup into practical validation: Portal V1 API/auth/logging, Mainnet Lite E2E, Payment Staking regression, and PyClaw’s open dev path.

#Cortensor #Testnet #Phase4 #AIInfra #DePIN #Portal #PyClaw #MainnetLite #Security #L3

[Cortensor @cortensor]

🛠️ DevLog – Basic Periodic E2E Checks Are Now Running on the Portal Path

We’ve started running some basic periodic E2E checks on the Portal path.

🔹 What these checks are for
The goal is to keep testing the core path at a simple/regular level:

- API key → API Gateway
- API Gateway → router pool
- router pool → session-backed execution
- request / usage / log visibility back into the Portal

🔹 What we’re seeing so far
At the basic level, the path is behaving as expected:
- requests are going through
- usage counters are updating
- request logs are being populated
- session-backed execution is showing up
- router-pool/session rotation is visible from the request path

🔹 Why this matters
This is not meant to be a heavy stress test yet.

It is more of a basic periodic health/E2E check so we can:
- catch regressions earlier
- confirm the main product path still holds
- surface weak spots before pushing harder on scale/latency work

🔹 Current direction
We’ll keep running these lighter periodic checks while continuing to refine the Portal path underneath.

#Cortensor #DevLog #Portal #Gateway #RouterPool #API

[Cortensor @cortensor]

🛠️ DevLog – Router Pool Follow-Up: More Tests Before Broader Expansion

A quick follow-up on the Portal router-pool path.

🔹 Current status
The additional router nodes we added into the router pool are working so far in the current round of testing.

🔹 What’s next
Before we expand further, we want to test this setup a bit more first:
- more checks on the current router-pool behavior
- more confirmation on stability / request flow
- more confidence in how the pool behaves with the current node set

🔹 Why this matters
The goal is to make sure the current expansion is holding up cleanly before we add:
- more models
- different model mixes
- broader permutation tests on top of the pool

🔹 Current direction
So the next step is not immediate expansion everywhere.
It is:
- validate the current larger router-pool setup a bit more
- then expand into more models and permutations after that

#Cortensor #DevLog #Portal #RouterPool #Gateway #API