El_Cano

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

🗓️ 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 – 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 – 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 – 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 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