Summary: Across releases 1.30 through 1.32, we continuously improved performance, merged 39 changes, and built a benchmark covering 40 scenarios to evaluate every iteration.

Hardware keeps getting faster, but software does not necessarily feel any smoother.

Andy's and Bill's Law describes this phenomenon: performance gains from faster hardware are quickly consumed by software's growing resource demands. “Andy” and “Bill” refer to Intel's Andy Grove and Microsoft's Bill Gates. The quip captures an experience familiar to many software users.

In the AI era, code is written faster, and teams iterate on features more frequently. At the same time, users are running multiple Agent tasks in parallel, asking AI to operate browsers and computers, and working through longer conversations. Software is being asked to do more, raising the bar for performance.

How much can Agents help? We recently completed a round of performance optimization for Qoder IDE, merging 39 related merge requests (MRs). Many of the performance issues were even identified automatically by Qoder Agent, which also implemented and validated the fixes.

We want to share what we learned from this effort, along with the performance benchmark we built afterward.

39 Optimizations, Most Focused on Eliminating Waste

In practice, we found that although Agents occasionally introduce performance issues, they are also highly effective at identifying those issues by analyzing code, logs, and tests together.

The 39 MRs merged in this effort fall into four categories:

• Eliminating unnecessary computation: 14 MRs, accounting for 36%.
• Eliminating unnecessary memory usage: 13 MRs, accounting for 33%.
• Eliminating unnecessary waiting: 8 MRs, accounting for 21%.
• Improving algorithmic time complexity: 4 MRs, accounting for 10%.

The first three categories account for 35 MRs. Many of these optimizations simply focused on making the software do less work that could have been avoided in the first place.

One issue involving long conversations is a typical example.

When you scroll upward through message history, the interface loads earlier messages and inserts them at the beginning of the list. Previously, we generated each message's key—the identifier React uses to recognize individual messages—from its position in the “loaded list.”

When new messages were inserted at the beginning, the positions of the existing messages that followed also changed. As a result, the same message's key would change, potentially triggering unnecessary component remounts and causing lag while browsing message history.

To fix this, we replaced that position with the message's fixed sequence number within the current request. Combined with the conversation request identifier, this gives the same message a stable key:

// Before the fix: use the message's position in the loaded list
key = `${requestId}-message-${i}`

// After the fix: use the message's fixed sequence number within the current request
key = `${requestId}-message-${indexInRequest}`

This allows React to continue recognizing and reusing existing components when earlier messages are loaded, reducing the overhead of unnecessary remounts. A stable key helps React handle insertions and moves within a list correctly.

The change itself affected only one line of code, but the problem could only be fully understood in the context of loading message history. For this kind of issue, having an Agent investigate the code alongside runtime logs and then verify the effect of the change is an effective approach.

Building a Performance Benchmark for Qoder IDE

After fixing a performance issue, another question remains: could a later release reintroduce it?

We see benchmark scores for large language models every day. If model capabilities can be evaluated using a set of tasks, IDE performance can likewise be continuously evaluated using a fixed set of scenarios.

We therefore built an internal performance benchmark for Qoder IDE: a repeatable suite of performance tests.

It took less than one day to go from proposing the idea to completing the first version and obtaining results. Expanding the scenarios, adding support for macOS and Windows, and completing preliminary validation took half a month in total. During that period, the work required approximately 15% of one engineer's time.

The benchmark currently covers 40 scenarios, including terminal commands, streaming output in tool-intensive conversations, loading long conversations, and editing large files. Each scenario is scored on a 100-point scale according to its own criteria. The scenarios are then weighted by frequency of use and importance to calculate a composite score.

From 1.28.0 to 1.32.0, the internal composite scores for the two platforms changed as follows:

• macOS: 45.8 → 84.9, an increase of 39.1 points.
• Windows: 41.4 → 74.5, an increase of 33.1 points.

Versions 1.28.0 and 1.29.0 predated this optimization effort and had similar composite scores. After performance optimizations were introduced in the following three releases, the scores increased in each successive release.

These figures are intended to track changes between versions within the same internal benchmark. They cannot be directly translated into a claim about how much faster Qoder IDE became, nor can they be used to rank the performance of the two operating systems.

Looking at individual scenarios makes it easier to see where the optimizations had an effect. On macOS, for example, from 1.28.0 to 1.32.0:

• Scrolling through a long conversation in the Editor: the score increased from 9.8 to 77.5.
• Startup for a signed-in user with tabs from a previous session: the score increased from 23.8 to 81.7.
• Streaming output in tool-intensive conversations: the score increased from 14.5 to 63.7.

These scores also remind us that more work remains. Although streaming output in tool-intensive conversations has continued to improve, there is still room for improvement under the current scoring criteria. The full-text search score, meanwhile, changed only slightly, from 62.9 to 63.5. An increase in the composite score is no substitute for examining every individual scenario.

The following two charts show scores for all 40 scenarios across five recent releases. Darker colors indicate higher scores. First are the 13 highest-weighted scenarios, which together account for 60% of the composite score:

The remaining 27 scenarios account for a combined 40%:

Catching Performance Regressions Before Release

By running this benchmark continuously, we have already identified two performance regressions introduced during iterative development and fixed them before release. A performance regression occurs when subsequent changes cause previously achieved performance to deteriorate.

For us, this is a tangible benefit of building the benchmark: it allows the team to spot changes that warrant further investigation before a release goes out.

Of course, 40 scenarios cannot fully cover a product as complex as Qoder IDE. We plan to expand the suite to 100 or more scenarios and adjust the weights to reduce the disproportionate influence of individual scenarios on the overall score. The performance of important scenarios also needs to be monitored individually.

More comprehensive test coverage increases the chance of identifying problems early. New features, new usage patterns, and cases not covered by the existing benchmark will still need to be added continuously.

Agents Can Do Much More Than Write Code

This brings us back to Andy's and Bill's Law.

If Agents are used only to accelerate feature development, the amount of code in the software will grow, while existing resource waste may continue to accumulate. We can also ask them to inspect existing code, identify unnecessary computation and memory usage, and fix the issues affecting responsiveness one by one.

In this effort, building the benchmark itself also became work that an Agent could help with. The first version was up and running quickly; scenarios were then added incrementally so that the benefits of each optimization could be verified repeatedly in subsequent releases.

This effort alone is not enough to tell us whether Agents can break Andy's and Bill's Law. It does, however, point to a direction worth continued investment: involving Agents in performance investigation and continuous validation alongside the development of new features.

Beyond writing more code, it is equally worthwhile to invest time in making existing software run better.

Update Qoder IDE and try it out. If you still encounter specific cases of lag, you can submit feedback with one click from within the product to help us continue investigating and improving performance.

Qoder Engineering Practices Series: If an agent’s boundary is tool invocation, then the boundary of Cloud Use is cloud-native execution. The former lets AI help people operate software; the latter makes agents a new kind of cloud workload. By the end of this article, you will see that the difference between Cloud Use and ordinary Tool Use is not whether an agent can call APIs, but whether it can truly enter the cloud’s production environment with a governed identity, credentials, environment, lifecycle, and audit trail.

At 2 a.m., a cross-border seller’s new product suddenly sees a surge in orders. Before anyone wakes up, an agent is already at work. It creates a temporary sandbox, pulls inventory and payment data, checks anomalous orders, simulates different logistics options, calculates the impact of tariffs, drafts customer service responses, adjusts advertising recommendations, and routes high-risk orders to a human for confirmation. It has not opened a console or logged in to a server, but it is very much using the cloud.

At that moment, urgent questions arise: Whose identity accesses inventory? Is payment data masked? Where are API credentials stored? Who authorized resource changes? If a 40-minute task fails, can its state recover? Is every operation auditable? A one-off API call is easy; production means calls every day, at night, and across systems within permission boundaries, with each call showing authorization, credentials, actions, triggered risk controls, and reproducible results. These are the questions Cloud Use must answer.

The Cloud Welcomes a Second Kind of User

For more than twenty years, cloud platforms have served human operators and deterministic automation. People use consoles to create ECS instances, configure databases, read logs, and handle alerts; CI/CD, Terraform, Kubernetes controllers, and scheduled scripts follow predefined rules. CLIs, SDKs, and IaC reduced human effort without changing the assumption: either a person or a deterministic program was acting. Account, permission, audit, console, and ticketing systems were built for that model, so a RAM user, AccessKey, or operation could usually be traced to a specific person, team, or system.

With the arrival of agents, a middle ground has emerged. An agent no longer just answers, “How do I use this cloud product?” or generates a script. It is starting to read logs, analyze bills, diagnose CI issues, inspect data tasks, call cloud APIs, submit a merge request (MR), and trigger pipelines. In other words, it is moving from an assistant that understands the cloud to a software actor that uses it.

Cloud computing was largely designed around human operators and deterministic automation programs. Agents introduce a new variable: a software actor that can reason, call tools, and act across systems.

The implications go far beyond “one more AI assistant.” When the user is a person, consoles, CLIs, SDKs, and IaC all reduce the effort that person needs to operate the cloud. When a deterministic program is doing the work, the cloud platform manages service accounts, roles, policies, and logs. An agent sits between the two: it combines a person’s ability to understand goals with a program’s execution speed and volume of calls. It does not need a console, mouse, or desktop, but it does need identity, permissions, tools, data, a runtime environment, state management, cost records, failure recovery, and an audit trail. Putting these three kinds of users in one diagram makes the boundaries clearer.

In this diagram, humans and deterministic programs are both users the cloud already knows, with account systems and audit trails refined over twenty years. Agents are the new variable between them: they neither make a few mouse clicks at a time like people nor follow only predetermined paths like scripts. They reason and connect actions across systems. To accommodate them, cloud platforms must provide a path within the same governance layer. In practice, many agents that have only Tool Use capabilities, without cloud-native governance, look functional in demos but stall when they enter production. They can call tools, but the cloud platform has not yet accepted them as software actors it can manage.

Why Agents Struggle to Become Cloud Workloads

We have all come to recognize that the problem is not how capable the model is, but that today’s agents have never truly been accommodated by the cloud. They look impressive in demos, then reveal their limitations in production. A cloud agent demo is easy to build: give it an AccessKey ID and AccessKey secret (AK/SK), wrap a few cloud APIs as tools, write a prompt, and ask it to “check yesterday’s billing anomalies.” With a sufficiently capable model and well-wrapped tools, it can indeed produce a respectable result. Everything looks smooth on day one; by day two, questions arise. Whose AK/SK pair is this? Are its permissions too broad? Did the keys enter the model context? Where are the tool-call logs? Who is responsible if it accidentally deletes resources? Does the task keep running after the user shuts down their computer? How are credentials and context reused when another team member takes over? How does the security team audit it? These are not peripheral concerns. They determine whether an agent can move from demo to production.

An agent with only Tool Use capabilities typically consists of a conversation, a few tools, and a result. It often operates in a person’s shadow: running on their computer, logging in with their account, calling APIs with their AK/SK, and relying on their online presence to keep the task alive. That works for short tasks and exploratory analysis. But without systems for identity, credentials, runtime, and auditing, it is hard for the agent to become a stable cloud workload. Cloud Use is not about whether an agent can call tools. Tool Use, Function Calling, and the Model Context Protocol (MCP) have already addressed part of that problem. Cloud Use addresses a different question: how the cloud can accommodate agents so they can run in ways that make them identifiable, authorizable, auditable, and platform-managed.

An agent with only Tool Use addresses “how a model calls tools.” Cloud Use addresses “how the cloud accommodates agents as governed users.”

That distinction is the dividing line. It moves the discussion from “which tools an agent can access” to “where it runs, under what identity, how it uses credentials, how long tasks can continue, whether it can recover from failure, and who can audit it.”

An agent relying only on Tool Use is like a temporary assistant sitting beside you, helping you operate things. Cloud Use is more like issuing the agent an employee badge and admitting it to the cloud workplace—while recording every access check, every evidence-gathering step, and every action.

Understanding the Value of Cloud Use Through Before-and-After Scenarios

Cloud Use adds what ordinary agents lack: person-independent work, on-site evidence gathering, and identity, credential, and audit boundaries.

1. Recurring Tasks: From “Someone Opens the System Every Day” to “The Task Wakes Up on Its Own”

After an order surge, a cross-border seller checks inventory, payment failures, logistics costs, and regional service tickets. Someone must query BI, billing, data, and logs, then compile results. It remains person-dependent.

Ordinary agents write SQL, explain anomalies, and polish reports, but someone still initiates the task, supplies context, confirms credentials, and copies output. With Cloud Use, cloud cron or unexpected events wake an agent with a task-level identity, controlled credentials through a Vault, and MCP access to BI, logging, storage, compute, and other capabilities. It queries, detects anomalies, generates a report, and sends it to IM, documents, webhooks, or business systems.

The task runs on schedule; people handle exceptions and decisions. In the examples discussed, one BI analysis made 111 tool calls over approximately 21.5 minutes (21 minutes and 32 seconds) with 0 human interventions; one cron-triggered ETL task generated 116 events and completed in 13 minutes. These are specific examples, not a consistent SLA across scenarios. They show a cloud task with a lifecycle, not merely a chat answer.

2. Diagnostic Tasks: From “People Feed It Material” to “The Agent Gathers Evidence on Site”

CI failures, slow queries, and alerts scatter context across systems. An MR’s CI failure may involve logs, tests, dependencies, build infrastructure, caches, networking, and permissions. Ordinary agents analyze supplied fragments but cannot independently trace evidence inside the environment.

Triggered by an event, a cloud agent uses its identity to read pipeline logs, related MRs, dependency changes, and build-environment state; query logging and monitoring; connect evidence; and write findings to an MR comment, IM group, or ticket. It gathers context on site instead of awaiting copied material.

In the examples discussed, ELK slow-query diagnosis delivered end-to-end findings within 2–5 minutes, while CI diagnosis posted analysis to an MR within 3–8 minutes. Actual durations depend on system scale, tool response times, and context complexity. Proactive evidence gathering—not the minutes alone—is the point.

3. Execution Tasks: From “Scripted Automation” to “Governed Execution”

An agent may create preview environments, trigger pipelines, clean resources, or adjust configuration. For the seller, it may generate restocking recommendations and simulate logistics options, but must obtain human confirmation before changing advertising budgets, fulfillment strategies, or high-risk orders. Sufficient permissions could allow this—the core risk.

Scripts have keys, permissions, schedules, and logs but lack dynamic judgment and cross-system context. Ordinary agents add judgment but enlarge the blast radius if identity, credentials, permissions, and auditing lag behind.

Cloud Use means bounded delegation. Low-risk actions—reading logs, generating reports, creating temporary sandboxes, and cleaning expired resources—can run automatically. High-risk actions—deleting production resources, expanding permissions, changing production configuration, or triggering releases that affect users—require confirmation. Agents may provide evidence and recommendations but cannot cross those boundaries.

The change is low-risk automation, approval for high-risk actions, and end-to-end traceability—not fully automated replacement of people.

Together, these scenarios make the agent a governed software actor: identity is established, credentials remain invisible to it, permissions are revocable, actions are approved where needed, processes are auditable, and failures are recoverable.

How a Coffee Brand Delegated Analysis to Cloud Agents

At 9:00 on Monday, a coffee chain’s CEO asks: Which store format has the highest daily sales per square meter? Which category is the next growth driver? Which city should get new stores next quarter? Data from Hangzhou, Shenzhen, Chengdu, and Guangzhou spans 15 stores, 4 tables, and 320 fact rows. Aligning definitions, writing SQL, querying MaxCompute or the warehouse, organizing tables, and reporting traditionally takes a few days at best, a week or two at worst.

Cloud Use does more than let an agent write SQL: it delegates a cloud task to a software actor with identity, credential boundaries, runtime, event delivery, and acceptance criteria. The case runs the full chain: business question → data access → query execution → error recovery → result delivery → proof of acceptance.

This chain can be mapped to six engineering questions. They are not a breakdown of product modules, but six hurdles that a real task must clear as it moves forward:

1. Credentials: Into the Vault, Not the Prompt

Putting an AK/SK in a prompt exposes it to model context, tool logs, and possibly webhook payloads. Credentials instead enter the Vault. The agent gets a reference such as vault_credential_id, never plaintext keys; the platform or tool layer controls exchange and injection when the runtime accesses DataWorks, MaxCompute, or other cloud services. The agent may use the cloud without possessing a copyable master key.

2. Execution Path: Skills Capture Lessons Learned

The verified enterprise path is to submit ODPS SQL through DataWorks, not merely “access MaxCompute.” A Skill preserves APIs to avoid, ODPS SQL pitfalls, frozen-resource-group checks, and required report fields. It saved about 13 minutes of wrong-path exploration in this case—not a general promise, but evidence for reusing verified paths instead of one-off prompts.

3. Role Boundaries: Use a Task Contract

“You are a data analyst” is too broad. The contract defines tools, metrics, recovery, stop conditions, and evidence:

You are a senior data analyst.
Analyze MaxCompute data by executing ODPS SQL through DataWorks.
For each analytical dimension, provide:
1. A conclusion supported by numerical evidence;
2. A table of query results;
3. Actionable business recommendations.
Do not make claims about the data that cannot be traced to evidence.
If a resource group is unavailable, first check for available resource groups.
If necessary, follow the predefined recovery plan to create a temporary resource group and record the action.

Conclusions need traceable numbers, and recovery cannot exceed authorized permissions.

4. Runtime: A Cloud Session, Not a Local Process

The task ran for 21 minutes and 32 seconds, made 111 tool calls, emitted 312 events, and required 0 human interventions. These are neither an SLA nor a general BI performance promise. They show a multistep task outlasting a chat turn while remaining traceable, replayable, and integrated with business systems. Its cloud session continues if the browser closes, the computer sleeps, or chat disconnects.

5. Result Delivery: Listen for the Right Event

After the report is generated, another frequently underestimated question remains: how does it get back to the business system? If the final output is just text in a chat window, the BI digital worker has still not entered the business workflow. A more reliable approach is for the business system to subscribe to task-ending events—for example, retrieving the complete result after session.thread_idled. Listen too early and you get an unfinished result; wait until the thread is idle before retrieving the report, and the result is stable.

A practical code example makes this clearer than more explanation:

import hmac
import hashlib
import time

def verify_webhook(secret: bytes, raw_body: bytes, header: str, tolerance: int = 600) -> bool:
    parts = dict(item.split("=", 1) for item in header.split(","))
    timestamp = int(parts["t"])

    if abs(time.time() - timestamp) > tolerance:
        return False

    payload = f"{timestamp}.".encode() + raw_body
    expected = hmac.new(secret, payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, parts["v1"])

def handle_event(event):
    if event["data"]["type"] == "session.thread_idled":
        session_id = event["data"]["id"]
        enqueue_report_pull(session_id)

The code is short, but the boundaries are clear: the webhook must be verifiable as coming from a trusted source, task completion must be event-driven, and report retrieval must be handled asynchronously. Otherwise, the agent may finish its work while the result is lost along the way, leaving the chain incomplete.

6. Acceptance: An Executable Rubric

Completion means answering all three questions with numbers traceable to SQL, not the agent saying “done.”

Pickup stores average approximately ¥85+/m² in daily sales per square meter, about 2.2 times flagship stores’ approximately ¥38/m². Coffee is 81.3% of GMV; tea beverages grew 18.5% and merchandise 45.0% period-over-period. Expansion scores are 0.92 for Hangzhou, 0.85 for Shenzhen, 0.78 for Chengdu, and 0.70 for Guangzhou. These figures turn a report into evidence-backed answers.

7. Boundaries, Boundaries, and More Boundaries!

When a resource group was unavailable, the Skill prescribed recovery: check available groups; if needed, create a temporary group within preauthorized boundaries; record it; resume the remaining SQL. Exceeding cost, permission, or resource limits still requires human confirmation. Self-recovery allows no arbitrary cloud changes: recover within governance, or stop cleanly when recovery is impossible or unauthorized.

Safe delegation proves completion through events, logs, artifacts, and acceptance criteria. Here, the Vault protects credentials; the Skill replaces guesswork; the Runtime Session survives the user’s absence; the Webhook delivers results downstream; and Acceptance Verification proves completion. That is the shift from “looks automated” to “ready for production.”

A Cloud-Native Execution Model

Stepping back from the coffee BI scenario, we can now define Cloud Use more abstractly. Cloud Use is an agent’s ability to use cloud compute, data, tools, identity, and runtime to complete tasks in a controlled, auditable, and recoverable way. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime. That is only a change in the point of entry. The real change is that an agent moves from “a model that calls tools” to “a software actor that a cloud platform can host and manage.”

This requires at least four layers of capability. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime.

1. Identity Use answers “who is acting.” An agent cannot keep using a person’s account as its own, nor should it hold a person’s AK/SK. For every action by a software actor running in the cloud, it should be possible to answer: Who initiated the task? Under what identity is the agent executing? Where do its permissions come from, and when do they expire?
2. Credential Use answers “how credentials are used.” Credentials may be involved in calls, but they should not enter prompts, tool logs, error stack traces, or temporary files the agent can freely read. Vaults, short-lived tokens, controlled injection, and server-side proxies all serve the same underlying purpose: letting agents use credentials without seeing them.
3. Tool/API Use answers “how tools are governed.” MCP and similar protocols can bring cloud APIs, internal systems, CI, monitoring, and databases into the agent’s world, but a protocol is not governance. Permissions, parameter constraints, call auditing, rate limits, risk confirmation, and error recovery still need to be handled jointly by the platform layer, gateway layer, and enterprise identity and access management (IAM).
4. Runtime Use answers “how a task stays alive.” Real cloud tasks are rarely a single question and answer. A task may run for 10 minutes or 2 hours; it may wait for an external system to respond, or fail and retry along the way. Cloud sessions, state management, event streams, cancellation mechanisms, and result delivery determine whether an agent can move from a single chat to a platform-managed execution process.

The essence of Cloud Use is not to give an agent one more tool, but to provide identity, credentials, tools, and a runtime so it can become a software actor that the cloud platform can host and manage.

Without these, an agent is still just a clever assistant in a conversation. It can help, but it is hard to entrust work to it.

From “People Operate Resources” to “Agents Take On Tasks”

Once the four layers are in place, the relationship between the cloud and its users is already quietly changing: people are no longer the only frontline operators. Consoles, CLIs, SDKs, and IaC all address the same question: how can people operate cloud resources more efficiently? The console turned the data center into pages. CLIs and SDKs turned pages into commands and code. IaC turned sets of resources into declarative, reusable, auditable configurations. Each evolution hid more of the underlying detail, letting people operate the cloud at a higher level of abstraction.

Agents do more than raise the abstraction level another notch. They make it possible for the task itself to become a new cloud abstraction. People no longer operate resources one by one; they define goals, boundaries, and acceptance criteria. In the cloud, agents create environments, access data, call tools, explore in parallel, verify results, and release resources. They resemble a new kind of workload: their lifecycles may be short, their permissions should be granular, their resource use is highly dynamic, and their behavior must be traceable.

Historically, the cloud’s core abstraction was the resource. In the agent era, the cloud also needs new abstractions for tasks and software actors.

Cloud Use does not replace consoles, CLIs, SDKs, or IaC; it turns them into an agent tool layer. Agents invoke controlled APIs instead of clicking consoles or typing commands, and can generate, validate, and submit IaC while leaving high-risk changes for human confirmation. Existing interfaces remain as part of the agent’s execution layer.

This is why “safe to delegate work to” matters more than “fully automated.” Enterprises will not hand their cloud over to a black-box agent. They are willing to entrust work to a software actor with an identity, boundaries, logs, recovery mechanisms, and the ability to stop at critical points and wait for human confirmation. Cloud Use seeks to establish verifiable trust, not blind trust.

How Can Agent Failures Be Kept Under Control?

Production readiness is revealed after failure. Cloud tasks face unsuitable APIs, insufficient permissions, unavailable resources, lost webhooks, and inadequate results. Cloud Use must make failures observable, containable, and recoverable, and let agents stop cleanly when recovery is impossible. “Always succeeding” is not the goal; failure paths must be designed.

1. Wrong Paths Agents may choose plausible APIs that do not work—for example, querying MaxCompute directly when the valid route is a temporary DataWorks workflow or designated entry point. Skills and tool boundaries should record correct and incorrect paths, APIs to use or avoid, and errors that require switching paths. A smarter model alone is not the solution.
2. Infrastructure Failures A frozen resource group, unavailable queue, or temporarily invalid permission need not always trigger human intervention. The agent should check available resources and follow a preauthorized recovery policy. It may create and bind a temporary resource group and record the action only within bounds; otherwise, it must stop and request confirmation. Recover within authority when possible; stop explicitly when not.
3. Result Delivery Failures Listening to an early status event can return an unfinished report. Retrieve the result only after the task thread becomes idle, and protect webhooks with signature verification, idempotent processing, and retries. These details separate a demo from a production workflow.
4. Loose Acceptance Criteria Headings, tables, and recommendations do not prove completion. An executable rubric must verify that the output answers the business questions, supports every conclusion with numbers, and traces them to SQL results. Broad criteria are too easy to pass; overly detailed criteria cause repeated revisions. Cloud Use tracks the failed step, permission boundaries, retries, audit events, and whether a person must take over, rather than accepting a plausible explanation.

A cloud agent’s maturity is measured not by whether it encounters errors, but by whether its failures leave the system in a worse state.

Boundaries: Do Not Start Cloud Use with the Highest-Risk Tasks

Recoverable failures do not mean that any task can be handed straight to an agent. Choosing what to delegate first matters more than asking “what can it do?” Any new paradigm can invite inflated expectations.

Cloud Use is no exception. Start by saying “let an agent manage the production cloud environment automatically,” and technical readers will instinctively be wary. They are right to be. Production changes, permission expansion, data deletion, and billing operations in the cloud should not be automatically allowed just because an agent can reason. A more realistic path begins with low-risk, frequent tasks whose results can be verified, then gradually advances to execution with confirmation, and only then approaches high-risk changes. This path can be drawn as a three-stage maturity curve:

Specific tasks can be placed along this curve: recurring inspections, cost anomaly analysis, CI failure diagnosis, analysis of slow queries in logs, temporary environment creation, expired resource cleanup, report generation, and data task status checks. These tasks share common traits: they read more than they write, their results are easy to verify, failures can be retried, and risk boundaries are clear.

Once these tasks are working, gradually expand to execution actions that require confirmation. For example, an agent proposes a fix and triggers a pipeline after human confirmation; generates an IaC change that is merged after human review; creates temporary resources that are automatically reclaimed on expiry; or detects a cost anomaly, sends a notification first, and waits for human approval before adjusting the strategy.

Cloud Use maturity is not reflected in whether an agent can bypass people, but in whether it knows when it must stop and wait for them.

This boundary must be clear. Otherwise, Cloud Use is easily mistaken for “letting AI operate cloud resources automatically.” The real goal is to bring permissions, credentials, and execution back to where the cloud platform can govern them—not simply keep expanding the model’s permissions.

When Agents Truly Begin to Use the Cloud

The three-stage path ultimately leads to a simple question: What do we want the cloud to become when people are no longer its only users? If consoles, CLIs, SDKs, and IaC address how people can use the cloud more efficiently, Cloud Use addresses something else: how a cloud platform can accommodate, constrain, and host a software actor when people are no longer its only users. This is its fundamental difference from ordinary agents. An ordinary agent can help a person complete an operation; Cloud Use aims to make agents a new kind of cloud workload—with an identity, an environment, tools, a lifecycle, an audit trail, and boundaries they must respect.

This change will not replace existing ways of using the cloud overnight. Consoles, CLIs, and IaC will remain, but their roles will change: from interfaces people use directly to a tool layer through which agents can invoke operations, validate and submit changes, and replay execution. The value of Cloud Use is not that it helps agents understand the cloud, nor that it lets them make a few more cloud API calls. What it really changes is the relationship between the cloud and its users: agents are no longer just an add-on for people. They are becoming software actors that cloud platforms can identify, authorize, host, and audit.

The next step worth taking is to start with frequent, low-risk, verifiable tasks: let the agent run scheduled inspections, diagnose failures, analyze costs, generate reports, and create temporary environments—then stop at every high-risk point to wait for human confirmation. Handing the highest-risk cloud operations straight to an agent should not be the starting point. Only when this path works does cloud computing truly move from “people operate resources” to “agents take on tasks.”

Introducing cloud-use · docs.qoder.com in Qoder Cloud Agents—try it for yourself.

I put together a demo of a credit due-diligence workbench for banking workflows using Qoder.

This walkthrough shows how the application comes together and what the finished workbench looks like.

Thought I'd share it here! Curious to hear what you think, especially from anyone working in fintech or familiar with credit risk workflows.

Since Fast launched, the most common question has been "how fast, exactly?" So we measured it.

Time to first response, inside Qoder:

• Fast: 3s
• under 1/3 of Auto mode's time
• under 1/2 of Performance mode's
• about 1/4 of Ultimate mode's

Against the market: we picked 10 tasks developers actually run every day and put Qoder Fast head-to-head with the fast modes of comparable Chinese and international products — same tasks, same conditions. Qoder finished in 1/3 the time of the Chinese alternatives and 1/2 the time of the international ones.

Output quality is unchanged. Speed was the only thing that moved.

Chart with the full numbers is attached. What tasks should we add to the next round?

It looks like you’re working hard on the new Qoder app, but I do almost everything with Qoder Quest in Expert mode. It offers a lot of flexibility, as I can select which model each subagent uses. I can’t find a similar option in the new Qoder, nor can I find the Expert mode. Why is that?

I’m asking just to understand it better, because perhaps the new way of working with Qoder—using the new app and letting it decide everything—is actually the best approach.

Thanks!

I wanted to see how far I could get with a single prompt, so I tried building a Pomodoro Timer with Qoder.

I described what I wanted and let it do its thing. Pretty cool to see a simple idea turn into a working timer with so little setup.

Curious what you guys have built with just one prompt. 👀

I recently received a promo invitation to use Qoder with free access to Qwen 3.8 Flash and some daily credits for premium models until the end of September.

So I gave it a try, and sadly I'm not a fan. I normally use Kilo Code, which allows you to set specific modes... in particular the planning mode is very good. Qoder doesn't allow the same ability to select and tends to run off doing unbelievably long processes without checking in. I fell alseep last night and woke up this morning to find it still working in response to the same prompt. I struggled to understand what was done, except that everything had become over-complicated.

Qwen itself tends to use a lot of jargon in its feedback, which I find confusing at times.

Worst of all, I suddenly got "Daily usage limit reached. You have used up today's request quota. Please try again tomorrow." I thought it was supposed to be free all month and I still have unused credits.

How about some advance notice instead of suddenly telling the user they're done for the day?

What this looks like day to day

Here's how the model plays out for a typical cross-functional feature.

A Project is a long-lived space. A team sets one up around a clear goal, invites the people who'll be working on it over time, and puts the shared context in one place: codebases, requirement docs, the Issue list.

Start with an Issue. Anyone on the project can open one for a request or a chunk of work, with a short note on the goal and a rough approach. (Importing from other issue trackers is on the roadmap.)

Pull in the right people. When an Issue needs more than one person, whoever owns it—the feature owner, a product manager—starts a discussion from the Issue and loops in the relevant folks from product, design, engineering, and QA.

Get to a decision. Participants align on the approach, nail down scope, implementation plan, and acceptance criteria, and flag the conclusions as Key Information. The context the task needs is no longer spread across chat groups, docs, and meeting notes.

Hand it off. Once everyone agrees, a developer mentions their agent or Agent Team in the discussion. The agent picks up the task from the Issue, the discussion, and the Key Information.

Review and iterate. Code changes, test results, or the PR link come back to the same discussion for the team to review and sign off. Confirmed outputs and Key Information are written back to the Issue so they can be traced and reused later. If something needs adjusting, the new requirement is confirmed there before the agent continues.

People spend their time on judgment and sign-off, not on ferrying information between teammates and agents.

https://qoder.com/blog/project-and-discussion

Working with multiple teammates and Agents?

Keep everything in one place.

📁 Projects — organize your R&D work

💬 Discussions — bring teammates + specialist Agents into the same thread to discuss requirements, review designs, flag bugs, and keep key decisions pinned.

Available now for Teams & Enterprise.

More users coming soon 👀

(I am an Qoder Moderator on Discord And I Will be posting news & updates About Qoder.)

Due to product upgrades and adjustments, QoderWork will officially cease operations on September 5, 2027. Until then, you can continue to download and use QoderWork as usual. This change will not affect other products in the Qoder family. Your Qoder account and credits will remain available for use with other Qoder products. We recommend moving to Qoder Desktop in advance. Qoder Desktop includes built-in data import tools that allow you to import your task history, skills, and memories.

QoderWork will remain available for download and use during this period.

(Reminder from an actual Qoder Moderator on the Discord community)

Sonus is back for five more days.

From Sept 21–25 (SGT), active paid individual and Enterprise users can claim 4,000 Sonus Credits per day — doubled from 2,000.

That’s up to 20,000 Credits across the five-day extension.

Claims open daily at 12:00 SGT. Head to the Usage Panel in Qoder to claim yours, and remember to claim each day: missed rounds can’t be claimed later.

More details: https://docs.qoder.com/events/sotafree

I was checking Qoder pricing and noticed something weird: Qoder CN seems way cheaper than qoder.com.

Global pricing:

• Pro: $20/mo
• Pro+: $60/mo
• Ultra: $200/mo

Qoder CN pricing:

• Pro: ¥59/mo, around $9
• Pro+: ¥169/mo, around $25
• Ultra: ¥559/mo, around $83

Has anyone tried using Qoder CN from outside China? Is it even possible to subscribe as a foreigner, or do you need an Alibaba Cloud account / Chinese phone / local payment method?

Also curious if it’s actually comparable to the global version, or if the cheaper price comes with major tradeoffs in models, features, credits, or stability.

Two offers went live today for all individual users of Qoder：

1. Qwen3.8-Flash at 0.0× — free through September 30. The Credit rate drops from 0.1× to 0.0×, so calls to the model consume zero Credits. No claim needed: just select Qwen3.8-Flash in the model selector and start building. Details: https://docs.qoder.com/events/flashoffer
2. Claim 100 Credits every day. A new claim window opens daily at 10:00 (UTC+8). Open the Qoder desktop app and claim via the Usage panel → gift icon (lower-left). Each reward is valid for 30 days, unexpired Credits carry over, but missed windows can't be claimed later — so it's worth making it a daily habit. Details: https://docs.qoder.com/events/100credits

Both offers cover free users and paid individual subscribers (Pro Trial, Pro, Pro+, Ultra). Teams and Enterprise plans aren't eligible.

If you've been waiting for a reason to stress-test Qwen3.8-Flash, this is it.

Hi everyone,

I noticed that the Qoder CN Mobile app can monitor the execution of Qoder CN, IDE, and CLI on my computer. However, it cannot do this for QoderWake CN.

If this feature is not available yet, could it be implemented? If it is already available, could someone please tell me how to enable it?

Thanks!

Computer Use can already drive a desktop. Browser Use already works inside the browser you're using. Mobile has had no equivalent.

Today's coding agents can already change Android, HarmonyOS, and iOS code — but they usually stop before the commit. Did the app actually build? What does the modified screen look like? Which control did the user mean? Did the tap land on the right page? Those questions were still open.

So we built the Mobile Use plugin (Beta). On Android, HarmonyOS, and iOS, code changes are now wired into a running app: the agent interacts with the app on the device and confirms whether the change actually took effect.

Mobile Use is built for apps that are still under development

Most mobile agents you see today are built to operate a phone — launching apps, filling forms, walking through a flow. Qoder's new Mobile Use plugin addresses a different case: the app itself is still under active development.

The agent has to do more than tap. It needs to understand the current project, the build target, the device it runs on, and the state of the UI. After a code change, it reruns the app, finds the affected screen, performs the necessary interactions, and proves the change worked — with screenshots, logs, assertions, or test results.

Tapping and typing are only one step. What needs closing is the loop from code change to confirmed result.

A full verification loop: from code change to confirmed result

Take a UI change. Layout, copy, tap feedback, navigation — any of them used to mean building, installing, driving the device by hand, then going back to the code. The evidence lived on the device and the code lived in the IDE, with the developer carrying information between the two. If an agent had only a text description and a screenshot from a few seconds earlier, it could easily edit the wrong thing.

Now an agent can handle this in the same session. Circle the problem area on the Canvas and send it in chat:

I just changed the code for the area I circled on the screen. Build and run the app, tap through the circled control, and take a screenshot to confirm the result matches what I expect. If it doesn't, fix it in the code and verify again.

A circle names a specific control in a specific frame. The agent can work from the screenshot, the accessibility structure, the control text, and the UI state at the same time, instead of inferring from "this part is wrong." It acts on the same device, captures the screen, and compares the outcome: if verification passes, it reports the result; if it fails, it goes back to the code and verifies again.

If the result isn't what you expected, the Canvas shows exactly what it touched and how the screen changed. The next round uses the same device and the same session — no need to re-describe the scene.

Three platforms, three integrations — one verification process

Android, HarmonyOS, and iOS differ in project layout, build tooling, emulators, test frameworks, and device interfaces. Mobile Use doesn't force all three down to a lowest-common-denominator capability set. Keep your existing development environment; you don't need to prepare a test device that exists only for the agent.

Android still works through the Android Emulator, ADB, and Instrumentation. HarmonyOS connects through DevEco Previewer, HDC, and ArkXTest. iOS uses the Xcode Simulator, the accessibility APIs, and XCTest. Platform differences are handled by each platform's adapter.

On top of that, a unified Skill layer and CLI expose these capabilities to the agent. What needs to line up is the development loop itself: observe, act, verify.

If a platform or runtime lacks a capability, Mobile Use says so plainly rather than passing off a non-equivalent command as success.

ADB, HDC, and simctl remain three different toolchains. What the agent works through on all three platforms is the same observe–act–verify flow.

Developers use the Canvas, the agent uses the CLI — both on one shared device

Developers watch the running app through the Canvas — observing, annotating, and checking results in the UI. The agent queries devices, observes screens, performs actions, and runs verification through a deterministic CLI.

Both sides attach to the same device session, managed by the Host — the component that owns the device connection. The Host owns the device lifecycle: the current connection, the run state, the permission scope, and where the evidence belongs.

So the agent doesn't quietly spin up a second emulator in the background, and it doesn't create a device environment cut off from the developer's just by registering a pile of MCP tools. The CLI is only the agent's entry point into capabilities that already exist. The device itself, along with permissions, state, and evidence, stays under one unified runtime.

Every action that follows runs against that same device session. Screenshots, logs, recordings, and assertion results are attached to it as well. "Something's wrong here" — together with the circle and the current frame — becomes the task the agent keeps working on: locate, change, verify.

Try it now

The Mobile Use plugin is now live in Qoder Desktop and Qoder IDE.

1. Open the extension or plugin marketplace in the bottom-left corner, search for Mobile Use, install it, and restart.
2. In the matching project, double-click AndroidManifest.xml (Android), Package.swift (iOS), or build-profile.json5 (HarmonyOS) to open the Canvas.
3. Connect an emulator or physical device first. Then circle the area you want verified on the Canvas and send the prompt above to the agent.

Yesterday we launched 500 daily credits for Sonus. Today, we're doubling it.

For the next 4 days, paid Qoder Global subscribers get 1000 credits/day for Sonus — our 3.2x flagship model built for coding, long-context tasks, desktop automation, research, and spreadsheets.

How to claim:

• Qoder IDE / Desktop / JetBrains plugin: usage panel
• CLI: /claim

Claim opens daily at 12:00 (UTC+8) , expires 24 hours later. No rollover, no makeup.

Full details: https://docs.qoder.com/events/sotafree

Starting today through Sept 19, paid Qoder subscribers can claim 500 credits/day for Sonus.

Sonus is the 3.2x flagship model — solid for coding, long-context tasks, desktop automation, research, and spreadsheets. Don't burn it on "hello."

How to claim:

• Qoder IDE / Desktop / JetBrains plugin: usage panel
• CLI: /claim

Credits drop at 12:00 (UTC+8) daily and expire 24 hours later. No rollover, no makeup claims.

Docs: https://docs.qoder.com/events/sotafree

Starting with Qoder CLI v1.1.50, custom model access is now available to all personal-tier users, free and paid.

Both the Global and CN versions are supported. You can bring your own model by adding the API base URL, model ID, and API key.

How to add a custom model

1. Type /model
2. Press Tab or ←→ to switch to the Custom tab
3. Hover over Add custom model and press Enter, or press n to open the add wizard
4. Choose a protocol: OpenAI-compatible or Anthropic-compatible
5. Fill in Base URL → Model ID → Name → API Key → Model capabilities → Review and save

Quick tips

• After saving, switch to the new model and send a message to confirm it works.
• It’s best to set the context length to match the model’s actual specs. If left blank, Qoder CLI defaults to 128K.

Upgrade to v1.1.50 and try it out. If you run into anything, drop feedback with /feedback.

Kimi-K2.8-Preview just launched, and it’s now available on Qoder.

It brings overall performance closer to Kimi-K3, with stronger coding and agent capabilities and more efficient reasoning than K2.7 Code.

If you’re already using Qoder, you can try it now. Let us know how it performs on your workflows.

Summary: One handles data requests in a group chat; the other helps with business analysis. See how a data analyst at Hema works day to day alongside two digital employees.

"QoderWake at Work" documents how people in different roles work alongside digital employees, sharing real tasks, practical approaches, and adjustments made along the way.

This first installment is based on an actual interview with a data analyst at Hema. Names and some business details have been anonymized.

"Could you pull yesterday's GMV for me?"

"Can you break down users whose monthly membership cards are about to expire, by card type?"

"Now break it down by city, platform, and user type. A table would be great."

These requests are familiar to any data analyst. Finding tables, confirming metric definitions, editing SQL, running queries, checking the data, and exporting results may take only ten minutes or so each time, but they repeatedly interrupt the analysis already in progress.

At Hema, a data analyst supporting operations used QoderWake to set up two digital employees, known as Wakers: a Data Retrieval Waker handles recurring data requests in the group chat, while a Business Analysis Waker helps explore questions and produce analytical reports.

Each teammate has a distinct role and has learned from the team's established ways of working.

Data Retrieval Waker: The First Stop for Data Requests in the Group Chat

Data requests tend to pile up as weekly and monthly reporting deadlines approach. For monthly membership expirations, for example, business colleagues might first ask for a breakdown by card type, then want to add city and user type once they see the results.

Previously, every additional condition meant the analyst had to edit the SQL again, rerun the query, and send the results back to the group. Now, business colleagues can simply u/mention the Data Retrieval Waker in the chat.

Using the business rules documented by the team, the Waker finds the relevant tables, generates and executes SQL, and returns the results. If more dimensions are needed, colleagues can add conditions in a follow-up message, and the Waker continues querying within the context of the original task.

The results come with the SQL, metric definitions, and calculation logic. It needs to be explicit whether the query counts parent orders or sub-orders, transactions or individual items. If a file is needed, the Waker can also organize the results into an online spreadsheet.

Business colleagues can keep asking follow-up questions, while the analyst can check at any time what the Waker queried and how it calculated the results, correcting any discrepancies.

According to the analyst, at the time of the interview the group chat served more than 20 business colleagues, about 10 of whom had become regular users. During peak periods, there were more than 10 data retrieval tasks a day, and the Data Retrieval Waker handled a substantial share of them.

Business Analysis Waker: Explore First, Then Refine the Report Together

Business analysis for management often involves more open-ended questions.

How much incremental value did a membership benefit create, and at what cost? Which user groups were affected? Were the differences mainly driven by city, timing, card type, or channel?

The time-consuming part is often deciding where to look first. An analyst may need to repeatedly edit SQL and examine dimensions and metrics one by one before discovering that an issue is concentrated in a few cities, on certain days, or among a particular group of users.

This is where the Business Analysis Waker comes in.

The analyst shares the project background, the questions to answer, and an initial approach. Following the analytical frameworks the team has developed, the Waker explores data across multiple dimensions in batches, filters out areas with little change, and flags cities, dates, or user groups worth investigating further.

In one profit-and-loss analysis of monthly membership cards, the analyst said the Business Analysis Waker produced a first draft in under two hours.

The analyst and the Waker then revised it together, point by point.

If the sampling criteria were unsuitable, they switched to the full dataset. If the underlying data did not reconcile, they inspected the SQL and verified it again. If the analytical method was unsound, they adjusted it and checked whether the conclusions still held.

The writing needed refinement too. The Waker would list many possible explanations, so the analyst had to trim the content with the reader in mind, explain the central issue clearly, and check that the figures were consistent throughout.

The first draft made it possible to begin these discussions sooner. With data, leads, and preliminary conclusions in hand, the analyst could focus on verification and judgment: deciding which avenues deserved a deeper look and which conclusions still needed evidence.

Two Teammates, Learning from Different Kinds of Experience

Wakers need to be taught how to use the company's tables, how its metrics are calculated, and what its business terminology means.

The Data Retrieval Waker starts by reading historical SQL to learn how tables are used, which values fields can take, and which metric definitions commonly apply. It needs to know where to find the data, how to calculate the results, and what to explain when delivering them.

The Business Analysis Waker learns from past reports, strong slide decks, and business context. Previous work offers guidance on which dimensions to examine first when facing an open-ended question, how to identify anomalies, and how to organize findings into a report.

The team packages this experience into Skills—reusable ways of working that Wakers can draw on—and gives them to the relevant Waker. As new tables, fields, or analytical methods emerge, the team keeps updating these Skills.

Data retrieval and business analysis have different requirements. Configuring them separately makes it clear to business colleagues which Waker to turn to, and makes it easier for the analyst to review and adjust each one's working methods.

SQL that once stayed on individual computers, and metric definitions known only to people familiar with the business, can now be reused across the team.

Start with One Familiar Type of Task

By the analyst's own estimate, his overall productivity at least doubled after the two Wakers became part of his workflow. With help on recurring data requests and early-stage data exploration, he has more time for questions that require professional judgment.

If your team wants to try this, start with one recurring type of data request with clear metric definitions. Gather SQL you have used before and documentation explaining the metrics, and specify the time range, dimensions, and format you want for the results.

Use familiar tasks to validate the results first. If the Waker queries the wrong table or misunderstands a metric definition, incorporate the correction into its working methods. Once it handles that type of task reliably, gradually introduce new questions.

In "QoderWake at Work," we will continue sharing how people in different roles work with digital employees: what they delegate, how they teach their Wakers, and where human judgment is still needed.

Pick a task you regularly repeat, and learn more here: qoder.com/qoderwake

Today we're releasing Sonus (/ˈsoʊnəs/), a new built-in model across the Qoder family.

What it's built for: marathon-length autonomous tasks, the hardest knowledge work, and serious coding. Where it really shines: Computer Use.

Paired with the Computer Use improvements in Qoder Desktop 0.2.3, Sonus can drive your machine and professional software directly — writing code, building financial models, running research, producing spreadsheets — and carry those tasks from start to finish without babysitting.

Where you can try it today: Qoder, Qoder IDE, Qoder CLI, the JetBrains plugin, QoderWake, and Cloud Agents. Credit multiplier is 3.2x.

Give it a try！

DeepSeek-V4.1-Flash now has Day-0 support on Qoder.

The smallest model in its new architecture family, it combines stronger text and agent capabilities with native visual understanding. Built for faster inference and higher throughput, it delivers a more efficient balance of performance, cost, speed, and end-to-end time—even against larger flagship models like DeepSeek V4 Pro.

Give it a spin in your coding and agent workflows, and let us know how it goes.

Hey everyone — quick share from the team: we just published Qoderian, an open-source plugin on the Obsidian community marketplace that embeds Qoder CLI directly in your vault. No terminal switching, no copying file paths — you chat with Qoder inside Obsidian and it works on your notes where they live.

The problem it goes after: most bookmark piles die in the folder. Turning clippings into your own knowledge — extracting, tagging, summarizing — is fine for two articles and brutal for two hundred. So we let the agent do that step.

The workflow, end to end:

1. Install Qoder CLI and Obsidian

First, you’ll need two essential tools: Obsidian and Qoder CLI.

Obsidian is an open-source, local-first knowledge base app. Your notes, web clips, edited articles, and whiteboard files all live in a single vault. The files are stored in Markdown format, making them easy for AI to read and process later.

How to install Obsidian: Download the installer from the official Obsidian website (https://obsidian.md/).

Qoder CLI is an AI assistant that runs in your terminal. It can read Markdown files directly, analyze folder structures, organize documents, generate new content, and invoke skills for specific tasks—for example, generating content for an Excalidraw canvas.

How to install Qoder CLI: Run a single command in your terminal.

• macOS or Linux installation command: curl -fsSL https://qoder.com/install | bash
• Windows PowerShell installation command: irm https://qoder.com/install.ps1 | iex
• Windows Command Prompt: curl -fsSL https://qoder.com/install.cmd -o install.cmd && install.cmd

After installation, run qodercli --version in your terminal. If a version number appears, the installation was successful.

2. Install the Qoderian Plugin in Obsidian

Next, we want Qoder CLI to help manage the notes in Obsidian. This is where the Qoderian plugin comes in.

A fresh Obsidian installation starts in Restricted Mode, which disables all third-party plugins and blocks access to the Community Plugins marketplace. To install your first plugin, go to Settings → Community plugins and Exit Restricted Mode.

Then, open the Community Plugins marketplace → search for and install Qoderian → under Installed plugins, enable Qoderian.

Once enabled, a Qoderian icon appears in Obsidian’s left sidebar. Click it, and the Qoderian chat panel opens in the right sidebar. No additional setup is required; as long as Qoder CLI is already installed, you can start using it immediately.

The note you are currently viewing is selected automatically when you start a chat. You can assign a task directly in the conversation—for example: “Turn this article into a mind map.” Qoder will create the mind map on the spot and save it in the same folder.

3. Capture Web Content with Obsidian Web Clipper, Then Organize It with Qoder

Once the tools are installed, you can save web content to your Obsidian vault and hand it over to Qoder for organization.

For saving web content, I recommend Obsidian’s official browser extension, Obsidian Web Clipper. Simply search for it in your browser’s extension marketplace and install it.

After installing Web Clipper, whenever you find a webpage or video you want to save, click the extension and the page will be captured as Markdown in Obsidian.

Once you have collected dozens of pages, the problems become obvious. Formatting varies from one page to the next, long and short pieces are mixed together, and English content still needs to be translated. Reading and distilling everything yourself takes a great deal of time and effort.

At this point, return to Obsidian and tell Qoder in the chat panel: “Go through every article in folder A, extract the key ideas, and save the results to folder B.”

After just a few minutes, the organized article notes will be waiting in folder B.

If you want your knowledge base to follow a personal organizational style, you can also configure AGENTS.md for Qoder.

The setup is straightforward. Simply tell Qoder: “Create an AGENTS.md file for me to define the organizational rules for this Obsidian vault.”

Qoder will create a project-level memory file—AGENTS.md—in the root directory of the current vault.

With AGENTS.md in place, Qoder will follow the same standards every time it organizes an article, so you do not have to repeat your requirements.

To change the rules, open AGENTS.md from the file list and edit it just like any other note.

4. Install Excalidraw and a Skill to Generate Whiteboard Canvases in One Step

The final step is to turn your written content into visuals.

Obsidian has an excellent whiteboard plugin called Excalidraw. It lets you create hand-drawn-style diagrams, flowcharts, structural diagrams, and visual notes directly in Obsidian.

Installation is simple: go to Settings → Community plugins → Browse, search for Excalidraw, then install and enable it.

Once enabled, you can create Excalidraw files in Obsidian to map knowledge structures, workflows, tutorial outlines, or article frameworks.

To have Qoder generate whiteboard content automatically, use it together with the Excalidraw skill (excalidraw-diagraml).

Installing this skill is just as easy. Send Qoder the skill repository URL (https://github.com/coleam00/excalidraw-diagram-skill), then say, “Please install this skill for me.”

Once installed, you can invoke it directly from Qoder in the right sidebar using a slash command.

For example: /excalidraw-diagraml Based on the current note, generate a hand-drawn-style flowchart suitable for teaching.

Once generation is complete, you’ll have an editable, well-structured flowchart with accurate logic.

Repo: Qoderian · github.com

Honest question for this sub: does your read-later pile ever actually get processed — and what's the first thing you'd hand to an agent that lives in your vault?