Cortensor

🧭 Mainnet Full Alpha Is Kicking Off Mainnet Full Alpha marks the next stage of the Cortensor rollout. This is not a one-time launch event. Alpha is the period where Mainnet1, the product layer, and developer-facing tools start being exercised together under more realistic usage before we expand further toward Beta. 🔹 What Alpha is for - controlled access rather than broad public availability - continued validation of Mainnet1, routers, sessions, dedicated nodes, dashboard, indexer, and recovery paths - real product traffic through Portal, Corgent, Bardiel, and PyClaw-related workflows - identifying operational, compatibility, onboarding, model, and capacity gaps through actual use 🔹 Product focus - Portal will continue improving as the simpler hosted API entry point into Cortensor - Corgent / Bardiel will keep iterating on delegation, validation, fact-checking, and the early v4 direction - PyClaw will continue maturing across research, coding, memory, tools, scheduling, delegation, recovery, longer-running projects, packaging, and the early Desktop App - Mainnet Full capacity will gradually expand as we learn where real demand appears 🔹 Developer exposure - Alpha is also preparation for broader builder activity - We expect to prepare more examples, documentation, onboarding, model availability, and product capacity for hackathons and builder programs - Portal and PyClaw should provide two accessible entry points, while Corgent / Bardiel can give agents additional delegation and validation services to build around 🔹 What happens between Alpha and Beta - bring in controlled real usage - expose gaps through actual workloads - fix bugs and compatibility issues - improve onboarding and developer experience - mature PyClaw and the product surfaces - iterate v4 delegation / validation - expand node, model, router, and gateway capacity - run early hackathons / builder programs - use that feedback to prepare for broader Beta access 🔹 What Beta should represent Beta should mean more than simply “more users.” It should mean a stronger network and product baseline that has already gone through real developer usage, more diverse workloads, broader model testing, and another round of operational hardening. Alpha → real usage → iteration → developer exposure → more workloads → stronger products → Beta. Mainnet Full Dashboard: dashboard.cortensor.network Mainnet Full Explorer: explorer.cortensor.network #Cortensor #MainnetFull #Portal #PyClaw #Corgent #Bardiel #AgenticAI

🛠️ DevLog – PyClaw: Focusing on Dependable Work, Not Just More Features As PyClaw continues to mature, the next phase is becoming less about adding every possible feature and more about proving that the runtime can be trusted with real recurring work. We are treating this as a product plan to test over roughly the next 90 days. 🔹 What we want the experience to become - Give PyClaw a real job - Let it work through the task - See what completed and what did not - Get the relevant evidence, files, checks, or results - Recover cleanly if the app closes, connectivity drops, or a model/provider fails - Continue from where the work stopped instead of starting over For the user, the experience should increasingly feel like: give it a job → let it work → see the result → see the proof → continue later if needed 🔹 Days 1–30: Find the workflows people actually trust - Work with a small group of real users / teams - Identify recurring technical workflows they already spend meaningful time on - Measure where PyClaw succeeds, where users intervene, and where trust breaks down - Focus fixes on completion reliability, onboarding, and the most common failure points One example workflow we want to test deeply: issue → investigate → reproduce → prepare fix → validate → present reviewable result 🔹 Days 31–60: Prove recovery and safe execution - Tighten restart / resume behavior - Make interrupted work easier to continue - Improve visibility into what completed, what remains, and why something stopped - Continue strengthening approvals, permissions, evidence, and installed-release behavior - Test the same workflows across different models without changing the underlying user experience 🔹 Days 61–90: Test repeat usage - Package the strongest workflows into simpler repeatable experiences - Improve setup, templates, and guidance around those workflows - Measure whether users actually come back and delegate the same work again - Use those results to decide where deeper product investment and broader distribution make sense 🔹 Reliability before feature count PyClaw already covers a broad surface: - coding and research - tools and integrations - memory - scheduling - delegation - browser workflows - approvals - CLI / SDK / Desktop access But a long feature list is not the goal. The more important question is: Can someone depend on those capabilities repeatedly without constantly supervising the agent? 🔹 Model-independent by design - PyClaw should remain usable across different model providers - Users should be able to choose based on quality, cost, privacy, and task requirements - The runtime should preserve the workflow, permissions, state, and evidence around the model The model is an important component, but the dependable workflow around it is the product. 🔹 What we will watch Over these next development cycles, we want to understand: - which recurring workflows users actually delegate - how often a task reaches an accepted result - how much human intervention is still required - where interruptions or recovery break down - whether users return and use the same workflows again - which improvements actually increase trust rather than simply add capability 🔹 Current takeaway - The next ~90 days are about testing dependability, not chasing feature count - Days 1–30 focus on workflow selection and completion problems - Days 31–60 focus on recovery, safety, and continuity - Days 61–90 focus on repeat usage and product fit The long-term test is simple: Can someone hand PyClaw an important recurring job, trust the result, and come back next week to use it again? #Cortensor #DevLog #PyClaw #AgenticAI #OpenSource #DeveloperTools #AIInfra

🛠️ DevLog – PyClaw: Making Runtime Limits Clearer and Easier to Recover From One area we are tightening next is how PyClaw explains execution limits when a task stops. The goal is simple: users should not have to guess why a workflow stopped or what they can do next. 🔹 Clearer stop reasons - Stop messages will identify the exact limit that was reached - Current usage will be shown alongside that limit - Context, time, tool calls, output length, and delegation limits should be distinguishable from one another 🔹 Better recovery guidance - Interrupted workflows should provide clearer guidance for continuing or resuming unfinished work - The runtime should make it easier to understand whether a task can continue in the same thread, needs another turn, or needs a different execution path 🔹 More accurate context visibility - We are tightening the distinction between total model context capacity and the context actually available to a specific task phase - This should make context-related stops easier to understand and debug 🔹 Provider-specific output handling - Anthropic output-budget handling is being corrected to reduce unexpected truncation - Provider-specific limits need to map cleanly into the runtime rather than appearing as ambiguous task failures 🔹 No blanket limit increases - Current execution budgets are already intentionally generous - The focus is better visibility and recovery, not simply raising every ceiling - Delegation limits will only be adjusted when real stress testing shows that they are genuinely too restrictive 🔹 Why this matters Longer-running agent workflows naturally operate across several different resource boundaries. When one of those boundaries is reached, the runtime should be able to answer two questions clearly: - What stopped the task? - What should happen next? 🔹 Current takeaway - Limits are part of making agent execution bounded and predictable - Better UX means making those boundaries visible rather than hiding them - The next improvements are focused on clearer stop reasons, accurate usage reporting, and more actionable recovery paths #Cortensor #DevLog #PyClaw #AgenticAI #DeveloperTools #AIInfra

🛠️ DevLog – Real Workloads Are Becoming a Capacity Planning Tool As more products, builders, and external workflows begin touching the Cortensor stack, real usage is starting to give us better signals about where capacity may eventually need to grow. That does not mean we are expanding every part of the network immediately. For now, we are still watching the market, usage patterns, and actual demand while continuing to validate the existing infrastructure and product paths. 🔹 Real workloads create better signals - Portal traffic can show which models and API paths are actually being used - PyClaw and external applications create longer and more varied workloads - Hackathon projects expose different combinations of models, tools, sessions, and developer behavior - Corgent / Bardiel workflows can add another layer of delegation and validation demand over time 🔹 Capacity planning should follow usage Instead of scaling every model, node type, or infrastructure component equally, the goal is to increasingly use observed demand to understand: - which models need additional capacity - where node availability needs to grow - which product paths are generating sustained usage - where latency or failure patterns appear - when router, session, or gateway capacity needs expansion 🔹 Market conditions matter too - Infrastructure expansion also has real operational and economic costs - We will continue watching the broader market alongside actual product demand - Capacity decisions can then be made gradually as usage becomes clearer rather than based only on projected demand The longer-term loop is: products → builders → real workloads → usage + market signals → capacity decisions → stronger infrastructure → more product usage 🔹 Where we are today - Mainnet Full already provides a working baseline for product and infrastructure validation - External workloads are starting to provide additional signals - We are still in the observation and validation stage rather than aggressively expanding capacity - As demand develops over time, those signals can increasingly guide where additional nodes, models, and infrastructure are most useful 🔹 Current takeaway - Real workloads are becoming more than a product-testing tool - They can eventually become one of the inputs for network capacity planning - The goal is to expand deliberately based on actual demand, product usage, operational data, and market conditions as the ecosystem develops #Cortensor #DevLog #MainnetFull #Portal #PyClaw #NodeOps #AIInfra

🗓️ Weekly Recap – Mainnet Full Alpha, Hackathon #5 & PyClaw 0.1.x This week kept Mainnet Full Alpha steady while Hackathon #5 accelerated external builder activity and PyClaw continued a fast feedback-driven 0.1.x refinement cycle. 🔹 Mainnet Full – Alpha Progress ‐ Mainnet Full continued moving from infrastructure validation toward connected product and developer workloads across the broader stack. ‐ Builder activity is increasingly providing real signals around reliability, routing, model capacity, onboarding, and developer-experience gaps. 🔹 Hackathon #5 – Growing Builder Activity ‐ Hackathon #5 reached 63 builders and 16 submitted projects, with submissions remaining open through 12/18. ‐ Real projects are actively testing PyClaw, Portal, SDK behavior, models, documentation, onboarding, and developer UX. 🔹 Hackathon #5 – External Feedback Loop ‐ Builder usage increasingly feeds directly into the normal product cycle: workflow → issue/feedback → reproduce → fix → regression → patch → external retest. ‐ External bug reports, fixes, compatibility findings, and PRs are becoming part of the regular development process. 🔹 PyClaw – 0.1.x Reliability ‐ Releases 0.1.11 → 0.1.17 continued tightening long-running projects, deterministic state, failure semantics, memory continuity, scheduling, artifacts, and runtime cleanup. ‐ Focus remains on strengthening the existing 0.1 baseline rather than rapidly expanding the core feature surface. 🔹 PyClaw – Memory, Scheduling & Runtime ‐ Memory work improved around PostgreSQL/SQLite recovery, consolidation, scoped authorization, migration discovery, and safer candidate filtering. ‐ Task/cron/watch workflows, scheduling recovery, telemetry, MCP interoperability, and runtime-resource handling also received deeper regression coverage. 🔹 PyClaw – SDK & Builder Experience ‐ SDK iteration continued around thread/session continuity, typed tool inputs, structured outputs, provider failures, and safer tool boundaries. ‐ Research synthesis, first-turn context, and module-level PostgreSQL isolation are also being tightened for the next release. 🔹 PyClaw – Desktop & Distribution ‐ Desktop entered a clearer tagged-release cycle with 0.0.4 and 0.0.5 while continuing CLI/Focus parity work. ‐ Public CLI, daemon, Desktop, and packaging repos now expose more of the source → binary → manifest → distribution pipeline across macOS, Linux, and Windows. 🔹 Builder → Product → Network Loop ‐ Hackathon usage is turning external development into a practical testing layer rather than a separate community activity. ‐ The broader loop is becoming clearer: network → products → builders → real apps → usage → feedback → stronger products + capacity. A productive week overall - Mainnet Full Alpha stayed healthy, Hackathon #5 grew significantly, and external builders are now becoming a meaningful part of PyClaw’s ongoing quality and release cycle. #Cortensor #MainnetFull #Alpha #PyClaw #Portal #Hackathon #AgenticAI #AIInfra #MCP s

🛠️ DevLog – External Contributions + Hackathons Are Becoming Part of the Development Loop October gave us a clearer signal that open-source contributions and hackathons are starting to work together as a practical product-development loop. 🔹 October community contributions - 10 external contributors - 92 issues raised - 82 pull requests submitted - 62 pull requests merged into dev These contributions include reproductions, bug fixes, documentation improvements, compatibility findings, and other changes that help tighten the runtime and developer experience. 🔹 Hackathons add another source of real usage - Hackathon #5 has grown to 63 builders and 16 submitted projects so far - Builders are using PyClaw, Portal, models, SDKs, and documentation in ways we may not reproduce internally - Those projects create another stream of bugs, edge cases, missing examples, and workflow feedback 🔹 The two loops increasingly connect hackathon / external usage → issue or reproduction → contributor fix / PR → review → regression coverage → merge into dev → patch release → public verification → more external usage 🔹 Why careful review still matters - Contributions are reviewed before merge - Issues may remain open even after a fix lands in dev - We generally wait for the change to reach a published release and be verified there before treating the issue as fully closed That keeps the process focused on shipped behavior rather than just merged code. 🔹 Why this matters - Open source gives developers a direct path to improve what they are using - Hackathons give us more real workloads and more external perspectives - Together, they help turn community activity into concrete product iteration rather than separate ecosystem programs 🔹 Current takeaway - October showed meaningful external participation across both development and building - The important signal is not only the number of issues, PRs, builders, or submissions - It is that those activities are increasingly feeding into the same repeatable development cycle More external usage → more feedback → more fixes → stronger releases → better builder experience. #Cortensor #DevLog #PyClaw #Hackathon #OpenSource #DeveloperTools #AgenticAI

🛠️ DevLog – From Infrastructure Validation to Real Product Workloads Early network development naturally focused on infrastructure validation: Can the chain run? Can nodes participate? Can routers and sessions execute tasks? Can the dashboard and indexer observe the network? Can the system recover when infrastructure fails? Those checks still matter, but Mainnet Full Alpha is increasingly adding another validation layer: real product workloads. 🔹 Infrastructure validation remains the foundation - Mainnet Full / L3 operation - routers and sessions - ephemeral and dedicated nodes - dashboard and indexer visibility - recovery and operational tooling - model and node availability These paths provide the baseline that the product layer depends on. 🔹 Product workloads test something different When PyClaw, Portal, Corgent, Bardiel, hackathon projects, and other applications begin using the stack, they introduce behavior that infrastructure-only testing does not fully reproduce. That can expose: - API compatibility gaps - model behavior differences - latency and timeout patterns - routing and session edge cases - node / model capacity constraints - onboarding and developer UX problems - recovery behavior under longer workflows 🔹 Builders become another validation layer External developers are especially useful here. They create applications and workflows based on their own assumptions rather than ours. That gives us a growing set of real workloads moving through the product and infrastructure stack. The loop becomes: products → builders → real workloads → infrastructure + product signals → fixes → capacity expansion → stronger products 🔹 This changes how scaling decisions can be made Instead of expanding every part of the network equally, real usage can increasingly show us: - which models need more capacity - where router / session behavior needs refinement - which product paths create the most load - where latency or failures appear - which developer workflows are actually gaining usage 🔹 Current takeaway - Mainnet Full Alpha is not only about confirming that infrastructure stays online - It is increasingly about seeing how infrastructure behaves when actual products and external developers depend on it - Portal, PyClaw, Corgent, Bardiel, and hackathon workloads give us another source of real operational signals That is the transition from infrastructure validation toward product-driven network validation. #Cortensor #DevLog #MainnetFull #Portal #PyClaw #Corgent #Bardiel #AIInfra

🛠️ DevLog – PyClaw 0.1.17 Is Taking Shape The next PyClaw release is expected to be 0.1.17, with the current merged work focused on SDK continuity, PostgreSQL isolation, better first-turn reasoning, safer memory capture, and more reliable research output. 🔹 Explicit SDK thread continuation - Agent.run(...) can now continue an existing thread through an explicit thread_id - This gives SDK integrations clearer control over conversation continuity - Longer-running application workflows no longer need to rely as heavily on implicit session behavior 🔹 Better first-turn context - The initial context budget has been expanded - Agents have more relevant context available when making their first decisions - This is especially useful for workflows where early planning or tool selection determines the rest of the run 🔹 PostgreSQL module isolation - PostgreSQL-backed modules now use more isolated schemas - Ownership validation has been tightened around those boundaries - This reduces accidental cross-module storage assumptions and makes persistent deployments easier to reason about 🔹 Safer memory capture - Denied tool calls are prevented from becoming automatic memory candidates - Pending tool calls are also excluded until their outcome is actually known - This keeps memory from treating unapproved or incomplete actions as durable experience 🔹 Research synthesis reliability - Structured-output instructions for research synthesis have been corrected - This helps keep synthesis output aligned with the schema expected by downstream workflows - It also improves reliability for research pipelines that depend on structured results 🔹 Upgrade and consolidation coverage - Older memory-consolidation jobs now have clearer upgrade guidance - Regression coverage has been expanded around those migration paths - This helps protect existing persisted workflows as the memory system continues evolving 🔹 Current status - The merged dev baseline is currently passing its checks - The release still needs the 0.1.17 version bump, final changelog, dev → main promotion, and publication steps - GitHub, PyPI, runtime manifests, and unsigned CLI / daemon binaries will follow once the release gate is complete - There are currently no substantive unreleased Desktop changes requiring a separate Desktop 0.0.6 release 🔹 Current takeaway - 0.1.17 is shaping up as a focused continuity and correctness release - SDK threads, first-turn context, PostgreSQL isolation, research synthesis, and memory policy are all being tightened together - The goal remains making longer-running agent workflows more explicit, predictable, and easier to integrate into real applications #Cortensor #DevLog #PyClaw #SDK #PostgreSQL #AgenticAI #DeveloperTools

🛠️ DevLog – Hackathon #5 Is Becoming a Product Testing Layer Hackathon #5 is continuing to grow, and it is already starting to serve a bigger purpose than collecting project submissions. With 63 builders and 16 submitted builds so far, we are getting a growing set of external workflows testing PyClaw, Portal, models, documentation, and the broader developer experience. 🔹 Real builders create different workloads - External developers approach PyClaw differently than the core team - They combine tools, memory, delegation, models, scheduling, and SDK features in ways we may not reproduce internally - Those workflows expose practical edge cases much earlier 🔹 The hackathon tests more than PyClaw - SDK behavior - Documentation and onboarding - Portal API compatibility - Model behavior and reliability - Tool execution - Memory and longer-running workflows - Desktop / CLI usability - Packaging and cross-platform behavior 🔹 Issues become development inputs - Builder usage exposes bugs or unclear behavior - Reports move into triage and reproduction - Fixes get regression coverage - Changes move into patch releases - Updated releases go back out to builders The loop increasingly looks like: builders → real projects → bugs / feedback → reproduce → fix → regression coverage → release → more external testing 🔹 Portal adds another validation layer - Builders using hosted models create real API traffic - That helps surface compatibility, latency, reliability, and model-behavior issues - Over time, those workloads also help show where additional model and infrastructure capacity is needed 🔹 Why this matters - Hackathons are becoming part of the product iteration process - The goal is not simply to maximize submission count - The more useful outcome is a repeatable external feedback loop across PyClaw, Portal, models, SDKs, documentation, and eventually the broader Cortensor infrastructure 🔹 Current takeaway - Hackathon #5 has now reached 63 builders and 16 submissions - Their projects are becoming another real-world testing layer - The findings feed directly back into product fixes, releases, and future capacity decisions That makes the hackathon useful both for ecosystem growth and for improving the products themselves. #Cortensor #DevLog #Hackathon #PyClaw #Portal #OpenSource #AgenticAI

🛠️ DevLog – PyClaw 0.1.16 + Desktop 0.0.5 Are Now Out The latest PyClaw and Desktop releases are now live, with this cycle focused on tighter memory authorization, safer startup cleanup, stronger migration behavior, improved room concurrency, and refreshed cross-platform builds. 🔹 Authorization-aware memory capture - Automatic memory capture now checks memory.write authorization before persisting turn data - This keeps background memory behavior aligned with the same permission boundaries as explicit memory operations 🔹 Protected decision and refusal records - Decision records can no longer bypass memory-write policy - Refused tool outcomes are also protected from being persisted when memory-write authorization is not available - This closes another path where runtime-generated state could otherwise outlive the permissions that produced it 🔹 Safer API startup and resource cleanup - Failed API startup now cleans up partially initialized runtime resources more reliably - Storage, telemetry, modules, services, and other runtime-owned resources are handled more safely when initialization does not complete 🔹 Storage migration reliability - Nested compression migration discovery has been restored - This strengthens migration behavior across both SQLite and PostgreSQL-backed environments - Upgrade paths are becoming more predictable as storage coverage expands 🔹 Room and active-agent concurrency - Active-agent selection is now better protected against concurrent room membership changes - This reduces conflicting state when leave, kick, and agent-selection operations happen close together 🔹 Desktop 0.0.5 + cross-platform builds - Desktop 0.0.5 is now out alongside PyClaw 0.1.16 - Delegated-task inspection, status, and result access remain available during active replies while cancellation stays more constrained - Refreshed unsigned CLI, daemon, and Desktop builds are available for macOS, Linux, and Windows 🔹 Current takeaway - 0.1.16 is another reliability-focused release centered on permission boundaries, cleanup, migrations, and concurrent runtime behavior - Desktop 0.0.5 continues improving visibility into longer-running delegated work while keeping active execution safer #Cortensor #DevLog #PyClaw #DesktopApp #AgenticAI #DeveloperTools #AIInfra

🛠️ DevLog – PyClaw 0.1.16 + Desktop 0.0.5 Are Moving Through Final Validation The next PyClaw release is still in progress, with the latest merged work focused heavily on memory authorization, startup cleanup, storage migration reliability, and safer concurrent runtime behavior. Desktop 0.0.5 is also progressing separately with improvements around delegated-task inspection during active replies. 🔹 Memory-write authorization - Automatic turn memory capture now checks memory.write authorization first - Decision records can no longer bypass memory-write policy - Refused tool outcomes are also prevented from being persisted when memory-write permission is not available - This keeps automatic memory behavior aligned with the same permission boundaries as explicit memory operations 🔹 Safer failed startup cleanup - Partially initialized runtime resources are now closed more reliably after failed API startup - Cleanup covers storage, telemetry, modules, services, and other runtime-owned resources - This reduces the chance of failed startup attempts leaving behind stale or partially active state 🔹 Storage migration reliability - compress module discovery has been restored for both SQLite and PostgreSQL migration paths - PostgreSQL controlplane and telemetry baseline migrations have been corrected - Existing-table compatibility has also been tightened for upgrades against already-initialized databases 🔹 Safer room concurrency - Active-agent selection inside Rooms is now serialized against concurrent leave / kick operations - This helps avoid conflicting state changes when multiple room operations happen at nearly the same time 🔹 Desktop 0.0.5 - Delegated-task inspection remains available while an active reply is running - Task status and results can still be viewed during that reply - Cancellation is intentionally more restricted to keep active execution state safer and more predictable 🔹 Release status - PyClaw 0.1.16 is still moving through its final merged-revision gate - The current feature set is largely locked, but final integrated validation still needs to clear before release promotion - Desktop 0.0.5 is progressing alongside it as a separate versioned release 🔹 Current takeaway - 0.1.16 is shaping up as another infrastructure-focused reliability release - The main themes are tighter authorization, cleaner failed-start recovery, safer migrations, and more deterministic concurrent runtime behavior - Desktop 0.0.5 continues improving how longer-running delegated work can be inspected without disrupting active execution #Cortensor #DevLog #PyClaw #DesktopApp #AgenticAI #DeveloperTools #AIInfra

🛠️ DevLog – One PyClaw Runtime, Multiple Ways to Use It As PyClaw continues to mature, one design principle is becoming more important: We do not want separate agent systems for every interface. The goal is one underlying runtime, exposed through multiple ways to build, operate, and interact with it. 🔹 CLI for direct control - Useful for developers, power users, debugging, and automation - Gives direct access to sessions, tasks, tools, schedules, approvals, diagnostics, and runtime controls - Remains one of the fastest ways to test new capabilities as they land 🔹 SDK for builders - Lets developers embed PyClaw into their own applications and workflows - Provides access to tools, streaming, structured output, delegation, memory, and longer-running agent behavior - Keeps the runtime usable as infrastructure, not only as a standalone app 🔹 Daemon for persistent execution - Supports longer-lived runtime behavior behind the interface layer - Helps sessions, scheduled tasks, background workflows, and state continue without tying everything to one terminal window - Gives both CLI and Desktop a common execution foundation 🔹 Desktop for broader access - Brings the same runtime into a graphical interface - Makes sessions, tasks, schedules, models, approvals, artifacts, diagnostics, and other runtime capabilities easier to access - Desktop is not a separate agent stack; it is another interface and distribution layer over PyClaw 🔹 Why keeping one runtime matters - Capabilities do not need to be rebuilt independently for each surface - Fixes to memory, scheduling, tools, recovery, security, and state handling can benefit multiple interfaces - CLI, SDK, daemon, and Desktop can stay closer to the same execution semantics - Users can choose the interface that fits them without moving to a different underlying system 🔹 Distribution is becoming part of the architecture - PyPI remains an easy path for Python developers - CLI / daemon binaries provide a more packaged runtime path - Desktop adds a more accessible end-user surface - Cross-platform builds now cover macOS, Linux, and Windows The broader model is: one runtime → multiple interfaces → more ways to build and use agents → more real workloads → more feedback → stronger runtime underneath 🔹 Current takeaway - PyClaw is increasingly becoming less about a single CLI or app - The runtime is the common layer - CLI, SDK, daemon, and Desktop are different ways to reach that same foundation - This gives us a cleaner path to improve the core once while expanding how developers and users can access it #Cortensor #DevLog #PyClaw #DesktopApp #SDK #AgenticAI #DeveloperTools

How the Cortensor stack is coming together is easier to see when you look at it layer by layer. 🔹 Foundation - Network, validators, routers, sessions, dashboard, and indexer established the core execution layer - Testnet → Mainnet Lite → Mainnet Full / L3 created the path toward a more complete long-term environment 🔹 Product layer - Portal simplified hosted model access - Corgent / Bardiel added delegation, validation, fact-checking, and trust-oriented services 🔹 Current focus - PyClaw is becoming the main agent runtime layer - Desktop extends that same runtime toward broader distribution and easier end-user access The broader progression is: Core infrastructure → Mainnet + product integration → Portal / Corgent / Bardiel → PyClaw → Desktop + distribution → real developer workloads → continuous improvement The key point is that these are connected maturity stages, not isolated products or permanent finish lines. Each layer reaches a working baseline, connects to the next one, and keeps improving as real usage exposes new gaps. #Cortensor #MainnetFull #Portal #Corgent #Bardiel #PyClaw #AgenticAI

🛠️ DevLog – PyClaw 0.1.15 + Desktop 0.0.4 Are Now Out The latest PyClaw release is now live alongside a new Desktop build, continuing the push toward a more durable runtime and a clearer cross-platform distribution path. 🔹 PostgreSQL and storage reliability - PostgreSQL-backed runtime startup has been tightened - Migration failures now surface more clearly - This makes startup and upgrade problems easier to identify before they turn into harder-to-debug runtime issues 🔹 Memory consolidation and recovery - Memory consolidation now runs with more trusted runtime context - Pending memory captures have a stronger recovery path - Longer-running workflows can retain and recover useful state more predictably 🔹 Tasks, cron, and watch workflows - Task lifecycle controls have expanded - Cron execution, history, and run-state visibility are more complete - Material-change watch workflows can better track when something actually changes instead of treating every check as a new event 🔹 Usage, telemetry, MCP, and artifacts - Token usage and telemetry visibility have been improved - MCP interoperability continues to mature across external tools and servers - Artifact handling and retention behavior have been tightened further 🔹 Runtime and security assessment - Runtime assessment coverage has expanded - Security workflows received additional evidence and validation improvements - The focus remains bounded, inspectable execution with clearer recovery and failure behavior 🔹 Desktop + cross-platform distribution - PyClaw 0.1.15 ships alongside Desktop 0.0.4 - Unsigned CLI, daemon, and Desktop builds are available for macOS, Linux, and Windows - This continues bringing the core runtime and Desktop release paths into a more consistent versioned distribution cycle 🔹 Current takeaway - PyClaw is continuing to mature across persistence, scheduling, memory, observability, MCP, security, and distribution - With Desktop now moving through its own versioned releases, the same underlying runtime is becoming easier to access across CLI, daemon, and graphical interfaces #Cortensor #DevLog #PyClaw #DesktopApp #MCP #AgenticAI #DeveloperTools

PyClaw, Portal, and Hackathon #5 are starting to connect into one practical builder cycle. 🔹 PyClaw is where developers build Agents, tools, memory, delegation, structured output, and longer-running workflows. 🔹 Portal is where those workflows can reach hosted models A simpler API path into Cortensor-backed inference, including Gemma4 as capacity allows. 🔹 Hackathons turn both into real-world testing External builders create workloads we may not reproduce internally and expose gaps across SDK behavior, onboarding, models, reliability, and runtime UX. The important part is the loop: Build with PyClaw → run real workflows → use Portal / models → find gaps → improve the products → bring in more builders → repeat Hackathons are not only about project submissions. They give us a continuous way to test how the full builder experience behaves outside our own development environment. #Cortensor #PyClaw #Portal #Gemma4 #Hackathon #SDK #AgenticAI

🛠️ DevLog – PyClaw: 0.1.15 Is Taking Shape Across Security, Scheduling, Memory, and MCP The next PyClaw patch release is starting to come together, with a broader set of runtime, security, scheduling, storage, and interoperability improvements already confirmed. Expected version: 0.1.15 🔹 Security workflow expansion - Local security audits are becoming more isolated and repeatable - Recurring evidence collection has been expanded - SARIF export is now part of the workflow - Offline AWS checks and bounded web / API scanning are being added with tighter execution limits 🔹 Tasks, cron, and scheduled execution - Task and cron controls now cover more of the full lifecycle - Run-now, scheduler status, history, one-shot execution, and watch delivery are being tightened - This gives scheduled workflows better visibility and control instead of treating them as fire-and-forget jobs 🔹 Artifact and retrieval durability - Artifact retention validation has been strengthened - Alias expiry handling is more reliable - Retrieval ingestion is becoming more durable across longer-lived workflows 🔹 PostgreSQL and storage reliability - PostgreSQL-backed APIRuntime startup is now supported more cleanly - Storage migration failures provide clearer output - This continues reducing ambiguity around startup, migration, and recovery behavior 🔹 Memory and recovery - Memory consolidation now receives more trusted runtime context - Capture recovery is becoming more capability-aware - The goal is to make memory writes and recovery paths more explicit and dependable 🔹 Telemetry and debugging - Exporter behavior has been tightened - Debugging visibility has improved - Token history is linked more clearly into runtime telemetry 🔹 MCP interoperability - HTTP / SSE compatibility has been strengthened - Coverage has been updated against the current official SDK behavior - This continues improving PyClaw's ability to work with a broader set of external MCP servers and tools 🔹 Still in flight - Room activation locking - Failed-runtime-start cleanup - Memory-write authorization - These changes are green individually but are not yet part of the confirmed release set 🔹 Release status - The branch is not release-ready yet - The latest integrated CI has one remaining macOS Focus PTY resize failure - The rest of the hosted checks passed - That final failure still needs to be rerun or fixed before 0.1.15 can be promoted 🔹 Current takeaway - 0.1.15 is shaping up as another broad reliability release across security workflows, scheduled execution, memory, storage, artifacts, telemetry, and MCP - The release will move forward once the remaining integration issue is cleared and the final set is locked #Cortensor #DevLog #PyClaw #MCP #Cybersecurity #AgenticAI #DeveloperTools

Monthly Node Rewards – October 2026 We've now sent out the October 2026 ethereum:0x8e0eef788350f40255d86dfe8d91ec0ad3a4547f node rewards to 19 nodes as part of our monthly node reward program. 🔹 Rewards sent to 19 nodes total 🔹 Includes 10 dedicated nodes + 9 ephemeral nodes 🔹 Recognizing uptime, stability, and contribution 💬 Join our Discord to set up a node or get involved: discord.com/invite/gPHh6wtZy… Thanks to all node operators continuing to support the network and push decentralized AI forward - it’s ethereum:0x8e0eef788350f40255d86dfe8d91ec0ad3a4547f or nothing. #Cortensor #AI #DePIN #NodeRewards #COR

🛠️ DevLog – PyClaw: 0.1.14 Improves Time Grounding, Typed Tools, Storage Safety, and Recovery The latest PyClaw release is now out, continuing the 0.1.x focus on more reliable agent execution, stronger tool contracts, and safer state / storage management. 🔹 More reliable time grounding - Exact UTC dates can now be grounded through canonical time evidence - This gives workflows a stronger source of truth when current date context matters - It also reduces ambiguity across longer-running and resumed tasks 🔹 Stronger typed tools - Tool handlers now support typed Pydantic and dataclass inputs - Structured arguments can move through tool execution with clearer schemas and validation - This makes more complex SDK and agent-tool integrations easier to define consistently 🔹 Memory and resource cleanup - Memory resource ownership and cleanup have been tightened further - PostgreSQL-backed workflows receive stronger cleanup behavior - This continues reducing resource leakage across persistent and longer-running runtimes 🔹 Safer storage operations - Storage commands now provide clearer exit-state behavior - Backup and rollback paths have been strengthened - Failure states are easier to distinguish before potentially destructive storage operations continue 🔹 Security and recovery - Security evidence validation has been tightened - Plan recovery is more reliable when workflows are interrupted or need to resume from existing state - The focus remains evidence-backed execution rather than assuming a step succeeded 🔹 Current takeaway - 0.1.14 continues tightening the runtime underneath longer and more structured agent workflows - Time grounding, typed tools, storage safety, memory lifecycle, evidence validation, and recovery are all becoming more explicit as the 0.1 line matures #Cortensor #DevLog #PyClaw #SDK #AgenticAI #DeveloperTools #AIInfra

🛠️ DevLog – Hackathon #5 Reaches 50 Builders and 12 Submissions in the First 12 Days Hackathon #5 is continuing to pick up early momentum, with 50 builders and 12 submitted projects already participating after only 12 days. 🔹 Current progress - 50 builders have joined so far - 12 projects / builds have already been submitted - The submission window remains open through 12/18 - PyClaw 0.1 remains the primary builder surface, with Portal available as an optional hosted model path 🔹 Why this matters - The goal is not only to increase submission count - Each external project gives us another real workflow for testing the SDK, runtime, documentation, onboarding, model behavior, and broader developer experience - Builders are also surfacing bugs, compatibility issues, missing examples, and areas where the product can be simplified 🔹 The feedback loop is starting early - Builders use PyClaw - Real projects expose issues and edge cases - Bugs and feedback move into triage - Fixes and regressions move into patch releases - Updated builds go back out for more external testing 🔹 What comes next - Continue bringing more builders into the hackathon over the remaining submission period - Keep iterating PyClaw and Portal based on real developer usage - Encourage useful bug reports, fix PRs, reusable tools, and documentation improvements alongside project submissions - Use the growing workload set to better understand where runtime, model, and infrastructure capacity need to improve 🔹 Current takeaway - 50 builders and 12 submissions in the first 12 days is a healthy early signal - More importantly, Hackathon #5 is already becoming another external product-development loop for PyClaw and the broader Cortensor stack #Cortensor #DevLog #Hackathon #PyClaw #Portal #OpenSource #AgenticAI