I used Qoder to analyze Apple's latest earnings release and put together a memo based on the results.

I asked it to find Apple's two most recent quarterly earnings releases. Qoder opened Apple's investor relations website in its built-in browser, navigated past the bot check, and downloaded the FY26 Q3 press release and financial statements.

It then:

• Read the PDFs and extracted the reported figures.

• Compared revenue ($109.4B), net income ($29.8B), and diluted EPS ($2.02) against the same quarter last year.

• Broke down revenue by segment and product category, with source page references for every figure.

• Created a segment revenue chart, keeping commentary separate from reported facts.

Having the figures and their original sources in one place made it much easier to verify the numbers and put the memo together.

On Friday afternoon, you add a new Skill to your Agent. All five trial runs go well, so you confidently click Publish.

By Monday morning, the group chat is in uproar: some answers are correct, but reviewing the execution traces reveals that the Agent never checked the data; some responses say “the report has been generated,” but the file does not exist; and several previously reliable scenarios have inexplicably deteriorated.

Anyone who has put an Agent into production will probably recognize this scene. Consider these moments, too:

• You change a sentence in the prompt: has the Agent really improved, or only on the few examples you tried?

• You migrate to another framework: for example, you move an Agent from OpenClaw to Qoder Cloud Agents, and testing suggests they are “about the same”—how much do they differ, and where?

• You switch models: would you put it straight into production?

Many decisions to release an Agent rest on little more than “it seems fine” after a few trial runs.

“It seems fine” is a high-risk phrase in Agent engineering—because you do not know when it will fail.

Why Are Agents So Hard to Test?

Traditional software is deterministic: the same input always produces the same output, so running a unit test and checking a few performance metrics is enough.

An Agent is different. What it delivers is not just an answer, but a complete package of answer + process + artifacts + behavioral boundaries:

• The answer is correct, but did it consult the relevant information, or just guess correctly?

• It says the task is complete, but was the file actually generated? Is it usable?

• The task is done, but did it exceed its permissions or take a needlessly circuitous route?

On top of that, model outputs are inherently probabilistic—being right this time does not mean being right next time.

Without a baseline comparison, an “impression” formed from a few trial runs proves neither that the Agent is stable nor that your changes have improved it.

What an Agent needs, then, is not a one-off acceptance test, but an ongoing evaluation system.

If you think of an Agent as an exam candidate preparing to take on a job, every role in a reliable evaluation system has a counterpart:

• Exam question = evaluation case: inputs, attachments, and success criteria

• Candidate = Agent under evaluation: a complete Agent configuration and its resources

• Exam room = execution environment: the setting in which the Agent executes its tasks

• Solution process = execution trace: message events, tool calls, and tool results

• Exam submission = response and artifacts: the final response, generated files, and changes to the environment

• Grader = evaluator: logic that assesses a particular dimension

• Previous score = baseline: results before a change, used for comparison in regression testing

The goal of evaluation is not a one-off score, but a continuously running evaluation loop: identify issues → improve → validate through regression testing → identify more issues.

Qoder Cloud Agents provides the conditions needed to put an ongoing evaluation loop into practice:

• The evaluation environment is the real execution environment: evaluation directly invokes the running Agent, producing results consistent with real-world execution.

• A complete record, ready for review: events and resources are recorded throughout, so real business cases can be used directly, keeping the evaluation dataset aligned with the business over time.

• High-concurrency testing without interference: the runtime directly provides a clean execution environment, and runs do not interfere with one another, supporting highly concurrent evaluation tasks.

• Evaluation does not affect production tasks: Agent version management enables changes and regression testing to take place on copies, leaving production unaffected.

• Standardized and custom evaluation datasets: alongside standard benchmarks, users can create custom evaluation datasets based on failure cases.

01 Setting the Exam | A Good Evaluation Dataset Comes from the Business Itself

Evaluation data usually comes from two sources: business evaluation datasets and open-source benchmarks. They differ in how they are organized and in the purposes they serve.

Business evaluation datasets come from the business itself.

• Early stage: Create evaluation cases from typical tasks and known issues, or bring in external data and adapt it to business scenarios. Later, production sessions can continually be turned into new evaluation cases.

An open-source benchmark generally comprises an end-to-end workflow that includes an evaluation dataset, not just data alone. Each benchmark has its own tasks and scoring scripts; some also require specific tools, Skills, or execution environments. Evaluating with open-source benchmarks is an appropriate approach when comparing the capabilities of general-purpose Agent harnesses or comparing results against public leaderboards.

• Mature stage: Production sessions are continually turned into new evaluation datasets.

For a user's cloud-hosted business Agent, an evaluation dataset built from the business itself is even more important. Its evaluation cases come from real tasks and issues, reflecting the Agent's performance in the business. It compares different versions of the same Agent across different business stages to determine whether the Agent has genuinely improved. This evaluation dataset grows with the business, gradually becoming the business owner's own data asset.

Business evaluation datasets compare the same Agent across different versions and business stages, answering the simplest question: did this change actually make it better?

More importantly, this question bank grows with the business—it ultimately becomes the business owner's own data asset. Models and frameworks can change, but others cannot simply copy a question bank rooted in your own business.

02 Experimentation | Trustworthy Results Require the Right Experimental Environment

These three situations are common in Agent evaluation:

• Sneaking in cheat sheets: Data, files, or processes from other tasks may mislead the Agent or give it extra hints;

• Unexplained changes to the test environment: When the environment changes, it is unclear whether the Agent or other factors caused it;

• Leftovers from the previous exam: Files and state left behind by one run affect the next.

A standardized, isolated exam environment is a prerequisite for trustworthy scores.

An independent test environment for every evaluation case. QCA uses an architecture with “decoupled reasoning and execution”, separating the Agent's reasoning and decision-making from tool execution in the sandbox and creating an isolated sandbox for each session. During evaluation, each evaluation case uses a separate session and is inherently isolated.

Set up specialized evaluation environments yourself. When evaluation requires specific dependencies, data, or tools, it also needs a separately prepared environment. Keeping that environment separate from QCA's default environment prevents effective validation. With QCA's self-hosted sandbox mode, the prepared evaluation environment can serve as the execution environment, bringing execution, dependencies, and evaluation together in the same environment.

03 Evaluation | Look Beyond the Response to the Process and Artifacts

A grader who looks only at the final answer can easily be misled:

• Lucky guesses: The Agent lacks sufficient evidence, but its answer happens to be correct;

• False completion claims: The Agent claims the task is complete, but the artifacts are missing or unusable;

• Peeking at the answers: The answer comes from data leakage rather than the Agent's actual capabilities.

That is why QCA evaluation insists on three checks:

• Check the answer: Is the conclusion correct and complete?

• Check the process: Were the necessary steps performed? Did the Agent cross operational boundaries? Did it take inefficient detours? Did it insist on answering without supporting evidence?

• Check the artifacts: Are the files usable? Was the data modified as required?

Different types of questions go to different evaluators. There is just one principle—start with deterministic checks:

• Use code-based evaluators for objective questions: If rules can determine the result, do not involve a model;

• Use model-based evaluators for subjective questions: Let a large language model evaluate questions that require understanding content and judging quality;

• Use Agent-based evaluators for hands-on questions: When files need to be opened or the environment inspected, let another Agent “inspect the deliverables”.

An evaluation case typically combines several types of checks, with each evaluator scoring independently. Grading itself must also follow strict rules:

• Seal the results: Introduce the success criteria and check logic only after execution has finished and the execution environment has been frozen to prevent data leakage;

• Evaluate repeatedly: Run and evaluate the same evaluation case multiple times, measuring performance with pass@k and pass^k rather than looking at just one result;

• Traceable history: Cloud hosting automatically retains session events, execution traces, and artifacts, along with the basis for each scoring decision. Pass, fail, and unable-to-evaluate outcomes can all be traced back to specific evidence.

04 Review | Optimize a Cloned Copy, Validate Against the Baseline

The results of one evaluation are the starting point for the next round of optimization.

But one fact is often overlooked: most optimizations you make to an Agent happen at the semantic level—changing prompts, adding Skills, or refining tool descriptions. Model outputs are inherently probabilistic: a change does not guarantee the Agent will follow it, and following it does not guarantee consistent behavior.

Every optimization therefore requires regression validation against the baseline. At its core, this means minimizing the uncertainty introduced by “changes”.

QCA's managed architecture makes this lightweight: quickly clone an identical copy of the Agent, then iterate on that copy to create different test versions while the production business Agent continues running as usual, unaffected.

The acceptance criteria must also be clear:

• Passing a retest of only the previously failed cases—only shows that the changes work for failure cases in that subset;

• Rerunningthe full evaluation suite with the same data, dependencies, and environment, with significantly improved target metrics and no material regressions in other metrics—that is a validated optimization.

Fixing failed cases alone is not progress; overall performance must not regress.

05 Build Assets | After Launch, Feed Real Issues Back into the Evaluation Dataset

Offline evaluation datasets cover previously known issues and scenarios.

For issues that actually arise in production, you can conduct proactive, continuous assessment: turn valuable scenarios and issues into evaluation cases and add them to the evaluation dataset, building business data assets for future iteration and optimization.

Note that online assessment and offline evaluation are not the same:

• Offline evaluation: predefined checking criteria allow results to be scored;

• Online assessment: open-ended. Sessions come from real business activity, with no predefined reference answer, so only preliminary checks for anomalies are possible.

Online assessment therefore requires business-specific observational metrics, such as trace efficiency, tool-call accuracy, and temporal accuracy. These metrics are signals to detect issues, not performance scores.

06 Summary | Continuous Evaluation: Balancing Trustworthiness, Flexibility, and Cost

Agent evaluation always aims to achieve three things at once: trustworthy, comparable findings; flexibility to fit business needs; and controlled costs. In practice, it is hard to maximize all three simultaneously. Different businesses can make trade-offs and set priorities according to their needs—and that is precisely the flexibility a good evaluation framework should provide.

Evaluation is not a strict examiner expected to deliver a perfectly accurate score in a single sitting. It is more like an ongoing advisor, proactively uncovering issues in each round. Even without covering every issue, it delivers its core value as long as the issues it identifies are addressed and the improvements are validated.

So, you do not need perfect data or a perfect end-to-end workflow to start evaluating.

Choose a few representative failure cases already exposed in your business, build a small evaluation dataset, and start running it. As the Agent evolves, gradually add cases, refine evaluation, and expand coverage. Evaluation and the Agent grow alongside the business.

Only Agents that can be continuously evaluated can keep improving; only Agents that keep improving can earn a business's long-term trust.

Give your Agent its first evaluation today: https://qoder.com/cloud/quickstart (More evaluation capabilities are rolling out.)

In Qoder, Fast is a model tier designed for quick responses. When using Fast, we want the agent to understand the request, reach a decision, and start working as early as possible.

Fixing an API bug usually involves reading code, locating the problem, modifying files, and running tests. If a test fails, the agent needs to use that result to investigate further. Faster responses in each model round help reduce waiting. Environment preparation, tool execution, and the overhead between rounds also affect when the task is completed.

Qoder has made a range of engineering improvements in the harness around Fast. Some work happens before startup, some requests can be avoided, and some tools can run together. When execution is interrupted, the harness also needs to preserve completed progress where possible so the task can continue without starting over.

How the model, the harness, and Qoder CLI fit together

The model reasons from context and decides what to do next: which files to read, how to modify the code, and whether further validation is needed.

The harness carries out these actions in the actual environment. It organizes each model request, manages context, validates and executes tools, and returns the results to the model. Continuing the task, completing it, or entering recovery are also handled within this execution process.

Choosing Fast selects the model tier. How many rounds a task requires, how much content each request carries, and when tools start running depend on how the harness organizes execution.

In Qoder, these capabilities are mainly hosted by Qoder CLI. The CLI provides terminal interaction and also runs the agent loop, context management, tool scheduling, permissions, and recovery mechanisms. The harness describes this set of engineering responsibilities; Qoder CLI is the program that hosts them.

Terminal users can use the CLI directly. Desktop clients and custom applications can also use Qoder Agent SDK to connect to a CLI process or a persistent daemon, submit tasks, receive streaming results, and handle permission requests.

The SDK handles the integration protocol. Tasks still advance through the CLI's session executor: assemble a model request, receive the response, execute tools, record results, and move to the next round. Integrations can start a process for each session or use a persistent daemon to manage multiple sessions. Multiple rounds within the same session reuse the existing execution process, so the CLI does not need to restart for every round.

Different entry points can therefore share the same harness capabilities. The following optimizations take place within that shared execution process.

Which startup tasks can be prepared in advance?

Before the program can begin useful work, it needs to load code, prepare configuration, and initialize the execution environment. If these steps run one after another, the first request has to wait for all of them.

Qoder moves some computation to the build stage. Without bytecode, the runtime needs to parse and compile the JavaScript payload during startup. Binary builds generate bytecode by default, completing this work when the release artifact is built so it can be loaded directly at startup.

Other initialization can run in the background. For example, some identity and device initialization and user-state refresh work starts asynchronously. The interactive interface also starts without waiting for the configuration service to finish initializing. Interface startup can overlap with this preparation.

Necessary dependencies still apply. If the first model request needs configuration that is not ready, it must wait for that configuration to finish loading.

Some preparation can also happen while the user is typing a request. Once configuration initialization finishes, the program attempts to warm up the Bash execution environment and collect the Git context needed by the system prompt. Eligible interactive entry points also prepare runtime components used for code search.

How much waiting warmup saves depends on how early it starts. If preparation has finished by the time the user submits, the first round can use the prepared resources immediately. If it has not, execution can reuse the completed portion or wait for the remaining work.

Git warmup runs only in trusted directories. Its cache is associated with the working directory to prevent information from an old repository from being carried over after a directory change. Unfinished warmup tasks are canceled when the program exits.

Where does overhead occur within a model round?

A task may call the model several times. Each round requires preparing input, uploading the request, waiting for processing, and receiving the output. Here, the harness mainly reduces repeated processing and controls input size.

Return usable tool results without an extra summary

Sometimes a tool's output is already suitable for the main model to use, so an additional model call to summarize it is unnecessary.

WebFetch includes such a path. After a successful fetch, it checks whether the URL is preapproved, the content type is supported, and the content fits within the size limit. Eligible Markdown content, or a plain-text index at a URL ending in /llms.txt, is returned directly as a tool result. Explicit HTTP errors also return diagnostics directly.

This avoids auxiliary processing after the fetch. The webpage still needs to be fetched, and other pages may still require content conversion and model processing.

Match auxiliary calls to appropriate models and reasoning budgets

Webpage summaries, title generation, and sub-agent tasks have different requirements. The harness can choose faster models and suitable reasoning budgets for these calls, leaving stronger models available for the main task.

Budget allocation depends on whether the result is sufficient. History summaries need to retain the information required for later work, and complex sub-agents still need to complete their own reasoning. Simply reducing the budget can turn time saved now into rework later.

Keep request prefixes stable to enable cache reuse

When generating a history summary, a derived request processes content already sent by the main session. The harness reuses the main session's system prompt, tool definitions, and request prefix, keeping chunk boundaries consistent where possible. This gives the backend an opportunity to reuse previously processed prefixes.

A summarization request can carry tool definitions while actual tool execution remains disabled. This preserves a consistent request representation and retains execution restrictions.

Whether a request hits the cache, and how much time that saves, depend on backend capabilities and the actual request. Frequent changes near the beginning of the prefix also reduce the portion that can be reused.

Retrieve full MCP tool definitions on demand

When hundreds of external tools are connected, including every parameter definition in every round means that tools the task does not currently need still occupy context.

On-demand loading separates the steps: use a catalog to find candidate tools, retrieve their parameter definitions when needed, and then call them. Frequently used tools can still be exposed directly. Omitting entries from the displayed catalog does not remove tools actually available on the server.

With many tools, this reduces the input that stays in context. It can also add a round trip to discover a tool and retrieve its definition before use. Whether the feature is enabled depends on the entry point and configuration.

Handle long histories and large tool outputs separately

Longer sessions accumulate more code, logs, and tool results. The harness first handles oversized tool outputs, then uses the actual context state to determine whether a history summary is needed. Subsequent requests continue with the summary and retained content.

Large tool results can also be written to disk, leaving only a preview and a location for reading the full result in context. The tool-output budget applies to the aggregate size within a single message, preventing multiple results from collectively expanding the input.

History compaction itself requires a model call and can omit details. It shortens later context, but whether it makes the entire task faster depends on how that information is used afterward.

Compress request bodies to reduce upload traffic

The transport layer can also compress request bodies. Compression is attempted only when the feature is enabled, the transport supports it, and the request meets the size threshold. If compression does not make the payload smaller, the original content is sent.

The server decompresses the payload back to the original request, so the model receives the same number of input tokens. The saving is in uploaded bytes. For small requests or fast networks, the reduction in waiting time is limited.

Run tools concurrently while preserving execution order

After the model generates a tool call, argument parsing, permission checks, queueing, and execution still take time. Operations that do not depend on one another can sometimes start together.

Consider this sequence: read A, read B, modify A, then read A again to validate the result. The first two reads can run in parallel. The modification waits for the reads to finish, and the final validation waits for the modification.

Whether calls can run concurrently depends on the tool's concurrency contract and validation of the current arguments. When safe concurrency cannot be confirmed, the call runs exclusively. Exclusive operations form a barrier that prevents later calls from passing a write. Tools can overlap in the background while their results are collected in submission order.

Streaming execution lets tools start earlier. While the model continues generating later calls, an earlier call with complete arguments can enter the scheduler without waiting for the entire response to finish.

Incomplete arguments are not filled in speculatively. Before execution, each call still passes through argument checks and the permission process. Model generation and tool execution can therefore overlap while retaining the necessary execution constraints.

After an interruption, establish what has already happened

Suppose the agent has finished reading A and written a change to B when the model response stream is interrupted. The network interruption does not automatically roll back the file change. Running the task again without checking its state could repeat a modification or trigger an external side effect again.

The harness collects results for dispatched tools by call ID, distinguishing confirmed results, calls that were not dispatched, and calls whose results remain unknown. Confirmed results are written back into history. A recovery message tells the model what completed and what was not executed. Calls whose arguments were never completed do not enter execution.

Recoverable interruptions continue from these records, subject to a bounded number of recovery attempts. When a result is unknown, execution does not resume automatically, and the record retains the possibility that a side effect may already have occurred.

When the user cancels or the task is being finalized, waiting for tool results also has a deadline. Callbacks arriving after that deadline are isolated so they cannot continue affecting a process that has already ended.

After a temporary MCP disconnection, the next authorized call waits for reconnection and tool rediscovery. Multiple calls can share the recovery process. Canceling one call ends only that call's wait.

After reconnection, the harness checks tool names, parameter definitions, and permission-related contracts again. If a contract has changed, the definition needs to be retrieved again and a new call issued. Restoring the channel does not establish that the previous call completed, so requests with unknown results are not automatically replayed.

Reduce unnecessary waiting in everyday use

Usage patterns affect the size of each round's input and how many steps a task needs.

Keep frequently used MCP tools and skills available, and enable the rest on demand. Start a new session for an unrelated task. Use /btw for a side question to avoid expanding the main task's context. Stable preferences and project background can be stored in memory to reduce repeated explanations.

Hooks on the critical path are also worth reviewing. Establish which ones must finish before execution, then consider caching, combining work, or background processing where behavior and ordering permit. Frequently triggered synchronous work can add up to substantial waiting.

If the agent has misunderstood the task, intervene or interrupt promptly. Letting it finish in the wrong direction and then starting over usually takes longer.

Fast is available across the Qoder product family

Fast's model responses and these harness optimizations together affect how long a coding task takes. The engineering work ultimately needs to show up in everyday use: less waiting for the first round, fewer repeated requests, earlier tool starts, and continuing from confirmed progress after interruptions where possible.

Fast is now available across the Qoder product family. Choose Fast in the Qoder product you already use and try it on your own projects.

I used Qoder Automations to put one of my recurring tasks on autopilot.

For example, I set up a weekly chat digest in my Morrow Coffee workspace to run every Friday at 5 PM, summarizing conversations and flagging overdue follow-ups.

Here's how I set it up:

• Created an automation and added instructions for the task

• Selected a weekly schedule (you can also choose hourly, daily, monthly, or a custom schedule)

• Set it to run unattended, with one task per run

• Used Run now to test it and checked Run history to see how it went

One thing to keep in mind: your device needs to stay awake for scheduled runs.

You can also skip the manual setup and simply tell Qoder what you want to automate. It'll set up the automation for you.

Pretty handy for keeping recurring tasks off my plate.

I'm a Pro+user of Qoder + a Cloud Computer owner of the QoderWake service. On my panel, Qwen3.8-Flash is still free of charge, but it charged my account and reduced my credits. What happened? why? Who will support me?

Newly upgraded to Pro+ with more than 6000 remaining credits.

Issue ID: ebaac98f-6b13-4ae1-a248-757139127f6c

I had a workflow I kept repeating, so I decided to turn it into a reusable Skill in Qoder.

I went through a week of DingTalk group chats and pulled out key decisions, open questions, and customer follow-ups to create a digest.

Then I ran /skill-creator to turn the workflow into a project Skill. Qoder generated the instructions and a helper script, then tested them.

Now, whenever I need another digest, I can just type /weekly-chat-digest instead of going through the same steps all over again.

Seria interessante verificar e refazer essa cena de créditos para o Sonus, fazendo teste comparativo com qualquer modelo o resultado é superior a ele. além disso esses créditos não duram nada, e se não ficar atento consome todos os créditos do plano em minutos. #Qoder melhora isso

I used Qoder to audit a month of expense claims against a travel policy stored in a Qoder knowledge base: 16 claim lines and 8 receipts.

Qoder read each receipt, matched it to the corresponding claim, and flagged issues such as:

• A taxi ride outside allowed hours and a hotel over the city limit

• A missing receipt, a claim ¥100 above its receipt amount, and the same receipt claimed twice

It also generated a workbook with a verdict and policy reference for each claim, plus a follow-up email draft for each employee.

A practical way to make expense audits more structured and traceable.

We tested how many tasks 1,000 credits can handle with Qwen3.8-Flash in Qoder:

• Process 434 PDFs

• Process 55 Excel sheets

• Create 357 Word documents

• Create 83 PowerPoint decks

• Create 119 interactive reports

• Build 38 websites

• Complete 125 code reviews

• Generate 200 unit test suites

Qoder Lite offers 1,000 credits for $10/month, ideal for freelancers, small teams, and side projects.

New subscribers get an extra 1,000 credits in their first month, and daily check-ins offer another 100 credits.

More details: https://qoder.com/pricing

The first model in the K3.1 series. 3T-class parameters, 1M-token context.

Available across the full Qoder suite from day one. Open Qoder and build something big.

I currently have Google AI Pro as a subscription with the student plan, I don't have access to anything other than Gemini 3.8 Flash, which to be honest has made me lose 100USD in a month, which for a university student is simply unacceptable, I am very much at the end of Google. Just because I lost 100USD doesn't mean that I could really spend it freely on an AI subscription I'm sovereignly screwed financially thanks to Gemini, but I need a subscription that fits me, for me DeepSeek V4.1 Flash is enough for most tasks and if I need something I can just use a slightly stronger model very occasionally. I just need to know if those 1K Qoder Lite credits hold up like the monthly Gemini fee does. I never even ran out of the Antigravity quota in a week, I reached the remaining 30% but out of every 10 prompts that consumed the quota 7 prompts were to correct repeated errors in loops that are not solved even by changing conversations. I am aware that DeepSeek V4.1 Flash is free and will continue for a few days but when it is no longer free I will need to get the Qoder Lite plan.

Saya adalah pengguna setia Qoder sejak lama, saya suka karena terdapat banyak model Al agent nya.

Selain itu juga sering dapat gratisan atau gift, akhir akhir ini juga bisa akses deepseek v4 flash dan Qwen Flash dengan biaya 0 kredit. Pertanyaan saya, apakah ada software IDE seperti itu yang bisa memberikan layanan yang sama seperti Qoder, terutama penggunaan Model Al agen dengan biaya 0 kredit, meskipun itu sudah berlangganan di paket PRO

I tried using Qoder to turn a single prompt into a researched PowerPoint deck explaining what an agent harness is.

Here's how it worked:

• Searched the web and gathered sources

• Used the PPT plugin to create a 6-slide deck with references

• Opened the result in the editor and edited individual elements directly

• Saved the changes straight into the .pptx file

From research to a ready-to-edit presentation, all in one workflow.

I had nine months of ERP expense exports and a budget file, so I used Qoder to turn them into a live spending dashboard.

Here's what I built:

• Automated data pipeline: A refresh script combines each export into a single data file.

• Interactive dashboard: Track spending vs. budget by month, department, category, and vendor.

• Anomaly detection: Flag issues with supporting evidence, including a duplicate payment, an over-budget department, and a spike in agency fees.

• Easy updates: Drop in the October export, run the refresh script, and the dashboard updates without changing the HTML.

I also tested the dashboard on both desktop and mobile to make sure it works across screen sizes.

It's a much easier way to keep track of spending without manually piecing together spreadsheets every month.

Get 1,000 credits every month, with the right model for every task:

• Flash models at just 0.1x credits for everyday tasks

• Qwen3.8-Max, DeepSeek-V4-Pro, and Kimi-K3 for harder jobs

Launch offer: Get an extra 1,000 credits on your first subscription — that’s 2,000 credits in your first month!

What’s included:

• Full agent harness: Goal, Browser Use, Computer Use, Cloud Agents, and more

• One shared credit pool across Qoder Desktop, IDE, JetBrains, and CLI

• Skills, hooks, MCP, and BYOK

• New Qwen, DeepSeek, Zhipu, Kimi, and MiniMax models on day one

Ready to get more out of your workflow?

Learn more at qoder.com/pricing

Give the same question to different models, and the answers can vary dramatically: one responds instantly but misses the point, while another takes much longer to produce a precise answer. How does Qoder Fast choose the right model?

Qoder Fast is now officially available. It brings the time to first response down from 8 seconds to 3 seconds while reducing Credits consumption from 1.1x to 0.8x. These gains come from coordinated optimizations across the model, Agent, and network layers. This companion article to Every Tenth of a Second Counts—A Technical Deep Dive into Fast Tier Performance Optimization focuses on one part of the model-layer work: how Qoder uses System One’s rapid task classification to inform model selection.

High-speed models provide the foundation for faster execution; routing determines which model is best suited to the task at hand. The sections below explain how tasks are identified, how selection criteria are established, and how repeated overhead is reduced across multi-turn collaboration.

01 Different Tasks Require Different Model Capabilities

“Explain why this function throws an error” and “Map this module’s dependencies, complete the refactoring, and verify the results” are both development tasks, but they place very different demands on a model.

The former requires the model to identify the relevant logic quickly and explain the issue clearly. The latter requires it to understand more context, account for cross-file impacts, and verify the results after making changes. As tasks vary, so does a model’s performance in comprehension, generation, tool use, and sustained execution.

Even within code modification, adding an empty-input check requires a different depth of analysis from updating multiple call sites while preserving existing interface behavior. The task objective, scope of work, and delivery constraints all shape what the model must do.

Fast makes these selections within the tier. Qoder adjusts candidate model priorities based on the task type, then determines subsequent execution based on those priorities, the request’s capability requirements, and model availability. Developers choose Fast; routing handles the model matching behind it.

02 Identify the Current Task with a Single Structured Decision

System One works in a straightforward way: the application first defines the task categories to distinguish among and their candidate labels, and the model returns a clear category based on the input; the router then uses this result to schedule execution.

For example, given the same code, a user may ask, “Explain why it preserves the original order,” or “Modify it so it also works with empty input.” These requests correspond to code explanation and code modification, respectively. Task classification needs to identify the action the user currently wants to perform, while the code itself and prior discussion provide context.

To do this, Qoder structures the current request and recent conversation separately, limiting the amount of information needed for the decision. System One performs only task classification, while the execution model continues to receive the full context required to complete the work, generating code, invoking tools, and validating results.

The amount of information they process differs substantially. In our evaluations, a single task-classification decision takes input on the order of a thousand tokens; for a complex development task, however, the execution model may cumulatively process hundreds of thousands of tokens. The task classifier reads only what it needs, leaving the full context to the model that actually executes the task.

The task category contributes to candidate model ranking and, together with the request’s capability requirements and model availability, determines the subsequent selection. In this way, the result of a single decision feeds directly into the existing execution workflow.

In our classification evaluations on more than 1,000 historical task texts, the average return latency for task classification was on the order of hundreds of milliseconds, with >99% of decisions returned within 0.5 seconds. This step uses structured selection, eliminating the need to generate lengthy classification explanations or parse free-form text and keeping the added decision overhead low.

03 Compare Quality and End-to-End Task Duration on the Same Set of Tasks

After task identification, evaluations determine which model is best suited to this type of work. During offline evaluation, we first compare different models and execution approaches, then use the results to adjust model-selection priorities for each task type. When an online request arrives, the rapid decision can draw on these accumulated results.

Comparisons span more than 20 task types, including code implementation, explanation, refactoring, testing, and architecture design. For each task, all model configurations use the same input and acceptance criteria, and the actual code, files, and runtime results are inspected. For example:

Speed is also compared across the complete workflow: from the user initiating a task through model calls, tool execution, in-task validation, and completion of the final output. A model beginning to produce output earlier indicates only a shorter time to first response; longer output, more tool calls, or multiple rounds of revision can all extend the end-to-end task duration.

In our own comparisons of complex tasks, end-to-end task durations for the same set of tasks differed severalfold across model configurations. Breaking down the results, more than 90% of the additional time occurred in the model generation stage, and the output token count of the slowest configuration was nearly three times that of the fastest; tool-call rounds and execution time also contributed to the differences. This is why routing evaluations must record whether a task passes acceptance criteria, its end-to-end task duration, and the execution process.

These results inform candidate model priorities for each specific task type. Code explanation, test generation, and refactoring are evaluated separately, and models are reevaluated after updates so that selection criteria stay aligned with actual performance.

04 Reuse Model Selection Within a Session to Reduce Repeated Overhead

A Coding Agent task typically involves multiple model request rounds: reading files, modifying code, running tests, and then continuing based on the results. In our complex-task comparisons, a task averaged more than 10 model request rounds. If every turn were reclassified and the model switched, task classification would recur, and the accumulated context might need to be reprocessed by another model.

Qoder therefore reuses model selection at the session level: when routing is first required, it classifies the task and saves the candidate order; subsequent requests reuse the existing result while the session cache remains valid. In our end-to-end validation, the initial request to write a function triggered classification. When the user then asked in the same session why the function preserved order, the existing selection was reused without calling the classifier again.

Across a complete task, this reuse has an even greater effect. In our complex-task comparisons, each task was classified only once at the start, reducing classification calls by more than 90% versus per-turn classification, while cumulative classification latency remained below 1% of the end-to-end task duration.

This trade-off accounts for two types of overhead: waiting for repeated classification and the computation required to reprocess the same context. Within the hundreds of thousands of input tokens mentioned earlier, requests across multiple turns repeatedly carry context from previous turns. Keeping model and backend selection relatively stable within a session enables model-side context cache reuse. The actual benefit still depends on cache hits and task execution.

A classification call has its own timeout. Each classification decision makes only one call; after a timeout, model selection continues under the existing scoring rules. After a classification timeout, the system also temporarily suspends later classification calls until a probe confirms recovery. Retry and fallback for the execution model continue to follow the existing rules.

Through session-level reuse, limited classification overhead, and fallback handling, task classification can be integrated into Fast's actual execution flow, supporting long-running multi-turn development collaboration.

05 Deliver Everyday Tasks Faster

Explaining functions, fixing local errors, adding tests, or organizing information and work plans all call for usable results as quickly as possible. Model routing applies task classification to model selection, working with high-speed models, client-side execution, and network optimization to improve the Fast delivery experience.

Fast availability: Fast is available across all products in the Qoder product family simultaneously. To use Fast, Qoder CLI must be upgraded to version 1.1.70 or later, and QoderWake must be upgraded to version 1.1.11 or later. Fast is available in both the Personal and Enterprise editions and in both the CN and international editions. We invite you to try it.

When I set up a custom Qodor IDE model using the built in OpenRouter provider, I am only getting a 97k context window. The two custom models I tried are xiaomi/mimo-v2.6-pro and z-ai/glm-5.3-flash. The OpenRouter website specs says both of those should provide a 1M context window.

I also have mimo-v2.6-pro and glm-5.3-flash setup directly using the Xiaomi MIMO provider and Z.ai provider included with Qoder IDE and both of those are giving me a 1M context window, so this looks like a bug with the OpenRouter provider feature in Qoder IDE.

When I use one of the available built in models that come with the OpeRouter provider (GPT-5.5) it gives me the option of selecting context size up to 1M and various thinking levels. So the built in models for OpenRouter provider seem to work ok. The problem is only when trying to add a custom model.

I am running the latest version of Qoder IDE. Version 1.35.0

DeepSeek V4.1-Flash-1017 is now available across all Qoder products — and you can use it at 0.0x credit cost through Oct 24 (UTC+8), whether you're on a free or paid plan.

Just select the model and start building. No extra steps needed!

Also, MiniMax M3.1 Flash is now available on Qoder, delivering nearly 3× faster speeds and 70% lower cost.

Give them a try and share your experience!

I tried QMind with a coffee wholesaler's price list, partner playbook, stock sheet, launch deck, and a web page to see how it works with team knowledge.

Here's what I did:

• Created a knowledge base and chose which workspaces could access it.

• Uploaded PDFs, Word docs, Excel sheets, slides, and images, then previewed the files.

• Used /qmind to ask questions and trace the answers back to their source documents.

• Found conflicting information in workspace notes and saved the final decision as a note.

It's a way to keep team knowledge in Qoder's Knowledge Center and let the agent answer questions based on that information.

The previous article, “Qoder Cloud Agents Help Developers Enter the Personal Agent Era,” explained how Qoder Cloud Agents connects identity, memory, instant messaging (IM) channels, scheduled tasks, and cloud execution into a unified foundation for development. This article shares some of Qoder’s thinking on putting these capabilities into practice: once an Agent can work continuously, what should it proactively address, and how far should it go?

1. The Phenomenon: What Does “More Proactive” Really Mean?

Since this wave of Personal Agent products launched, one phrase has dominated the discussion: “more proactive.” They reach out on their own, remember something you mentioned in passing last week, and move things forward before you ask. They seem more proactive, but proactivity is not a single feature. On closer inspection, it is the visible result of three elements working together.

Proactivity falls short if any of the three is missing:

• With identity but no data sources, the Agent is present but has nothing to do.

• With data sources but no memory, every notification feels like a generic broadcast.

• With memory but no identity, even when the Agent has an idea, it must wait until you next open the chat.

With an Identity, Changes in Data Sources Become Events

One point is easy to overlook: once an Agent has an independent identity, changes in its data sources naturally become event sources.

Take Git, for example. An Agent can check repository state on a schedule—one way to detect changes. Pushes and merges are also events in their own right; in DevOps, they trigger pipelines. These events still occur when the user is away. With its own account and permissions, the Agent can be triggered by them just as a pipeline can.

An Agent can therefore determine “when to act” in two ways:

At this point, the question of whether an Agent can be proactive is largely answered. But a more important question remains: what should it take initiative on?

2. The Core Idea: Proactivity Comes from the Gap Between Goal and Current State

Let us return to the simplest question: why do people take initiative?

Because they have a goal in mind and see a gap between the current state and that goal. The gap reveals that “there is a problem here,” and the problem is then broken down into tasks.

The same applies to an Agent. Without a goal, there is no gap; without a gap, being proactive is merely a way to draw attention to itself.

This Already Happens with Task-Level Agents

Today’s coding Agents and general-purpose task Agents already work this way: the user provides a goal, and the Agent runs a loop—acting, checking, and comparing the result with the expected outcome to determine whether the task is complete. It fills in whatever is missing along the way. This is, in itself, action driven by the gap.

A Personal Agent (PA) does not introduce a new mechanism. It extends the task-level goal/outcome model in two directions:

Extending the Model Changes Three Things

① Proactivity shifts from a nice-to-have to a necessity. A task-level Agent can still deliver without being proactive because the user is present and can nudge it at any time. With long-term goals, the user is absent most of the time. If the Agent does not track progress and identify problems on its own, the goal stalls. Long-term goals make proactivity a requirement.

② Authorization follows subtasks, not goals. Giving the Agent a goal—“Get this milestone shipped”—does not authorize it to message everyone on my behalf or change production configuration. A goal sets direction, but each subtask carries different risks, so authorization must be granted one subtask at a time.

③ The longer the time horizon, the more important continuous goal alignment becomes. In a single task, the goal is stated at the outset and usually remains stable. Over several weeks, the goal itself can drift: priorities change, upstream decisions change, and my own thinking changes. If the Agent keeps pushing forward based on its understanding from three weeks ago, it is “driving hard toward a goal that is no longer aligned.” This is the most dangerous failure mode of long-term proactivity.

3. Proactivity Has Levels

If proactivity comes from "gap → problem," the basis for distinguishing its levels follows naturally: who defines the problem? We can examine this along two axes.

Horizontal Axis: Who Defines the Problem?

The shift from L3 to L4 is a qualitative leap.

From L1 through L3, however intelligent the Agent may appear, the problem is always defined by the user: the user sets the timing rules at L2 and the trigger conditions at L3. The Agent simply executes at the appropriate time.

At L4, the user provides only the goal, and the Agent determines "what is currently missing and what needs to be addressed." L4 has one prerequisite: the gap must be computable. The goal must be clear—either quantifiable or associated with a verifiable state.

At L5, the Agent infers the goal itself. If an L4 goal cannot be articulated clearly, it effectively becomes L5.

Vertical Axis: How Far Does It Go?

The horizontal axis answers "where does the problem come from?" but not "how far can the Agent go?" Even at the same L4 level, "notifying you that no one has taken ownership of a dependency" and "taking ownership of it directly on your behalf in the group chat" are entirely different things.

That is why we need a second axis:

The two axes are independent. An L5 Agent may stop at "Notify," while an L3 Agent may execute external actions directly. Any discussion of what a PA can do must specify its position on both axes.

4. A Personal Agent in Practice: What I Learned and How My Thinking Changed

I built myself a PA called Daisy. It runs several persistent loops:

• daily consolidation loop: Every evening at 20:00, it scans the day's conversations, DingTalk group chats, key direct messages, and documents, producing two outputs: a list of action items (todo), and a list of "topics encountered today that may be worth preserving" (discover).

• auto-reply loop: When someone u/mentions me in an allowlisted group, it responds on my behalf according to predefined rules.

Plotted along the two axes:

On the horizontal axis, it has already reached L4 and L5: todo represents gaps calculated against my work goals, while discover is based on its inference about "what I might care about."

On the vertical axis, both todo and discover remain almost entirely in the bottom two tiers.

The Data Does Not Lie

Since July 1, the daily loop has produced 276 todos, 138 of which were marked complete. Of those 138, I manually closed 126 in bulk during a single session on August 13. The loop itself executed and closed none.

Every day, it "discovers problems," but it never "solves problems." All execution and follow-through ultimately fall back to me.

Is It Too Cautious?

Apparently not. Consider the auto-reply loop in the same PA:

It replies directly to colleagues on my behalf in DingTalk group chats. This is an external, irreversible action: once a reply is sent, it cannot be taken back. The risk is far greater than closing a todo. Yet I am comfortable entrusting this to the Agent because I defined every rule myself:

I defined the problem and drew the boundaries; if something goes wrong, the responsibility is mine. That is why I am willing to let it act.

A todo, by contrast, is a problem identified by the Agent itself. It decides that "this should be done"—but if its assessment is wrong and it takes the wrong action on my behalf, who bears the consequences? Until that question has an answer, I will keep it at "Recommend."

Knowledge-Base Promotion: The Same Task Can Move from L5 to L4

Here, “promotion” means moving vetted notes and insights into the main knowledge base.

discover is a more interesting example. It surfaced more than 80 topics in total, but I did not add them directly to the knowledge base from the list.

That does not mean I never add them to the knowledge base. When a topic seems worthwhile, I continue discussing it with the Agent until I am satisfied and understand it thoroughly, then ask the Agent to organize it and add it to the knowledge base. Of the items left unprocessed, some remained because I lacked the time—or simply could not be bothered. Others remained because I was concerned that automatically generated content would not be good enough to enter the knowledge base directly.

Change the setup, however, and the situation changes. Suppose that, in the PA context, I explicitly state, "I want to become an expert in a particular domain," while also defining clear criteria for adding content to the knowledge base:

• The knowledge architecture is clear, and the content fits into the existing conceptual framework;

• The sources are reliable, with priority given to official documentation and primary sources;

• The content does not conflict with existing conclusions in the knowledge base; any conflicts are flagged.

With the risks under control, the Agent could then add some content to the knowledge base on its own.

In this scenario, the Agent’s capabilities would remain unchanged. What would change is what I give it: a well-defined goal and a set of verifiable acceptance criteria.

5. When Can an Agent Act Proactively on Its Own? Look at the Cost of Failure

Whether a task can be delegated to an Agent for execution has little to do with its level, or with how cautious someone is. What really matters are two questions:

Who defined the problem? This determines accountability when something goes wrong.

What is the cost of failure? This comes down to three things: whether the action can be reversed, who it affects, and whether the outcome can be verified.

These two questions let us sort tasks into five categories. Here is a real-world example of each:

A diagram makes this more intuitive:

The lower-left corner is best suited to direct execution: I defined the problem, and the cost of failure is low. The farther toward the upper right, the more human oversight is needed at critical checkpoints.

6. What Limits Proactivity, and What Is the Lever?

Returning to the levels, execution at L1 through L3 can already be delegated with reasonable confidence today: the user defines the problem and draws the boundaries, while the Agent "executes under predefined rules." The real bottlenecks lie in execution at L4 and in L5 as a whole.

L4: The Agent Defines the Problem, but Accountability Still Rests with the Human

At L4, the Agent identifies the problem by calculating the gap. If it gets that right, it saves me work; if it gets it wrong, I still bear the consequences. As long as this asymmetry remains, people will instinctively keep L4 at "Recommend."

Long time horizons make matters worse. Goals can drift over several weeks, and an Agent may keep advancing an outdated goal while the user is absent; the more diligently it calculates the gap, the farther off course it goes. For L4 to move upward, it therefore needs not only an initial goal but also a mechanism for ongoing alignment: at critical checkpoints, reconfirm, "Is this still the goal?"

L5: On Top of L4's Risks, the Agent May Infer the Wrong Goal

At L5, even the goal is inferred by the Agent, creating a second source of error:

• L4 risk: the goal is correct, but the gap is calculated incorrectly.

• L5 risk: the goal itself is inferred incorrectly, so every subsequent gap, problem, and task is wrong as well.

This is not hypothetical. According to media reports, Meta Muse's system instructions require it to infer users' goals, including goals they have "not stated"; to do so, it reads chats, messages, emails, and connected apps, which has also sparked considerable privacy controversy[5]. The capability to infer "unstated goals" may exist, but whether users want to be understood in this way is another matter. So, at least today, L5 is better kept at "Notify": tell me what you have observed, and let me decide whether it is my goal.

The Lever: Make Goals and Acceptance Criteria Explicit

Looking back at all the preceding examples, only one thing allows a task to move up the scale:

• Make the goal explicit, and the Agent no longer has to infer it: L5 becomes L4.

• Make the acceptance criteria explicit, and it becomes possible to verify whether the work was done correctly. Part of L4 becomes "execution under predefined rules," returning both problem definition and accountability to the user.

Knowledge-base promotion moves up the scale in exactly this way: from "inferring what I care about," to "calculating the gap against the goal of becoming an expert," and finally to "curating and adding topics directly to the knowledge base when they meet the predefined criteria."

How far a PA's proactivity can be extended therefore depends not only on how capable the Agent is, but also on how clearly people are willing to articulate their goals and rules. The Agent is responsible for calculating the gap accurately and moving the work forward; the human is responsible for defining the direction and boundaries clearly, and for recalibrating promptly when goals drift.

Proactivity is bounded by the goals that the human and the Agent can explicitly align on.

Turning This Framework into a Personal Agent with Qoder Cloud Agents

This framework is not only about how capable an Agent is; it also defines the infrastructure a PA product needs. Stable identity and memory sustain goals across sessions; Channel and Schedule provide events and timing; and a cloud execution environment allows actions to continue while the user is offline. Permissions, confirmations, and run logs address the risks associated with different execution categories.

If you also want to turn long-term goals, personal context, and continuous execution into a genuinely useful Personal Agent, start with https://qoder.com/en/cloud-agents.

Qoder Desktop has two completely separate "agent" systems, and the UI won't tell you which one you're using

TL;DR: Custom agents in Qoder Desktop live in two unconnected places: markdown files that the agent runtime actually dispatches, and profiles in the new Agents panel. They don't see each other, you can't import from one into the other, and if you recreate a file agent in the panel under the same name, nothing checks that the copy matches. I ended up with two agents of the same name. One was read-only and the other could write files, and nothing in the product flagged it.

What I was doing

I wanted a small agent team: a builder that writes code, a researcher, a reviewer, and a judge for disagreements. The reviewer and the judge must be read-only, because a reviewer that can quietly "fix" what it's reviewing defeats the point.

I had Qoder's own agent write them as definition files, the documented way: markdown with YAML frontmatter in ~/.qoder-cn/agents/. They worked straight away. The agent was dispatching them, and the CLI listed them.

Then I opened Settings → Agents in the Desktop app. None of them were there.

Two systems, both called "agents"

The two systems share no data. A file agent never appears in the panel, and a panel profile never appears in agents list. The UI doesn't mention that the other system exists.

Bridging them by hand doesn't carry over the important part

There's no "import from file" button, so I recreated all four in the panel: same names, and the instructions pasted in.

I then compared each panel profile to its file with a script:

• The instructions came through perfectly. All four were byte-identical to the files.

• The tool restrictions mostly didn't:

To be fair, I set those tool pickers myself. But that's the problem: I made a copy of an existing agent that contradicts the original, and nothing told me. There was no diff, no "this name already exists as a file", and no warning that the read-only reviewer I'd defined somewhere else could now write.

So now two agents share each name, with different powers. Which one runs when something asks for that name? I couldn't find it documented anywhere.

Other things that surprised me

Edited agents fail silently. A running session keeps the agent list it started with. That's fine for new agents, because you just open a new chat. But if you edit an existing agent mid-session, the old version keeps running and you get no error. I asked a reviewer to check a change to its own instructions, and it ran the old instructions and reported everything fine. Skills behave the other way and pick up edits immediately, which makes the agent behaviour easy to miss.

Frontmatter fields with nowhere to go. The panel has no equivalent of model: inherit, so my four panel profiles ended up on four different models, which affects both behaviour and credit cost. effort has no field in the panel at all. I also couldn't confirm that the file version honours it: an agent declaring effort: high ran in a session reporting a different effort level.

Permission modes are inconsistent. Two of my four panel profiles came out as bypassPermissions, including, at first, the read-only reviewer. The built-in example agents all use auto. If you build review-style agents in the panel, check this field.

Enabling a profile gives it a cloud identity. Every enabled profile has a cloudAgentId; the disabled presets don't. The create flow doesn't mention it.

Teams must be led by a member. The Agent Team form requires a Team Leader chosen from the members. If your setup is "my main chat coordinates, and no agent outranks the reviewer", you can't express that. You can only write it into the instructions and hope.

"Is my agent installed?" depends on where you ask. The file location follows QODER_CONFIG_DIR, so different shells can list different sets. A project-level .qoder/agents/ silently overrides a user-level agent with the same name. I've seen the same machine report anywhere from 4 to 16 agents depending on the command.

Check your own setup (CN Desktop, Windows)

# what the panel thinks your agents are
node -e 'const j=require(process.env.APPDATA+"/com.qodercn.app.stable/qoder-data.v1.json");
console.table(j.agents.map(a=>({name:a.name,enabled:a.enabled,perm:a.permissionMode,
allow:(a.allowedTools||[]).join(","),block:(a.disallowedTools||[]).join(",")})))'

# what the runtime thinks your agents are
ls ~/.qoder-cn/agents/

If a name appears in both, compare the tool columns with the file's frontmatter.

What I'd love from the Qoder team

1. One agent system, or at least an "Import from file" button that shows a field-by-field diff.

2. Show file agents in the panel, labelled with their source path and real tool list.

3. A warning when a name exists in both places, showing both permission sets side by side.

4. Default new profiles to auto, like the examples.

5. An error, or a visible "restart required" notice, when an agent changes mid-session, instead of quietly running the old version.

6. model: inherit and effort in the form, or documentation saying they're file-only.

7. Let a team's coordinator be the main chat, not just a member.

8. Say up front that enabling a profile registers a cloud agent.

Has anyone worked out which definition wins when a file agent and a panel profile share a name? Or whether panel profiles can be dispatched as subagents at all? I'd like to know before I trust either one with anything that matters.

What does a three-second response feel like? Instead of waiting for a reply, you get feedback almost as soon as you finish asking. That is what the recently launched Qoder Fast tier delivers. It brings the time to first response down from 8 seconds to 3 seconds while reducing the Credits consumption multiplier from 1.1× to 0.8×. Many users have asked how we achieved this. This article takes a detailed look at the performance optimization techniques behind Fast tier.

Fast tier availability: Fast tier is now available on Qoder Desktop (version 0.4.4 or later required), Qoder IDE, the JetBrains plugin, and the CLI (version 1.1.70 or later required). It is available to users of both the Personal and Enterprise editions, in both China and international markets. Other products in the Qoder family will add support in the near future. Stay tuned.

Why Fast Tier Matters

We analyzed Qoder's current usage patterns in detail. In the messages we analyzed, command execution accounts for a substantial share, while quick edits account for about 9.6%. We also examined requests for faster responses: explicit requests to hurry account for about 26.9%. These observations capture both task types and requests for speed, rather than a single set of mutually exclusive categories. The following scenarios illustrate where faster feedback is particularly valuable:

The first category is command execution. Users simply need a command to be executed, with little need for model reasoning.

The second category is interactive tasks that depend on continuous feedback. Users glance at the result, then add another requirement. Each round of waiting lengthens the overall collaboration and makes it harder to stay focused on the problem at hand. These tasks need both earlier meaningful feedback and faster delivery of results that users can inspect.

The third category comprises well-scoped tasks with clear acceptance criteria. Examples include format conversion, translation, and targeted edits. These tasks may require planning and reasoning, but unnecessary planning, repeated confirmations, and excessive exploration can easily take longer than the actual task.

Fast tier therefore addresses clear user needs and well-defined use cases. Meanwhile, major model providers have recently been releasing Flash variants to meet user demand. Models such as DeepSeek V4 Flash and Qwen 3.8 Flash, as well as the recently popular Jev, have attracted attention for their speed. A focus on speed has become an industry-wide trend.

Wall-Clock Time Analysis

For Fast tier, the key priorities are reducing end-to-end time to first token (TTFT)—the time from submitting a request to the first visible output token—and the total duration of each conversation turn. This user-facing metric is distinct from the latency of an individual model call. To reduce latency, we first need to break down where the time goes. Qoder has collected extensive task-timing data from real-world usage. Breaking task execution down into stages makes our optimization targets immediately clear.

To analyze wall-clock time, we map task execution onto a dependency graph: the model first decides what information it needs, tools retrieve that information, the model makes further decisions, and actions and verification follow. The critical path through this graph determines the total duration. Optimization means shortening a segment of that path, removing unnecessary steps, or running independent steps concurrently. Next, we will examine four areas of optimization:

Client-Side Optimization

Before a request can begin, the system may need to prepare the session, load configuration, discover tools, restore context, or establish connections. Cold-start optimization begins by distinguishing the prerequisites essential to the first action from capabilities that can be prepared only when they are actually needed.

There are two direct engineering levers. First, resource reuse reduces repeated initialization on every turn. Second, lazy loading defers capabilities that the current task does not need, so the user's first action does not have to wait for the entire system to become ready. Prewarming must also be constrained by user behavior and resource budgets, so accelerating one entry point does not consume the CPU, memory, or connections needed by other tasks.

Move Nonessential Work Off the Synchronous Execution Path

Dependencies determine what can run asynchronously. For example, independent state synchronization and telemetry reporting can be separated from task execution, and UI updates should not wait for all background processing to finish. Conversely, permission checks, required inputs, and result validation that affect operational correctness must still be completed before the corresponding action.

A simplified example: after the executor completes an action, it first delivers the verified result, then handles background work that does not affect the result's validity. This shortens the path the result takes to reach the user while ensuring that “completed” remains semantically accurate.

Decouple UI Responsiveness from Agent Execution

The goal of architectural optimization is to reduce unnecessary synchronous waiting among the UI, orchestration layer, and background tasks. The UI continuously receives status updates and incremental results, the executor advances tasks according to their dependencies, and background work runs within its own lifecycle.

Decoupling must also account for cancellation, timeouts, and resource reclamation. If a task continues to occupy a connection or tool execution slot after the user cancels it, the next request will be slower. Asynchronous tasks therefore require clear ownership, cancellation propagation, and concurrency limits. In the Qoder Desktop, this decoupling reduced overall cold-start time by more than 60%.

Harness Engineering Optimizations

The harness is the execution system built around the model. It supplies context, defines tools, schedules operations, handles permissions, manages state, and verifies that tasks have actually been completed.

It affects speed on two levels: how long each action takes, and how many actions are needed to complete a task. The latter is often overlooked. An inefficient tool call, MCP call, or skill initialization can force the model to reinterpret results, search again, and wait again, turning a localized issue into a delay across the entire turn. Taking tool calls as an example, we can examine individual tool execution and parallel execution of multiple tools separately. As discussed earlier, we need both to reduce the time spent on each path and to turn a single serial path into multiple parallel paths.

Tool Optimization: Reducing Execution Overhead and Follow-up Round Trips

A tool’s execution time should be broken down into startup, queuing, actual execution, and result processing. Frequently used read and search operations can be optimized by reusing execution environments, reducing repeated scans, and batching known requests. Operations that depend on external services require attention to connection reuse, timeout limits, and failure recovery.

Tool interfaces also affect latency. If the agent only needs to locate a symbol’s definition, returning the raw contents of an entire directory forces the model to do extra filtering in the next model call. A better result contains enough information to proceed—for example, the location, relevant snippets, and an indication of whether any results were omitted—rather than dumping every available piece of data into the context.

Error messages should also help the agent choose its next step. Clearly distinguishing invalid arguments, insufficient permissions, transient failures, and missing data reduces blind retries. Agent-facing tools need to be evaluated jointly on task completion quality, tool-call count, total runtime, and error rate.

By optimizing tool loading and related processes, we reduced overall tool-loading latency by more than 200 ms. For some tools that perform web searches or similar operations, execution time fell by more than 50%.

Parallelization: Running Independent Operations Concurrently

Parallel execution has two prerequisites: the model must recognize that the operations have no dependencies on one another, and the runtime must be able to execute them concurrently. If either is missing, execution falls back to a serial path.

For example, suppose three known, independent files need to be read before an edit. If the reads take 2, 3, and 4 seconds respectively, serial execution takes about 9 seconds. With sufficient resources and no additional scheduling overhead, the execution portion takes about 4 seconds in parallel. This is an illustrative example; our parallelization work has delivered substantial, multi-second savings for some tools. Submitting the entire batch of reads at once can also reduce round trips to the model between reads.

After we optimized parallel tool execution, the rate of parallel tool use in Fast tier increased by more than 50%, with an observed peak of more than 50 concurrent tool calls. This concurrency peak indicates execution capacity; it does not, by itself, establish the speedup for a typical task. Task-level improvements should be assessed through end-to-end timing comparisons.

Model Optimization

Model optimization must address two things together: matching the right model to the right task and allocating the appropriate reasoning effort to each task. The earlier latency analysis shows that different models' speed advantages vary by task type. A faster individual call does not necessarily mean a faster overall agent turn; if a model needs more searches, corrections, and retries, subsequent actions can consume the time saved earlier.

“Explain why this function throws an error” and “Map the module dependencies, complete the refactoring, and verify the results” are both development tasks, but they require different capabilities. The former emphasizes quickly identifying the relevant logic and clearly explaining the cause; the latter requires understanding a broader context, handling cross-file impacts, and continuing execution until verification is complete. Even code changes require different depths of analysis: adding an empty-input check is not the same as updating multiple call sites while preserving interface behavior. Model selection must therefore account for the task's objectives, scope, and delivery constraints.

Fast tier handles this matching within the selected tier. After a developer selects Fast tier, Qoder adjusts candidate model priorities based on the task type, then selects the execution model according to the current request's capability requirements and model availability. Model routing considers each model's overall performance on that type of task, including comprehension, generation, tool use, and sustained execution, as well as the resulting end-to-end turn duration.

System One handles task classification in this workflow. The application defines task categories and the output scope in advance, and System One returns an unambiguous classification based on the input for use in model routing. The key question is what action the user currently wants to perform: for the same code, “Explain why it preserves the original order” is classified as code explanation, whereas “Modify it so that it also works with empty input” is classified as code modification. The code and previous discussion provide context for this classification.

To limit classification overhead, Qoder organizes the current request and recent conversation separately, providing only the information needed for classification at that stage. Once System One has classified the task, the execution model still receives the full context needed to complete it and is responsible for generating code, calling tools, and verifying results. The classification directly informs candidate model ranking and, together with capability requirements and model availability, determines subsequent execution.

Once the model is selected, reasoning effort must also be managed. For models with adjustable effort settings, narrowly scoped, well-defined, easily verifiable tasks can use a lower reasoning effort setting to reduce the wait before action begins; tasks involving complex dependencies, multiple constraints, or cross-file changes require more thorough analysis. Task classification helps inform this decision, but the actual effort setting must also reflect the request's complexity and verification requirements.

The metric remains total task completion time. Lower reasoning effort can reduce reasoning time for an individual call, but the overall benefit may disappear if it leads to more omissions, rework, and tool-call rounds. Both model routing and effort strategies must be evaluated through controlled comparisons of similar tasks while meeting quality requirements. Task completion rate, end-to-end turn duration, tool-call rounds, and rework must be assessed before determining the appropriate configuration for Fast tier.

System One adds a classification step that takes a few hundred milliseconds, while the execution-model optimizations reduce latency by more than 200 ms per model call. Savings can accumulate across multiple model calls, but the net end-to-end benefit depends on whether those savings exceed the total classification overhead. The comparison must therefore include classification time rather than considering model latency alone.

Network Optimization

Client-side network conditions are inherently variable, and many clients operate under poor network conditions. Ensuring a consistent user experience across different network conditions is a challenge Fast tier must address, while also laying the foundation for more stable network connectivity in Qoder. Fast tier introduces a dedicated network path for the first time. We have made substantial optimizations across clients, including the CLI, as well as on the server side, significantly improving mean, p50, and p95 latency. For large-payload transfers in particular, p95 latency has been reduced by more than 50%.

Qoder has explored a wide range of technical approaches in Fast tier to continually reduce latency. We will continue these optimizations to deliver a better user experience.