Hands-on test of Grok Bot, WorkBuddy, and Qoder CN: Writing a large model routing review on the same topic

From the "chat box" to the "cloud computer": Musk recently added new skill points to Grok Bot. (Leiphone) On October 7, he stated on X that Grok Bot will integrate third-party top-tier models such as Claude Opus 5.5, Midjourney, and Suno; and recently it has even seen a leap in its core paradigm: the main Bot will identify work it can take over for the user and proactively offer to take it on. In other words, it is no longer merely a chatbot passively waiting for questions, but has become an AI cloud team that "actively looks for work to do." Unlike traditional chat assistants, which mainly work around a single dialog box, users can create multiple Bots with different names and responsibilities, such as researchers, project managers, and operations specialists, each responsible for a type of work. The main Bot will, based on the daily task execution status, help users discover the next step of work and proactively offer to take it on, leaving decisions that require user judgment to the user. (Illustration: without the user actively asking, Grok Bot, based on the existing work context, proactively reminds about the AAAI-27 review deadline and proposes further checking manuscripts not yet submitted in OpenReview.) Just after finishing gathering materials, it proactively drafts an email for you to confirm and approve; when you shut down your computer, it is still in the cloud handing over work with its "AI colleagues." To what extent has this "multi-agent collaboration" and "proactive Agent" represented by Grok Bot actually evolved? How much stronger is several Bots working together than a single agent? To this end, we planned a "same-topic hardcore test": we brought in Grok Bot and two domestic Agents—WorkBuddy and Qoder CN—and had them each form an AI team to complete a research task that is highly prone to errors: writing a "Survey of Large Model Routing Research." This test requires completing literature retrieval, method organization, numerical verification, and independent review. This topic requires the agent to distinguish among multiple studies with highly similar names, requires review comments to be implemented in the final document, and also requires the agent to leave traces in the deliverables throughout the processes of division of labor, handover, and error correction.

After actual testing, Grok Bot submitted in 12 minutes 49 seconds, the fastest and with the most papers included; WorkBuddy took 21 minutes 43 seconds and delivered the main text closest to an editorial draft; Qoder CN took 14 minutes 42 seconds and presented a valuable instance of cross-agent error correction. The three deliverables also respectively left issues in file citations, numerical standards, or method classification. From this, it can be judged that the next stage of competition for multi-agent products is delivery reliability: whether verification conclusions can pass through every handover and accurately land in the final document.

02

Three AIs writing on the same topic: who submits first? Why choose large model routing? This is a research topic that is very prone to errors during the material organization stage. Different papers may use similar names but adopt different routing methods; the same study may also present experimental numbers under different standards in papers, project repositories, and other introductory materials. Merely collecting a dozen papers and piecing the content into a survey does not mean the task is complete. We require the agents to respectively assume responsibilities such as literature retrieval, method organization, experiment and benchmark verification, and independent review, and to retain visible task handover and revision records in the final delivery. The test instructions are as follows:

Code block

1. Please use the multi-agent collaboration mechanism available to you to complete a Chinese research survey as of October 15, 2026, on the topic of "Large Model Routing Research."

2. Please have different agents respectively assume responsibilities such as literature retrieval, method organization, experiment and benchmark verification, and independent review, with one person in charge integrating the results.

3. You may divide the work in a way supported by the product, but you must retain actually visible task handover and review revision records; do not fabricate agent collaboration that did not occur.

4. Final delivery: ① a survey of about 3,000–4,000 Chinese characters explaining what problem large model routing aims to solve, how the main methods are classified, and the specific contributions and limitations of LLMRouter; ② a comparison table covering at least 12 original papers, listing methods, routing basis, model pool, quality/cost/latency metrics, and applicable boundaries; ③ a "questions still unresolved" subsection; ④ a brief collaboration record explaining which agent discovered what problem, who verified it, and how it was ultimately revised.

5. Prioritize reading the full text of papers, author projects, and public code.

6. Attach openable original source links for each key fact and number; distinguish between results reported in papers, independent benchmark results, and your own inferences.

7. Mark claims that cannot be verified as "to be verified"; do not fill in or fabricate citations.

8. Before completion, an agent that did not write the draft should independently check the citations, numbers, method classification, and the boundaries of the conclusions. Let's look at how the three products performed: first, Grok Bot, which completed the task with the fastest user experience. As shown in the figure below, Grok first assigned the task to three named Bots displayed as the "Academic Researcher," "Project Manager," and "Article Writer," while handling the final integration itself. The Academic Researcher produced a comparison table of 19 papers and distinguished in advance among several highly similar study names; the Project Manager checked the numbers; the Writer Bot wrote a first draft after receiving the materials, and the Academic Researcher then reviewed it. In the end, Grok Bot delivered an output containing eight document files, covering the main text, comparison table, open questions, literature review, benchmark verification, review comments, and collaboration record. Grok Bot run screenshot 1: after the task starts, three Bots are invoked to work together. Grok Bot run screenshot 2: after the task is completed, a delivery checklist is provided. During Grok Bot's execution of the task, the independent review comments caught two percentages that had not been confirmed by the verification table, and the Writer Bot subsequently deleted them. Another round of handoff also corrected the arXiv numbers of two papers; these are revisions that can be matched between the files and the session, showing that multi-Bot collaboration, beyond expanding the search scope, indeed took on verification responsibilities. Next is Qoder CN. After the task started, it launched three retrieval sub-agents to search for core papers, benchmarks, and recent progress respectively; then two roles, method organization and fact-checking, took over; an independent reviewer checked after the draft was completed; and finally Qoder CN delivered four documents: the review, the paper comparison table, open questions, and the collaboration record. Qoder CN run screenshot 1: after the task starts, three agents are created to retrieve literature. Qoder CN run screenshot 2: two agents, method organization and fact-checking, are created to process the retrieved papers. Qoder CN run screenshot 3: screenshot of the deliverables. Qoder CN run screenshot 4: summary of the use of six agents after the task ends. At the end of task execution, the verifier agent, referring to the RouteLLM paper, considered the source of "saves up to 85% of cost" unclear; the reviewer then went on to find the project repository to confirm this statement about the project. In addition, the paper's table gives a cost-saving ratio of 3.66 times; the evaluation conditions and calculation bases of the two numbers need to be explained separately and cannot be directly interchanged. Therefore, the added review step did change the content of the manuscript. Then there is WorkBuddy. From the evaluation experience, WorkBuddy took the longest time, and the main text it delivered was also the most like a research draft that could continue to be edited. It arranged three research roles to work in parallel on literature retrieval, method organization, and benchmark verification; the lead integrated the first draft, which was then handed to a role that had not participated in writing for review; and the final review organized methods around "routing signals" and "decision structure," clearly distinguishing paper self-reports, independent benchmarks, author inferences, and numbers pending verification, and readers could follow the annotations back to the evidence. WorkBuddy run screenshot 1: after the task starts, three agents are created to retrieve literature. WorkBuddy run screenshot 2: the task took 21 minutes and 43 seconds in total and produced complete deliverables. WorkBuddy run screenshot 3: collaborative error correction is the key summary issue. In addition, for the entire task, Grok Bot took 12 minutes 49 seconds, Qoder CN 14 minutes 42 seconds, and WorkBuddy 21 minutes 43 seconds. Number of agents: Grok Bot's 4 roles and WorkBuddy's 5 roles both include the main agent; Qoder CN's 6 sub-agents, plus a main agent. The counting basis for the number of roles is not consistent, so it cannot be used to infer that "fewer agents means faster running"; the time consumed includes retrieval, waiting, review, and delivery, and is not pure model inference time. The time consumed by the three agents and the number of agents used to execute the task were actually measured. All three products completed the paper writing as required, and they also exposed the advantages and disadvantages of different approaches:

Grok Bot demonstrated extreme "speed and breadth": it finished the draft in only 12 minutes 49 seconds, the shortest time, and its retrieval covered the largest paper library;

WorkBuddy excelled in "engineered draft quality": it took the longest (21 minutes 43 seconds), but the main text it delivered had the tightest logic and was closest to a first draft that a human editor could use directly;

Qoder CN staged the most exciting "cross error correction": it took a medium amount of time (14 minutes 42 seconds), and its internal independent review mechanism successfully intercepted a loophole with an unclear citation source, proving the feasibility of "AI supervising AI."

03

Breaking down Grok Bot: when AI starts finding work for itself. During the evaluation of three products, Grok Bot's way of collaborating brought testers a rather pleasant surprise, as shown in the video below: the main session of this task laid out a clear sequence of actions: Grok issued the division of labor; the researcher sent over a literature package, and the project manager pointed out problems with numbers and links; the writing Bot received the verified materials and wrote a first draft; the researcher who had not taken part in writing reviewed it and sent it back over two hard numbers; the writing Bot revised it, and Grok finally copied the files to the designated directory, and users could clearly see the running status of all the Bots taking part in the action. This handoff method relies on Grok Bot's shared cloud computer. According to the official description, Bots can continue working after the user closes the local application, and multiple Bots under the same account share files, browser login states and command-line credentials, each with session windows that can operate in parallel. Materials saved by the previous Bot can be used by the next Bot, reducing the steps of manually moving materials, while the session windows are used to distinguish different work interfaces and do not constitute permission isolation between Bots. Cloud execution is not an innovation unique to Grok Bot; many similar products also have cloud environment running settings, such as Manus Cloud Computer, WorkBuddy enterprise agents, Qoder Cloud Agents and so on. In addition, on October 2 Grok Bot also announced the ability for the "main Bot to proactively discover work and offer to take it on." As shown in the figure below, Grok reported five new research papers in the morning and generated an email draft awaiting user confirmation. This is a user approval that Grok Bot proactively initiated after a previous user research task, "pushing the retrieval results forward to email." Screenshot of Grok Bot proactively initiating user approval to push research results forward to email after literature research.

04

From taking on tasks to proactively finding work,

what is the multi-agent track competing on? In this round of same-prompt testing, Grok Bot delivered the research package with the widest coverage in 12 minutes 49 seconds, with records of the division of labor, verification and rejection among Bots, while WorkBuddy's main text was more suitable as an editorial base draft, and Qoder CN demonstrated effective cross error correction. Together, the three products show that multi-agent systems can already handle specific steps in the research process, while the quality of the results still needs to be further optimized by readers in light of their own professional level. Compared with WorkBuddy and Qoder, Grok Bot shows another side of the product form, putting agents into a continuously running cloud environment, so that Bots can retain materials across sessions and also continue the work of their peers. Accordingly, whether long-term tasks can recover after a failure, how access to shared materials is controlled, and how many resources each task consumes have all become part of product capability. In addition, the interaction method is also changing. Grok Bot puts named Bots, work status, routine tasks and deliverables on the same interface; users can see who is handling the task and take over when judgment is needed. At the same time, through the fragment "Grok reports five new papers, generates an email draft, and leaves the sending action for user confirmation," Grok can "proactively discover work" based on previously set accounts and retrieval tasks. This is a very interesting and useful capability, but in the future, measuring proactive suggestion capability will also depend on whether suggestions hit the need, whether they frequently interrupt users, and which actions must stop and wait for authorization. Musk recently proposed on X that Grok Bot will in the future select backend models, including third-party services, according to the task. This may also mean that the industry will further subdivide, the division of labor between model R&D and agent product R&D will become clearer, and the two types of teams will still extend into each other's fields. From the perspective of agent products, what determines product competitiveness is whether this process can deliver stably and let users clearly see data flows, task costs and the basis for results. Therefore, the notable difference among the three products is that Grok Bot has brought cloud persistence, cross-session handoff and proactive suggestions into the same working environment, while the three products still each have gaps in the finished draft, showing that the results of retrieval, verification and review still need to accurately enter the final document. As models and Bots can be combined according to tasks, product competition will increasingly depend on whether this chain can keep running: after a task interruption it can be picked up again, key decisions are checked by users, the process and cost can be checked, and the finished product can withstand professional review.

Click the keywords to view the corresponding hands-on test content

English text is being prepared.

vivago R1

Seedance 2.5 vs Kling 3.0

Minimax H3 vs Seedance 2.0 Fast