November 2026 status archive, page 14 of 15

Shutdown notices, recent changes and all monthly archives

These events link to today's eligible findings, not historical before-and-after claims.

Cited events

7 Nov 202619 ADEs

Replicasfreshness recheckresearch correction48 findings · 24 sources

Findings today

• Replicas provides a web/phone-browser client, desktop apps for three OS families, CLI and native iOS access to cloud…
• Replicas integrates the six-agent picker Claude Code, Codex, Cursor, Muse Code, OpenCode and Pi across app and…
• Own coding-agent subscription or API credentials are required in addition to Replicas account.
• Connect agent and source control, configure environment, send first task.
• CLI, versioned REST API and MCP control workspaces; sanctioned unattended paths are API and Automations.
• Environment skills/plugins/MCP tools extend selected agents.
• Desktop is a native window around hosted deployment; iOS includes native controls.
• Prompt, integration or API starts a workspace; external tracker context can initiate work.
• Claude/Codex plans open beside the chat in Canvas or the sidebar, with download and selection replies sent to the agent.
• Mothership/ships retain parent-child work and board state; no general issue dependency enforcement established.
• Shared learnings, environment instructions and durable orchestrator notes preserve context.
• Language-server navigation, images and MCP knowledge are available.
• Replicas Motherships own a persistent task-ticket board distinct from the derived ship/workspace and pull-request list.
• Concurrent chats/workspaces and separate-VM ships run parallel work.
• Orchestrator assigns ships and exchanges followups/results.
• Shipped Mothership orchestration delegates separate VMs and exposes child transcripts and messages.
• API/Automations run saved tasks without an open client.
• Steer or queue followups, stop sessions and answer questions from multiple clients.
• Ships board exposes fleet state and attention, with recent organization activity.
• Single chats or Motherships support configurable workflows.
• Managed cloud VMs run independently of clients; Enterprise can run the platform in own infrastructure.
• Separate Linux VM per workspace is documented; chats within one VM share its working files.
• Sleep/wake and archive/restore retain state subject to deletion and history settings.
• Warm/start hooks, pools, services and secrets configure development environments.
• Documented shell timeouts, provider retries and usage limits constrain runs.
• Visible VM/chat/background statuses and usage dashboards expose progress.
• Metered VM compute and usage drilldowns are separate from own model billing.
• CPU/memory drive automatic VM resizing; explicit broader fair scheduling not established.
• Shared teammates can run the same Mothership and workspaces.
• Organization roles and resource Read/Write apply; Enterprise advertises SCIM.
• Organization merge/identity policies and MCP permissions constrain actions.
• Persistent chat and append-only configuration audit retain different histories.
• PR/MR tour, ordered diffs and agent chat support contextual review.
• Shared workspace/Mothership retains conversation and runtime for teammates.
• Canvas retains plans/media and workspace changes for review subject to retention.
• Orchestrator follows CI/review; merge respects repository rules.
• Branches, PR/MR creation, review, checks, conflicts and merge operate inside product.
• Eligible reviewers approve and merge subject to host rules and org policy.
• Workspace/ships retain PR links and delivery state.
• Review queue and Ships board consolidate many requests.
• The main Replicas platform is proprietary closed-source software, offered as a paid managed service or Enterprise…
• Enterprise platform self-hosting and API history access are documented.
• Provider processing, masked analytics, history settings and deletion are disclosed.
• Developer starts$50/month with matching compute allowance; Team$200+; model costs separate.
• Public signup and current weekly releases are documented.
• Vendor claims SOC2TypeI with TypeII in progress; report scope/period not independently verified.
• Evaluation is$100 finite credit without card, not ongoing free hosted usage.
• Public compute rates and allowance are explicit; Enterprise terms require sales.

Sources

• Replicas Workspaces
• Replicas Motherships
• Replicas Automations
• Replicas Desktop app
• Replicas iOS app
• Replicas Team
• Replicas Billing
• Replicas Security policies
• Replicas Data retention
• Replicas Review
• Replicas Learnings
• Replicas Plan mode
• Replicas Codex
• Replicas CLI
• Replicas API
• Replicas MCP server
• Replicas Environments
• Replicas Quickstart
• Replicas Audit log
• Replicas Analytics
• Replicas Changelog
• Replicas Enterprise
• Replicas Privacy
• Replicas Terms

Open the Replicas page

Rookeryfreshness recheckresearch correction46 findings · 13 sources

Findings today

• Rookery supplies native desktop, CLI and Slack clients for its resident daemon.
• Claude and Codex are the only product-owned session/worker backends.
• Own provider API keys or native Claude/Codex login enable agents.
• Bundled desktop runtime or Node 22 headless setup are documented.
• CLI and scoped external MCP drive daemon workers.
• Trusted capability packs supply instructions/skills/MCP to scoped agents.
• Electron/React desktop wraps daemon-backed mission control.
• Prompt, spawn dialog, GitHub issue or Linear ticket can initiate worker.
• Plan cards and session memory retain planning conversation; no native spec approval lifecycle established.
• Home sessions retain child worker relationships; general issue dependency enforcement unknown.
• Local master memory and trusted scope-aware capability packs share context.
• Trusted MCPs and repository context inform agent tasks.
• Rookery persists master/worker agent sessions and external ticket references, without an independent native…
• Global fleet runs parallel worktree workers without a concurrency cap.
• Master or human dispatches workers and routes followups.
• Shipped daemon orchestrator delegates inspectable Claude/Codex worktree workers.
• Persistent daemon rules trigger master turns or worker spawns without client.
• Messages queue at turn boundaries; interrupt/stop and ranked attention support intervention.
• Mission control presents master sessions and global live worker fleet.
• Single session, worker fleet or automation supports natural-language custom orchestration.
• The operator-owned resident daemon runs on a local machine or deliberately configured headless server, independently…
• Rookery workers run native agent processes in separate Git worktrees on the daemon host; they have no…
• Daemon restart reconstructs resumable workers only if session handle and worktree survive.
• Bundled runtime and scoped secret/environment setup support local execution.
• Worker USD budgets and Claude per-send turn caps stop at observed turn results.
• Worker states, transcripts and budget/loop notices expose progress and failure.
• Local usage dashboard and worker cost estimates support spend visibility.
• No fleet concurrency cap; per-worker budgets provide limited control.
• Distinct permitted Slack users can send instructions into the same persistent Rookery master thread.
• Rookery has capability-token control, Slack user allowlists and external MCP read-only/full-control scope, without…
• Headless defaults autoapprove tools; trusted capability digest and MCP scope are separate gates.
• Local session/worker events and checkpoint records persist decisions and activity.
• Per-worker diffs, checkpoints, transcripts and attention queue guide review.
• Forks preserve conversation into same or different provider; colleague access itself unknown.
• Workspace files, diffs, transcripts and Git checkpoints remain locally.
• Reviewer spawning is configurable worker-settled automation, not an enforced exact-revision ship gate.
• Product manages worktrees/branches/diffs; instructed worker uses shell for commit/push/PR.
• Worker shell can run delivery commands when instructed; no separate native merge/deploy authority established.
• Per-turn checkpoints snapshot tracked and untracked work for local restore.
• Attention queue ranks many worker results for review.
• Main application is Apache-2.0; proprietary provider SDK stays separately licensed.
• Full local desktop/daemon source is self-hostable; history lives in local SQLite.
• Task context goes to the selected provider while Rookery history/settings remain local.
• Rookery is Apache-2.0 open source with no paid plan published; you bring your own Anthropic/Codex API keys or CLI…
• Public desktop installers and source are available; v0.6.0 released October 19.
• Apache application is freely installable; model usage and own compute cost separately.

Sources

• Rookery README
• Rookery Fleet lifecycle
• Rookery Master and worker turns
• Rookery Automation architecture
• Rookery Settings
• Rookery Data model
• Rookery Application license
• Rookery Third-party notice
• Rookery desktop implementation
• Rookery worker budget and recovery
• Rookery fleet implementation
• Rookery automation implementation
• Rookery v0.6.0 release

Open the Rookery page

Solentafreshness recheckresearch correction48 findings · 27 sources

Findings today

• Solenta ships macOS, Windows and Linux desktop clients and a host-served browser UI, including phone browsers.
• Installed CLI providers retain their sessions in Solenta.
• Existing subscriptions, keys and local models are documented.
• Setup uses installed CLIs and offers an SSH host installer.
• External MCP callers launch and inspect tasks.
• MCP configuration and skill imports are product-managed.
• The desktop application uses Electron and React.
• External issue trackers remain authoritative.
• Approved task artifacts and repository workflow templates precede dispatch.
• Dependencies constrain dispatch.
• Local project memory carries source context.
• Code indexing and multimodal attachments provide context.
• Solenta's Planboard is backed by GitHub/GitLab issues.
• Agents write the GitHub issues shown on the Planboard.
• Spec mode is scoped to a thread; cross-release maintenance remains unverified.
• Independent provider runs execute concurrently.
• Crews share claims and the global queue gates execution.
• A product-owned orchestrator inspects workers and returns results.
• App-owned schedules and polled events trigger runs.
• Threads support intervention and retain visible failures.
• Fleet views expose relationships and attention states.
• Interactive runs and flexible orchestration coexist.
• Solenta executes installed agent CLIs on the user's local machine or an SSH/headless host.
• Solenta separates code with worktrees and launches local or SSH processes.
• Recovery retains conversations, interrupted phases and outside turns.
• Workspace configuration covers environment and development lanes.
• Budgets and provider quota waits constrain runs.
• Usage, traces and explicit failures are visible.
• Thread usage separates estimates from reported costs.
• Concurrency is bounded by a product queue.
• Multiple paired browser devices can instruct the same host threads through Solenta Web.
• Solenta Web has per-device read-only, steer and full-access grants with revocation.
• Permissions and MCP pairings have bounded grants.
• Activity and checkpoints retain decisions.
• Diff review connects comments to agent follow-ups.
• Diffs, spec artifacts and checkpoints remain linked to threads.
• Configured verification gates green completion.
• The app manages worktree branches and PRs.
• Merge and PR actions are available in the Git pane.
• Checkpoints, revert PRs and post-merge verification aid recovery.
• PR queues organize high-volume review.
• Solenta is publicly MIT licensed.
• The full app runs on owned hosts and exports history.
• Local storage and provider requests have different boundaries.
• The entire Solenta application is free and MIT licensed.
• Release activity is documented.
• The application is free to download.
• The ADE has no application subscription charge.

Sources

• Getting started | Solenta docs
• Threads and providers | Solenta docs
• Orchestration | Solenta docs
• Guardrails and verification | Solenta docs
• Other computers and SSH | Solenta docs
• Phones and browsers | Solenta docs
• Worktrees and pull requests | Solenta docs
• External MCP pairing | Solenta docs
• Shared Memory for Claude Code, Codex and Cursor Agents
• Inbox, Planboard, Review | Solenta docs
• Spec mode | Solenta documentation
• Skills | Solenta documentation
• Automations | Solenta docs
• Spend guardrails | Solenta docs
• Usage and fleet analytics | Solenta docs
• Review itinerary | Solenta docs
• Architecture | Solenta docs
• Solenta: run Claude Code, Codex and Cursor in parallel
• Solenta changelog: release notes and new features
• Notifications and updates | Solenta docs
• Build workflows | Solenta docs
• Codex sessions | Solenta docs
• Import, eject and reclaim | Solenta docs
• Project config files | Solenta docs
• Dev servers | Solenta docs
• Terminal and Browser panes | Solenta docs
• Windows | Solenta documentation

Open the Solenta page

super.engineeringfreshness recheckresearch correction40 findings · 24 sources

Findings today

• Super Engineering ships native macOS and Linux desktop clients, a public iPhone/iPad TestFlight app and bundled…
• Provider adapters distinguish stable chat and experimental terminal paths.
• Subscriptions and API-key profiles remain separate billing paths.
• Git-free local folders and managed SSH helpers have explicit prerequisites.
• Bundled sc controls sessions, worktrees and reviews.
• The app exposes its own context and browser automation commands.
• The desktop app uses native Rust rendering.
• A task starts as a worktree-bound agent session.
• Shared context is experimental and scoped to branch groups.
• Orchestration sequences can express dependencies without a native epic guarantee.
• Context follows a worktree or shared branch group.
• Files and a visible browser provide external context.
• App-managed team roles run concurrently.
• Shared ownership is advisory and versioned.
• Product-owned sc sessions support visible cross-provider delegation.
• Scheduled and event-driven automations are an experimental early preview.
• Agents can be interrupted, stopped and messaged through visible queues.
• Visible agent layouts and an attention inbox help inspect parallel work.
• Explicit natural-language orchestration can evolve during work.
• Local and owned SSH hosts are documented; disconnection durability is unverified.
• Git worktrees separate task code.
• Restore retains bindings with explicit fallback limits.
• Project scripts and managed SSH helpers configure environments.
• Lifecycle events, results and failures are inspectable.
• Provider approvals and browser grants have distinct authority.
• Session history and review threads remain attached to worktrees.
• Native diff comments route findings back to an agent.
• Worktree diffs and experimental HTML chat artifacts are documented.
• Forge checks influence merge state; independent review is a documented orchestration pattern.
• GitHub, GitLab and Bitbucket workflows stay inside the app.
• Mechanical merge actions run directly under forge constraints.
• Delivery state comes from current Git and forge records.
• Attention and review queues support triage.
• The main app uses a limited vendor license.
• The complete core desktop ADE runs on user-controlled hardware without a vendor account.
• Anonymous telemetry can be disabled; provider data flows remain separate.
• Software is free; sponsorship is optional.
• Desktop downloads and iPhone TestFlight access are documented.
• Free application access does not depend on sponsorship.
• No ADE subscription charge is required.

Sources

• Install on macOS | super.engineering Docs
• Install on Linux | super.engineering Docs
• Mobile app | super.engineering Docs
• Providers and models | super.engineering Docs
• Non-Git projects | super.engineering Docs
• CLI automation | super.engineering Docs
• Orchestration overview | super.engineering Docs
• Agent communication | super.engineering Docs
• Coordination state | super.engineering Docs
• Team workflows | super.engineering Docs
• Workspaces, projects, and worktrees | super.engineering Docs
• Shared context | super.engineering Docs
• Session history and restore | super.engineering Docs
• Notifications and approvals | super.engineering Docs
• Review changes | super.engineering Docs
• Git actions and pull requests | super.engineering Docs
• Project config and scripts | super.engineering Docs
• Remote workspaces (SSH) | super.engineering Docs
• Settings reference and privacy | super.engineering Docs
• Files, mentions, and context | super.engineering Docs
• Agent browser control | super.engineering Docs
• Docs | super.engineering
• Terms of Service | super.engineering
• Privacy Policy | super.engineering

Open the super.engineering page

Superconductorfreshness recheckresearch correction47 findings · 24 sources

Findings today

• Superconductor ships browser, macOS/Linux desktop and native iOS/iPad clients.
• Multiple named coding harnesses run in cloud environments.
• Connected subscriptions, API keys and model credits are separate.
• Cloud setup configures repositories, credentials and environments.
• Personal access tokens support a bounded public API.
• Project-managed MCP and repository skills extend agents.
• Native ticket intake includes integrations and agent-created work.
• Ticket descriptions are durable starting briefs.
• Stacked branches retarget after upstream merges.
• Repository skills and project history provide reusable context.
• Agents can retrieve project history and connected knowledge.
• Native tickets are separate from implementation sessions.
• Agents share native ticket reads and creation, with update limits.
• Independent cloud implementations run concurrently.
• Credential precedence and profile selection route work.
• Superconductor supplies always-on agent skills for delegation: create/launch a ticket implementation, inspect its…
• Cloud schedules and merged-PR events trigger actions.
• Chat supports stop and provider-specific steering.
• Activity and ticket cards expose work and attention.
• Model and effort choices can change without replacing a conversation.
• Agent work executes in vendor-managed cloud environments.
• Each implementation has isolated code and enforced network rules.
• Idle pause preserves files but restarts processes.
• Reusable build snapshots separate setup from startup.
• Quota exhaustion and startup failure remain explicit.
• Tool logs and activity metrics expose actual runs.
• Estimated costs and plan-covered token value are distinguished.
• Plan concurrency and environment resources are configurable.
• Multiple workspace members can prompt the same implementation.
• Workspace roles have documented read/write limits.
• Network access and API tokens have bounded grants.
• Shared conversations and activity retain team context.
• Diff comments and Guided Review support agent feedback.
• A colleague can continue the same shared cloud conversation.
• Artifacts and diffs remain with implementations.
• Separate QA validates requirements only for private-beta participants.
• Cloud branches can be submitted or updated as PRs.
• Ticket and implementation state link to pull requests.
• Guided Review and implementation comparisons support review triage.
• Superconductor is offered under vendor-authored service/application terms.
• Vendor states privacy and encryption controls with separate provider requests.
• Free and credit-based paid plans include cloud compute.
• Compute and model charges vary separately by usage.
• A support contact and a 48-hour security-inquiry response aim are documented.
• SOC 2 Type 2 is a future goal, not a current report.
• The Free plan has a one-time compute grant, without recurring credit replenishment stated.
• Credit and compute units are public; final workload cost is usage-dependent.

Sources

• Overview | Superconductor Docs
• Desktop apps | Superconductor Docs
• Mobile apps | Superconductor Docs
• Agents | Superconductor Docs
• Agent credentials | Superconductor Docs
• Superconductor API | Superconductor Docs
• Skills and MCPs | Superconductor Docs
• Connectors | Superconductor Docs
• Superconductor skills | Superconductor Docs
• Quick start | Superconductor Docs
• Tickets | Superconductor Docs
• Implementations | Superconductor Docs
• Chat | Superconductor Docs
• Diff & Guided Review | Superconductor Docs
• QA Checks [Beta] | Superconductor Docs
• Artifacts | Superconductor Docs
• Development environment | Superconductor Docs
• Lifecycle | Superconductor Docs
• Network sandboxing | Superconductor Docs
• Automations | Superconductor Docs
• Workspaces | Superconductor Docs
• Usage | Superconductor Docs
• Pricing | Superconductor Docs
• Security | Superconductor Docs

Open the Superconductor page

Paradevfreshness recheckresearch correction39 findings · 125 sources

Findings today

• Paradev, formerly Superset, has macOS desktop, experimental Linux, CLI and iPhone/iPad clients.
• Superset does not sell model access: all plans use the user's own agent subscriptions or API keys, and it does not…
• Onboarding detects git, gh and installed agents; projects come from a local folder or Git URL and must be git…
• Current CLI and OAuth HTTP MCP tools cover tasks, workspaces, agents, terminals, pages, automations and hosts.
• Current Paradev plugins supply MCP tools and skills with agent-specific support and a vendor credential proxy.
• Native tasks and connected Linear/GitHub issue lists support workspace intake.
• Current automations combine schedules and provider-event triggers, up to 25 per automation, on selected hosts or cloud.
• Local and user-hosted remote execution plus managed Team/Ultra Cloud workspaces.
• Cloud GB-hour usage limits are checked at start/wake and during execution; a running workspace stops about ten…
• Usage estimates token costs from local session logs across supported agents, with workspace/model/session drilldown…
• Granted organization members can open the same remote host workspaces and send input to their shared agent terminals.
• Remote hosts have explicit member grants with owner promotion and removal; Enterprise lists SAML SSO and SCIM.
• Built-in diff and Pull Requests views stage, commit, push, create PRs and merge (squash, merge commit or rebase and…
• PRs can be merged (squash, merge commit, rebase and merge) from Superset on the real PR through the user's GitHub…
• Current desktop-v2.0.5 root repository code is MIT-licensed.
• Per-seat Pro $20 monthly/$192 yearly; Team $60/$648 yearly; Ultra $200 monthly.
• Fixed local/Pro examples: one Free user $0; two Pro users $40/month or $384/year; five $100/month or $960/year.
• Superset became Paradev on October 26, 2026; latest stable desktop-v2.0.5.
• Free covers one local desktop/CLI user without a card.
• Seat prices, pooled Cloud GB-hours and $0.06/GB-hour extras are public.
• Paradev states it completed a SOC 2 Type II audit (Aug 27, 2026 changelog entry) and lists the SOC 2 Type II report…
• Paradev documents 22 built-in terminal agents, custom CLI agents and mixed-harness orchestration.
• Paradev documents parallel agents in separate local worktrees, with sidebar activity and workspace list/board views.
• Paradev bundles the superset:orchestrate skill: a Claude Code or Codex coordinator launches mixed-agent workers via…
• Paradev documents split/unified and binary diffs, versioned Pages with workspace lists and retrieval, browser…
• The MIT local core can import a repository, run agents and review diffs signed out and offline on the user machine,…
• Bundled Superset skills are installed into agents, and a session can be handed to another agent with its last 36,000…
• Design mode sends screenshots and DOM context to agents and the Slack agent searches the web with citations; code…
• Native tasks support create, edit, priority, assignee, labels (with label hierarchy), semantic search,…
• Agents can list, read, create, update and soft-delete tasks over MCP, CLI and SDK.
• Local workspaces are git worktrees on separate branches; the FAQ states they are not sandboxes and share processes,…
• Terminals run in a background daemon that survives app restarts and updates; unexpected agent-terminal deaths…
• Setup and teardown commands run per workspace on create and delete (install dependencies there).
• Agents can pause for tool approval in the chat pane.
• Sessions, run history and task activity persist; export, retention and integrity are not documented.
• Pull Requests and diff views offer split/unified/focus diffs, check status, review threads and iPhone diff review.
• PR-based workspaces show pull request state in the sidebar, and an Open Preview button appears when the branch has a…
• The Pull Requests view lists PRs with check counts, and attention-based board columns (Needs attention, Needs…
• Paradev discloses desktop analytics.

Sources

• Superset
• Pricing
• Tasks
• Remote Access
• Task router
• The Superset Model
• Workspaces
• Diff Viewer
• Pull Requests
• Agent Sessions & Forking
• Agent Status & Notifications
• Automations
• Superset MCP Server
• Superset CLI Reference
• Host Server
• Superset SDK Reference
• Slack Integration
• FAQ
• Troubleshooting
• Terminal
• Project Lifecycle Scripts
• Port Management
• Pages
• In-App Browser
• Skills
• Superset changelog
• Superset for iPhone
• Privacy Policy
• Desktop analytics
• Database schema: tasks
• Desktop task record screen
• Superset desktop shared constants (pinned)
• Overview and Node.js setup examples
• Port ranges and busy ports
• setUserId lines 36 to 38; track() lines 40 to 45; isTelemetryEnabled lines 32 to 34
• Read an Agent's Transcript
• PR Status
• Sandbox Access; Inline Prompts
• Tasks section (tracker selection and --tracker flag)
• Run Script section; How It Works step 3
• Superset
• Pricing
• Tasks
• Remote Access
• Task router
• Superset roadmap
• Install
• The Superset Model
• Workspaces
• Diff Viewer
• Pull Requests
• Agent Status & Notifications
• Automations
• Usage
• Superset MCP Server
• Superset CLI Reference
• Host Server
• TypeScript SDK
• Superset SDK Reference
• Linear Integration
• Slack Integration
• Providers
• FAQ
• Troubleshooting
• Pages
• Skills
• Your First Parallel Session
• Clear PR Feedback in the Background
• Superset changelog
• Superset for iPhone
• Superset releases
• Superset issues
• Database schema: tasks
• Superset CLI: Getting Started
• Superset changelog: event triggers entries (Aug 23 and Oct 4, 2026)
• Chat Integration
• Tasks section (tracker selection and --tracker flag)
• Paradev desktop-v2.0.5 root license
• Cloud Workspaces
• Plugins overview
• Install | Paradev Docs
• Paradev README at desktop-v2.0.5
• Paradev AI Agents
• Paradev Supported Agents
• Paradev provider configuration
• Paradev Chat interface
• Paradev Agent Sessions & Forking
• Paradev Agent Status & Notifications
• Paradev Workspaces
• Paradev Agent Orchestration
• Paradev Skills
• Paradev CLI reference
• Paradev In-App Browser
• Paradev Diff Viewer
• Paradev Pages
• Paradev FAQ
• Paradev Remote Access
• Paradev Pricing
• Paradev Changelog
• Paradev MIT licence at desktop-v2.0.5
• Paradev README at desktop-v2.0.5
• Paradev task schema at desktop-v2.0.5
• Paradev Tasks
• Paradev desktop-v2.0.5 release
• Paradev roadmap local-first shipped entry
• Paradev: mcp-server
• Paradev: sdk/reference
• Paradev: cli/cli-reference
• Paradev: plugins/build-a-plugin
• Paradev: plugins/organization-plugins
• Paradev: skills
• Paradev: editor
• Paradev: tasks
• Paradev: bring-your-own-cloud
• Paradev: cloud-workspaces
• Paradev: agent-sessions
• Paradev: setup-teardown-scripts
• Paradev: ports
• Paradev: pages
• Paradev: pull-requests
• Superset has a new name: Paradev
• Paradev Tasks
• Migrate from Conductor
• Paradev home page
• Paradev changelog: SOC 2 Type II (Aug 27, 2026)

Open the Paradev page

Synarafreshness recheckresearch correction48 findings · 22 sources

Findings today

• Synara ships macOS, Windows and Linux desktop clients plus a self-hosted browser workspace.
• Synara's fixed runtime adapters cover Claude Code, Codex, OpenCode, Cursor, Grok, Pi, OMP, Droid, Antigravity and Devin.
• Existing provider accounts and subscriptions are reused.
• Local and headless setup have explicit prerequisites.
• Paired external MCP and server startup/status commands are documented.
• MCP clients and app-owned tools have explicit provider boundaries.
• The desktop application is packaged with Electron.
• To-dos and coordinator requests are separate intake routes.
• Durable task briefs survive without dispatch.
• Hubs retain coordinator-worker associations and queues.
• Hub instructions, memory and Library persist across workers.
• Editor intelligence and external MCP supply scoped context.
• Native to-dos remain separate from agent chats.
• Agents maintain the same native to-do IDs.
• Hub workers and standalone tasks can run concurrently.
• Hub queues and idempotent operations bound dispatch.
• The product-owned gateway coordinates visible task workers.
• Schedules and heartbeat conditions drive app-owned runs.
• Tasks expose intervention and pending approvals.
• Inbox and Hubs group attention and worker progress.
• Quick chats and coordinator workflows can evolve with provider handoffs.
• Core server and agents can run on owned infrastructure.
• Synara separates task code with managed worktrees and launches provider processes on the execution host.
• Server transcripts and provider recovery retain explicit limits.
• Headless remote-host installation is documented; project dependency, service and collision handling are not.
• Failure policy and opt-in limit recovery constrain repeated work.
• Usage snapshots and work logs expose recorded state.
• Recorded provider usage is distinguished from missing metrics.
• Hub parallelism limits and a persistent queue bound concurrent workers.
• Multiple authorized browser clients can send instructions into the same server thread through the shared…
• Synara authenticates owner/client sessions and guards owner-only account operations.
• Task and integration privileges are bounded without worker self-approval.
• Transcripts and versioned Library retain history.
• Editor diffs and PR repair keep review near the task.
• Provider handoff preserves task identity with stated context limits; human colleague takeover was not established.
• Library, diffs and previews retain deliverables.
• PR checks and separate review tasks are documented without a universal spec gate.
• GitHub PR and local Git operations are integrated.
• Remote PR actions use GitHub authority.
• Checkpoint and PR records retain recovery context.
• PR aggregation and attention groups help batch review.
• Main application code is public under MIT.
• The core ADE can be run from source or a headless release.
• Local state, connectors and diagnostics have separate boundaries.
• Local use of Synara is free ($0, no card or account) and MIT open source.
• Stable release and source support channels are public.
• MIT source can be used without an ADE license fee.
• Source license is free while provider billing remains external.

Sources

• Synara v1.1.0 documentation: getting-started/installation
• Synara v1.1.0 documentation: getting-started/providers
• Synara v1.1.0 documentation: getting-started/first-task
• Synara v1.1.0 documentation: features/provider-accounts
• Synara v1.1.0 documentation: features/hubs
• Synara v1.1.0 documentation: features/tasks-and-inbox
• Synara v1.1.0 documentation: workflows/agent-gateway
• Synara v1.1.0 documentation: workflows/external-mcp
• Synara v1.1.0 documentation: workflows/headless-server
• Synara v1.1.0 documentation: features/connectors
• Synara v1.1.0 documentation: features/conversation-history
• Synara v1.1.0 documentation: features/workspace-editor
• Synara v1.1.0 documentation: workflows/worktrees
• Synara v1.1.0 documentation: workflows/pull-requests
• Synara v1.1.0 documentation: workflows/automations
• Synara v1.1.0 documentation: workflows/handoffs
• Synara v1.1.0 documentation: features/synara-beta
• Synara v1.1.0 documentation: troubleshooting/diagnostics
• https://raw.githubusercontent.com/Emanuele-web04/synara/b6aa37bc82eec649dd527c5956fdccc2c63d3b24/README.md
• https://raw.githubusercontent.com/Emanuele-web04/synara/b6aa37bc82eec649dd527c5956fdccc2c63d3b24/LICENSE
• https://raw.githubusercontent.com/Emanuele-web04/synara/b6aa37bc82eec649dd527c5956fdccc2c63d3b24/apps/desktop/package.json
• https://api.github.com/repos/Emanuele-web04/synara/releases/latest

Open the Synara page

T3 Codefreshness recheckresearch correction37 findings · 76 sources

Findings today

• v0.1.7 documents Mac/Windows/Linux desktop, iOS/Android mobile, web and CLI.
• v0.1.7 documents installed Codex, Claude Code, Cursor, Grok Build, Kiro (beta, Early Access), OpenCode, Antigravity,…
• T3 Code reuses each provider's own subscription or login, supports multiple accounts per provider and per-instance…
• The t3 CLI and remote HTTP MCP expose project/thread operations in v0.1.7.
• Partly established for T3 Code v0.1.7 at thread level: threads can exist without a project, and settling keeps…
• Provider usage-limit stops (for example Claude subscription limits, and Codex windows when Codex reports them) are…
• v0.1.7 Usage shows provider/token estimates and model trend, cache-hit-rate and cost-per-million drilldown.
• Terms state no T3 Tools subscription fee currently, unless a feature states otherwise; they do not mention seats or…
• The current terms state no T3 Tools subscription fee and do not mention seats or user counts; provider usage and…
• Latest stable is v0.1.7, displayed November 4; v0.1.8 nightly builds are separate.
• T3 Code is currently offered without a T3 Tools subscription fee, and the terms allow paid features with prices…
• The pricing URL returned HTTP 404 and the homepage was reachable in the November 7 second pass.
• T3 Code relies on the underlying harness for MCP servers, plugins and skills; it reads skills from harness config…
• Plan mode and proposed-plan artifacts exist in current stable.
• Stable v0.1.7 has T3-owned MCP delegation across compatible providers, with role/model selection, scoped…
• Stable v0.1.7 runs server-owned recurring/one-time schedules and webhook tasks with signature, filtering,…
• Users can queue follow-ups or steer new messages into a running turn, interrupt the turn with the thread.stop…
• The sidebar groups and searches saved threads; Agents views and cards expose delegated children and retained results…
• Threads can start without a project and choose model or permission defaults.
• T3 Code uses project checkouts or per-thread Git worktrees and launches provider/ACP processes on the environment host.
• Threads persist on the environment server.
• Project actions and automatic submodule initialization for new worktrees are documented; desktop-managed SSH relies…
• The Usage page reports token use, cache savings, model breakdowns and estimated cost over 24 hours to 90 days, with…
• Optional beta guestlinks share recent/live thread history and accept guest messages/files, gated by the owner…
• T3 Code controls devices with environment pairing credentials, session tokens and scoped grants; administrators can…
• Thread permission modes expose command, edit and child approvals in the conversation, with provider-specific…
• Current stable PR review includes mobile diffs/draft comments and optional beta model-written guides with ordered…
• Partly established for T3 Code v0.1.7: pull requests can be reviewed, reviewers requested and merged from T3;…
• Threads can use per-thread worktrees and branches, commit, push and open pull requests with generated titles and…
• Linked pull requests, PR status badges and GitHub revert-PR creation are documented; rollback via checkpoints and…
• Optional beta PR review guides provide ordered stops, grouped mechanical changes, retained review context and agent…
• Self-hosted environment servers can use LAN, SSH or optional T3 Connect.
• The live privacy policy describes anonymous usage data sent by default; the pinned telemetry guide describes a…
• Agents run on the user's own machine or a machine they keep running (SSH, T3 Connect, LAN/tailnet); clients on other…
• Threads retain conversations and tool activity, but supported rewind can remove later conversation history.
• Portable provider handoff preserves a bounded selection of saved conversation context and retrieval references.
• Workspace file changes are captured in hidden Git checkpoint refs, and the Terms describe T3 displaying file changes…

Sources

• T3 Code README at v0.0.45
• Remote access (v0.0.45)
• T3 Code home page
• Install T3 Code (v0.0.45)
• Permission modes (v0.0.45)
• Source control (v0.0.45)
• Usage and limits (v0.0.45)
• Working with threads (v0.0.45)
• Messages and context (v0.0.45)
• Settings and project overrides (v0.0.45)
• Devices (v0.0.45)
• Updating T3 Code (v0.0.45)
• Running T3 Code in the background (v0.0.45)
• Product usage data (v0.0.45)
• Codex provider (v0.0.45)
• Claude provider (v0.0.45)
• OpenCode provider (v0.0.45)
• Antigravity provider (v0.0.45)
• Mobile notifications (v0.0.45)
• Welcome wizard (v0.0.45)
• T3 Code internals overview (v0.0.45)
• Keyboard shortcuts (v0.0.45)
• T3 Code v0.0.45 release
• T3 Code Privacy Policy
• T3 Code Terms of Service
• Ideas: Environment-level MCP servers shared by every provider
• Feature: On-demand cloud task environments through an external sandbox broker
• T3 Code docs/internals/providers.md on main (9a3070b)
• Usage guide, main branch
• Keybindings guide, main branch
• Portable handoffs (main 9a3070b, unreleased)
• T3 Code README at v0.0.45
• Remote access (v0.0.45)
• T3 Code LICENSE at v0.0.45
• Install T3 Code (v0.0.45)
• Source control (v0.0.45)
• Usage and limits (v0.0.45)
• Working with threads (v0.0.45)
• Messages and context (v0.0.45)
• Running T3 Code in the background (v0.0.45)
• Codex provider (v0.0.45)
• Claude provider (v0.0.45)
• Antigravity provider (v0.0.45)
• Mobile notifications (v0.0.45)
• Welcome wizard (v0.0.45)
• T3 Code releases
• T3 Code Security Policy
• T3 Code Terms of Service
• T3 Code v0.1.7 outside agents
• T3 Code v0.1.7
• T3 Code v0.1.7 portable context
• T3 Code pricing URL second-pass response
• T3 Code v0.1.7: docs/user/faq.md
• T3 Code v0.1.7: docs/user/providers-acp.md
• T3 Code v0.1.7: docs/user/outside-agents.md
• T3 Code v0.1.7: docs/user/permission-modes.md
• T3 Code v0.1.7: docs/user/project-settings.md
• T3 Code v0.1.7: apps/web/src/components/chat/ProposedPlanCard.tsx
• T3 Code v0.1.7: docs/orchestration-v2/orchestrator-mcp-server.md
• T3 Code v0.1.7: apps/server/src/mcp/toolkits/orchestrator/tools.ts
• T3 Code v0.1.7: docs/user/thread-sidebar.md
• T3 Code v0.1.7: docs/user/providers-pi.md
• T3 Code v0.1.7: docs/user/portable-handoffs.md
• T3 Code v0.1.7: docs/user/thread-migration.md
• T3 Code v0.1.7: docs/user/providers-opencode.md
• T3 Code v0.1.7: docs/user/terminal.md
• T3 Code v0.1.7: docs/user/telemetry.md
• T3 Code v0.1.7: docs/user/guest-links.md
• T3 Code v0.1.7: docs/user/managed-policy.md
• T3 Code v0.1.7: docs/user/source-control.md
• T3 Code v0.1.7: remote access
• T3 Code v0.1.7: docs/user/background-service.md
• T3 Code v0.1.7: docs/user/keybindings.md
• T3 Code v0.1.7: docs/user/mobile-notifications.md
• T3 Code v0.1.7: docs/user/updating.md
• T3 Code v0.1.7: docs/internals/overview.md

Open the T3 Code page

Temboresearch correctionfreshness recheck42 findings · 22 sources

Findings today

• Tembo offers web/desktop, device CLI and documented iOS/Android phone-browser PWA.
• Public API and sandbox tools expose agents, sessions, artifacts, schedules and run state; pairing CLI is separate.
• Tembo planning mode produces a plan for review and a shareable artifact.
• Tembo documents sessions consuming worker capacity and self-hosted pools running separate VM sessions.
• Tembo capacity queues integration bursts and self-hosted hosts claim sessions.
• Scheduled and event-triggered agents run in the background in Tembo sandboxes; capacity and spend constraints are…
• Tembo exposes planning/questions, live steering, recovery controls and reset/retry.
• Cloud VMs and licensed/self-hosted machines have distinct responsibility and resource boundaries.
• Dated release notes report automatic recovery; self-hosted same-host memory and replacement-host disk restores differ.
• Project environments cache setup, and setupScript reruns only on fresh builds.
• Session admission respects allowance/overage caps; existing runs can continue and setup hook failures are non-blocking.
• Public API reports run status, duration and errors; Billing separates usage categories.
• Self-hosted host controller sizes pools from running/waiting memory and bounded host counts.
• Tembo documents enterprise SSO, admin/reviewer/operator roles and team/repository permissions.
• Vendor documents centralized audit trails for every agent session, with prompt-to-PR traceability, configurable…
• Tembo supports file artifacts created for sessions, preview service artifacts and PR-linked diffs.
• Current plans pool gateway/compute usage with optional capped overages.
• Compute/model units, overage admission and custom Enterprise pricing are documented.
• Tembo manages MCP integrations and repository/workspace skills.
• External issues, chat and Git events supply agent intake.
• Repo/project rules and managed skills provide repeatable workspace context.
• Tembo publishes model/compute usage accounting with separate Billing categories.
• Setup hooks are not delivery gates; prePush is explicitly not executed.
• Session sandbox cleanup differs from Cloud Git mirrors, audit retention and provider inference.
• Vendor reports SOC 2 Type II and ISO certifications; report scope, issuer and audit period remain unverified.
• A seven-day trial is followed by paid continuation when time or allowance expires.
• Agents have selectable harness and model defaults.
• Tembo documents BYOK and separate agent-subscription routes.
• Self-hosting uses a licensed machine image and browser installer.
• Rule files can carry architecture conventions; enforcement was not demonstrated.
• Agents can update external issue records through connected services.
• Tembo supports planning, session forking and reusable agent instruction revisions.
• Cloud sessions have dedicated VMs; device commands use host-user permissions.
• Workspace visibility can be set per session.
• Connected devices are restricted to owner-started human sessions.
• Tembo documents expandable task diffs and line comments.
• PR actions support multiple repositories and Git providers.
• Documentation leaves review and merge to the user.
• PRs retain links to the starting issue, error or session.
• Tembo is offered under vendor-authored service/license terms.
• The licensed self-hosted platform remains dependent on vendor release licensing.
• Desktop and Devices have explicit release/access restrictions.

Sources

• Tembo downloads
• Tembo agents
• Tembo models
• Tembo sandbox
• Tembo self-hosted
• Tembo connected-device CLI
• Tembo MCP connections
• Tembo rule files
• Tembo prepared projects
• Tembo pull requests
• Tembo agent actions
• Tembo pricing
• Tembo changelog
• Tembo Installation; Supported browsers
• Tembo Available hooks; When setup runs; Failure handling
• Tembo Repository skills; Managed skills
• Tembo MCP; Sessions/artifacts; CLI commands
• Tembo Public API index; Agent instruction revisions; Artifacts
• Tembo Allowance; Overages; Bursts; Monitoring
• Tembo Access controls; Compliance; Data handling
• Tembo Classes/pools; Scaling; Sessions
• Tembo Sep 18 automatic recovery; Sep 11 planning; Sep 4 plan artifacts; Apr 17 diff comments

Open the Tembo page

Unpeelfreshness recheckresearch correction40 findings · 24 sources

Findings today

• Unpeel ships a native Apple-Silicon Mac GUI, iPhone/iPad clients and a native macOS/Linux CLI.
• CLI runtime integration is provider- and launch-specific.
• Users bring provider logins and API keys.
• App setup bundles server; headless hosts have a supported installer.
• CLI and session-scoped MCP expose actual operations.
• Built-in MCP and optional Plugins expose tools with per-session grants.
• Apple clients use Swift platform packages.
• Project folders and presets provide session intake.
• Provider transcripts and skill guidance are distinct from managed product memory.
• Browser tools and image attachments provide task context.
• The scoped Unpeel core persists projects, presets and terminal sessions, without a native issue/backlog entity…
• Multiple live sessions run concurrently.
• Workspace process leases and occurrence checks prevent stale targeting.
• In the pinned v0.7.6 core, a session granted Create & remove can create worker sessions, inspect transcripts/state,…
• Unpeel's headless product CLI explicitly supports starting/driving sessions from external CI or cron.
• Terminal state and intervention remain visible across clients.
• Fleet activity groups attention without requiring every transcript.
• Any command can run in a configurable preset.
• Owned hosts continue sessions independently of clients.
• Unpeel uses detached Host-user PTYs, separate workspace state and optional worktrees.
• Client/worker recovery differs from process death and stopped-output retention.
• Host service and browser engine have product-owned setup.
• Runtime identity checks bound resume operations.
• Status authority and retained diagnostic limits are explicit.
• Usage plugins are optional external views; billing reconciliation remains unverified.
• Paired clients can enter the same terminal session.
• Unpeel's core uses paired-client Host access.
• Peer writes and device access are scoped and revocable.
• Host files and provider transcripts retain inspectable history.
• Unpeel's optional first-party Git sidebar App displays proposed working-tree code changes and commit patches in…
• Another paired client can inspect and continue the same session.
• Per-session image artifacts connect browser output to phone review.
• Unpeel's optional Git App displays history/diffs and performs fetch, fast-forward pull and push.
• Core local/direct functionality can be hosted without Link.
• Host content stays local; relay and notifications have different metadata paths.
• Local app is free; optional Link is billed yearly per Host seat.
• Costs separate free local software from optional service and agent usage.
• A dated release and contact support are available.
• Local application and direct pairing are free.
• Optional service price and cancellation are public.

Sources

• Getting started — Unpeel Docs
• How Unpeel runs — Unpeel Docs
• Supported agents — Unpeel Docs
• Agent runtimes — Unpeel Docs
• CLI reference — Unpeel Docs
• Headless Host — Unpeel Docs
• Workspaces — Unpeel Docs
• Git worktrees — Unpeel Docs
• Unpeel Link — Unpeel Docs
• Overview — Unpeel Docs
• Sessions — Unpeel Docs
• Agents — Unpeel Docs
• Session gallery — Unpeel Docs
• Sessions & terminals — Unpeel Docs
• Activity & the menu bar — Unpeel Docs
• Overview — Unpeel Docs
• Projects & presets — Unpeel Docs
• Terms of service — Unpeel
• Privacy policy — Unpeel
• Changelog — Unpeel
• https://raw.githubusercontent.com/unpeel-com/unpeel/e2e0e647a51422683639b858e08cf48b46827c9e/README.md
• https://raw.githubusercontent.com/unpeel-com/unpeel/e2e0e647a51422683639b858e08cf48b46827c9e/clients/native/UnpeelNative/Package.swift
• https://raw.githubusercontent.com/unpeel-com/unpeel/e2e0e647a51422683639b858e08cf48b46827c9e/clients/ios/UnpeelIOS/Package.swift
• unpeel-usage README (pinned Unpeel repository)

Open the Unpeel page

Verdentfreshness recheckresearch correction43 findings · 32 sources

Findings today

• Desktop, Cloud browser and VS Code clients have distinct capabilities.
• Desktop has built-in agents plus named external worker harnesses.
• BYOA runtime login and BYOK provider billing are separate.
• Local, SSH and Cloud projects have separate onboarding.
• MCP, skills and plugins extend Desktop workflows.
• Manager turns requests into tracked task work.
• Plans include structured subtasks and acceptance criteria.
• Manager decomposes stages and dependencies.
• Manager memory and project rules provide reusable context.
• Context retrieval and external tools are documented; shipped repository indexing remains unverified.
• Desktop has tracked task cards and a review column; task/session separation is not established.
• Manager workers and Cloud tasks can run concurrently.
• Manager dispatches and routes worker models.
• Manager is a product-owned coordinator with specialized workers.
• Desktop schedules require the app to stay active.
• Tasks allow feedback and explicit approval prompts.
• Kanban board exposes progress and review attention.
• Quick execution and planning can be selected by task needs.
• Local/SSH Desktop and vendor Cloud modes have different lifetimes.
• Desktop worktree isolation separates file and Git state.
• Reopened tasks retain context while uncommitted workspace files need care.
• Environment and tool settings have explicit limits.
• BYOK key/balance failures and missed schedules surface visibly.
• Tools, task states and balances are visible.
• Credit balance and usage history are available.
• Team Owner and member access includes Feishu SSO.
• Certain operations require user approval.
• Task conversations retain decisions and results.
• Reviewer findings and Task Changes provide code review.
• Task outputs and Cloud previews remain accessible.
• Optional Reviewer and review rules provide verification guidance.
• Desktop supports worktree rebase and change review.
• Cloud publishing is explicit and resource-gated.
• Published apps have URLs and observable build progress.
• To Review and structured findings support review triage.
• Application code rights remain with the vendor.
• Cloud and account dependencies are explicit; core self-hosting is unverified.
• Current public monthly plans start at $5.
• Fixed subscription and variable credit charges are separate.
• Release and support commitments are dated.
• Vendor states assurance certifications are being pursued.
• Desktop v2.18 retires free AI use and welcome-credit evaluation.
• Plan/top-up units and renewal rules are public.

Sources

• Overview | Verdent Docs
• Supported Operating Systems | Verdent Docs
• Quick Start | Verdent Docs
• Manager | Verdent Docs
• Multiple Managers | Verdent Docs
• Automation | Verdent Docs
• Bring Your Own Agent (BYOA) | Verdent Docs
• Bring Your Own Key (BYOK) | Verdent Docs
• Subagents | Verdent Docs
• Rules | Verdent Docs
• MCP Integration | Verdent Docs
• Skills | Verdent Docs
• Integration | Verdent Docs
• Plan Mode | Verdent Docs
• Agent Mode | Verdent Docs
• Code Review | Verdent Docs
• Workspace Isolation | Verdent Docs
• Cloud Projects and Publishing | Verdent Docs
• Verdent Cloud Overview | Verdent Docs
• Overview | Verdent Docs
• Managing Tasks | Verdent Docs
• Parallel Work and Multitasking | Verdent Docs
• Differences from Desktop | Verdent Docs
• Version Control | Verdent Docs
• Credits and Plans | Verdent Docs
• Billing Cycle and Rollover | Verdent Docs
• Configure Feishu SSO for Verdent Team | Verdent Docs
• Verdent AI Pricing | Subscription Plans
• Changelog · Verdent
• Verdent AI Privacy Policy
• Verdent AI Security Policy
• Terms of Use · Verdent

Open the Verdent page

Vibe Kanbanresearch correctionfreshness recheck43 findings · 40 sources

Findings today

• Local Codex uses native login or API keys and detects custom configuration directories.
• Local plan approval and workspace notes coexist with explicit archive retention.
• Local sessions share files and reusable prompts while keeping conversations separate.
• Local chat provides stop, queue/retry and history controls.
• Local users can try a different approach by duplicating a workspace, which keeps the repository/branch configuration…
• Branches/worktrees separate workspace files; sessions within one workspace share files/Git.
• Local archive preserves history/files and missing worktrees rebuild from last commit with uncommitted changes lost.
• Repository setup/dev/cleanup scripts prepare environments with user-defined lifecycle behavior.
• Local logs include expandable tool command/search results and execution states.
• Local conversation history persists across session switches and archive, but message retry can replace later visible…
• Local review UI provides diff modes, filtered files and submitted GitHub comments.
• Local archive retains conversation notes/files, while diffs and previews remain separate review views.
• Local telemetry has a settings toggle and a released source default of enabled, but a successful sign-in turns…
• Local merge is documented.
• The pinned release ships an explicit orchestrator MCP mode.
• The continuing local product provides browser workspaces, a product CLI and Tauri desktop packages.
• Released source integrates multiple coding-agent adapters; actual mixed-harness execution was not tested.
• The documented local flow is npx, agent authentication and repository selection.
• Local MCP provides workspace start, session creation/follow-up and execution inspection.
• Vibe Kanban manages per-harness MCP configuration; connections and permissions execute through the selected harness.
• The desktop distribution uses Tauri webviews and a web UI.
• Local prompt-driven workspaces continue independently of the retired hosted issue tracker.
• Local chat accepts file mentions and images; architecture-aware retrieval and enforcement remain untested.
• The vendor-hosted issue board is retired.
• Docs describe independent sessions that can run simultaneously and multiple workspaces.
• In the pinned local continuation, work starts through explicit session/workspace requests.
• The local workspace list supplies session status context, but a 12-state fleet/epic fixture was not evaluated.
• Local agent execution continues.
• Approval timeouts are documented; enforced time, token and spend budgets remain unverified.
• The documented context gauge is not a verified cost ledger.
• Resource limits, check reuse and fleet backpressure remain unknown.
• The shutdown announcement retired vendor-hosted issue discussion/comments.
• The vendor-hosted organisation/project service was named for retirement.
• Harness-specific plan/permission controls appear in local configuration.
• Repository scripts can run checks; docs advise review and CI before merge.
• Local workspace docs cover branches/worktrees, PR creation, push, merge and rebase/conflict handling.
• Git PR workflow is documented, but completion-to-revision evidence, rollback and stale-approval invalidation were…
• Single-workspace review is documented; six-output batch review, dependency queues and exact-revision approvals…
• Pinned repository distribution has an Apache-2.0 license.
• Local workspaces continue without vendor sign-in.
• Commercial services were sunset while the local open-source project continues.
• The local open-source project remains available without vendor sign-in.
• Commercial subscriptions were terminated, so historical Vibe Kanban tariffs do not describe a current service.

Sources

• Goodbye bloop
• Release v0.1.44
• What would a community edition of Vibe Kanban look like?
• packages/web-core/src/pages/kanban/ProjectKanban.tsx
• packages/web-core/src/pages/kanban/ProjectSunsetPage.tsx
• packages/web-core/src/pages/export/ExportPage.tsx
• crates/remote/src/routes/export.rs
• crates/tauri-app/tauri.conf.json
• crates/tauri-app/src/main.rs
• crates/executors/src/executors/mod.rs
• crates/executors/src/executors/codex.rs
• crates/mcp/src/task_server/tools/sessions.rs
• crates/mcp/src/task_server/tools/task_attempts.rs
• crates/mcp/src/task_server/tools/remote_issues.rs
• crates/services/src/services/config/mod.rs
• crates/services/src/services/config/versions/v8.rs
• LICENSE
• getting-started
• workspaces/index
• workspaces/creating-workspaces
• workspaces/sessions
• workspaces/chat-interface
• workspaces/git-operations
• settings/general
• settings/projects-repositories
• settings/agent-configurations
• agents/openai-codex
• integrations/vibe-kanban-mcp-server
• integrations/mcp-server-configuration
• integrations/vscode-extension
• browser-testing
• self-hosting/deploy-docker
• Changes Panel
• crates/server/src/routes/workspaces/git.rs
• Vibe Kanban docs/workspaces/managing-workspaces.mdx
• Vibe Kanban docs/workspaces/sessions.mdx
• Vibe Kanban docs/settings/projects-repositories.mdx
• Vibe Kanban docs/workspaces/chat-interface.mdx
• Vibe Kanban docs/workspaces/changes.mdx
• Vibe Kanban Login; Custom configuration

Open the Vibe Kanban page

Warpresearch correctionfreshness recheck37 findings · 25 sources

Findings today

• Warp Terminal downloads are offered for macOS 10.14+, Windows 11/10 and Linux.
• Terminal integrations include Claude Code, Codex, OpenCode, Cursor CLI, Gemini CLI, Pi and Grok Build, plus Amp,…
• A third-party Claude Code session uses the user’s paid Claude plan or API credits through Claude login, separate…
• Install the CLI, start warp, approve its browser device-code login, then send a first prompt.
• warp starts the standalone interactive Warp Agent CLI; /status reports version, conversation ID and account.
• Warp local agents can use configured command, Streamable HTTP or SSE MCP servers.
• /plan or a natural-language request creates a structured plan.
• Global Rules and repository AGENTS.md or backward-compatible WARP.md provide reusable instructions.
• Without indexed context agents can still navigate with grep and sed.
• Agents automatically create step lists for complex requests.
• The agent automatically decomposes complex requests into task lists.
• Plans persist as reusable documents in Warp Drive.
• A native parent agent spawns and coordinates child agents.
• /orchestrate accepts a natural-language task and proposed child boundaries.
• Warp runs agents on local worktrees and via SSH.
• Each worktree has its own checked-out branch and Git status.
• Finished command blocks can be shared by permalink or embed; this does not establish co-prompting.
• Single-team workspaces have Owner, Admin and Member roles.
• Command permissions, allowlists and denylists control approval prompts.
• The product page describes reviewing changes, commenting and sending changes back to agents.
• A collaborator with edit access can continue prompting the same shared session.
• Warp detects worktrees for branch-aware review and indexing.
• Line/block comments collect concrete requested changes.
• Warp's privacy documentation says its client source is open source under AGPL v3 and links warpdotdev/warp.
• Terminal and customer execution are local/customer-controlled, while orchestration, observability and inference…
• With telemetry disabled no console interactions are persisted on Warp servers, according to the privacy documentation.
• Warp states SOC 2 Type II certification.
• Ctrl+C stops a streaming agent response or running command.
• CLI conversation history saves and syncs with the Warp account, including after exiting.
• Every CLI conversation is saved automatically as work proceeds.
• Warp documents running several Warp Agent conversations in parallel, tracked in the Agent Management Panel, and…
• Tab indicators can mark commands that exit with errors; full task-state consistency was not tested.
• Warp says the user's own provider bills customer-supplied inference separately.
• An integrated editing and review interface is advertised, without an artifact persistence test.
• Build is $20/month monthly or $18/month annually.
• Free is $0/month with core terminal features, limited cloud access and limited conversation storage; additional…
• Platform usage applies to cloud runs and to local Business or Enterprise runs with customer-supplied inference;…

Sources

• Warp Terminal
• Warp Terminal documentation bundle
• Warp pricing
• Platform usage
• Warp Agent CLI
• Warp Agent CLI quickstart
• Third-party CLI agents overview
• Set up Claude Code
• Agent Session Sharing
• Agent planning and execution
• Agent Task Lists
• Rules for agents
• Model Context Protocol
• Codebase Context
• Git worktrees
• Running orchestrated agents
• Profiles & Permissions
• Roles and permissions
• Privacy and data control
• Architecture and deployment
• Warp Trust Center
• Interactive Code Review
• Agent conversations in Warp Agent CLI
• warpdotdev/warp LICENSE-AGPL
• warpdotdev/warp README

Open the Warp page

Warp Factories / Ozresearch correctionfreshness recheck48 findings · 33 sources

Findings today

• Warp desktop app is offered on macOS, Windows and Linux and exposes the cloud-agent setup and conversation surface…
• The documented harness identifiers are oz, claude and codex; factory agents can use different harnesses.
• Managed-secret Codex cloud authentication bills a funded OpenAI API account, not a ChatGPT subscription; Claude Code…
• Guided browser onboarding offers automation, app-based cloud agents or programmatic agent workflows.
• oz agent run-cloud and oz agent run provide distinct managed and unmanaged execution.
• Factory and standalone agents use stdio, Streamable HTTP or SSE MCP servers.
• A direct request goes to the factory foreman.
• A spec agent defines behavior, constraints and validation criteria when planning is needed.
• Default spec approval is foreman instruction policy; merging is enforced by repository permissions and branch…
• Factories accept direct requests, integration events or Factory MCP tasks.
• External coding agents retrieve the same task through URL, source ticket, PR or branch reference.
• Spec agent produces behavior, technical constraints and validation criteria for a work item.
• Parent and child agents execute in parallel with independent conversations and run lifecycles.
• The foreman routes work to triage, spec, implement or review agents.
• A parent spawns children for supervisor/worker, verifier, fan-out or dependency-ordered work.
• A run detail page has a stop action.
• App status pills and browser nested rows show one parent/direct-child level.
• A parent can expand a task into child work and dependency-ordered execution.
• oz agent run executes on the current dev host; unmanaged execution supports macOS, Windows and Linux.
• Configured environments clone the authorized repositories.
• Inactive cloud environments shut down; continuation then uses Fork to local rather than reconnecting to a stopped VM.
• Environment images and setup commands define the toolchain and install steps.
• Worker idle-on-complete defaults forty-five minutes unless overridden; direct Agent API runs default ten minutes.
• Run detail panes expose transcripts and outputs.
• Run pages expose a timeline and cost.
• Managed workers support --max-concurrent-tasks; zero defaults to unlimited.
• Shared links expose the remote conversation, commands, logs and outputs to authorized teammates.
• Inherited Owner/Admin permissions govern administration; factory roles include Factory user and Editor.
• Factory role does not confer repository merge rights.
• Inbox shows questions, specs and PR reviews awaiting the current user.
• Authorized users send follow-up instructions through a shared active cloud session.
• Shared runs expose Computer Use artifacts when produced.
• A separate review agent checks requirements, tests and security expectations.
• The implement agent works on a branch.
• A person decides when/whether to merge; branch protection and repository permissions enforce that boundary.
• Factory handoff presents pull requests and evidence linked to the originating work item.
• Factory Inbox collects the current user’s question, spec-review and PR-review items.
• Hosted Warp services use the vendor’s product/services license agreement with limited access and…
• Customer-hosted workers execute jobs, but Warp hosts routing, tracking and control-plane metadata; the complete core…
• Warp retains control-plane operational logs, configuration, run metadata and billing records.
• Warp Factories is labeled Early Access in the current documentation navigation; standalone cloud-agent availability…
• Cloud runs support project guidance through Rules.
• Recurring maintenance uses factory automations or standalone schedules.
• Warp states SOC2 TypeII certification.
• Codebase Context provides indexed repository search subject to indexing settings and harness scope.
• Build is $20/month monthly or $18/month annually.
• Free is $0/month with core terminal features, limited cloud access and limited conversation storage; additional…
• Eligible dollar-billed accounts pay $3/agent-hour or $0.05/billable minute.

Sources

• Warp pricing
• Platform usage
• Cloud agents
• Agent harnesses
• Cloud agent session sharing
• Factory inbox
• Warp Factories overview
• Oz web app for cloud agents
• Oz CLI reference
• How Warp Factories work
• Multi-agent orchestration
• Configuring harness authentication
• Self-hosting overview
• Unmanaged execution
• Direct backend Git worktrees
• Configuring cloud agent environments
• Self-hosted worker reference
• Cloud agent session sharing
• Factory inbox
• Managing factory permissions
• MCP servers for cloud agents
• Factory MCP for coding agents
• Factory dashboard
• Warp product and services license agreement
• Warp Terminal
• Cloud agents quickstart
• Scheduled Agents
• Agent harnesses
• Warp Trust Center
• Warp Factories: Infrastructure for Software Factories
• Transitioning from Oz to Warp Factories
• Build the factory. Let it run. Go kayaking.
• Oz Cloud Agent Platform: Every agent at your command

Open the Warp Factories / Oz page

Xumfreshness recheckresearch correction45 findings · 33 sources

Findings today

• Desktop, browser/mobile web, CLI and editor access are documented.
• Xum has its own agent runtime and multiple model providers.
• Provider keys, local endpoints and provider-specific OAuth are distinct.
• Scratch chats do not require Git; runtime prerequisites are explicit.
• Product CLI and server protocols provide programmable access.
• MCP servers and reviewed plugins expose scoped tools.
• Desktop uses Electron while server browser mode is separate.
• Work starts as a workspace conversation.
• Plan files persist and reflect external edits.
• Agent trees have a configurable nesting limit.
• Instructions, skills and optional session memory have explicit scopes.
• MCP and artifact files add context with scoped access.
• Xum tasks are agent workspaces or child-agent execution records, with session goals and todos.
• Native child-workspace tasks execute concurrently.
• Queues and shared locks have bounded concurrency semantics.
• Product-owned task tools delegate and inspect child agents.
• Agent heartbeat tools and external CI can schedule work.
• Questions and stop controls have mode/process limits.
• Workspace/agent views expose hierarchy and status.
• Modes, definitions and scripted workflows are configurable.
• Local and owned-host modes are distinct from client location.
• Worktree and container runtimes provide different boundaries.
• History/recovery limits are explicit across processes and context windows.
• Runtime setup can reuse project containers and init hooks.
• Agent and workflow limits are configurable.
• Local diagnostic and usage reporting have explicit scopes.
• Workspace costs and hard budgets include only eligible routed usage.
• Linux CPU/RAM limits and task queues constrain parallel work.
• Separate browser clients sharing one owner/server bearer credential can send instructions to the same workspace…
• Browser sessions have revocation; organization roles are not established.
• Tool policy, project trust and session tokens bound operations.
• History and artifact retention differ from revision history.
• Review panels and rendered diffs sit beside chat.
• Forking and context rollover retain bounded task context.
• Opt-in artifacts retain task files and copied cross-workspace shelves.
• Configurable tool hooks and review agents support optional verification.
• Task branches and patch integration are native; PR operations use external tools.
• Workspace history and artifact copies retain bounded outputs.
• Review outputs can be retained, without an established batch shipping queue.
• Main application is AGPL-3.0-only.
• The core desktop/server app can run on owned infrastructure.
• Anonymous telemetry has a documented backend-off control.
• Xum distributes its AGPL application and installers without a paid Xum tier.
• Stable and alpha surfaces have public release/support channels.
• Source and binaries are publicly available; separate costs remain unpriced.

Sources

• https://xum.cdr.dev/index.md
• https://xum.cdr.dev/install.md
• https://xum.cdr.dev/config/providers.md
• https://xum.cdr.dev/reference/cli.md
• https://xum.cdr.dev/workspaces/scratch-chats.md
• https://xum.cdr.dev/workspaces/index.md
• https://xum.cdr.dev/workspaces/fork.md
• https://xum.cdr.dev/runtime/index.md
• https://xum.cdr.dev/runtime/ssh.md
• https://xum.cdr.dev/runtime/docker.md
• https://xum.cdr.dev/runtime/devcontainer.md
• https://xum.cdr.dev/agents/index.md
• https://xum.cdr.dev/agents/instruction-files.md
• https://xum.cdr.dev/agents/agent-skills.md
• https://xum.cdr.dev/agents/plan-mode.md
• https://xum.cdr.dev/config/mcp-servers.md
• https://xum.cdr.dev/config/project-secrets.md
• https://xum.cdr.dev/config/agent-resource-limits.md
• https://xum.cdr.dev/config/server-access.md
• https://xum.cdr.dev/workspaces/artifacts.md
• https://xum.cdr.dev/config/notifications.md
• https://xum.cdr.dev/hooks/tools.md
• https://xum.cdr.dev/hooks/init.md
• https://xum.cdr.dev/adr/0007-session-memory-is-the-rollover-checkpoint.md
• https://xum.cdr.dev/integrations/vscode-extension.md
• https://xum.cdr.dev/integrations/acp.md
• https://xum.cdr.dev/guides/github-actions.md
• https://xum.cdr.dev/reference/debugging.md
• https://xum.cdr.dev/reference/telemetry.md
• https://raw.githubusercontent.com/coder/mux/329f9cf841ff0282bd3a6ae1b56b5637a675719f/package.json
• https://raw.githubusercontent.com/coder/mux/329f9cf841ff0282bd3a6ae1b56b5637a675719f/LICENSE
• Releases · coder/xum · GitHub
• Coder Runtime

Open the Xum page

Zedresearch correctionfreshness recheck40 findings · 36 sources

Findings today

• Collaborators see shared files, cursors, navigation and edits, and guests can view read-only.
• The pinned README lists macOS, Linux and Windows downloads; minimum OS versions need the platform guides.
• Zed Agent runs alongside ACP-integrated External Agents.
• A separate existing-subscription setup route is documented; support must be checked per provider and agent path.
• The CLI opens arbitrary files or directories as editor workspaces; no Git remote is required for opening them.
• zed [OPTIONS] [PATHS] opens files/directories and supports --wait, --diff, --new, --add and --reuse.
• Zed native agents use locally spawned or remote MCP servers.
• Zed uses Rust and the GPU-accelerated GPUI framework for its editor/client.
• Users create native or installed external-agent threads from the panel/sidebar.
• Zed Agent loads personal AGENTS.md and the first matching compatible project instruction file.
• Native find_path and regex grep navigate project files.
• Zed task records are terminal commands, while agent history consists of conversation threads.
• Persistent channel Markdown notes can hold design/status ideas, but are not a typed requirements object.
• Multiple agent and terminal threads can run at once, against different projects.
• Native spawn_agent delegates a bounded task to a subagent with a separate context window.
• The native agent and agent UI start work from explicit session prompts.
• A stop button interrupts execution; a distinct durable pause mechanism is not established.
• Native Write, Ask and Minimal profiles provide different tool sets.
• Native agent terminal tools run shell commands in the project environment.
• A new agent worktree has its own checkout.
• Thread History can restore Zed threads; external-agent restoration depends on its integration.
• Project devcontainer.json defines the container image, dependencies and environment.
• Automatic compaction defaults at ninety percent of context; a configurable threshold or /compact is supported.
• The thread transcript shows streamed responses and tools in use.
• Active native threads show token usage near the model/profile selector.
• Business organizations have Owner, Admin, Billing Manager and Member.
• Native terminal commands are matched against regex allow/deny/confirm rules, including chained subcommands.
• Thread History retains archived conversations across projects until deleted.
• Review Changes opens a multi-buffer view of all agent-edited files and changed-line counts.
• Project Diff shows repository changes.
• The native terminal tool can run repository tests and return command output.
• The Git Panel reflects working-tree, staging and branch state, commits and undoes commits, manages branches and…
• Multi-buffer review groups the thread’s changed files.
• At commit 0dea8c63d9a5d747b3d0903adb110a9def1d1020, Zed's README states primarily GPL-3.0-or-later with Apache-2.0…
• The native editor/agent can use locally hosted llama.cpp, Ollama, LM Studio or customer-compatible endpoints on user…
• Zed does not retain prompt or code context by default; opt-in feedback/data sharing is separate.
• Plans and token allowances are quoted in US dollars.
• Zed publishes a stable editor release channel alongside other channels.
• Zed Free supports the editor, own API access and external agents; Zed-hosted models require a paid or trial route.
• Hosted-model usage is metered in tokens and converted to dollars.

Sources

• AI overview
• LLM providers
• Agent panel
• Remote development
• Collaboration
• Sandboxing
• Tool permissions
• AI privacy
• Telemetry in Zed
• Plans & pricing
• Git
• Zed pinned README
• Zed roadmap
• CLI Reference
• External Agents
• Parallel Agents
• Agent Panel
• Tools
• Agent Settings
• MCP
• Instructions
• Skills
• Agent Profiles
• Tool Permissions
• Dev Containers
• Roles
• Channels
• Use a Local Model
• Authenticate with Zed
• AI Privacy
• Telemetry in Zed
• Plans & Pricing
• Developing Zed
• Use an Existing Subscription
• Zed Agent sandboxing
• Zed stable releases

Open the Zed page

Deltafreshness recheckresearch correction46 findings · 27 sources

Findings today

• Public-beta desktop, web/mobile browser and CLI surfaces differ.
• Delta supports its native agent, a Claude Code conversation-sharing plugin and a public-beta desktop Claude Agent…
• Provider subscriptions, keys, hosted credits and local models are supported separately.
• Git projects require configured remotes; projectless threads are separate.
• CLI provides thread/worktree/account operations.
• Skills, external MCP tools and CLI plugins have different scopes.
• Delta has a native desktop UI.
• Thread prompts and project context are primary intake.
• Plans can be files in retained thread history.
• Agent-created subthreads form a visible hierarchy.
• Skills, past-thread retrieval and compaction provide context.
• Agents retrieve prior threads and current project context.
• Native subagents execute in separate conversations.
• Profiles route model/effort and code ownership.
• Native agents delegate, message and receive child results.
• Threads support stop, questions and model continuation.
• Sidebar and organization Overview expose thread relationships.
• Interactive threads and delegated workers share flexible model settings.
• Public-beta desktop turns run locally, on user-managed Personal Runners including headless servers, or on Zed-hosted…
• DeltaDB checkouts separate code but do not sandbox agents.
• Deltas restore history while checkout and compaction recovery have limits.
• Repository preparation and private-runner setup are separate.
• Terminal cap and hosted spend controls have explicit enforcement.
• Thread status, context diagnostics and account telemetry are documented.
• Hosted/account usage follows the sender rather than thread owner.
• Concurrency controls apply only to legacy attached subagents.
• Authorized collaborators steer the same thread with explicit input ordering.
• Thread owner/editor permissions and membership are documented.
• Current agents have no tool approval system; secrets are redacted separately.
• Authored deltas retain edits and discussion between Git commits.
• Review threads preserve context and return verdicts with selected fixes.
• Teammates continue shared work while runtime-local state stays local.
• Deltas and review subthreads retain change evidence.
• Merge/review skills configure checks but are agent-executed policies.
• Git publication and explicit child integration are supported.
• Merge skills execute the chosen landing strategy.
• Edit-level revert and merge result references remain available.
• Review subthreads return verdicts and retained findings.
• Delta application access is governed by a restricted early-access agreement.
• Vendor account/synchronization dependencies remain distinct from local checkouts.
• Privacy docs distinguish synchronization, direct provider calls and account telemetry.
• Delta shares Zed Personal at USD 0, Pro at USD 10 monthly and Business at USD 30 per paid seat monthly.
• Fixed subscription and variable model usage are separate.
• Public beta and current releases are documented.
• Personal is an ongoing free plan with external model costs.
• Plan units and hosted spend limit are public.

Sources

• Install Delta — Delta Docs
• Quick Start — Delta Docs
• Models & Providers — Delta Docs
• Plans & Usage — Delta Docs
• Get Started with Delta CLI — Delta Docs
• Claude Code Plugin — Delta Docs
• Build a Coding Agent Plugin — Delta Docs
• Subagents — Delta Docs
• Collaborate in a Thread — Delta Docs
• Delta on the Web — Delta Docs
• Delta Worktrees — Delta Docs
• Delta & Git — Delta Docs
• Reviewing & Syncing Changes — Delta Docs
• Comments — Delta Docs
• Skills — Delta Docs
• MCP Servers — Delta Docs
• Prepare your project — Delta Docs
• Settings — Delta Docs
• Data Storage & Deletion — Delta Docs
• AI Privacy & Telemetry — Delta Docs
• Security — Delta Docs
• Agentic Safety — Delta Docs
• Cloud Runners — Delta Docs
• Release notes — Delta Docs
• Delta — Pricing
• Building fine-grained version control for agents with Rust and Durable Objects — Delta Blog
• Replacing Pull Requests with Delta

Open the Delta page

Zencoderfreshness recheckresearch correction38 findings · 22 sources

Findings today

• Zencoder is an IDE extension for VS Code, JetBrains and Android Studio; standalone Zenflow is a separate profile.
• IDE Agent hosts native ZenCLI plus locally authenticated Claude Code and Codex; model choice is separate.
• Existing Claude and ChatGPT subscriptions can authenticate the IDE runtime.
• Install the IDE plugin, sign in and open a workspace; external CLIs have separate prerequisites.
• REST access covers organization analytics; official GitHub Action runs agent prompts in CI.
• IDE Agent is an MCP client with per-agent tools and standardized repository instructions.
• Prompt-driven IDE chat accepts Jira context; CI integration accepts PR events.
• Coding Agent creates an execution plan, but a durable native plan editor is not established.
• Personal and project memory are independently controllable; AGENTS.md supplies rules.
• Agents retrieve code, external docs and images, with a separately configured multi-repository index.
• Native ZenCLI can run parallel subagents; Claude Code has an explicit parallel subagent limitation.
• Humans choose named agents; the ZenCLI master can delegate specialized work.
• ZenCLI owns delegation through MCP subprocess calls that return results to the master.
• Official integration starts agent work on CI events; add-on entitlement must be confirmed.
• Inline diffs, follow-ups and tool approval prompts support intervention.
• Use the default Coding Agent, named custom agents or specialized children.
• IDE-hosted agent CLIs execute on the user's machine, and private deployments run agents and inference on customer…
• IDE tools edit the current workspace; vendor data isolation is separate from runtime sandboxing.
• External runtime installation and environment key handling are documented.
• Coding Agent tool-call count is uncapped per turn; runtime/tool errors remain inspectable.
• Structured logs expose tool inputs/outputs/duration and model errors with an Operation ID.
• Per-request credit usage is visible in IDE alongside remaining credits.
• Account administration has named roles and paid-plan SSO; repository retrieval has separate access controls.
• Tool permission prompts and per-agent tool selection bound execution; auto-approve is optional.
• Paid organization audit logs record identity, configuration and usage events and can be exported.
• IDE displays changed-file diffs with inline explanations and follow-up refinement.
• IDE shows diffs and execution traces; durable artifact gallery not established.
• Coding Agent runs tests/lint/types and self-corrects; configured review agents are optional.
• Native Git tools stage, commit, diff and manage branches; official CI integration can comment on PRs.
• Diffs and PR review comments provide bounded delivery evidence.
• The main service is proprietary software licensed for limited use.
• Customer infrastructure deployment is documented; account and provider dependencies remain.
• Recurring Free BYOK access and per-seat credit plans are public: Pro $45, Pro Plus $95 and Pro Max $195 per user per…
• Seat-only arithmetic is possible; no measured end-to-end engineering fixture cost.
• Current IDE plugins have published updates; rollout notes qualify newer integrations.
• Vendor claims SOC 2 Type II, ISO 27001 and ISO 42001; audit scope, issuer and validity are unverified.
• Free is recurring BYOK access, distinct from the seven-day bundled-credit trial.
• Seat fees, included credits, usage rules and cancellation are public; Enterprise remains custom-priced.

Sources

• Pricing & Plans
• Models
• Configuration
• Security & Privacy
• Team Administration
• Analytics Dashboard
• Analytics API
• Private Deployments
• Context Management
• Multi-Repository Search
• Skills
• SubAgents
• Zencoder Terms of Service
• Install IDE Plugin
• Universal AI Platform
• Coding Agent
• AI Agents
• Integrations and MCP
• MCP Configuration Guide
• IDE Agent Changelog
• CI/CD Automation and Autonomous Agents
• GitHub - zencoderai/zen-agents-action: Zencoder agent GitHub Action · GitHub

Open the Zencoder page

Zenflow Code by Zencoderfreshness recheckresearch correction45 findings · 43 sources

Findings today

• Desktop macOS/Windows/Linux and user-hosted browser access; phone client not established.
• Zenflow runs native ZenCLI, Claude Code, OpenAI Codex and Gemini CLI with per-step configuration.
• Claude native subscriptions or provider keys are supported; remote login is independent.
• Guided agent setup; code repositories and folder-based Work tasks have separate prerequisites.
• Zenflow is an MCP client with configurable tools and repository rules.
• Native tasks accept prompts, imported Linear context and configured GitHub events.
• Durable Markdown plans and workflow steps support edits and checkpoints.
• Organization/repository/task/subtask-chat structure and ordered steps are documented; dependency graph is not.
• Rules, skills and task artifacts provide retained context.
• Agents retrieve code, external docs and images, with a separately configured multi-repository index.
• Zenflow has native persistent task records and states, distinct from per-task chat tabs.
• PRD/spec/plan artifacts persist and can be reviewed before implementation.
• Parallel task worktrees and ZenCLI children support concurrency with harness limits.
• Humans dispatch tasks/presets and the native master delegates subprocess work.
• Product-owned master delegates isolated subagents and collects their results.
• Schedules and GitHub events start work unattended; remote host removes laptop dependence.
• Live chat/terminal activity, checkpoint pauses and notifications support intervention.
• Repository board/list offers source-documented fleet status; no scenario fixture executed.
• Quick Auto tasks can move into editable multi-step workflows and agent presets.
• Full Zenflow runs locally or on user-managed Ubuntu host and continues after laptop disconnect.
• Git worktrees separate code; MCP process controls and Codex sandbox settings are narrower scopes.
• Remote persistence, archival restoration and documented recovery differ from guaranteed crash resume.
• Repository scripts set up dependencies and copy local secret files; remote installs provide service/update controls.
• Agent errors and stuck runs have visible/manual retry paths.
• Task logs/tool streaming and verification states explain execution; analytics are account-level.
• Credits are provider/model-dependent; direct-key usage is paid to the provider.
• Parallelism is limited by host resources; docs recommend manual staggering and expose MCP-specific limits.
• Zenflow uses Zencoder account membership and paid organization SSO; same-task edit permissions not established.
• MCP approvals and runtime-specific execution modes can be configured.
• Git checkpoints and retained task history coexist with account audit logs.
• Diff, verification and configurable multi-model review provide review context.
• Task files retain plans/specs/reviews, diffs and verification context; archival differs from disk cleanup.
• Configured scripts and staged reviewers verify changes; hard authority enforcement is unverified.
• Zenflow creates task branches/PRs, commits and syncs PR status.
• Docs describe review/merge and configurable external tools; exact-revision authority gate unverified.
• Checkpoint rollback, PR links and retained review evidence support delivery traceability.
• Multiple finished tasks can be reviewed before sequential merging; no enforced dependency queue established.
• The main service is proprietary software licensed for limited use.
• Core Zenflow is installable on user infrastructure; data/history retention is documented.
• Recurring Free BYOK access and per-seat credit plans are public; model and own-host costs remain separate.
• Seat-only arithmetic is possible; no measured end-to-end engineering fixture cost.
• Zenflow ships desktop/remote clients with stable and beta channels; some settings remain experimental.
• Vendor claims SOC 2 Type II, ISO 27001 and ISO 42001; audit scope, issuer and validity are unverified.
• Free is recurring BYOK access, distinct from the seven-day bundled-credit trial.
• Seat fees, included credits, usage rules and cancellation are public; Enterprise remains custom-priced.

Sources

• Pricing & Plans
• Models
• Configuration
• Security & Privacy
• Team Administration
• Analytics Dashboard
• Analytics API
• Private Deployments
• Context Management
• Multi-Repository Search
• Skills
• SubAgents
• Zencoder Terms of Service
• Install Zenflow
• Zenflow Code
• Zenflow Code
• Projects & Tasks
• Settings
• Git and Worktrees
• Tracking Changes
• Archiving Tasks
• Remote Hosts
• VPS Setup
• Agent Presets
• Multi-Agent Orchestration
• Subagent Pipelines
• Review Rubric
• Automations
• Blast Multiple Agents
• Workflows
• Custom Workflows
• Requirements First
• MCPs (Model Context Protocol)
• GitHub Integration
• Linear Integration
• Built-in Browser
• Troubleshooting
• Zenflow Changelog
• Claude Code
• Codex (OpenAI)
• Gemini
• Download | Zencoder – The AI Coding Agent
• Terms of Service | Zenflow

Open the Zenflow Code by Zencoder page

6 Nov 20261 ADE

Orchestrator.incproduct changeresearch correction48 findings · 61 sources

Findings today

• Orchestrator ships desktop, native mobile and CLI clients.
• Orchestrator launches and supervises external agent CLIs through compiled adapters, with structured Chat on a subset.
• Local use relies on the user’s own agent sign-ins and API keys; Orchestrator does not proxy model calls.
• Local setup is documented for Git repositories and Scratch work; Cloud and VM onboarding have separate flows.
• The ao CLI is the supported programmable surface; the local HTTP API is loopback-only.
• MCP and skills are inherited from the provider harness; Orchestrator has no plugin system.
• Desktop uses Electron and React over a Go daemon; mobile uses Expo and React Native.
• Work starts as a local prompt or session; GitHub and GitLab can feed workers one way, and they stay the issue authority.
• Chat keeps provider plans in session history; a durable task-plan record with acceptance criteria was not found.
• Orchestrator-to-worker supervision is documented; epics, blockers and dependency enforcement were not found.
• Project rules are typed and role-scoped; memory across sessions was not established.
• Multimodal input is provider-dependent; code search, indexing and architecture checks are left to the harness.
• Work is represented by worker sessions and external tracker intake, without an independent native task/issue record…
• Agents use the ao CLI on sessions and PRs; no issue object exists for them to manage.
• Parallel sessions run in isolated workspaces; local concurrency has no plan limit.
• PR ownership and feedback routing are enforced by the product; task queues and human assignment were not found.
• Product-owned orchestrator and worker sessions delegate, message and report across harnesses.
• Recurring Automations and built-in PR event rules run in the local daemon.
• Stop, resume, steer and attention are documented; a pause control was not found.
• A fleet board shows attention by session; a fixture walkthrough was not run.
• A quick worker and a project orchestrator run without mandatory workflows.
• Execution runs on the local computer, a linked self-hosted machine, or hosted Cloud sandboxes.
• Git worktrees and branches separate work by session; no OS sandbox claim was found for local runs.
• Sessions outlive client close and daemon replacement where hosts survive; recovery depends on the harness.
• Per-project setup scripts, symlinks and an optional preview launcher prepare workspaces.
• Setup and request timeouts are documented; run-level turn, token and spend limits were not found.
• Status derives from saved facts; session and project usage summaries exist for certified harnesses.
• Estimated session usage exists for Claude Code, Codex and Kimi; billed reconciliation was not established.
• Cloud concurrency is capped by plan; local resource-aware scheduling was not found.
• Cloud has organizations with admin billing controls; SSO and team management are not built.
• Permission modes come from each provider; safer and bypass modes are selectable per role.
• Session records persist locally for one user; no audit model was found.
• The inspector gathers PR state, reviews, files and preview; raw logs stay on the host.
• Colleague takeover is not offered; a session can move to another agent.
• Artifacts, previews, diffs and reviewer output are retained by session.
• Independent review is optional; merge gating stays with the repository host.
• Branches, worktrees, PR tracking, comment and CI routing, and conflict nudges are integrated.
• Merge is explicit and can pin the head SHA; release and deploy are outside the product.
• PR links and checks are tracked; deployment evidence and rollback were not found.
• The board supports a review queue; batch approval features were not found.
• Desktop, daemon, CLI and mobile are Apache-2.0; the hosted control plane is in a private repository.
• Local use needs no account; Cloud and account-linked remote hosts depend on the vendor.
• Local work stays on the machine apart from telemetry; AO Cloud data handling is outside the privacy policy.
• Public USD prices: Free, Starter $20/month, Pro $40/month and custom Enterprise.
• Only the fixed parts of a scenario can be priced from public sources.
• Stable releases ship frequently; support routes are public, with an SLA only on Enterprise.
• Local use is free with no account; Cloud needs a paid plan.
• Partially specified: plan prices and limits are public, while compute and Enterprise terms are not.

Sources

• Orchestrator introduction
• Installation
• Quickstart
• Platforms
• Dashboard
• Examples
• Per-role agents
• Parallel work
• CI recovery
• Review loop
• Handle CI and review feedback
• Multi-project
• Cloud sessions
• Built-in capabilities
• Agent adapters
• Codex adapter
• OpenCode adapter
• Workspaces
• Git worktrees
• Issue tracking
• GitHub issue intake
• Source control and pull requests
• GitHub SCM
• Notifications
• Notification center
• CLI reference
• Configuration
• Projects
• Automation reference
• Connect Mobile
• Architecture
• Troubleshooting
• FAQ
• Migration
• Orchestrator.inc llms.txt
• Agent Orchestrator for AI agents
• Pricing
• Refunds & Cancellations
• Support & Contact
• Privacy Policy
• Mobile
• v0.14.9 release notes
• GitHub release v0.14.9
• Repository lineage check
• Orchestrator.inc v0.14.9 source: backend/internal/service/session/delegation.go
• Orchestrator.inc v0.14.9 source: backend/internal/cli/mcp.go
• Orchestrator.inc v0.14.9 source: backend/internal/httpd/apispec/openapi.yaml
• Orchestrator.inc v0.14.9 source: backend/internal/service/usage/summary.go
• Orchestrator.inc v0.14.9 source: backend/internal/service/usage/capabilities.go
• Orchestrator.inc v0.14.9 source: .gitmodules
• Orchestrator.inc v0.14.9 source: contracts/cloud/openapi.yaml
• Orchestrator.inc v0.14.9 source: packages/mobile/package.json
• Orchestrator.inc v0.14.9 source: frontend/package.json
• Orchestrator.inc v0.14.9 source: docs/self-hosted-remote.md
• Orchestrator.inc v0.14.9 source: docs/STATUS.md
• Orchestrator.inc v0.14.9 source: LICENSE
• domain/harness.go at v0.14.9
• Orchestrator v0.14.10 release
• Commit: cloud on for everyone (#7615)
• Migration: npm package status
• npm registry metadata for @aoagents/ao

Open the Orchestrator.inc page

Archived event links

• 2026-11-13 · Agent Deck
• 2026-11-13 · Agent of Empires
• 2026-11-13 · Orchestrator.inc
• 2026-11-13 · Agent Teams
• 2026-11-13 · ai-devkit
• 2026-11-13 · Alethe
• 2026-11-13 · Amp
• 2026-11-13 · Google Antigravity
• 2026-11-13 · Archon
• 2026-11-13 · Atlas
• 2026-11-13 · Augment Code
• 2026-11-13 · Open-Inspect
• 2026-11-13 · bb
• 2026-11-13 · Bolt
• 2026-11-13 · Buzz by Block
• 2026-11-13 · Capy
• 2026-11-13 · Cate
• 2026-11-13 · Claude Code
• 2026-11-13 · claude-code-action
• 2026-11-13 · claude_codex_bridge
• 2026-11-13 · Claude Squad
• 2026-11-13 · Cline
• 2026-11-13 · cmux
• 2026-11-13 · CodeLayer / HumanLayer
• 2026-11-13 · CodeNomad
• 2026-11-13 · OpenAI Codex
• 2026-11-13 · codex-action
• 2026-11-13 · collaborator
• 2026-11-13 · Zeron
• 2026-11-13 · Conductor
• 2026-11-13 · Cursor
• 2026-11-13 · Devin
• 2026-11-13 · dmux
• 2026-11-13 · Emdash
• 2026-11-13 · Factory
• 2026-11-13 · Fusion
• 2026-11-13 · Gas Town
• 2026-11-13 · gh-aw
• 2026-11-13 · Ghostex
• 2026-11-13 · GitHub Copilot
• 2026-11-13 · Happy
• 2026-11-13 · Herdr
• 2026-11-13 · Intent by Augment
• 2026-11-13 · Jcode
• 2026-11-13 · Jean
• 2026-11-13 · JetBrains Air
• 2026-11-13 · Jules
• 2026-11-13 · Kiro
• 2026-11-13 · Lanes Desktop
• 2026-11-13 · Linzumi
• 2026-11-13 · lody
• 2026-11-13 · loki-mode
• 2026-11-13 · Lovable
• 2026-11-13 · Maestro
• 2026-11-13 · MonoCode
• 2026-11-13 · multi-agent-shogun
• 2026-11-13 · Multica
• 2026-11-13 · Nimbalyst
• 2026-11-13 · Omnara
• 2026-11-13 · Omnigent
• 2026-11-13 · Ona
• 2026-11-13 · open-swe
• 2026-11-13 · OpenChamber
• 2026-11-13 · OpenCode
• 2026-11-13 · OpenHands
• 2026-11-13 · OpenSpec
• 2026-11-13 · Orca
• 2026-11-13 · Paseo
• 2026-11-13 · Podium
• 2026-11-13 · Proliferate
• 2026-11-13 · QM from YC
• 2026-11-13 · ralph-claude-code
• 2026-11-13 · ralph-orchestrator
• 2026-11-13 · Ralph TUI
• 2026-11-13 · ralphex
• 2026-11-13 · Replicas
• 2026-11-13 · Replit
• 2026-11-13 · Rookery
• 2026-11-13 · scion
• 2026-11-13 · Solenta
• 2026-11-13 · Supacode
• 2026-11-13 · super.engineering
• 2026-11-13 · Superconductor
• 2026-11-13 · SuperPlane
• 2026-11-13 · Paradev
• 2026-11-13 · Synara
• 2026-11-13 · T3 Code
• 2026-11-13 · Tembo
• 2026-11-13 · ThinkRail
• 2026-11-13 · Traycer
• 2026-11-13 · Unpeel
• 2026-11-13 · v0
• 2026-11-13 · Verdent
• 2026-11-13 · Vibe Kanban
• 2026-11-13 · Waku
• 2026-11-13 · Warp
• 2026-11-13 · Warp Factories / Oz
• 2026-11-13 · workmux
• 2026-11-13 · Xum
• 2026-11-13 · Zed
• 2026-11-13 · Delta
• 2026-11-13 · Zencoder
• 2026-11-13 · Zenflow Code by Zencoder
• 2026-11-12 · Atlas
• 2026-11-12 · Cate
• 2026-11-12 · SuperPlane
• 2026-11-12 · ThinkRail
• 2026-11-12 · workmux
• 2026-11-11 · Orchestrator.inc
• 2026-11-11 · Herdr
• 2026-11-11 · Lanes Desktop
• 2026-11-11 · Orca
• 2026-11-11 · Paseo
• 2026-11-11 · Podium
• 2026-11-10 · Agent Deck
• 2026-11-10 · Agent of Empires
• 2026-11-10 · Orchestrator.inc
• 2026-11-10 · Agent Teams
• 2026-11-10 · ai-devkit
• 2026-11-10 · Alethe
• 2026-11-10 · Archon
• 2026-11-10 · Open-Inspect
• 2026-11-10 · bb
• 2026-11-10 · Buzz by Block
• 2026-11-10 · claude-code-action
• 2026-11-10 · claude_codex_bridge
• 2026-11-10 · Claude Squad
• 2026-11-10 · Cline
• 2026-11-10 · cmux
• 2026-11-10 · CodeLayer / HumanLayer
• 2026-11-10 · CodeNomad
• 2026-11-10 · OpenAI Codex
• 2026-11-10 · codex-action
• 2026-11-10 · collaborator
• 2026-11-10 · Zeron
• 2026-11-10 · dmux
• 2026-11-10 · Emdash
• 2026-11-10 · Fusion
• 2026-11-10 · Gas Town
• 2026-11-10 · gh-aw
• 2026-11-10 · Ghostex
• 2026-11-10 · Happy
• 2026-11-10 · Herdr
• 2026-11-10 · Intent by Augment
• 2026-11-10 · Jcode
• 2026-11-10 · Jean
• 2026-11-10 · JetBrains Air
• 2026-11-10 · loki-mode
• 2026-11-10 · Maestro
• 2026-11-10 · MonoCode
• 2026-11-10 · multi-agent-shogun
• 2026-11-10 · Multica
• 2026-11-10 · Nimbalyst
• 2026-11-10 · Omnara
• 2026-11-10 · Omnigent
• 2026-11-10 · open-swe
• 2026-11-10 · OpenChamber
• 2026-11-10 · OpenHands
• 2026-11-10 · OpenSpec
• 2026-11-10 · Orca
• 2026-11-10 · Paseo
• 2026-11-10 · Proliferate
• 2026-11-10 · QM from YC
• 2026-11-10 · ralph-claude-code
• 2026-11-10 · ralph-orchestrator
• 2026-11-10 · Ralph TUI
• 2026-11-10 · ralphex
• 2026-11-10 · Rookery
• 2026-11-10 · scion
• 2026-11-10 · Solenta
• 2026-11-10 · Supacode
• 2026-11-10 · Synara
• 2026-11-10 · T3 Code
• 2026-11-10 · Tembo
• 2026-11-10 · Traycer
• 2026-11-10 · Unpeel
• 2026-11-10 · Vibe Kanban
• 2026-11-10 · Waku
• 2026-11-10 · Warp
• 2026-11-10 · Xum
• 2026-11-10 · Zed
• 2026-11-10 · Zencoder
• 2026-11-08 · Agent Deck
• 2026-11-08 · Agent of Empires
• 2026-11-08 · Agent Teams
• 2026-11-08 · ai-devkit
• 2026-11-08 · Alethe
• 2026-11-08 · Archon
• 2026-11-08 · Open-Inspect
• 2026-11-08 · bb
• 2026-11-08 · Bolt
• 2026-11-08 · claude-code-action
• 2026-11-08 · claude_codex_bridge
• 2026-11-08 · CodeNomad
• 2026-11-08 · codex-action
• 2026-11-08 · collaborator
• 2026-11-08 · Zeron
• 2026-11-08 · dmux
• 2026-11-08 · Fusion
• 2026-11-08 · Gas Town
• 2026-11-08 · gh-aw
• 2026-11-08 · Ghostex
• 2026-11-08 · Happy
• 2026-11-08 · Herdr
• 2026-11-08 · Jcode
• 2026-11-08 · loki-mode
• 2026-11-08 · Lovable
• 2026-11-08 · MonoCode
• 2026-11-08 · multi-agent-shogun
• 2026-11-08 · Nimbalyst
• 2026-11-08 · open-swe
• 2026-11-08 · OpenChamber
• 2026-11-08 · ralph-claude-code
• 2026-11-08 · ralph-orchestrator
• 2026-11-08 · Ralph TUI
• 2026-11-08 · ralphex
• 2026-11-08 · Replit
• 2026-11-08 · scion
• 2026-11-08 · Supacode
• 2026-11-08 · Traycer
• 2026-11-08 · v0
• 2026-11-08 · Waku
• 2026-11-07 · Orchestrator.inc
• 2026-11-07 · Amp
• 2026-11-07 · Google Antigravity
• 2026-11-07 · Augment Code
• 2026-11-07 · Buzz by Block
• 2026-11-07 · Capy
• 2026-11-07 · Claude Code
• 2026-11-07 · Claude Squad
• 2026-11-07 · Cline
• 2026-11-07 · cmux
• 2026-11-07 · CodeLayer / HumanLayer
• 2026-11-07 · OpenAI Codex
• 2026-11-07 · Conductor
• 2026-11-07 · Cursor
• 2026-11-07 · Devin
• 2026-11-07 · Emdash
• 2026-11-07 · Factory
• 2026-11-07 · GitHub Copilot
• 2026-11-07 · Intent by Augment
• 2026-11-07 · Jean
• 2026-11-07 · JetBrains Air
• 2026-11-07 · Jules
• 2026-11-07 · Kiro
• 2026-11-07 · Lanes Desktop
• 2026-11-07 · Linzumi
• 2026-11-07 · Maestro
• 2026-11-07 · Multica
• 2026-11-07 · Omnara
• 2026-11-07 · Omnigent
• 2026-11-07 · Ona
• 2026-11-07 · OpenCode
• 2026-11-07 · OpenHands
• 2026-11-07 · OpenSpec
• 2026-11-07 · Orca
• 2026-11-07 · Paseo
• 2026-11-07 · Podium
• 2026-11-07 · Proliferate
• 2026-11-07 · QM from YC
• 2026-11-06 · Capy
• 2026-11-06 · Podium

Something wrong or missing?

Report wrong dataSuggest a missing ADE