It seems China is actively expanding not only into models but also into complete coding harnesses / agent apps.

Kimi K2.7 in GitHub Copilot
https://github.blog/changelog/2026-07-01-kimi-k2-7-is-now-available-in-github-copilot/
GitHub has added Kimi K2.7 Code to Copilot. This is the first open-weight model available in Copilot. Hosted on Microsoft Azure.

MiMo-Code CLI by Xiaomi
https://mimo.xiaomi.com/mimocode
https://mimo.xiaomi.com/blog/mimo-code-long-horizon
https://github.com/XiaomiMiMo/MiMo-Code
Xiaomi is developing its open-source CLI MiMoCode. It supports working with Git, checkpoints, task trees, subagents, compose mode, and voice input. It features persistent memory on SQLite FTS5 and commands like /dream and /distill to extract knowledge and repetitive workflows into skills.

Interestingly, this is not just "another CLI", but an attempt to build a Codex/Claude Code-like agent with its own memory and operating modes. There is a free starting tier called MiMo Auto, OAuth via Xiaomi MiMo Platform, and support for OpenAI-compatible providers.

ZCode App v3 by Z.ai
https://zcode.z.ai/en
ZCode is a desktop application for MacOS/Windows/Linux powered by the top-tier GLM-5.2 model. With v3, Z.ai optimizes the entire agent harness specifically for its model and pricing plans. It looks like a direct clone of the Codex app.

It features plugin management, file rewind with a safety summary, improved command suggestions for prompts, planning, review, deployment, workspace tasks, skills, and multi-agent interaction. You can manage the agent via chat in WeChat, Feishu, or Telegram.

Discussion
https://news.ycombinator.com/item?id=48753715
On HN, the main discussion point is trust. Unlike MiMoCode, ZCode is not open-source, so people are asking about telemetry, sandboxing, and whether running a desktop agent on a primary machine is safe at all. Many comments boil down to best practices: agents are best run in VMs/containers, given separate worktrees, separate GitHub deploy keys, and minimal access to secrets.

Sonnet 5 - Longer and More Expensive
https://www.anthropic.com/news/claude-sonnet-5
Anthropic has released Claude Sonnet 5. Positioning: the most agentic Sonnet yet, closer to Opus 4.8 but cheaper. Available in Claude, Claude Code, and API as claude-sonnet-5. Until August 31, 2026, the price is discounted to $2/$10 per million input/output tokens, after which it will be $3/$15. For comparison, Opus 4.8 is $5/$25.

An additional nuance: the new tokenizer may count the same text as 1.0-1.35x more tokens depending on the content. Meaning, a "cheaper Sonnet" is not always automatically cheaper in reality. The model isn't necessarily smarter, but it shows better results because it is more persistent. Therefore, it can consume a lot of tokens.

Discussion
https://news.ycombinator.com/item?id=48736605
HN met Sonnet 5 with skepticism. Many are asking why use Sonnet 5 for high-effort tasks if Opus 4.8 (low/medium) sometimes offers better value per dollar. Another complaint is that models are becoming more "agentic" but sometimes overcomplicate simple tasks and generate extra work for themselves.

#glm #kimi #githubcopilot #mimo

Comments

Cursor hosted Compile 26, its developer-focused event dedicated to the future of programming.

https://www.marketwatch.com/story/social-media-declared-cursor-dead-then-spacex-handed-the-ai-startup-a-60-billion-lifeline-50454e29
At Compile, Michael Truell showcased the new Composer—featuring their proprietary 1.5T parameter model, trained from scratch by Cursor using over 100,000 Nvidia GPUs from SpaceX/xAI. In his view, Cursor is no longer just "a better VS Code with a chat", but a platform for agentic programming.

The model may also become available in Grok Build.

https://www.youtube.com/watch?v=fWa7uxyhVDE

https://www.youtube.com/@cursor_ai/videos
Presentations are gradually being uploaded to the official YouTube channel. These are short 10 to 25-minute talks focusing not on "AI replacing programmers," but on how the nature of work is shifting: agent memory, infrastructure for parallel agents, the roles of PMs and senior engineers, training, and quality assurance.

In addition to agent workflows and memory, there are sessions covering note-taking, representation of thoughts, development environments, agency in language, intelligence efficiency, the shifting role of the engineer, and other non-technical topics.

Origin — GitHub for Agents
https://cursor.com/origin
Notably, the most intriguing announcement is Origin, Cursor's new Git platform. On their website, they refer to it as "Git for agents." During the presentation, Origin was explicitly introduced as an agent-native Git platform, ultimately positioned as the beginning of direct competition with GitHub.

Here, agents can interact with repositories, create and handle PRs, respond to comments, fix CI failures, resolve merge conflicts, and ping human developers only when absolutely necessary.

Currently, Origin is active for internal use, while a waitlist has been opened for the public.

#cursor #composer #agenticcoding #origin #github

Comments

Over the past six months, most new large language models have evolved beyond merely providing high-quality answers; they now possess the capability for sustained, autonomous operation.

Loop Engineering is a method of structuring agentic workflows so that instead of responding to a single prompt, an agent repeatedly executes a cycle: understanding the task, gathering context, taking a micro-action, verifying the result, correcting errors, and terminating based on an explicit rule.

While prompt engineering aims to optimize a single model response, loop engineering focuses on improving the entire process of driving a task to a verified outcome.

What is Loop Engineering
https://kilo.ai/articles/what-is-loop-engineering
This article provides the foundational concepts. The strength lies not in a single step, but in closing the loop—where any test failure or code error becomes new context rather than just a failure. However, a well-designed loop should not run indefinitely; it requires explicitly defined goals, context, verification, and termination rules. The article also addresses the risks associated with such high autonomy.

The basic cycle is structured as follows:

1. Intent. A human or system specifies a concrete desired outcome.
2. Context. The agent reviews code, documentation, errors, logs, requirements, or project guidelines.
3. Action. The agent modifies code, executes a command, calls a tool, or drafts a plan.
4. Observation. The system captures test results, compiler errors, build outputs, logs, screenshots, or review comments.
5. Correction. The agent adjusts its plan and repeats the cycle.
6. Termination. The cycle ends when there is proof of completion or a blocking issue arises.

Origin of the Term's Popularity
https://addyosmani.com/blog/loop-engineering/
Addy Osmani references insights from Peter Steinberger and Boris Cherny, popularizing the terminology. Instead of manually prompting the agent for each subsequent step, we build a system that prompts the agent on our behalf. This involves learning to design feedback loops, memory management, access controls, and termination boundaries.

Sub-agents separate the "doer" from the "verifier"; automated schedulers trigger tasks, separate git worktrees isolate parallel agents, and plugins provide access to real-world tools. Project-specific knowledge is stored externally—tracking what has been done, what remains, and what has already been attempted.

https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/
Lushbinary largely echoes Osmani's points but adds practical details: the Ralph loop, how automations are structured, isolated worktrees, skills, integrations, sub-agents, and memory architectures in modern tools.

Without guardrails, budgets, logging, persistent memory, isolation, and manual error overrides, a loop is not a production-grade system—it is simply an infinite loop hosting an expensive agent.

Four Levels of Loops
https://www.langchain.com/blog/the-art-of-loop-engineering
While LangChain uses this topic to promote its product stack, they openly acknowledge the core trade-off: verification increases cost and latency but is essential for quality. They propose categorizing loops into four levels:

1. Agent Loop. The model calls tools sequentially until the task is complete.
2. Evaluation Loop. A dedicated evaluator agent reviews the output against specific rules and provides feedback to the execution agent.
3. Event Loop. Triggers are event-driven (e.g., schedules, external webhooks, messages, or new documents) rather than manual.
4. Optimization Loop. Execution logs are analyzed to refine system configurations, tools, or prompts.

Matthew Berman's Video
https://www.youtube.com/watch?v=dMrm2jAyrKM

The video "Only the best are using them..." frames the topic as the new "meta" for coding. It employs a highly hyped tone—using phrases like "the future of software engineering," "only a few know how to do this," and "the best are already using it." While it explains the core concept well for a broad audience, it significantly amplifies the hype.

Critique of the Term
https://iii.dev/blog/loop-engineering-is-just-software-engineering/
In many discussions, "Loop Engineering" is presented as if a brand-new paradigm has emerged. Some authors frame it as the future of software development, even though many of its components are well-established engineering practices: automated testing, queues, schedulers, logging, access control, retries, and human-in-the-loop validation.

Terminology mapping:

• scheduled automations -> schedulers / cron jobs;
• out-of-conversation memory -> state management / persistent storage;
• verifier -> independent consumer of output with retry logic;
• stuck tasks -> dead-letter queues / error queues;
• external integrations -> webhooks and external integrations.

This approach works best for mechanical, repetitive, and highly verifiable tasks that can be broken down into clear, testable steps. For product decisions, architecture, security, financial transactions, database migrations, and anything requiring nuanced judgment, a human must remain in the loop.

#agenticcoding #autonomousagents

Comments

Finally, an answer to Claude Code and Codex from Elon Musk's team.

Grok 4.5 — Faster and Cheaper than the Opus-Class
https://x.ai/news/grok-4-5
https://cursor.com/blog/grok-4-5
On July 8, 2026, SpaceXAI unveiled the Grok 4.5 model—tailored for code generation, autonomous tool use, and "office" tasks. It was trained in collaboration with Cursor on tens of thousands of GPUs. The training data includes trillions of tokens from real Cursor sessions: how people work with repositories, agents, and tools, plus STEM and general knowledge, rather than just "pure" coding like in Composer 2.5. The model has seen what real-world work in Cursor looks like from users who opted in via their settings.

In benchmarks, the model isn't leading everywhere—sitting somewhere between GPT 5.5 (with 5.6 just around the corner) and Opus/Fable—as the focus is specifically on cost-effective intelligence. Compared to GLM-5.2, Grok has the ability to accept image inputs.

On SWE-bench Pro, the model consumes about 4 times fewer output tokens than Opus 4.8 at maximum settings while pushing around 80 tokens per second. On longer tasks, Grok tends to overcomplicate answers less than Sonnet 5 or Opus, meaning the actual bill often ends up being more favorable than a simple token-price comparison suggests. The API costs $2/$6 per million input/output tokens; if the context exceeds 200k (with a maximum of 500k), the price doubles.

Grok Build CLI for Everyone
https://x.ai/cli
https://x.ai/news/grok-build-cli
Grok Build is a terminal-native coding agent (a Rust-based CLI, in beta since May 2026). It’s not a browser chat, but an agent in your command line. It has everything you need: parallel subagents (including in separate git worktrees), skills / plugins / hooks / MCP / AGENTS.md. Out of the box, it intentionally picks up settings from Claude Code (skills from ~/.claude/ and some permissions). It features a headless mode (grok -p) for scripts and CI, voice, image/video tools, and a /goal command for long-term objectives.

Grok 4.5 with a 500k context window has now been set as the default model. So Grok Build focuses on speed and parallelism (multiple agents running simultaneously). Right now, it features a clean, nice terminal UX and compatibility with workflows from the Claude ecosystem. Plus, for a limited time, there is a free tier in Grok Build and Cursor (in Cursor, this applies to all plans, with double usage for the first week). It is not yet available in the EU (promised by mid-July).

Currently, the interface has a lot of "pay for subscription" prompts. By default, training data collection is enabled after installation—you have to go into the settings to opt out. In my comparative testing of ZCode (another relatively affordable GLM-5.2 model) vs. Grok Build, I preferred the results from Grok.

https://www.youtube.com/watch?v=RGXRUH3oK6U

According to the video creator, Grok generated a more visually appealing version (better color palette, more user-friendly design) of the presentation. Grok also produced a much better solar system simulation. For creating a web page from a photo, the results were roughly identical. The main advantage is the price, which is 5–6 times cheaper than Claude Code.

Discussion
https://news.ycombinator.com/item?id=48835111
On HN, the discussion revolves around price, speed, and how many tokens a task actually consumes. First impressions: it is very fast, performance-wise around the lower tier of Opus / GLM 5.2, and if you pay for the API, it often ends up cheaper than GPT and Opus. Grok Build's interface is being praised—"well made"—especially against the backdrop of Claude Code's ongoing decline.

There is skepticism too. It stops looking cheap once the context exceeds 200k; some are keeping it strictly for short reviews. There are complaints that for simple edits (inline helpers), the model tends to rewrite half a module instead of just ten lines. Grok's reputation (past safety scandals) is still cited as a reason to avoid using the model.

Cursor data and training in robust environments are strong points; Grok 4.5 + Grok Build look like good candidates to test on various tasks if your repositories aren't too large.

#grokbuild #cursor #newllmmodel #agenticcoding

Comments

Finally, model announcements that represent a meaningful step forward.

The Massive Kimi K3
https://www.kimi.com/blog/kimi-k3
Moonshot has released Kimi K3 — an open-frontier, extremely large 2.8T-parameter model (MoE: activates 16 out of 896 experts), featuring a 1M-token context window and native image understanding. It is the first open model in the ~3T parameter class. The model is optimized for long-running agentic workflows, and the launch presentation places particular emphasis on generating simple 3D games.

Among the showcased use cases are GPU kernel optimization, building a MiniTriton compiler from scratch, and a 48-hour chip design run. According to Moonshot's benchmarks, K3 trails Claude Fable 5 and GPT-5.6 Sol by a small margin, but consistently outperforms Opus 4.8, GPT-5.5, and clearly surpasses GLM-5.2. That effectively places it in third place worldwide today, with only about a 5% gap behind Fable 5. Following a proud Chinese tradition, it is also cheaper than its U.S. competitors.

At the time of the announcement, Moonshot released access to Kimi K3 through its API, Kimi.com, Kimi Code, and other company services, but not the model weights themselves. In the technical blog post, Moonshot explicitly states that the full model weights will be released by July 27, 2026.

Discussion
https://news.ycombinator.com/item?id=48935342
According to Simon Willison, this is "the most expensive pelican" among Chinese models. If K3 is genuinely close to Fable and Sol, that pricing may be justified. Running a 2.8T model locally is out of reach for nearly everyone, so the real value lies in GPU cloud access rather than "running it on a laptop." Much of the discussion revolves around whether Chinese AI labs have nearly caught up with Anthropic and OpenAI, or whether a significant gap still remains.

https://www.youtube.com/watch?v=QfCpRTLSOB4

Fable 5 Returns
https://www.anthropic.com/news/redeploying-fable-5
Following the June 9 release, the U.S. government imposed restrictions on open access to Anthropic's most capable models, Fable 5 and Mythos 5, requiring prior internal security review. Anthropic disabled access for all users because it had no reliable way to verify users' locations.

The restrictions were lifted on June 30, and starting July 1, Fable 5 became available globally again across Claude, Claude Code, Cowork, and the Platform API. Mythos 5 remains limited to a small set of U.S. organizations through the Glasswing program. Anthropic also extended the grace period during which Fable 5 remained available within subscription plans — first until July 12 and then until July 19. Whether access will eventually require token-based billing remains to be seen.

GPT-5.6 in Three Variants
https://openai.com/index/gpt-5-6/
OpenAI introduced the GPT-5.6 family: Sol (flagship), Terra (balanced, roughly GPT-5.5-level performance at a lower cost), and Luna (fast and inexpensive, roughly GPT-5.4-level performance). It's encouraging to see an explicit choice instead of a single model expected to handle everything. Routine agent loops fit Terra or Luna, while heavy refactoring and long-running tasks are better suited to Sol.

GPT-5.6 Sol already feels like GPT-6. It can autonomously work for hours, perform self-verification, execute complex tasks, and generate substantial amounts of code. This capability is precisely why the release initially went through a government preview program before becoming broadly available.

The New Work / Codex App
https://openai.com/index/chatgpt-for-your-most-ambitious-work/
OpenAI is integrating the Codex app with the Atlas browser (a few days later, Anthropic also integrated a browser into Claude Work/Code) and the new ChatGPT desktop applications for macOS and Windows. The platform now revolves around three modes: Chat (quick questions and drafts), Work (long-running agentic tasks involving documents and email), and Codex (repository-connected development workflows).

Computer Use has reportedly improved significantly. Plugins, skills, scheduled tasks, and related automation features now work across the ecosystem. Long-running tasks can be monitored and managed directly from a phone. A new Sites tab allows users to publish public dashboards and prototypes with minimal effort — simply by asking ChatGPT to publish a site.

OpenAI has also introduced inline editing. Code and text can now be modified directly inside the ChatGPT interface without constantly switching to an external editor for small changes.

Keyboard Codex Micro
https://worklouder.cc/codex-micro
OpenAI has also unveiled its first hardware product, the compact programmable keyboard (more accurately, a macropad) developed together with Work Louder for managing Codex agents. It features dedicated agent-control keys, status indicators, a reasoning-level dial, and support for voice commands.

#kimi #openai #codex #anthropic #fable5 #agenticcoding

Comments

The Grok scandal involving "silent" code uploads, followed by open-sourcing as an attempt to regain trust.

Grok CLI and Tracking
https://www.internationalcyberdigest.com/xais-grok-build-cli-uploads-entire-git-repositories-to-a-google-cloud-bucket/
https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547
Several users reported that upon session startup, the Grok Build CLI deterministically (not as an autonomous agent decision) archives the current directory or Git repository and uploads it to Google Cloud Storage (grok-code-session-traces). One user ran grok from their home directory and observed that SSH keys, password managers, documents, photos, and all other personal files were being uploaded.

Investigations revealed that this is NOT the model's behavior. The "Improve the model" / /privacy settings only control whether the data is used for training, not whether files are copied from the machine in the first place. This behavior is executed by the harness code. Analysis (by cereblab, on grok version 0.2.93) revealed two data transmission channels:

1. Model turn (/v1/responses) — content actually read by the agent (including .env files).
2. Entire directory snapshot — a separate upload of the entire repository, including Git history, even containing files that the agent was explicitly instructed not to read.

For a 12 GB repository, approximately 5.1 GiB was uploaded to Google Cloud Storage, compared to only ≈192 KB sent to the model. A local workaround was identified using a kill-switch: setting [harness] disable_codebase_upload = true in ≈/.grok/config.toml (along with environment variables to disable telemetry). However, following the public backlash, xAI servers disabled these uploads on their end around July 12. Elon Musk promised to completely delete all previously uploaded data.

https://news.ycombinator.com/item?id=48892468
The tone on Hacker News (HN) is highly critical, with users arguing that authorizing an agent to "trust this directory" should not grant permission to "upload everything to the vendor." Consequently, there is strong advocacy for running AI agents within VMs, containers, or dedicated user accounts to restrict access to local systems.

Comparisons were drawn to Cursor's indexing behavior (which also uploaded all files on startup), but in Cursor's case, this was clearly documented as a requirement for faster embedding generation.

Grok CLI Open-Sourced
https://x.ai/open-source
https://github.com/xai-org/grok-build
https://simonwillison.net/2026/Jul/15/grok-build/
Following the controversy, xAI/SpaceXAI open-sourced the Grok Build codebase on GitHub under the Apache 2.0 license. It consists of a Rust TUI and an agent runtime (≈845k SLOC, with ≈3% vendored). The repository acts as a periodic snapshot of their internal monorepo (SOURCE_REV), and external pull requests or issues are not accepted. Users can build from source and run it local-first using their own inference backend. However, in practice, the CDN-distributed binaries and the open-source tree may differ, as reproducible builds are not yet supported.

Traces of the upload mechanism remain in the code (upload/gcs.rs), but the session upload now returns session_state_upload_unavailable. The codebase also includes ported tools from Codex/OpenCode (with appropriate THIRD-PARTY notices), a terminal Mermaid renderer, and system/subagent prompts.

Discussion
https://news.ycombinator.com/item?id=48926590
Reactions on Hacker News are mixed: some view this as a strategy of a lagging player or as an "open-sourced because they got caught" move. Others praise the TUI for its mouse support and smoothness. The community has already started creating privacy-focused forks:

• gork-build: https://github.com/thedavidweng/gork-build (strips telemetry, blocks auto-updates),
• digi-grok / open-grok (multi-provider support),
• desktop Tauri wrappers,
• scripts to disable telemetry.
  However, many believe these forks lack utility for other models, as alternatives like Pi or OpenCode are better suited for those workloads.

#grokbuild #grok #agenticcoding

Comments