Cline vs Zencoder (2026)

Stands at F, re-based off first-party pages after the June basis cited the vendor's self-review blog. Breadth across classes is met on source control, ticketing, error monitoring, observability, CI and chat, and the record's 100-plus integrations claim is not relied on: an earlier vendor interview put the figure at 20-plus, so the basis names the classes and specific tools that are actually documented rather than repeating a count that has varied.

Stands at F and confidence normalised from a non-canonical 0.8, re-based off the enterprise page after the June basis cited the vendor's own self-review blog post. Multi-agent verification with each role on a different model is the distinguishing design and it is genuinely uncommon: most vendors in this lane run one agent with subagents, whereas here the reviewer is deliberately a different model from the builder, which is the same reasoning greptile applies in model inversion. Recorded honestly: the dozens-of-agents-in-parallel claim comes from marketing rather than documentation, and the merge-rate and velocity figures are vendor-reported.

Upgraded from P: invocation spans IDE, CLI, SDK, headless CI, cron schedules, and four chat surfaces including Slack, Discord, Telegram and Linear. That is breadth rather than an editor sidebar.

Stands at F and confidence normalised from a non-canonical 0.7, re-based off the enterprise page. All three trigger classes the axis names are documented first-party: schedules through time-based CI/CD triggers and recurring workflows, events through CI/CD pipeline integration, and channels across IDE, desktop, command line and cloud. Agents running 24 hours a day across four surfaces is the distinguishing claim and it is stated plainly rather than inferred, which is why this holds at F where refact-ai, tabby and zed sit at P for being editor-invoked only.

Stands at F and confidence normalised from a non-canonical 0.8, re-based off the product page after the June basis cited the vendor's self-review blog. The mechanism is now documented rather than asserted: a named Repo-Info Agent, dependency and build-system analysis, convention discovery, a generated repo.md, organisation-wide indexing and on-demand context construction for monorepos exceeding context windows. Multi-repo dependency tracing across service boundaries is the distinguishing property and is rarer in this lane than single-repo indexing.

Upgraded from N and confidence normalised from a non-canonical 0.6. The June basis reasoned that the repository index was codebase knowledge counted under Know rather than memory, which was defensible, but the Repo Grokking product page names the artefact and its role explicitly: a Repo-Info Agent generates a repo.md file that serves as memory for all agent interactions. Kept separable from Know so one fact does not do double duty: Know rests on the indexing, dependency mapping and multi-repo tracing, this rests on the persisted repo.md that every later agent reads. Held at P rather than F because repo.md is derived project context regenerated from the codebase rather than memory accumulating from interaction, and no per-user or per-session memory is documented.

Upgraded from P. The June basis credited quality gates and review handoff, which is verification rather than a guardrail, and missed the governance layer entirely: approval gates, role-based permissions and human-in-the-loop policies defining who can deploy what and when is a shipped policy engine, and org-wide enforced model policies bound which models agents may use at all. That is control set before the agent runs, which is what the axis grades. Sixth distinct oversight architecture in this lane, and closest in shape to poolside's centrally administered pre-run policy.

Held at P. Architecture is a genuine strength here, since bring your own key and local weights mean code need never leave the customer's control, but architecture is not controls. An enterprise page exists and was not retrieved on this pass, so a governance surface or attestation may exist; recorded as a limit rather than asserted absent. Same shape as aider and opencode in this lane.

Stands at F but the basis is materially corrected, because the vendor contradicts itself on the same page. Marketing copy claims the first and only security triple crown of SOC 2 Type II, ISO 27001 and ISO 42001 certified, and the comparison table repeats it; the FAQ lower down the same page states Zencoder is ISO27001 certified and is in process of obtaining its SOC2 Type II report. Under the section 7 rule the help-centre style FAQ wins, so SOC 2 Type II is IN PROGRESS, not held, and the June basis repeating the marketing claim was wrong. F still holds because the conjunction is met without it: ISO 27001 is a real attestation both sources agree on, and the named controls are extensive. Under the hedge ladder a SOC 2 in progress would cap at P on its own, which is why the ISO certification is doing the work here.

Held at P. Per tool call checkpoints and screenshot-after-every-browser-action give unusually granular visibility into what happened, and the whole runtime is inspectable open source, but there is no retained audit log or organisation level record of agent actions.

Stands at P, re-based off the enterprise page after the June basis cited the pricing page. The vendor claims full audit trails as a headline security property, which is a stronger assertion than the June basis carried, but it is a marketing phrase with no mechanism behind it on any page reached: no trace, replay, session record or export surface is documented. Under the lane-wide reading applied to graphite, cubic and sourcegraph, usage analytics and performance dashboards report on throughput and spend rather than on what the agent did and why. Held at P rather than lifted on an unevidenced claim; would move to F on a documented execution trace.

Upgraded from P and confidence normalised from a non-canonical 0.6, on first-party evidence replacing checkthat.ai. The June basis called self-hosting enterprise-gated and not fully documented; the vendor's own FAQ answers the question directly and names three deployment modes, and the enterprise page repeats cloud, on-premise or hybrid as a headline. Both halves of the axis are met: deployment surface across cloud, on-premise, private cloud and hybrid, and data location control through BYOK plus the stated position that code is not stored in the cloud and access stays within the customer's local machine and environment.

Upgraded from P: the MCP Marketplace is a browsable catalogue with one click install and automatic configuration, which is the axis. Servers are third party contributed but the marketplace itself is a vendor operated distribution surface, comparable to kiro Powers and Claude Code plugins.

Stands at F and confidence normalised from a non-canonical 0.8, re-based off first-party pages after the June basis cited g2.com, a review platform excluded as evidence. A published marketplace plus shareable org-wide custom agents plus named prebuilt role agents is the fullest form of this axis found in this lane, alongside codebuff's Agent Store and warp's Agent Kits. The distinguishing detail is that agents are shareable across an organisation rather than only per project, which is what the enterprise framing rewards.

Stands at F, re-based off the enterprise page after the June basis cited aichief.com. Role-based model routing is now first-party confirmed and is the distinguishing form here: not merely letting the customer pick a model, but assigning different models to build, review and audit within a single verified workflow, which is the same design greptile uses in model inversion and which few others in this lane document. BYOK against existing OpenAI and Anthropic agreements and org-wide enforced model policies complete the axis.

DOWNGRADED from F on Mike's ruling of 2026-08-30, overturning my own August grade. I held F while my own basis stated that no public REST API or SDK was retrieved, and flagged it as the weakest F on this axis in the lane, which was the right instinct followed by the wrong grade. The axis page states the bar directly: full coverage means the platform is composable from outside through a documented API or SDK, with MCP as one form of evidence rather than the bar itself, and partial is commonly a read-only API or webhook. Answering some of the surfaces and not others is the definition of Partial, the same arithmetic that keeps a bare SOC 2 certificate at P on Security. The deciding sentence is the one I had already applied correctly to appfactor and then failed to carry here: Ext measures whether THIS platform is callable, not whether it helps other things become callable. A visual MCP library, a CLI, a marketplace and a custom agent framework are a real surface and they answer three of the four buyer questions well, which is why this is P and not N, but none of them makes Zencoder itself callable from outside. F bar from here: a documented API or SDK for the vendor's own platform, plus whatever MCP, CLI, marketplace or custom tool surface exists. MCP, CLI and marketplace without an API or SDK is P with the gap named. Nothing documented is N. Grade would move to F on a documented platform API; docs.zencoder.ai was not fetched and remains the cheap check.

Held at P per the lane wide axis rule. Linter monitoring, test execution and browser verification are the agent checking its own output against the customer's code; no harness for evaluating or regression testing agent behaviour is documented.

Stands at F on the qodo, cubic and greptile precedent, where the axis and the product coincide, and this is a clear instance: Zentester is a named testing agent with its own launch and five documented capabilities, and verification is the platform's organising idea rather than a side feature. Recorded honestly and worth a buyer's eye: the 90-plus percent test coverage and 87 percent merge rate figures are vendor-reported with no methodology published, and the vendor's proven high success rates in real-world benchmarks phrasing appears on its own self-review blog, which is marketing.

Corrected from N, which contradicted the record's own longDescription. browser_action is a documented first class tool with its own docs page; the agent drives a real browser through the human interface, which is the axis test. Remote mode reuses existing authentication tokens and session cookies, so it reaches authenticated applications with no programmatic interface exposed to it.

DOWNGRADED from P, the thirteenth and final correction of this axis error in the 30 June cohort. The June basis credited executing work in isolated environments per agent, running code, tests and tools, as sandboxed computer use; isolated environments and tool calls are programmatic execution, which is precisely what the axis excludes. Both passes reached the enterprise page, the Repo Grokking product page and the marketing site and found no browser tool, screenshot capability or GUI automation anywhere. Graded as not documented rather than asserted absent, and worth noting the isolated-environment design is genuinely strong, it simply belongs to Orch and HITL rather than here.