El_Cano

🛠️ DevLog – Hackathon #5: Issue / PR Bonuses Will Prioritize Impact Over Quantity A quick clarification for Hackathon #5 builders regarding the bonus path for GitHub issues and PRs. The bonus will not be based simply on who submits the most issues or pull requests. 🔹 Quality and severity matter more than count - Each issue / PR will be reviewed based on its actual importance and impact - A serious reproducible bug can carry more weight than many minor reports - A meaningful fix for a core reliability problem can matter more than several small PRs - Duplicate, low-value, or quantity-driven submissions will not receive extra weight simply because there are more of them 🔹 What we will consider - Severity of the issue - Impact on real PyClaw workflows - Reproducibility and quality of evidence - Correctness and usefulness of the proposed fix - Regression coverage where appropriate - Whether the contribution improves reliability for other builders / users 🔹 The goal The issue / PR bonus exists to encourage builders to seriously use PyClaw while building their main hackathon project. That naturally creates the loop: build → find a real problem → reproduce it → report / fix it → improve PyClaw → continue building 🔹 Current takeaway - Main project quality remains the primary hackathon focus - Issues / PRs are a bonus contribution path - Bonus evaluation will prioritize severity, impact, and quality over raw contribution count One important issue is more useful than ten low-value ones. #Cortensor #DevLog #Hackathon #PyClaw #OpenSource #DeveloperTools #AgenticAI

🗓️ Weekly Recap – Mainnet Full Alpha, Hackathon #5 & PyClaw Iteration This week kept Mainnet Full Alpha steady while Hackathon #5 expanded further and PyClaw continued a fast feedback-driven 0.1.x refinement cycle. 🔹 Mainnet Full – Alpha Monitoring ‐ Mainnet Full remained the primary product and infrastructure environment under controlled Alpha usage. ‐ Portal/PyClaw workloads and builder activity continued providing signals around capacity, latency, reliability, and model demand. 🔹 Hackathon #5 – Builder Growth ‐ Hackathon #5 reached 74 builders and 22 submissions, with entries remaining open through 12/18. ‐ Real projects continue serving as an external testing layer for PyClaw, Portal, SDK behavior, models, docs, and onboarding. 🔹 Hackathon #5 – Technical Review ‐ Initial technical screening covered 20 submissions, with 5 moving into deeper evaluation. ‐ Reviews now look more closely at repositories, source availability, SDK usage, reproducibility, and real-model execution evidence. 🔹 External Feedback – Bugs / PRs / Regression ‐ External developer activity continued growing across issues and PRs covering runtime, daemon, tools, recovery, and workflow behavior. ‐ The loop continues to tighten: real workflow → issue → reproduce → fix → regression → release → external retest. 🔹 PyClaw – 0.1.x Reliability ‐ PyClaw 0.1.18 → 0.1.19 improved agent learning, usage accounting, user steering, bounded recovery, research-child handling, and runtime reliability. ‐ Additional fixes landed across async tools, A2A, cron, sessions, search, daemon diagnostics, and related workflow paths. 🔹 PyClaw – Reflection / Self-Check ‐ Reflection work started moving into the core so agents can review progress against goals, detect weak/incomplete work, and retry when useful. ‐ The design reuses existing planning, tools, verification, memory, and permissions instead of introducing another parallel framework. 🔹 Portal – Capacity Planning ‐ Portal capacity planning remains gradual, with managed baseline capacity first and DGX resources in the pipeline. ‐ Expansion will continue to follow actual workloads, model demand, latency, operating cost, and broader market conditions. 🔹 Builder → Product → Network Loop ‐ Hackathon activity is increasingly feeding directly into PyClaw and Portal iteration rather than sitting separately from product development. ‐ The loop is becoming clearer: builders → applications → model workloads → Portal usage → feedback → fixes → stronger products + infrastructure. A productive week overall - Hackathon #5 continued gaining traction, technical review became more rigorous, and external builders are now contributing more directly to PyClaw and Portal quality during Mainnet Full Alpha. #Cortensor #MainnetFull #Alpha #PyClaw #Portal #Hackathon #AgenticAI #AIInfra #DePIN

🛠️ DevLog – PyClaw: Reflection Is Becoming a Core Runtime Capability One area we are adding to PyClaw is Reflection: a way for the runtime to step back, review what happened, and decide what should happen next. The goal is not to create another agent framework. It is to make longer-running work more reliable using the systems PyClaw already has. 🔹 What Reflection does - Reviews progress and results against the original goal - Detects failed steps, weak progress, and incomplete work - Decides whether to retry, adjust the plan, ask for help, or close the task - Verifies the result before treating the work as complete 🔹 Built on the existing runtime - Uses the current planning system - Uses existing tools and verification - Works with memory and permissions - Reuses the same runtime state instead of introducing a parallel workflow engine 🔹 Runs only when useful - Reflection is not meant to trigger after every action - It should appear at meaningful checkpoints, failures, stalls, or completion points - The goal is better judgment without unnecessary overhead 🔹 Private reasoning, concise records - Internal reasoning stays private - Only concise decisions, outcomes, and supporting evidence are recorded - This keeps the runtime inspectable without storing unnecessary internal reasoning 🔹 Learning remains controlled - Useful lessons can become reusable across future tasks - Learned changes still require review, evaluation, and validation - Nothing should silently alter future behavior just because one task produced a lesson 🔹 Why this matters Long-running agent work rarely follows a perfect straight line. A dependable runtime needs to know when to: continue → retry → change approach → ask for help → verify → stop Reflection gives PyClaw a clearer way to make those decisions without adding unnecessary complexity. 🔹 Current takeaway - Reflection is being added as a core runtime capability - The focus is better progress checking, recovery, verification, and reusable learning - It builds on the systems PyClaw already has rather than creating another agent layer #Cortensor #DevLog #PyClaw #AgenticAI #DeveloperTools #OpenSource

🛠️ 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: Initial Technical Screening Complete We have completed the initial technical screening of 22 Hackathon #5 submissions. 🔹 Initial screening results - 22 submissions reviewed - 5 met the threshold to advance - 17 did not advance based on the evidence available 🔹 What we reviewed - Substantive application code around PyClaw / OpenMinion - Meaningful SDK integration - Evidence of a useful workflow running with a real model - Available source repositories and submitted run evidence - Selected workflows were also tested independently with controlled inputs and real model calls 🔹 What was not enough on its own - A single API call - A simple prompt change - A thin interface around existing functionality - Simulated behavior without enough real execution evidence 🔹 Common reasons projects did not advance - Source code was unavailable - Execution evidence was simulated or insufficient - PyClaw / OpenMinion integration was missing or too limited - The submission added little beyond existing functionality 🔹 Advancing does not mean final approval - The 5 advancing projects still have defects and reliability limitations - They will now move into deeper technical evaluation - We will look more closely at implementation depth, correctness, reproducibility, and how accurately each project reports failures - Individual assessments and rankings will remain private during this stage 🔹 Current takeaway - The first pass was focused on separating real, substantive builds from submissions that did not provide enough technical evidence - 5 projects have moved forward - The next stage is about deeper validation, not just whether a project runs once #Cortensor #DevLog #Hackathon #PyClaw #OpenSource #DeveloperTools #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 – 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 – 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 – 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

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