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 – External Developer Activity Continues to Expand A quick follow-up on the external development activity around PyClaw. Our previous external-only snapshot showed: - 89 external pull requests submitted - 75 external pull requests merged - 97 external reports / issues raised - 50 external reports closed - 47 external reports still open Since then, activity has continued moving quickly. 🔹 Current live repository queue - 74 total open issues are currently visible on GitHub - 11 total open pull requests are currently visible - At the previous snapshot, the repository had 53 open issues total: 47 external + 6 internal - That means the overall open issue queue has grown by 21 since the last snapshot The live GitHub counters include both external and internally filed work, so we will do another full external-only classification rather than treating every new open issue as an external report. 🔹 What we are seeing in the newer reports - Agent completion / final-answer behavior - Daemon lifecycle and recovery - Tool execution and async behavior - File read / search continuation - Context and token overhead - Runtime cancellation and failure recovery - Security and local storage behavior Several reported fixes are also already sitting in the awaiting-release stage rather than simply being counted as unresolved bugs. 🔹 Why issues remain open after fixes - Report is reproduced - Fix is developed and reviewed - Regression coverage is added - Change merges into dev - Fix reaches a published release - Published version is verified - Then the issue can be closed This means the open count includes work at several different stages, including fixes that have already landed but still need release verification. 🔹 Current takeaway - External testing continues to generate a meaningful amount of real engineering work - The issue queue has expanded as more workflows and edge cases are exercised - At the same time, fixes continue moving through contributor PRs, dev merges, releases, and public verification We will share another external-only stats snapshot after the current queue is fully reclassified. #Cortensor #DevLog #PyClaw #OpenSource #DeveloperTools #AgenticAI

🛠️ DevLog – Hackathon #5: First Filtering Pass Identifies 5 Qualified Builds So Far A quick follow-up on the current Hackathon #5 submission review. We have started the first filtering pass across the submitted builds, and 5 projects have qualified so far at the initial review stage. 🔹 Current review status - 22 builds / submissions are in the current review set - 5 have passed the first qualification filter so far - The remaining submissions are still being reviewed - The qualified count may increase as more projects complete the first-pass review 🔹 What first qualification means - The project appears to be real and implemented - The submission is relevant to the hackathon - There is enough source code / repository material to continue reviewing - PyClaw appears to be used meaningfully where required - The project is not just a placeholder or incomplete submission 🔹 Deeper code review comes next - We will inspect the qualified repositories in more detail - Source code will be checked / scanned for legitimacy and consistency with the submission - We will look at whether the project can actually be run or reproduced - We will verify that the claimed workflow matches what the code is doing - Stronger projects may receive additional functional testing 🔹 Why we are doing multiple review stages - The first pass removes obvious non-qualifying entries - The deeper pass helps confirm that the remaining builds are technically legitimate - This gives us a cleaner set of projects for final evaluation - It also gives us better external testing signals for PyClaw, Portal, SDK behavior, models, and onboarding 🔹 Current takeaway - 5 projects have qualified through the initial filtering stage so far - Review of the full submission set is still ongoing - Those 5 will now move into more detailed code and reproducibility checks - We will share another update as the qualified set develops #Cortensor #DevLog #Hackathon #PyClaw #OpenSource #DeveloperTools #AgenticAI

🛠️ DevLog – Hackathon #5: First Submission Filtering Starts This Week A quick follow-up on the current 22 Hackathon #5 builds / submissions. This week, we will begin the first filtering pass across the submitted projects. 🔹 What we will check - Review each submitted project individually - Open and inspect the linked GitHub repository where available - Run / test the source code when practical - Check whether the implementation matches what the submission claims - Confirm that the project is real, functional, and meaningfully connected to the hackathon - Verify that PyClaw is actually being used where required 🔹 First filtering pass - The goal this week is to separate clearly legitimate builds from placeholder, incomplete, unrelated, or non-functional submissions - This is only the first qualification layer - Stronger projects can then move into deeper technical review and reproducibility testing 🔹 Why this matters - Raw submission count alone does not tell us much about project quality - Code review and source verification give us a much better signal - Qualified projects can then become useful external testing workloads for PyClaw, Portal, models, SDK behavior, documentation, and onboarding 🔹 Current takeaway - 22 builds / submissions are currently in the review set - First filtering starts this week - We will check source code and implementation legitimacy before counting projects as qualified - Updated qualified-project numbers will follow as the review progresses #Cortensor #DevLog #Hackathon #PyClaw #OpenSource #DeveloperTools #AgenticAI

🛠️ DevLog – Hackathon #5 Reaches 74 Builders and 22 Submissions Hackathon #5 continues to grow, with 74 builders now participating and 22 projects / submissions in the current batch. The submission window is still open through 12/18, so there is still plenty of time for more builders and projects to join. 🔹 Current progress - 74 builders participating - 22 builds / submissions so far - PyClaw remains the primary builder surface - Portal continues to provide an optional hosted model path where capacity allows 🔹 Review is becoming the next focus - We are reviewing submitted projects beyond the raw submission count - Repositories and code will be checked / scanned where available to confirm that projects are real and implemented - We will also look at whether the workflow can be reproduced and whether PyClaw is being used meaningfully - Incomplete, placeholder, unrelated, or non-functional submissions may be excluded from the final qualified set 🔹 Why this matters - More builders create more real workflows - More workflows expose SDK, runtime, model, Portal, onboarding, and documentation gaps - Useful findings can move directly into triage, fixes, regression coverage, and new releases - Stronger projects also give us better examples of how people are actually trying to use PyClaw 🔹 The loop continues builders → real projects → review / qualification → feedback and issues → reproduce → fix → release → external retest 🔹 Current takeaway - Hackathon #5 has now reached 74 builders and 22 submissions - Participation continues to expand - The next important metric will increasingly be how many projects qualify after implementation, code, and reproducibility review - The strongest projects continue to become another external testing layer for PyClaw, Portal, and the broader Cortensor stack #Cortensor #DevLog #Hackathon #PyClaw #Portal #OpenSource #AgenticAI

🛠️ DevLog – PyClaw 0.1.18 + Desktop 0.0.7 Are Now Out The latest PyClaw release is now live alongside Desktop 0.0.7, with this cycle focused on safer agent learning, recurring security workflows, more complete usage accounting, and broader runtime reliability. 🔹 Reviewable agent learning - PyClaw can now turn successful workflows into reusable learning candidates - Those learned behaviors can be evaluated before being admitted - Operators retain control over approval, activation, and rollback - The goal is useful learning without silently changing runtime behavior 🔹 Recurring security assessments - Security assessments can now run on a recurring basis - Evidence is preserved alongside the workflow - Pause / resume support makes longer assessments easier to continue without losing progress - The emphasis remains bounded, reviewable, and evidence-backed execution 🔹 More complete LLM usage accounting - Token / model usage is now tracked more completely across the full agent cycle - This improves visibility into how much work a task actually consumes - Better accounting also helps with future model, cost, and capacity decisions 🔹 Runtime reliability - CLI and daemon behavior received additional reliability improvements - Provider handling and tool execution were tightened - Memory behavior and recovery paths were improved - The focus continues to be predictable execution rather than simply adding more features 🔹 Desktop 0.0.7 + cross-platform builds - Desktop 0.0.7 is now available alongside PyClaw 0.1.18 - Updated unsigned CLI and Desktop builds are available for macOS, Linux, and Windows - Cross-platform packaging continues becoming a normal part of the release cycle 🔹 Current takeaway - 0.1.18 pushes PyClaw further toward an agent runtime that can learn, verify, recover, and explain what it used along the way - The broader direction remains dependable recurring work with clear evidence, user control, and predictable runtime behavior #Cortensor #DevLog #PyClaw #DesktopApp #AgenticAI #OpenSource #DeveloperTools

🛠️ DevLog – PyClaw 0.1.18 + Desktop 0.0.7 Are Taking Shape The next PyClaw release is starting to come together, with the current dev branch focused on one-shot workflow reliability, memory quality, safer execution limits, provider configuration, and stronger CI discipline. The likely next versions are PyClaw 0.1.18 and Desktop 0.0.7. 🔹 One-shot workflow reliability - One-shot runs now use the caller’s working directory for file tools - Explicit --dir support gives users clearer control over where those tasks operate - Daemon 4xx responses remain authoritative instead of falling back into duplicate local execution - Settled one-shot session replies are acknowledged correctly rather than being replayed 🔹 Smarter execution limits - Adaptive LLM-call limits are now enforced - Provider schema-cost telemetry has been tightened while remaining privacy-safe - The goal is to make longer workflows more predictable without simply raising limits everywhere 🔹 Memory quality and recovery - Memory consolidation retries deferred or partially failed candidates more reliably - BM25 relevance ordering has been corrected for stronger memory matches - These changes improve both recovery behavior and the quality of recalled context 🔹 Tool and runtime improvements - Positional-only parameters now work correctly in @tool handlers - Git rename / copy parsing has been improved - Calculator failures now return more structured errors - Older SQLite environments receive more portable migration support 🔹 Provider and configuration cleanup - Provider configuration now has one authoritative write location - Default identity-profile logging is quieter - This reduces configuration ambiguity and unnecessary runtime noise 🔹 Stronger CI guardrails - New CI ratchets prevent unreviewed test skips - Expected failures are also tracked more strictly - This helps stop temporary test exceptions from quietly becoming permanent gaps 🔹 Desktop 0.0.7 - Desktop now warns before closing Settings when profile or credential changes have not been saved - This is a small UX change, but it helps prevent accidental loss of important configuration edits 🔹 Current status - These changes are merged into dev - They have not yet been promoted or published - Final integrated validation, versioning, changelog, and release promotion still need to clear before publication 🔹 Current takeaway - 0.1.18 is shaping up as another reliability-focused release - The main themes are safer one-shot execution, better memory retrieval, clearer resource limits, cleaner configuration, and stronger regression discipline - Desktop 0.0.7 continues tightening the everyday usability around the same runtime #Cortensor #DevLog #PyClaw #DesktopApp #AgenticAI #DeveloperTools #OpenSource

🔒 Liquidity Lock Update – Team Finance Page Now Reflects the Updated Lock A quick follow-up to the earlier liquidity lock update. The Team Finance page now appears to be showing the correct updated LP lock information rather than the older cached values. 🔹 Current status - The updated lock is now reflected on the Team Finance page - The new lock period is 6 months - This replaces the previous one-year extension approach - The goal remains to keep liquidity secured while giving us more flexibility to reassess conditions around mid-2027 🔹 Why we chose a shorter lock this time - Market conditions can change significantly over a year - The broader chain / liquidity landscape is still evolving - We want room to evaluate options such as Base or other ecosystems if they become strategically relevant - We also want future liquidity decisions to reflect actual market activity, product usage, and ecosystem demand 🔹 What this does not mean - There is no immediate LP migration planned - There is no immediate chain change planned - The shorter lock is simply about preserving flexibility while keeping liquidity secured We’ll continue watching the market, product traction, liquidity conditions, and broader ecosystem over the coming months before making any larger changes. Team Finance: team.finance/view-coin/0x8e0… #Cortensor #COR #Liquidity #MainnetFull

🛠️ DevLog – Portal Capacity: Scaling With Real Demand, Market Conditions, and Managed Baseline Infrastructure As Portal usage grows, one area we are watching closely is how and when to expand inference capacity. The goal is not simply to add as many nodes as possible. We want Portal capacity to grow in a way that can be sustained by actual usage, market conditions, and the economics of operating the network. 🔹 Where we are today - Portal already has a working inference baseline - Current capacity is intentionally limited while we continue watching real usage patterns - Hackathon workloads, PyClaw usage, model demand, latency, and failure rates are all useful signals - We are also watching broader market activity, including price action, market capitalization, and trading volume These signals help us understand when expanding capacity becomes economically reasonable rather than simply increasing infrastructure ahead of demand. 🔹 Managed capacity as a baseline - NVIDIA DGX capacity remains in the pipeline - The initial direction is to operate some capacity internally / under our management - This gives Portal a more predictable baseline rather than depending entirely on randomly available external nodes - The goal is to guarantee a minimum level of model availability before expanding further From there, external GPU and DGX-class node operators can increasingly supplement that baseline as demand grows. The rough direction is: managed baseline capacity → validate workloads → observe sustained demand → onboard additional GPU / DGX capacity → expand with usage 🔹 Why we are not scaling aggressively yet GPU infrastructure creates ongoing cost. If market activity and product demand are still limited, continuously increasing capacity can create an infrastructure burden without enough usage to support it. We therefore want to watch several signals together: - Portal inference demand - PyClaw-driven traffic - hackathon / developer workloads - model utilization - network participation - market price action / market capitalization - trading volume - operating cost versus sustainable reward levels No single metric determines expansion. We are looking for a combination of real product demand and healthier market conditions before making larger capacity commitments. 🔹 Hackathons are part of the learning process - Portal is available as a hosted inference path for builders where capacity allows - We are not forcing every hackathon workflow through Portal while capacity is still intentionally controlled - External projects still give us valuable signals about which models and workloads builders actually want - Those observations help guide future infrastructure decisions 🔹 PyClaw can change the demand profile PyClaw is another variable we are watching closely. If usage grows significantly through PyClaw, especially through free or subsidized access paths, Portal limits and capacity policies may need to be adjusted over time. That could include tuning: - free capacity - rate limits - model availability - routing policies - workload priorities - additional node capacity The objective is to keep access useful without allowing subsidized traffic to overwhelm the baseline infrastructure. 🔹 Current takeaway - Portal capacity expansion is planned, but it will be gradual - DGX is part of the pipeline for establishing a managed baseline - Additional external GPU / DGX capacity can follow as demand becomes clearer - We are watching both real product usage and broader market conditions before making larger infrastructure commitments Capacity should ultimately follow sustainable demand. Not the other way around. #Cortensor #DevLog #Portal #MainnetFull #PyClaw #NodeOps #AIInfra

🔒 Liquidity Lock Update Last year, we extended all Cortensor LP locks for another full year while we continued working toward Mainnet Full and the broader product rollout. For the upcoming renewal, we are planning a shorter 6-month lock period. 🔹 Why 6 months this time - The LP remains locked and protected during this period - A 6-month window gives us more flexibility to reassess market conditions around mid-2027 - The broader blockchain ecosystem continues to evolve, including Base and other chains / liquidity environments - Keeping some flexibility allows us to evaluate whether any future liquidity structure or chain expansion makes sense without being locked into another full year 🔹 What is not changing - We are not planning any immediate LP migration simply because the lock period is shorter - The objective remains maintaining stable liquidity while watching actual market conditions and ecosystem demand - Any future LP or chain-related changes would be evaluated carefully before action is taken Last year's one-year extension made sense while we were working through the Mainnet Full path. This time, a 6-month lock gives us a better balance between continued LP security and the flexibility to evaluate where the market and ecosystem are heading next year. #Cortensor #COR #Liquidity #MainnetFull

🔒 LP Re-Lock Update We will be re-locking the Cortensor LP this week. We’ll share the full details once completed, including: - new lock timeline - why we are choosing that duration - how current market conditions factor into the decision - how we are thinking about flexibility around liquidity and potential chain options going into next year The priority remains keeping liquidity secure while giving the project enough flexibility to adjust as the market and ecosystem evolve. More details shortly after the re-lock is completed. #Cortensor #COR #Liquidity #MainnetFull

🛠️ DevLog – Hackathon #5: Current Submission Review Snapshot Hackathon #5 continues to grow, and we are now moving into a more detailed review of the current submission batch. 🔹 Current stats - 67 builders participating - 20 builds / submissions currently identified - Final qualified-project count is still pending review 🔹 What happens during review - We will check each submission for an actual working project - We will review linked repositories and scan / inspect the submitted code where available - We will verify that the implementation is real and meaningfully connected to the submitted project - We will check whether PyClaw is actually being used as part of the workflow - We will look for enough documentation and evidence to reproduce or understand the build - Placeholder, incomplete, unrelated, or non-functional submissions may be excluded from the qualified set 🔹 Current build / submission batch - dorahacks.io/build/49989 - dorahacks.io/build/49990 - dorahacks.io/build/50003 - dorahacks.io/build/50049 - dorahacks.io/build/50061 - dorahacks.io/build/50067 - dorahacks.io/build/50093 - dorahacks.io/build/50210 - dorahacks.io/build/50222 - dorahacks.io/build/50259 - dorahacks.io/build/50315 - dorahacks.io/build/50401 - dorahacks.io/build/50459 - dorahacks.io/build/50472 - dorahacks.io/build/50477 - dorahacks.io/build/50494 - dorahacks.io/build/49165 - dorahacks.io/build/48982 - dorahacks.io/build/50756 - dorahacks.io/build/50881 🔹 Why qualification matters - The goal is not to count every submission equally - Qualified projects should demonstrate real implementation and reproducible work - Stronger projects give us useful external workloads for testing PyClaw, Portal, models, SDK behavior, documentation, onboarding, Desktop / CLI, and cross-platform packaging - Useful bugs and compatibility findings can then feed directly back into the development cycle 🔹 What comes next - Review and scan the current 20 submissions - Separate qualified projects from incomplete / non-qualifying entries - Test stronger projects more deeply - Collect useful bugs, compatibility findings, and product feedback - Share updated qualified-project stats as review progresses 🔹 Current takeaway - Hackathon #5 has reached 67 builders and 20 builds / submissions - The next step is verifying that those projects are real, functional, and meet the qualification requirements - The final qualified count will be based on actual implementation, code review, reproducibility, and meaningful use of PyClaw #Cortensor #DevLog #Hackathon #PyClaw #Portal #OpenSource #AgenticAI

🛠️ DevLog – External Developer Activity Continues to Grow Around PyClaw A fresh look at external GitHub activity shows the open-source feedback loop continuing to expand around PyClaw. 🔹 External contribution stats - 89 external pull requests submitted - 75 external pull requests merged - 12 pull requests currently open - 97 external reports / issues raised - 50 reports already closed - 47 reports still open 🔹 What the open issue count actually means Not every open issue represents an unfixed problem. Of the 47 open external reports: - 25 already have fixes landed and are waiting for published-release verification - 12 are actively being worked on by contributors - 7 are waiting for additional contributor work or evidence - 3 still need workflow-status classification We intentionally keep many issues open after a fix merges until the change reaches a public release and is verified there. 🔹 Open PR queue - 12 external PRs remain open - Several need reconciliation after recent changes landed in dev - Others still need correctness fixes, updated tests, or additional review - None of the remaining PRs is currently considered merge-ready 🔹 Why this matters The important part is not only the raw contribution count. External developers are increasingly becoming part of the normal engineering loop: usage → report → reproduce → contributor fix / PR → review → regression coverage → merge into dev → public release → verification 🔹 Current takeaway - External developers have now submitted 89 PRs and 97 reports - 75 external PRs have already made it into dev - A large portion of the remaining issue queue is already in verification or active-contributor stages - The contribution process is becoming a repeatable part of how PyClaw is tested and improved Thanks to everyone submitting reproductions, fixes, reviews, documentation improvements, and real-world feedback. #Cortensor #DevLog #PyClaw #OpenSource #DeveloperTools #AgenticAI

🛠️ DevLog – PyClaw 0.1.17 + Desktop 0.0.6 Are Now Out The latest PyClaw release is now live alongside Desktop 0.0.6, with this cycle focused on cross-machine agent communication, session continuity, SDK reliability, PostgreSQL isolation, and cross-platform distribution. 🔹 Cross-machine agent calls - A2A transport now supports token-authenticated communication between agents running on different machines - This creates a clearer foundation for distributed agent workflows while keeping access explicitly authenticated 🔹 Named sessions + easier resume - Sessions can now be given names - Existing work can be resumed by name instead of relying only on lower-level identifiers - This makes longer-running workflows easier to find, continue, and manage 🔹 Explicit SDK thread continuation - SDK users can now continue an existing thread more explicitly - This gives applications better control over multi-turn workflows and conversation continuity - Longer-running integrations can preserve state more predictably across calls 🔹 Stronger PostgreSQL isolation - PostgreSQL storage ownership and module isolation have been tightened - This reduces accidental overlap between runtime components - Persistent deployments become easier to reason about as storage usage grows 🔹 SDK and runtime reliability - Tool handling has been improved - Structured outputs are more consistent - Context ordering has been tightened - Blob lifecycle handling is more reliable across creation, use, and cleanup 🔹 Desktop + cross-platform distribution - Desktop 0.0.6 is now available alongside PyClaw 0.1.17 - Updated CLI and daemon builds are available for macOS, Linux, and Windows - Desktop and standalone binaries remain unsigned development builds for now 🔹 Current takeaway - 0.1.17 continues moving PyClaw toward more persistent and distributed workflows - Cross-machine communication, named sessions, explicit continuation, stronger storage boundaries, and broader distribution are all becoming more structured - The focus remains making longer-running agent work easier to resume, integrate, and operate across different environments GitHub: github.com/openminion/openmi… PyPI: pypi.org/project/openminion/… Desktop: github.com/openminion/deskto… Binaries: github.com/openminion/runtim… #Cortensor #DevLog #PyClaw #DesktopApp #A2A #SDK #AgenticAI

🗓️ Weekly Focus – Mainnet Full Alpha, Hackathon #5 & PyClaw Iteration This week continues the same core priorities: keep Mainnet Full Alpha stable, support Hackathon #5 builders, and use external feedback to keep tightening PyClaw 0.1.x. 🔹 Mainnet Full – Alpha Monitoring ‐ Continue monitoring Portal, PyClaw, Corgent, Bardiel, routers, validators, quality signals, dashboard, and indexer. ‐ Track reliability, routing, model capacity, onboarding, and product gaps as more real workloads come through. 🔹 Hackathon #5 – Builder Support ‐ Continue supporting builders through SDK usage, examples, docs, Portal access, and workflow questions. ‐ Keep Hackathon #5 as an external testing layer for PyClaw, Portal, models, onboarding, and broader developer UX. dorahacks.io/hackathon/2418/… 🔹 External Feedback – Bugs / PRs / Regression ‐ Continue daily triage of external bug reports, compatibility findings, fixes, and PRs. ‐ Keep strengthening the workflow → issue → reproduce → fix → regression → release → external retest loop. 🔹 PyClaw – 0.1.x Reliability ‐ Continue tightening long-running projects, memory, scheduling, delegation, MCP, artifacts, recovery, and runtime state. ‐ Prioritize reliability and builder-blocking issues before expanding the core feature surface. 🔹 PyClaw – Desktop / SDK / Distribution ‐ Continue improving SDK continuity and Desktop ↔ CLI / Focus parity while the public release cadence matures. ‐ Keep validating the open source → package → binary → manifest → distribution flow across macOS, Linux, and Windows. This week is mainly about keeping Mainnet Full Alpha steady while Hackathon #5 and external developers continue feeding real workloads, bugs, fixes, and product improvements back into the stack. #Cortensor #MainnetFull #Alpha #PyClaw #Portal #Hackathon #AgenticAI #AIInfra #MCP #DePIN

🛠️ DevLog – Hackathon #5 Reaches 66 Builders and 19 Submissions Hackathon #5 continues to grow, with 66 builders now participating and 19 projects submitted so far. The submission window remains open through 12/18, so we are still relatively early in the overall cycle. 🔹 Current progress - 66 builders participating - 19 submitted projects / builds - PyClaw remains the primary builder surface - Portal continues to provide an optional hosted model path for supported workflows - External usage is continuing to generate feedback across SDK behavior, models, documentation, onboarding, and runtime UX 🔹 More than a submission count The goal of Hackathon #5 is not simply to maximize the number of projects. Each builder gives us another real-world workflow that can test: - PyClaw SDK and runtime behavior - tools, memory, delegation, and longer-running workflows - Portal and model compatibility - documentation and onboarding - Desktop / CLI usability - packaging and cross-platform behavior 🔹 The feedback loop keeps expanding builders → real projects → issues / feedback → reproduce → fix → regression coverage → patch release → external retest This is increasingly becoming part of the normal development cycle rather than a separate hackathon-only process. 🔹 Open-source contributions connect into the same loop - External developers are also filing issues, submitting fixes, and improving documentation - Useful findings from hackathon projects can move directly into triage and development - Published releases then go back out to the same builders for another round of real-world testing 🔹 Current takeaway - Hackathon #5 has now reached 66 builders and 19 submissions - More importantly, the growing project set is giving us a broader external testing surface - That feedback continues helping us improve PyClaw, Portal, models, developer tooling, and the broader Cortensor stack #Cortensor #DevLog #Hackathon #PyClaw #Portal #OpenSource #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