Google’s Antigravity Teamwork framework is built for long-running research and engineering jobs, with groups of AI agents proposing, challenging, verifying, and refining each other’s work over hours or days. Google reports seven notable open-problem results from its Long Proof work, while a Gemini 3.7 Flash team separately built a cycle-level out-of-order RISC-V CPU simulator that booted xv6 to a shell and matched hardware timing within 0.71% on average.

Google let the agents keep working — and the jobs got ambitious

Google has been testing Gemini models in teams of autonomous agents, and the latest results are far beyond the usual “build me an app” demo.

With Antigravity Teamwork, groups of agents can work for hours or days on the same objective. They propose approaches, challenge one another’s results, verify intermediate work, and keep iterating until they have something ready for human review.

Google says that setup has now produced seven notable results across open problems in mathematics and theoretical computer science. In a separate systems-engineering test, a Teamwork configuration powered by Gemini 3.7 Flash built a cycle-level out-of-order RISC-V CPU simulator from scratch, booted xv6 to a working shell, and ran more than 100 standard RISC-V benchmarks.

That combination is what makes this update worth watching. Teamwork is being used on proofs, processor simulation, and real open-source performance work — three very different jobs, all built around the same idea: give several agents a shared objective and enough structure to keep improving the result.

Teamwork is more structured than “put several agents on it”

Google first introduced Teamwork as a multi-agent orchestration framework inside Antigravity. The current version is available through the `/teamwork-preview` command, and it does not use one fixed team for every problem.

Instead, Teamwork works with patterns. A pattern defines the roles the agents should play, how their work should move between them, and what has to be checked before the job can advance. Antigravity chooses a pattern based on the task and can change the number of agents while the run is underway.

The current set includes Iterative Coding, Distributed Coding, Long Proof, Self-Verification, and Document Review. A software project that splits cleanly into parallel work can use a different structure from a mathematical proof that needs repeated strategy search and verification.

That separation is important. The useful part is not simply having more model instances running at once. It is giving them a workflow that says who proposes, who checks, who combines, and when another round is worth running.

The seven research results come with an important model detail

The Long Proof pattern is where Google reports the seven notable open-problem results. It generates several candidate strategies, pairs them with agents that try to break or verify them, and then combines the strongest surviving ideas into a more complete approach.

The results span coreset construction for ℓp subspace approximation, sparse convex optimization, maximal inner-product embeddings, Hadamard quantization, the Erdős unit-distance problem, prefix-matrix factorizations, and Knuth’s Cycles Conjecture. Five resulting papers are available on arXiv.

There is one detail worth getting exactly right: Google says the seven results were obtained using Gemini 3.1 Pro. Three of them — problems 1, 3, and 4 in Google’s list — were also reproduced with Gemini 3.7 Flash. So this is not a claim that Flash alone produced all seven results.

For Knuth’s Cycles Conjecture, Google reports first proofs for two simpler constructions of the even-integer case, with proofs running beyond 40 and 70 pages. The shorter proof was formally verified in Lean. For the broader set, Google says human experts reviewed and confirmed the results, with Lean providing the formal verification path for the Knuth work.

Then Gemini 3.7 Flash built a CPU simulator

The hardware result is easier to picture.

Using Gemini 3.7 Flash, Teamwork built a highly accurate cycle-level simulator for an out-of-order RISC-V processor. It was not just executing RISC-V instructions functionally. The goal was to model the timing behavior of a modern out-of-order design closely enough to compare cycle counts against hardware ground truth.

The agents worked through two phases. First came functional correctness: building execution logic for pieces such as reorder buffers, caches, and the out-of-order pipeline, then getting the simulator to maintain correct architectural state and boot xv6. The second phase focused on timing, aligning the simulator’s behavior against strict reference measurements.

Google says the finished simulator booted xv6 all the way to a shell and successfully simulated more than 100 standard RISC-V benchmarks. On unseen test workloads, it reached an average cycle-alignment error of 0.71% against BOOM hardware execution ground truth.

That is a much richer engineering target than generating source code that compiles. The team had to build the simulator, run microbenchmarks, inspect traces, compare timing, and keep refining the microarchitecture until the behavior lined up with the reference.

The same framework also shipped real open-source optimizations

Google also pointed Teamwork at existing open-source software.

For Eigen, the widely used C++ linear-algebra library, the agents worked through microbenchmarks and identified an opportunity around matrix-vector operations where the matrix has a single row or column. The resulting implementation added a dedicated fast path using direct data access, SIMD operations, and four-way accumulator unrolling. Google says the change went through the normal open-source review process and landed upstream with assistance from Gemini 3.6 Flash.

A second project focused on ParlayHash, a high-performance concurrent hash table. Teamwork contributed to the design of “Swiss Parlay,” which brought ideas from Swiss Table into the library.

Google reports 2× throughput on initial inserts with 64 threads, 1.5× overall throughput with a single thread, and memory use per element that was 25% lower than the comparison sequential table while staying close to its performance. The improvement also landed upstream.

These examples give Teamwork a different kind of credibility from a closed benchmark. The work ended up inside existing projects after external maintainers reviewed it through their normal process.

The interesting part is the loop, not the agent count

Multi-agent systems are easy to describe as “several AIs working together,” but Teamwork’s design is more specific than that.

For Long Proof, candidate strategies compete before the system commits deeply to one route. Subproblems can be split into a dependency graph and solved in parallel where possible. Verification is built into the process, and later rounds can reuse useful results and observations from earlier work.

The coding patterns use a different rhythm. Distributed Coding can fan a decomposable engineering job across parallel workers and bring in critic review. Iterative Coding keeps a tighter agent-test-refine loop for work that needs repeated local improvement.

The result is a framework that changes shape around the problem. Mathematics, processor simulation, and library optimization do not need the same team structure, even if all three benefit from longer-running collaboration.

This is already moving into the Antigravity developer workflow

Teamwork is not only a Google research harness. The updated framework is being rolled into Antigravity through `/teamwork-preview` on paid plans, with Google saying more of the improvements will arrive over the next few weeks.

Gemini 3.7 Flash is a natural fit for that environment because Google is positioning it specifically around coding and agents. The model launched in August as Google’s latest Flash workhorse for software engineering, knowledge work, web development, and multi-step agent workflows.

That gives the research results a direct connection to a product developers can actually experiment with. The exact high-parallelism configurations behind some of Google’s research runs are not simply the default consumer setup, but the orchestration ideas are becoming part of the same Antigravity environment.

The broader direction is clear: the unit of work is getting larger. Instead of asking one model for one answer, developers can hand a structured team a problem and let the system keep working through planning, implementation, testing, critique, and verification.

The Upgrade Feeling

The strongest part of this story is not a single benchmark number.

It is the range of work produced by the same orchestration idea. One Teamwork pattern can spend hours exploring a proof. Another can build and calibrate a CPU simulator. Another can optimize production-grade C++ and send the result through an upstream review.

That makes agent orchestration feel less like a demo layer and more like an engineering primitive. The model still matters, but the structure around the model is starting to matter just as much: roles, verification, parallelism, shared state, and the ability to keep working long enough for a difficult problem to unfold.

For developers following the agent space, that is the signal here. The next jump may come from better models — but also from giving those models better ways to work together.

Agent Merge Moves Copilot Into the Final Stretch of a Pull Request

GitHub announced on September 4, 2026 that Agent Merge is now in public preview as part of the VS Code 1.136 release updates. The feature is designed to help get a pull request ready to merge by resolving review feedback, failed checks, and merge conflicts. That is a meaningful expansion of the coding-agent workflow because the work does not stop when code is generated. Copilot is being pushed further into the stage where changes are reviewed, validated, repaired, and prepared for the final merge.

The Goal Is a Merge-Ready Pull Request

The new feature is centered on a simple outcome: take a pull request that still has blockers and help move it toward a state where it can be merged. GitHub’s changelog names three common blockers directly: review feedback, failed checks, and merge conflicts. These are exactly the kinds of issues that often appear after the main implementation is already finished. Agent Merge gives Copilot a role in that follow-through instead of leaving every cleanup step as a separate manual task.

Review Feedback Can Become an Agent Task

GitHub’s Copilot app documentation already shows the broader workflow behind this idea. When a pull request has review comments, a developer can ask an agent to resolve a comment with a Fix action. The agent can inspect the requested change, update the code, and continue the pull request workflow. Agent Merge builds on that direction by making review feedback part of a larger merge-readiness process rather than a disconnected step.

Copilot Can Work on Failing CI Checks

GitHub also documents Copilot workflows for failing CI checks. In the Copilot app, developers can ask an agent to fix failing checks from the pull request view. In Copilot CLI, the /pr fix ci command lets Copilot inspect failing CI jobs, analyze the logs, apply targeted fixes, push the changes, and re-check the CI status. This makes automated validation part of the same agentic loop as code changes.

Merge Conflicts Are Now Part of the Agent Workflow

Merge conflicts are another important part of the new flow. GitHub already lets Copilot cloud agent help resolve conflicts from a pull request. The agent can analyze the conflicting changes, resolve them, and verify that the build, tests, and linter still pass before requesting review. Agent Merge brings that capability into a broader workflow whose goal is to move the entire pull request toward merge-ready status.

Copilot CLI Shows the Full Pull Request Lifecycle

GitHub’s /pr command in Copilot CLI makes the direction especially clear. Developers can view pull request status, create a pull request, address review feedback, resolve merge conflicts, fix CI failures, or run the entire sequence. The /pr fix command handles feedback, conflicts, and CI in order, while /pr auto can continue looping through those phases until the pull request is fully green. Agent Merge fits directly into this larger move toward end-to-end pull request automation.

One Command Can Address the Main Pull Request Blockers

The /pr fix workflow is a useful preview of how GitHub is thinking about agentic pull request work. It runs three phases: review feedback, conflicts, and CI failures. Those are the same categories highlighted in the Agent Merge announcement. Instead of requiring the developer to jump between several tools and manually coordinate each repair, Copilot can work through the sequence as one connected task.

Agent Merge Can Keep Working in the Background

GitHub’s Copilot app documentation describes Agent Merge as a background workflow. When enabled, it prompts the workspace’s Copilot session to read the pull request, fix what is blocking it, and merge it as soon as GitHub allows. The workflow survives app restarts and turns itself off once the pull request is merged. That makes the feature feel less like a one-shot command and more like an ongoing agent watching the state of the pull request until the job is complete.

The Human Still Owns the Final Development Workflow

The strongest version of this workflow is not about removing developers from the process. GitHub’s own documentation keeps review and repository rules in the loop. Copilot can make changes, resolve blockers, and request review, while normal branch protections, approvals, and repository settings continue to determine when a merge is allowed. That keeps the agent focused on execution while the project’s existing collaboration model remains intact.

Copilot Was Already Moving Into Pull Request Repair

GitHub has been expanding Copilot cloud agent beyond code generation for months. In an official GitHub Checkout demonstration, the company showed Copilot working on pull requests, resolving merge conflicts, and handling development tasks around CI and review. Agent Merge turns that broader direction into a more explicit merge-readiness feature inside the current VS Code release cycle.

The Agent Can Read the Pull Request as a Working Context

A pull request contains much more than a diff. It includes review comments, CI status, branch relationships, code changes, and project history. GitHub’s Copilot app lets an agent operate with this pull request context and start a session directly from the PR. That gives the model a richer working surface than a generic code prompt because the agent can act on the state of the actual change that is moving through review.

This Changes What a Coding Agent Is Expected to Finish

Early coding assistants were mainly judged by how well they generated code. Agent Merge points toward a broader definition of completion. A useful coding agent is increasingly expected to help with the full path from implementation to review, validation, conflict resolution, and merge readiness. The result is a workflow where the agent is responsible for more of the delivery process, not just the first draft of the code.

Pull Request Automation Is Becoming More Continuous

The combination of Agent Merge, Copilot CLI pull request commands, cloud-agent conflict resolution, and CI repair shows a clear pattern. GitHub is connecting individual Copilot actions into continuous workflows. A developer can ask for a change, move it into a pull request, respond to feedback, repair checks, resolve conflicts, and continue until the repository’s merge conditions are satisfied. The boundaries between coding, review, and release preparation are becoming much more connected.

VS Code Is Becoming a Home for Agent Sessions

The same VS Code 1.136 update also adds new ways to manage agent sessions. GitHub’s changelog notes multi-root workspace experiments, chat-session organization, and indicators for sessions that need attention. These additions matter because long-running agents need a place where developers can see what is happening, return to a task, and understand which sessions require input. Agent Merge fits naturally into that environment.

The Pull Request Becomes an Active Agent Workspace

With Agent Merge, the pull request is no longer just a review artifact at the end of coding. It becomes an active workspace where an agent can keep contributing after the initial implementation. Review feedback can lead to new edits, CI results can trigger repair work, and merge conflicts can become another step in the same ongoing session. That turns the PR into a live coordination point between the developer, reviewers, repository rules, and Copilot.

GitHub Is Connecting Copilot Across App, CLI, Cloud Agent and VS Code

One of the most important aspects of this update is that the same pull request lifecycle is appearing across several GitHub surfaces. The Copilot app can respond to reviews and failing checks. Copilot CLI exposes /pr commands for the full workflow. Copilot cloud agent can resolve conflicts directly from GitHub. VS Code now adds Agent Merge. The pieces are converging around one idea: Copilot should be able to participate wherever the pull request is being worked on.

The Upgrade Feeling

Agent Merge is a strong example of coding agents moving from code creation into software delivery. GitHub is giving Copilot a larger role after the first implementation is done: read the pull request, respond to review feedback, work through failing checks, resolve merge conflicts, and keep moving toward merge-ready status. For developers, that means the agent is becoming less like an autocomplete layer and more like a collaborator that can stay with a change through the final stages of the pull request.

Muse Spark 1.3 Pushes Meta Deeper Into Agentic Coding

Meta introduced Muse Spark 1.3 on September 2, 2026 as the newest step in its Muse model family. The release is aimed directly at developers building coding agents and AI-assisted development workflows. Meta says the model is trained for long-horizon agentic work, meaning it is designed to keep context across a larger task, remember prior results, and continue through multiple stages instead of treating every turn as an isolated request.

Long-Horizon Work Is the Main Theme

The clearest idea behind Muse Spark 1.3 is continuity. Meta says the model tracks context and prior results while working through messy or conflicting inputs. That matters for software work because real development tasks often span many files, tools and decisions. An agent may need to understand an existing codebase, make a plan, change several components, validate what happened, and then continue from the new state. Muse Spark 1.3 is tuned around that longer execution loop.

The Model Is Tuned for Coding Agents

Meta describes Muse Spark 1.3 as tuned for long-horizon coding workflows with fewer unnecessary turns and cleaner output. The company positions it both for developers building coding agents and for people using AI as a development partner. That makes the model relevant beyond code completion. The target is a system that can participate in a larger engineering task where planning, context retention and tool use matter as much as generating individual snippets.

Muse Spark 1.3 Can Perceive Images, Video and Documents

One of the strongest parts of the release is native multimodal perception. Meta says Muse Spark 1.3 can perceive video, images and documents. A developer can give it a screenshot or a clip and ask it to build from what it sees. That creates a practical connection between visual inputs and software generation, especially for interface work, prototypes and workflows where the source material is not already available as clean text.

Visual Reasoning Runs Through a Real Execution Environment

Meta also says the model’s visual reasoning runs through a real execution environment rather than a scripted sequence. The important point is that perception is connected to action. Muse Spark can interpret a visual input and then use that understanding inside a development workflow. For example, a screenshot can become an input to a coding task rather than something that has to be manually translated into a written specification first.

Muse Code Turns the Model Into a Terminal Workflow

Muse Code is the terminal coding experience built around Muse Spark. Meta says multiple agents can coordinate on every task. Instead of one agent handling every part of a project sequentially, Muse Code can distribute work across several agents and bring their results together. This is a useful model for development because many software tasks naturally break into parallel pieces such as implementation, testing, documentation and review.

Multi-Agent Orchestration Is a Core Part of the Stack

Meta has been building multi-agent orchestration into the Muse family from the beginning. The original Muse Spark release introduced parallel-agent reasoning, and the current developer stack makes that idea practical for coding. Meta’s quickstarts include a four-profile agentic team that can turn a one-line product idea into a working SaaS application. That shows where the company wants the workflow to go: one objective can fan out into coordinated specialist tasks.

Agent Fan-Out Can Work in Parallel

Meta also provides an agent fan-out pattern where multiple subagents can work in isolated worktrees. This lets different agents tackle parts of the same software project without stepping on one another’s changes while they are working. For larger coding systems, that architecture is useful because it turns parallelism into a first-class part of the workflow rather than requiring every task to wait for the previous one to finish.

Computer Use Connects the Agent to Real Interfaces

The Meta developer stack also includes a computer-use path for Muse Spark. Meta describes this as giving the model eyes and hands so it can build software the way a person does. For developers, that means an agent can potentially move beyond code generation and interact with interfaces involved in the development process. Combined with multimodal perception, this gives Muse Spark a broader working surface than a text-only coding assistant.

A GitHub Agent Is One of Meta’s Reference Workflows

Meta includes a GitHub agent among its official quickstarts, using Muse Spark with OpenCode on the Meta Model API. This is a good example of the model being positioned as infrastructure for autonomous developer tools. GitHub is where code, issues, pull requests and project history come together, so an agent operating there can participate in a workflow that is much closer to real software engineering than a standalone chat window.

Muse Code Covers Game, Web and Multimodal Development

Meta highlights game development, web development and multimodal visual coding as Muse Code examples. These categories show how broad the intended use is. The same model can work on a conventional software project, use visual material as part of the build process, or support interactive experiences. That range is important because long-horizon agents become more useful when they can move between code, visuals and application behavior without changing systems.

The Meta Model API Makes Muse Spark Available to Builders

Muse Spark is also available through the Meta Model API, giving developers a direct way to put the model inside their own products and workflows. Meta says developers can point an OpenAI SDK-compatible client at the Meta Model API for a quick start. That lowers the amount of plumbing needed to test the model in an existing agent stack, especially for teams already using OpenAI-compatible interfaces in their tooling.

Public Preview Expands Access to the Developer Stack

Meta currently presents Muse Spark on Muse Code and the Meta Model API as a public preview with expanded global access. That makes the release more than a research showcase. Developers can start experimenting with the model, terminal agent experience and API workflows now. The combination gives Meta both a model layer and a developer-facing execution layer, which is becoming an important pattern across modern AI coding products.

Muse Spark Started as a Native Multimodal Reasoning Model

The broader Muse Spark family was introduced in April 2026 as Meta’s first model family from Meta Superintelligence Labs. From the start, Meta described Muse Spark as natively multimodal with tool use, visual reasoning and multi-agent orchestration. Muse Spark 1.3 builds on that foundation with a more explicit emphasis on coding and long-horizon agentic workflows. The progression shows the model family moving from general multimodal reasoning toward more concrete developer execution.

Coding and Multimodality Are Converging

One of the most interesting patterns in Muse Spark 1.3 is the way coding and multimodal perception are being combined. A developer agent no longer has to receive every requirement as text. It can inspect a screenshot, video or document, understand what it contains, and use that information while building. That opens the door to workflows where design references, product demos, diagrams and existing interfaces become direct inputs to software creation.

The Agent Is Becoming the Workflow, Not Just the Assistant

Traditional coding assistants sit beside the developer and respond when asked. Muse Spark 1.3 is aimed at something broader: an agent that can keep working across a longer objective, coordinate with other agents, use a computer, inspect visual material and interact with developer systems. The change is not only about model intelligence. It is about giving the model a larger execution loop and more places where it can act.

Meta Is Building a Full Developer Surface Around Muse

Meta is pairing Muse Spark with Muse Code, the Meta Model API, quickstarts for multi-agent orchestration, agent fan-out, computer use and GitHub automation. Taken together, these pieces form a developer surface rather than a single model endpoint. That is important because the practical value of an agent often depends on the environment around it: the tools it can call, the context it can retain, and the workflows it can participate in.

The Upgrade Feeling

Muse Spark 1.3 is a strong example of where AI coding is heading next. Meta is not limiting the model to text generation or short code suggestions. It is building around long-horizon execution, multimodal perception, multiple cooperating agents and direct integration with developer tools. For builders, the most interesting part is the combination: one model that can see visual inputs, keep track of a longer job, coordinate work and operate through a developer-focused stack.

Claude Fable 5.1 Is Designed for Work That Keeps Going

Anthropic introduced Claude Fable 5.1 on September 1, 2026 as its most capable generally available model for coding and knowledge work. The most important shift is not simply a new model number. Anthropic is positioning Fable 5.1 for work that can continue for hours, move between applications, use tools, recover from failed steps, and keep progressing without constant supervision. That makes the release especially relevant to developers and teams building agentic workflows rather than using AI only for one prompt at a time.

The Model Is Built for Hours-Long Agent Jobs

Anthropic describes Fable 5.1 as a model for ambitious, long-running projects. In its agent examples, the company points to working through a backlog in Claude Cowork, picking up requests from Slack through Claude Tag, operating a browser, and running unattended as a managed agent on the Claude Platform. The common idea is continuity. Instead of completing one isolated answer, the model can plan a larger job, select tools, move through stages, and keep working until the task is ready for review.

Planning and Recovery Are Part of the Workflow

A long-running agent needs more than strong text generation. Anthropic says Fable 5.1 can plan the work, use the tools it needs, recover when a step fails, and keep the user updated as it goes. That combination matters because real projects rarely follow a perfect straight line. A coding task may require reading documentation, changing files, running tests, revisiting an earlier assumption, and checking the final result. Fable 5.1 is being presented as a model designed to stay coherent across that whole sequence.

Claude Cowork Gives the Model a Broader Work Surface

Anthropic specifically highlights Claude Cowork as one place where Fable 5.1 can take on extended work. Cowork is designed around delegating larger projects rather than treating every interaction as a short chat. With Fable 5.1, that model of work becomes more ambitious: a user can hand over a backlog or multi-stage assignment and review the result after the model has worked through the steps. The practical change is that Claude is moving closer to a project worker that can carry context across a longer job.

Claude Tag Extends That Agent Model Into Slack

Claude Tag adds another surface. Anthropic launched Claude Tag in Slack so teams can bring Claude into selected channels, connect it to tools and data, and delegate tasks by tagging @Claude. The company says Claude can break work into stages, operate asynchronously, and return with what it created. Fable 5.1 is now explicitly positioned for this kind of cross-application work, which connects model capability with a place where teams already coordinate projects.

Browser Work Makes the Agent More General

Anthropic also lists browser operation as a Fable 5.1 use case. That matters because many real tasks are not contained inside one code editor or one document. Research, dashboards, internal tools, forms, web applications, and cloud services often live in a browser. A model that can keep a plan while moving through browser-based steps can cover a much wider range of workflows than a model limited to generating text or code in isolation.

Managed Agents Bring the Same Idea to the Claude Platform

For developers building their own products and internal systems, Anthropic points to managed agents on the Claude Platform. The idea is to let a long-running Claude process execute programmatically rather than only through Claude’s consumer interfaces. This gives teams a way to build workflows where the model can receive a larger objective, use connected tools, and continue working in the background of an application until it has completed the job.

Coding Is One of Fable 5.1’s Main Targets

Anthropic calls Fable 5.1 its most capable model for ambitious coding projects. The company highlights features that span an entire codebase, code review, performance work, and multi-day autonomous sessions. These are very different from small code-completion tasks. They require the model to understand relationships between files, keep track of design choices, make coordinated edits, and verify that the system still works after those edits.

The Model Can Write Tests to Check Its Own Work

One of the more practical details in Anthropic’s description is that Fable 5.1 can write its own tests to verify its work. That gives the agent a feedback loop. Instead of only generating a change and stopping, it can create a test, run it, inspect the result, and continue adjusting the implementation. For developers, that is a more useful pattern than treating the model as a code generator because it brings verification into the same workflow.

Vision Is Used as Part of Coding Verification

Fable 5.1 also uses vision to check outputs against a design or goal. Anthropic says the model can implement designs with high fidelity and use visual understanding to evaluate what it produced. That creates an interesting bridge between coding and interface work. A model can change the code, render the result, visually inspect the output, and compare it with the intended design rather than relying only on source code and test output.

Document-Heavy Work Is Another Major Use Case

The model is not limited to software engineering. Anthropic says Fable 5.1 can understand diagrams, charts, and tables nested inside files and PDFs. That broadens the model’s usefulness for long-form research, analysis, and document-heavy projects. A complex assignment can combine prose, structured information, visual material, and multiple files while remaining inside the same working context.

Enterprise Workflows Move Toward Delegation

Anthropic describes Fable 5.1 as capable of handling complex, multi-stage knowledge work with minimal oversight. The intended workflow is clear: teams can hand over a large project, allow Claude to work through the steps, and then review a finished deliverable. That is a different relationship from supervising every prompt. The model is being designed around delegation, where the human sets the objective and the AI handles more of the execution path.

The Cost Change Is Especially Important for Agents

Long-running agents can reuse the same context many times. That makes prompt caching important because the agent may repeatedly reference a large codebase, instructions, documents, or project state. Anthropic cut Fable 5.1 cache-read pricing to $0.25 per million tokens, which the company says is 75% lower than Fable 5. This directly targets the economics of workflows that keep the same context active while performing many steps.

Anthropic Estimates About 25% Lower Cost for Typical Workloads

According to Anthropic, the cheaper cache reads reduce the cost of typical Fable 5.1 workloads by an estimated 25%. The base model price remains $10 per million input tokens and $50 per million output tokens, so the major efficiency change comes from how much cheaper it is to read previously cached context. For workflows that repeatedly reuse large prompts or project state, that can change the total cost of a long session more than a simple headline token price suggests.

Highly Agentic Workloads Can See a Bigger Difference

Anthropic says highly agentic workloads can cost up to approximately 45% less because of the new cache-read pricing. That is the number that makes this release especially interesting for developers building agents. The more a workflow plans, calls tools, revisits context, and continues through multiple stages, the more valuable inexpensive cache reads can become. The release therefore pairs stronger long-running behavior with a pricing change aimed at the exact workloads that use it most.

The API Model ID Is Ready for Developers

Fable 5.1 is available through the Claude API using the model ID claude-fable-5-1. Anthropic also lists availability through its platform marketplaces and across Amazon Web Services, Google Cloud, and Microsoft Foundry. That means the model is not only a Claude.ai feature. Developers can bring the same model into applications, coding systems, internal tools, and agent architectures built around the Claude Platform.

Availability Covers Claude’s Main Paid Workflows

For individuals and organizations, Anthropic says Fable 5.1 is available to Pro, Max, Team, and Enterprise users. The model is also positioned across Claude Code and Cowork workflows. This broad availability matters because Anthropic is not presenting Fable 5.1 as a research preview. It is meant to be used now for production-oriented coding and knowledge work where longer execution and stronger tool use are valuable.

The Bigger Shift Is From Chat Sessions to Ongoing Work

The most interesting part of Fable 5.1 is the shape of the product around it. Claude can now appear in a coding environment, a collaborative workspace, Slack, a browser, or a managed-agent workflow. Across those surfaces, the model is being asked to preserve a plan and continue working rather than waiting for a new prompt after every step. That moves AI interaction away from a sequence of isolated conversations and toward ongoing execution.

The Upgrade Feeling

Claude Fable 5.1 looks like an important step in Anthropic’s push toward AI that can own more of a project from start to finish. The model is built for hours-long work, codebase-wide changes, browser tasks, team workflows, and managed agents. At the same time, Anthropic has made repeated access to cached context much cheaper, with estimated savings of around 25% for typical workloads and up to roughly 45% for highly agentic ones. The combination is what makes this release stand out: stronger long-running execution paired with a cost structure designed for agents that keep working.

Zoho’s Catalyst 3.0 is built around a problem that appears after AI has already generated the application: someone still has to create the database, wire authentication, provision compute, deploy services, inspect logs, manage permissions and promote the finished system into production. Catalyst now combines Agent Skills, a Dynamic MCP server and a non-interactive CLI so coding agents such as Claude Code and Codex can operate the cloud platform from inside the coding workflow. The more interesting design choice is the guardrail: agents can work in development, but Zoho says production promotion remains a manual human action.

AI Solved the First Half of Vibe Coding Faster Than the Second

Vibe coding made application creation feel deceptively complete.

Describe the interface. Ask for a database-backed feature. Generate the API route. Fix the error. Refresh the page.

A working prototype can appear in hours.

Then the application leaves the prompt window.

It needs authentication, persistent data, secrets, storage, functions, background jobs, hosting, logs, permissions and a production environment.

The developer discovers that writing the code was only one layer of shipping software.

This is the problem Zoho is targeting with Catalyst 3.0. The September 2 release is less interesting as another AI coding feature than as an attempt to make the cloud itself understandable and operable by the coding agent.

Catalyst 3.0 Is a Cloud Platform, Not a New Coding Model

Catalyst is Zoho’s Platform-as-a-Service.

It provides managed application infrastructure rather than a model that competes with Claude, GPT or Gemini.

Catalyst 3.0 adds an agent-facing layer on top of that platform. Zoho’s current documentation describes integrations for coding agents including Claude Code, Codex and GitHub Copilot through its AI Plugin, while the broader Catalyst 3.0 page also lists tools such as Cursor and Gemini.

The design is intentionally model-agnostic.

Your coding agent generates and modifies the application. Catalyst supplies the application services and exposes platform actions the agent can invoke.

That separation matters. The model remains replaceable. The infrastructure becomes the persistent execution environment.

The Next Vibe-Coding Bottleneck Is Infrastructure Context

A coding model can know what a database is and still use a specific cloud platform incorrectly.

Every platform has its own naming, service boundaries, deployment rules, SDK initialization patterns, authentication conventions, CLI and production restrictions.

Without current platform context, an agent may generate code that is generally reasonable but wrong for the actual environment.

This is similar to the documentation problem in ordinary AI coding, except the consequences extend beyond code. A mistaken infrastructure action can create the wrong resource, deploy the wrong component or configure the wrong service.

Catalyst 3.0 tries to reduce that gap by teaching the agent the platform and giving it controlled ways to act on it.

Agent Skills Tell the Model How Catalyst Is Supposed to Be Used

The first layer is Agent Skills.

Catalyst’s current Plugin documentation lists 15 Product Skill Files and four AI Architect Skill Files.

The product skills cover platform-specific areas including functions, AppSail, Slate hosting, authentication, Data Store, NoSQL, cache, Stratus object storage, Signals, browser automation, Zia services, MCP, SDK usage and pricing.

Instead of expecting the model to infer the correct Catalyst architecture from general training knowledge, a skill gives it an explicit implementation playbook.

That moves some decision-making out of probabilistic memory and into maintained platform instructions.

For vibe coding, that can be more important than a larger model. A smaller model with the right current instructions can sometimes make a better platform decision than a stronger model guessing from stale context.

The Four Architect Skills Solve a Different Problem

Product skills explain individual services. Architecture requires choosing between them.

Should this workload be a serverless function or an AppSail service? Should data live in the relational store or NoSQL? Does the application need object storage? How should authentication be wired?

The four AI Architect Skill Files are intended to feed popular coding agents with platform context in an optimized form.

This is a useful distinction. A cloud agent needs both vocabulary and judgment.

Knowing every available service does not automatically tell the model which service belongs in the design. Catalyst’s orchestration layer is attempting to narrow that decision space before the agent starts creating infrastructure.

MCP Gives the Agent Hands, Not Just Documentation

Skills can tell the model what to do. Model Context Protocol gives it a way to do it.

Zoho’s Catalyst MCP server exposes platform operations to compatible AI clients.

The release gives simple examples such as creating a database table or adding a column directly from the developer’s coding environment instead of opening the Catalyst console.

That changes the role of the coding assistant. It is no longer only producing commands for the human to copy. The agent can be authorized to execute supported infrastructure operations itself.

The convenience is obvious. The risk is also obvious.

Once a coding model can change cloud state, permissions and environment separation become part of the AI system design.

Catalyst Uses Dynamic MCP Instead of Loading Every Tool at Once

Catalyst currently documents more than 100 MCP tools.

Loading every tool definition into every coding session would be wasteful. It could also make tool selection harder.

Zoho’s Dynamic MCP server uses tool discovery. When a prompt requires an action, the model queries the server directory and only the tools needed for that operation are loaded and enabled.

Zoho argues that this reduces tool overload and unnecessary hallucination while also reducing manual MCP configuration.

The broader design idea is worth watching beyond Catalyst.

As agent toolboxes grow, tool discovery may become as important as tool execution. An agent with 500 tools does not necessarily need 500 schemas in context. It needs a reliable way to find five.

The Dynamic Server Is Also a Context-Efficiency Strategy

Tool schemas consume context. Large tool descriptions consume more.

If an agent session carries dozens or hundreds of tool definitions that will never be called, part of the model’s working context is spent describing capabilities irrelevant to the current task.

Dynamic discovery turns that into an on-demand problem.

A prompt about a data table should surface data tools. A deployment prompt should surface deployment tools. A storage task should surface storage operations.

Zoho positions this as a way to optimize token use.

The company’s exact efficiency claims should be treated as product claims rather than universal guarantees. But the architectural direction is sensible: agent infrastructure needs context management, not only API access.

The Non-Interactive CLI Solves a Very Old Automation Problem

Command-line tools were built for humans long before coding agents became common.

A normal CLI often pauses: select an organization, choose a project, confirm a runtime, answer yes or no, pick a component.

Those prompts are friendly when a person is sitting at the terminal. They are friction when an agent is trying to execute a multi-step workflow autonomously.

Catalyst’s non-interactive mode lets required answers be supplied through flags, environment variables or programmatic arguments.

If required information is still missing, the command exits with an error instead of waiting indefinitely for human input.

That small change makes ordinary CLI operations much more agent-compatible.

Non-Interactive Does Not Mean Unrestricted

Removing interactive prompts could sound like removing safety.

Zoho documents the opposite intention.

Its Agent Skills page says destructive commands are disabled in non-interactive mode. The agent can also operate with its own scoped collaborator permissions.

That means autonomy is not supposed to come from giving the model an administrator account and telling it to be careful.

The intended model is narrower: give the agent only the permissions it needs, prevent some destructive paths entirely, log what it does and keep production separated.

This is much closer to how automation should be designed for a probabilistic actor.

The Orchestration Layer Decides Between CLI and MCP

Catalyst exposes more than one execution mechanism. Some operations fit the CLI. Others fit MCP.

Leaving that choice entirely to the language model creates another place for inconsistent behavior.

Zoho says orchestration is built into the Skill so the coding assistant can be routed deterministically down a CLI or MCP path.

The word deterministic should be interpreted carefully. The model is still interpreting the user’s request and the surrounding workflow is still agentic.

What Zoho is making deterministic is the platform-routing logic once a particular implementation path is selected.

That reduces one category of model improvisation. It does not turn the entire development process into deterministic software.

The Cloud Becomes Part of the Coding Conversation

Traditional development separates several interfaces.

The editor contains code. The terminal contains deployment commands. The cloud console contains infrastructure. The monitoring console contains logs. The database console contains tables.

The developer jumps between them and mentally keeps the state synchronized.

Catalyst 3.0 is trying to collapse more of those operations into the agent conversation.

A developer can ask for a feature. The coding agent can write the code. The skill can recommend the relevant Catalyst service. MCP can create supporting resources. The CLI can perform supported project operations.

The result is a more continuous prompt-to-infrastructure workflow.

But Zoho Draws a Hard Line Before Production

The strongest design decision in Catalyst 3.0 may be what the agent is not allowed to do.

Zoho says development and production environments are decoupled. Code moves to production through manual promotion only.

Its Agent Skills page states the rule even more directly: the agent never touches production.

That is significant.

The goal is not maximum autonomy. The goal is bounded autonomy.

An agent can build, configure development resources, deploy and test within the development workflow. But the final transition to the environment used by real users remains a human-controlled step.

That one boundary changes the risk model substantially.

Catalyst’s Existing Environment Model Makes That Guardrail Concrete

The production restriction is not only marketing language around AI.

Catalyst already has separate Development and Production environments.

The documentation says new projects begin in Development. Resource creation, configuration, testing, CLI actions and API-driven changes are reflected there. Changes do not appear in the live application until they are deployed to Production.

The production environment also restricts many direct modifications. For example, the documentation says new functions or Signals rules generally cannot simply be created directly in Production.

The agent guardrail therefore builds on an environment model that already existed. AI is being inserted into the safer side of that boundary rather than redefining the boundary around AI.

Manual Promotion Is Slower Than Full Autonomy — That Is the Point

A fully autonomous demo is more impressive.

Tell the agent to build an app. Watch it create resources. Watch it deploy publicly. Open the URL. Done.

That is also the workflow with the largest blast radius.

A production deployment can expose bad code to users. A schema change can affect live data. A misconfigured permission can become a security issue. A runaway resource can become a cost problem.

Manual promotion introduces friction exactly where friction is useful.

The developer has a natural checkpoint to inspect what the agent created before real users inherit it.

For production software, removing every click is not necessarily progress.

Scoped Permissions Matter More Once the Agent Can Change Infrastructure

Coding assistants already operate with filesystem and shell permissions. Cloud access raises the stakes.

A scoped collaborator model lets an organization treat an agent more like a constrained service identity than a trusted human administrator.

Catalyst documents detailed project profiles and permissions for development and production capabilities. Permissions can govern access to data stores, logs, settings, migrations and other components.

The exact safe configuration will depend on the application.

The principle is broader: AI agents should receive capabilities according to the task, not according to convenience.

If an agent only needs to create development tables, it should not automatically receive authority over billing or production migration.

Audit Logs Turn Agent Actions Into Reviewable Events

Agentic development creates a provenance problem.

When something changes, who changed it? The developer? A script? The coding agent? Which tool did it call? When?

Catalyst’s governance story includes application logs, platform logs and MCP tool-call logs. Zoho says these records can be used to reconstruct what an agent did and when.

The existing Audit Logs system also records configuration events such as adding a Data Store column, changing an event rule or deleting a cron job.

This matters because conversational interfaces can otherwise hide operational detail.

A natural-language prompt is not a sufficient audit record for the side effects that followed.

Reversible Changes Are an Antidote to Confident Agent Mistakes

AI agents often fail with confidence.

A tool call can be syntactically valid and still be the wrong operational decision.

Zoho says changes after launch are versioned, attributable and reversible.

That is the correct direction for agent-controlled infrastructure.

If the system assumes mistakes will eventually occur, rollback becomes a first-class capability.

The same philosophy already exists in source control. We do not trust every code edit simply because it compiled. We preserve history.

Agent infrastructure needs the same mentality. Autonomy becomes safer when actions leave evidence and can be undone.

The Benchmark Says Skills and MCP Help — but It Is Zoho’s Benchmark

Zoho publishes a task-completion comparison for three models on the Catalyst 3.0 page.

In the company’s test, completion without Catalyst Skills ranged from 25% to 55%. With Skills plus Zoho MCP, the reported completion rates were 90%, 92% and 95% depending on the model.

The table also reports fewer human interventions and, in several cases, fewer retries or tool calls.

That is an encouraging result. It is not independent validation.

Zoho is testing its own platform, skills and tool layer. The public page does not establish that every real-world application will see the same improvement.

The useful conclusion is narrower: in Zoho’s own evaluated tasks, supplying platform-specific skills and tools made the tested agents much more successful at completing Catalyst workflows.

The Benchmark Also Shows Why Bigger Models Are Not the Whole Answer

The interesting pattern in Zoho’s table is not which model wins.

All three reported models improve sharply when given the Catalyst-specific context and tools.

That supports a broader lesson in agent engineering.

Capability is not only model intelligence. It is model plus instructions plus tools plus permissions plus environment.

A coding model can be excellent at reasoning and still fail because it does not know the platform’s exact workflow.

Giving it a current skill file and the right API may create a larger practical improvement than switching to a slightly stronger model.

Vibe coding is gradually becoming systems engineering around the model.

Catalyst 3.0 Is Trying to Productize the Agent Harness

A serious coding agent needs more than an LLM.

It needs context, tool discovery, execution, authentication, permissions, logging, recovery and environment boundaries.

Developers can build that harness themselves. Many teams already do.

Catalyst 3.0 packages a version of that harness around one cloud platform.

The Agent Skills provide platform context. Dynamic MCP provides discoverable actions. The non-interactive CLI provides automation-friendly commands. The cloud supplies managed services. The production boundary supplies a human checkpoint.

This is why the release matters beyond Zoho.

Cloud platforms are beginning to redesign themselves around agents as first-class operators.

This Is Different From Infrastructure-as-Code

Infrastructure-as-code already lets developers describe cloud resources in version-controlled files.

Catalyst 3.0 does not make that idea obsolete.

The agent-ready approach attacks a different layer of friction.

Instead of requiring the developer to know the provider syntax and construct every resource declaration directly, the coding agent can translate application intent into supported platform operations.

The danger is obvious. Generated infrastructure can become harder to understand than generated application code.

That makes exportability, logging and review important.

A convenient agent interface should not become an excuse to stop knowing what infrastructure exists.

A Full-Stack Platform Reduces Integration Work by Reducing Choice

Catalyst includes frontend hosting, serverless functions, compute, authentication, relational and NoSQL data, storage, events and other managed services.

Putting those services together reduces the number of providers an agent has to understand. That can make orchestration easier.

It also creates platform dependence.

A system built deeply around one provider’s authentication, data services, event model and deployment workflow is not automatically portable to another cloud.

This is not unique to Zoho. It is the trade-off of integrated PaaS platforms in general.

Vibe coders should understand the bargain: you exchange some infrastructure flexibility for a smaller operational surface and a more opinionated development path.

The Platform Still Cannot Decide What Your Production Architecture Should Be

Agent Skills can recommend Catalyst patterns. They cannot understand every business constraint automatically.

A production architecture still depends on data sensitivity, latency, availability requirements, regulatory obligations, traffic shape, recovery objectives, cost, team capability and external dependencies.

A vibe-coded prototype may work perfectly on one service arrangement and still need architectural changes as usage grows.

Catalyst can reduce plumbing. It cannot remove architecture as a discipline.

The agent can propose the system. The developer still needs to know what promises the system must keep.

Cloud Cost Is Another Place Where Agent Autonomy Needs Limits

Infrastructure actions can create financial side effects.

Provision more resources. Increase storage. Invoke more functions. Move more data.

Those decisions can change a cloud bill.

Catalyst uses a pay-as-you-go model and documents budget alerts and ceilings.

That fits the same bounded-autonomy pattern as manual production promotion.

An agent should not only be limited by what it is technically allowed to create. The environment should also expose economic guardrails.

Vibe coding makes resource creation easier. That makes cost visibility more important, not less.

What Zoho Has Actually Shipped

Zoho announced Catalyst 3.0 on September 2, 2026 and says it is available for immediate use.

The current AI Plugin documentation lists a Dynamic MCP Server, 15 Product Skill Files and four AI Architect Skill Files.

Catalyst’s Dynamic MCP documentation says the service exposes more than 100 MCP tools through on-demand discovery.

The non-interactive CLI supports agent-friendly command execution without waiting for interactive prompts.

The platform documents separate development and production environments.

Zoho says production promotion remains manual and that agents do not directly touch production.

The company also documents scoped permissions, audit logging and production restrictions.

And Zoho publishes a vendor benchmark showing 90–95% task completion for three tested models when Catalyst Skills and MCP were added to its evaluation.

What We Should Not Claim Yet

We should not claim Catalyst makes arbitrary AI-generated code production-ready automatically.

We should not claim Dynamic MCP eliminates hallucinations.

We should not claim the 90–95% completion figures will reproduce across every application or coding agent.

We should not call Zoho’s benchmark independent.

We should not say a non-interactive CLI is equivalent to fully autonomous deployment.

We should not claim the agent can freely modify production; Zoho’s current positioning says the opposite.

And we should not claim using one full-stack platform removes the need for architecture, security review, testing, monitoring or cost management.

The Better Vibe-Coding Stack Has a Human Gate at the End

There is a temptation to judge agentic development by how little the human has to do.

Zero clicks. Zero confirmation. Zero review.

That may be the wrong metric.

A useful coding agent should remove repetitive implementation work. A useful platform should make the agent capable of operating the development environment. A safe production workflow should still know when to stop.

Catalyst 3.0’s most interesting idea is not that an AI can create a database table from Claude Code. Many platforms will eventually support that.

The more important idea is the boundary around the capability.

Give the agent platform knowledge. Give it tools. Give it a non-interactive automation path. Give it scoped permissions. Record its actions. Let it build aggressively in development. Then make a human decide when that work becomes production.

Maybe mature vibe coding is not unlimited autonomy. Maybe it is knowing exactly where autonomy should end.

AI coding agents are good at reading files, but large software systems are defined by relationships between files: calls, imports, inheritance, API consumers, execution flows and cross-repository dependencies. GitNexus indexes a codebase into a precomputed knowledge graph and exposes that structure to agents such as Claude Code, Cursor, Codex and Windsurf through MCP. The interesting idea is not another coding model. It is giving the model a structural map before it edits. GitNexus can surface callers, trace execution paths, estimate blast radius and map a git diff to affected flows — potentially reducing the amount of blind exploration an agent has to do as a vibe-coded project grows.

Vibe Coding Works Best Before the Codebase Has a Memory

A small project is unusually friendly to AI coding.

There may be ten files.

A route is easy to find.

A component imports one service.

A database helper lives in an obvious folder.

If an agent needs context, it can open a few files and reconstruct the system quickly.

That changes as the project grows.

A function that looks local may be called from twelve places.

A type change may affect an API handler, a background job and a test helper.

One frontend component may depend on a response shape that is produced three services away.

The codebase develops memory.

Relationships accumulate faster than any one file can explain them.

That is where vibe coding starts becoming dangerous.

The model can still write code.

The harder problem is knowing what the edit is connected to.

The File Tree Is Not the Architecture

Most coding agents begin with a filesystem.

Folders.

Files.

Names.

Search results.

That is useful, but architecture is not a directory listing.

The important questions are relational.

Who calls this function?

Which implementation satisfies this interface?

What endpoint returns the field this component reads?

Which services depend on this package?

What execution path reaches this database write?

Those answers may cross many files and repositories.

A file tree tells the agent where code lives.

It does not automatically tell the agent how the system behaves.

GitNexus is built around that distinction.

Its core idea is to index the relationships before the agent needs them.

GitNexus Is Not Another Coding Model

GitNexus does not replace Claude Code, Cursor, Codex, Windsurf or another coding agent.

It acts as context infrastructure around them.

The project indexes a repository into a graph containing software entities and the relationships between them.

Functions become nodes.

Classes become nodes.

Files become nodes.

Calls, imports, inheritance and other relationships become edges.

The resulting graph can then be queried through Model Context Protocol tools.

That means the coding model does not need to be retrained to understand one specific repository.

Instead, it receives structured answers about the repository at the moment it needs them.

For a vibe coder, that is a useful architectural pattern.

Keep the agent you already like.

Improve what the agent knows before it edits.

The Index Is Built Before the Prompt Arrives

The most important implementation choice is precomputation.

GitNexus does not wait for every agent request and then ask the model to explore the repository from scratch.

Its current documentation describes a multi-stage indexing pipeline.

It walks the repository structure.

It parses source code with Tree-sitter.

It extracts functions, classes, methods and interfaces.

It resolves imports and call relationships.

It groups related symbols into functional clusters.

It traces execution processes.

It builds search indexes.

The work is done ahead of the coding task.

When the agent later asks what depends on a symbol, much of the structural analysis has already happened.

That turns repository understanding from repeated exploration into reusable infrastructure.

Tree-Sitter Turns Source Files Into Syntax the Graph Can Reason About

Text search sees characters.

A parser sees structure.

GitNexus uses Tree-sitter parsers to extract language constructs from source code.

That lets it distinguish a function declaration from a string containing the same text.

It can identify classes, methods, interfaces and imports rather than treating every match as equivalent.

This matters because software relationships are defined by syntax and semantics, not simply by word similarity.

If an agent searches for “save,” it may find hundreds of unrelated text matches.

If a graph knows that one save method is called by a particular service method, the answer becomes much more specific.

Parsing is therefore the first step from code search toward code intelligence.

Resolution Is Where a Code Graph Becomes More Useful Than a Diagram

A graph is only useful if its edges mean something.

GitNexus says it resolves imports, function calls, inheritance, constructor inference and receiver types across files using language-aware logic.

Its current documentation gives a chained example such as user.address.getCity().save(), where the system attempts to resolve the receiver at each hop.

That is much more useful than drawing boxes around files.

The agent can ask about a symbol and receive callers or downstream relationships.

The graph becomes executable context.

But the word “resolve” also needs a limit.

Static analysis can be highly reliable when relationships are explicit.

Runtime reflection, dynamically generated code, unusual metaprogramming and some dynamic imports can still make static resolution incomplete.

Deterministic analysis does not mean omniscience.

GitNexus Tries to Discover Modules Instead of Trusting Folder Names

Large repositories are often organized imperfectly.

A folder named utils may contain authentication logic.

Billing code may span several packages.

A feature may have grown across layers over years.

GitNexus applies Leiden community detection to the relationship graph to group symbols into functional clusters.

The idea is that strongly connected symbols may reveal a real subsystem even when the repository structure does not describe it cleanly.

That can help an agent understand that a change belongs to an authentication flow or ingestion pipeline rather than merely to one folder.

This is an inferred architectural view.

It is not the same as a human-written architecture document.

But for an undocumented or fast-growing vibe-coded project, discovering communities from actual code relationships can be valuable.

The Most Useful Question May Be: What Breaks If I Change This?

Vibe coding often optimizes for the first edit.

Change the function.

Refresh the page.

If it works, continue.

The risk appears later when the same function has hidden dependents.

GitNexus exposes an impact-analysis tool designed around blast radius.

Given a symbol, it can trace downstream or upstream dependencies by depth and attach confidence to the relationships it returns.

That changes the workflow.

Before editing a shared service, the agent can ask what depends on it.

Before changing a return type, it can identify consumers.

Before renaming a symbol, it can inspect where the graph expects that symbol to participate.

The goal is not to predict every bug.

It is to turn dependency awareness into a normal pre-edit step.

detect_changes Moves Impact Analysis From a Symbol to a Git Diff

The current GitNexus CLI and MCP documentation includes a detect_changes tool.

Instead of starting with one manually selected function, the tool maps changed lines in the git diff to affected processes and graph entities.

That is interesting because real edits rarely touch exactly one symbol.

A vibe-coding session may change a component, a schema and an endpoint in one pass.

A diff-aware graph can ask a broader question:

Which execution flows are affected by everything that changed?

That moves the graph closer to review infrastructure.

The agent can inspect the likely blast radius after an edit instead of waiting for a failing test or a user report to reveal the connection.

trace Answers a Different Question: How Are These Two Things Connected?

Impact analysis expands outward.

Tracing tries to find a path.

GitNexus documents a trace tool that finds a directed path between two symbols using call and class-member relationships.

That can be useful when a developer knows the beginning and end of a behavior but not the middle.

A button triggers a request.

The request eventually writes to a database.

Where is the chain?

Without a graph, an agent may search one function, open its caller, follow an import, inspect another file and repeat.

A path query can compress that exploration into one structural answer.

The model still needs source code to understand what each step does.

But it no longer has to discover every step blindly.

The Current Repository Documents 17 MCP Tools

GitNexus exposes its code intelligence through MCP.

The current GitHub README documents 17 tools: 15 per-repository tools and two group-level tools.

They include general tools such as query, context, impact, trace, detect_changes and cypher.

The newer toolset also includes more specific checks such as route_map, shape_check and api_impact.

The public Akon Labs landing page still shows a smaller seven-tool count.

That appears to be a documentation/version mismatch rather than two different fundamental products.

For a fast-moving developer tool, this is worth noting.

The repository is the better source for the current CLI and MCP surface.

The marketing page is better for the broader product positioning.

route_map and shape_check Point Toward a More Practical Kind of Code Intelligence

A graph becomes more useful when it answers developer questions rather than simply exposing graph theory.

The current GitNexus tool list includes route_map, which maps API routes to callers and handlers.

It also includes shape_check, designed to compare API response shapes against the properties consumers access.

Those tools illustrate where code graphs can become useful for vibe coding.

A model may happily change an API response from user.name to user.displayName.

The backend still compiles.

The frontend may not.

A structural tool can surface that consumer relationship before the edit is treated as finished.

The value is not the graph visualization itself.

The value is converting graph relationships into checks that match how software actually breaks.

One Graph Can Span Multiple Repositories

The problem becomes harder when a system is split across repositories.

An API lives in one repo.

A web frontend lives in another.

A mobile app consumes the same endpoint from a third.

A shared schema package may live somewhere else.

Per-repository search creates artificial boundaries.

A breaking API change does not care which Git repository owns the consumer.

Akon Labs positions the managed and enterprise GitNexus system around unified multi-repository graphs.

Cross-repository edges can connect a service to downstream consumers.

For organizations, that may be the feature with the largest potential value.

The blast radius of a change can escape the repository long before it escapes the architecture.

For a Solo Vibe Coder, the Same Problem Arrives Earlier Than Expected

Multi-repo complexity sounds like an enterprise problem.

It is not only an enterprise problem.

A solo project can become structurally large very quickly with AI.

Agents write code faster than traditional manual development.

That means technical debt can also accumulate faster.

A person who would normally add five files in a week can generate fifty.

A prototype can become a product before the original author has built a reliable mental model of the new system.

This is one of the paradoxes of vibe coding.

AI reduces the cost of adding code.

That increases the value of tools that explain the code already added.

GitNexus is interesting because it targets the second half of that equation.

The Basic Local Workflow Is Deliberately Small

The current GitNexus README presents a two-command quick start.

Run gitnexus analyze from the repository.

Then run gitnexus setup.

The first command builds the index and installs agent-context integration.

The second configures MCP for supported coding tools.

The project currently documents integrations with Claude Code, Cursor, Codex, Antigravity, OpenCode, CodeBuddy, Qoder and Windsurf, with different levels of hooks and skills depending on the client.

For Claude Code and Codex, the repository documents deeper hook integration that can add graph context around tool calls and warn when the index becomes stale after repository changes.

The important point is that the graph is designed to sit inside the normal coding workflow rather than require a separate manual analysis session.

Local Indexing Is a Major Part of the Appeal

Source-code context can be sensitive.

A tool that improves coding by uploading the whole repository to another service creates a new trust decision.

GitNexus’s local CLI is designed to build and query the index on the developer’s machine.

The project documentation says local indexing and storage can operate without sending repository data to a remote GitNexus service.

Its browser mode similarly runs the graph in the browser for smaller repositories, while a managed enterprise offering also exists.

Those modes should not be conflated.

A local CLI workflow and a hosted SaaS workflow have different privacy boundaries.

For developers choosing the tool specifically because of local code intelligence, the deployment mode matters as much as the feature list.

The Web UI Is Convenient, but It Has a Different Scale Profile

GitNexus also provides a visual browser interface.

The README describes it as useful for quick exploration, demos and one-off analysis.

The local CLI is the recommended path for daily development and larger repositories.

The browser version uses in-memory WebAssembly storage and is constrained by browser memory, while the CLI uses native persistent storage.

This distinction is useful because the graph visualization is likely what attracts many developers first.

But the practical coding-agent value comes from persistent indexing and MCP access.

The pretty graph is the interface.

The reusable structural context is the infrastructure.

Language Support Is Broad, but Not Every Language Has the Same Depth

The current repository documents support across TypeScript, JavaScript, Python, Java, Kotlin, C#, Go, Rust, PHP, Ruby, Swift, C, C++ and Dart.

The capability matrix is not identical for each language.

Some languages have import resolution, named-binding tracking, inheritance analysis, type annotations, constructor inference and framework detection.

Others support only a subset.

Optional control-flow and program-dependence analysis is currently documented for TypeScript and JavaScript, with other languages planned.

This is another reason to avoid describing GitNexus as universally exact.

The quality of a code graph depends on what the parser and resolver can understand for a particular language and framework.

A TypeScript application may expose more structure than a codebase dominated by dynamic runtime behavior.

Deterministic Is Better Than Similarity for Some Questions — Not All Questions

Akon Labs contrasts GitNexus with embedding-based retrieval.

That comparison is strongest for questions with exact structural answers.

Who imports this module?

Which known callers invoke this function?

Which class implements this interface?

What static path connects these symbols?

Those are graph questions.

Semantic retrieval solves a different problem.

Where is code related to billing?

Which file discusses retry behavior?

What implementation is conceptually similar to this one?

Those may benefit from embeddings.

The current GitNexus query tool itself uses hybrid search that combines lexical and semantic retrieval.

So the useful lesson is not “graphs replace embeddings.”

It is that structural questions should not be answered only by similarity search when the codebase contains explicit relationships that can be resolved.

Akon Labs Reports a Large Benchmark Gain — but It Is Still a Vendor Benchmark

Akon Labs has published a DeepSWE benchmark comparing the same coding-agent setup with GitNexus, with a simpler Graphify extraction layer, and with no retrieval graph.

The benchmark reports 113 tasks across 89 open-source projects and 3,471 trials.

In that setup, GitNexus achieved a 68.37% pass rate.

The bare setup achieved 36.99%.

The company also reports fewer steps, fewer output tokens and lower average cost per trial with GitNexus.

Those results are interesting because the comparison tries to hold the model and agent scaffold constant.

They are not independent validation.

Akon Labs designed and published the benchmark implementation and is evaluating its own product.

The numbers should therefore be described as company-reported benchmark results, not universal proof that every agent becomes nearly twice as capable.

The Often-Repeated “51% Cheaper” Number Needs a Denominator

Product Hunt and Akon Labs describe GitNexus as making coding-agent runs roughly 51% cheaper in their public benchmark.

The detailed benchmark page makes the denominator clearer.

Average cost per trial falls from $0.6631 for the bare model to $0.6008 with GitNexus.

That is about 9.4% lower per attempt.

The much larger saving appears when cost is divided by successfully solved tasks.

Akon Labs reports $0.88 per solved task with GitNexus versus $1.79 for the bare setup.

That is roughly a 51% reduction in cost per successful fix.

Both measurements are legitimate.

They answer different questions.

A careful article should not describe a 9.4% per-run saving as a 51% cheaper run.

The Benchmark Is Also Narrower Than the Product’s Biggest Claim

Akon Labs explicitly acknowledges this limitation.

DeepSWE consists of individual bugs and feature requests in open-source repositories.

That can measure how well an agent navigates an unfamiliar codebase while fixing one issue.

It does not directly test the product’s most ambitious claims.

Cross-repository impact analysis.

Large organizational graphs.

Pre-merge blast-radius checks across services.

Long-lived graph reuse in a production team.

Those require different benchmarks.

In other words, the published evaluation tests the code-reading advantage.

It does not independently establish the full enterprise value proposition.

That does not weaken the benchmark.

It defines what the benchmark can actually support.

There Is an Important Licensing Catch for Commercial Vibe Coders

GitNexus is frequently described on the Akon Labs site and Product Hunt as open source.

The current GitHub repository is publicly accessible and its code can be inspected.

However, the repository license is PolyForm Noncommercial 1.0.0.

That license explicitly limits the granted software rights to noncommercial purposes, with specified exceptions.

That is materially different from permissive licenses such as MIT, Apache-2.0 or BSD.

A developer building a commercial product should not assume that the free repository can be used commercially simply because the source is visible.

Akon Labs also offers commercial enterprise options.

For TUF, the accurate wording is that GitNexus is source-available with a noncommercial license, while the company markets it using the “open source” label.

Commercial users should read the current license or obtain appropriate commercial terms.

A Code Graph Cannot Replace Tests

Knowing the blast radius is not the same as proving the change works.

Static relationships cannot model every runtime behavior.

External services may return unexpected data.

Configuration may change code paths.

Reflection can hide relationships.

Feature flags can alter execution.

A database migration can fail even when the call graph is correct.

A user can click a sequence nobody anticipated.

GitNexus should therefore sit before and beside testing, not replace it.

A better vibe-coding loop would be:

understand the graph,

estimate impact,

make the edit,

run tests,

exercise the interface,

inspect the diff,

then recheck affected flows.

The graph helps the agent ask better questions.

Tests still determine whether the software behaves correctly.

The Best Use Case Is Not Generating More Code

Most AI coding products sell speed.

Generate faster.

Refactor faster.

Ship faster.

GitNexus is more interesting when viewed as a braking system.

Before editing, ask what depends on this.

After editing, ask which flows changed.

Before renaming, inspect callers.

Before changing an API, inspect consumers.

That may add a step to the prompt.

But it can remove much more expensive steps later.

The strongest vibe-coding tools may not be the ones that generate the most code.

They may be the ones that prevent the agent from confidently changing code it does not understand.

What GitNexus Currently Documents

The current public GitNexus repository documents a local indexing pipeline based on Tree-sitter and graph construction.

It documents knowledge-graph entities and relationships for code structure, clustering and execution processes.

It exposes that context through MCP to multiple coding agents.

The repository currently lists 17 MCP tools, including query, context, impact, trace, detect_changes, route_map, shape_check and api_impact.

It documents support across a broad set of programming languages with different levels of analysis depth.

Akon Labs reports multi-repository graph capabilities in its commercial platform.

The company’s DeepSWE benchmark reports a 68.37% pass rate with GitNexus versus 36.99% for the bare setup under its published configuration.

And the current repository is licensed under PolyForm Noncommercial 1.0.0.

What We Should Not Claim Yet

We should not claim GitNexus understands every runtime dependency.

We should not claim static analysis can always resolve dynamic imports, reflection or generated code.

We should not claim the graph replaces tests.

We should not claim the 68.37% benchmark result will reproduce for every model, language or private codebase.

We should not call the vendor benchmark independent validation.

We should not say every GitNexus run is 51% cheaper; the large reduction in the published benchmark is cost per successful solved task, while cost per trial falls by about 9.4%.

We should not say all 17 MCP tools are equally supported by every editor.

And we should not describe the current repository as permissively open source for commercial use.

The license is explicitly noncommercial.

The Bigger Vibe-Coding Upgrade Is Giving the Agent a Model of the System

AI made code generation cheap.

That changes what becomes expensive.

Understanding.

Review.

Dependency tracking.

Regression discovery.

Architecture.

A small vibe-coded project can survive on file search because the developer and the model can still reconstruct the system quickly.

A large one cannot.

At some point, the question stops being “Can the AI write this function?”

The harder question becomes “Does the AI know what this function belongs to?”

GitNexus is one answer to that problem.

It turns a codebase from a pile of files into a queryable relationship map and gives that map to the coding agent through MCP.

The model still writes the code.

The tests still have to pass.

The developer still owns the result.

But the agent no longer has to navigate entirely by guesswork.

That may be one of the most important upgrades for vibe coding as projects stop being prototypes and start becoming software.

The Unit Under Test Is Getting Bigger

A normal software test usually begins with something concrete.

Call a function. Send a request. Open a page. Compare the result with what should happen.

AI features can still use those tests, but the unit under test is getting bigger.

A writing assistant may generate several valid answers to the same request. A research feature may retrieve sources, summarize them and build a final response. A coding agent may inspect files, call tools, edit code, run tests and continue until the repository reaches the intended state.

That means the test can no longer stop at one returned string.

The system may need to measure the input, the intermediate steps, the tools selected, the information retrieved, the final answer and the state left behind after the task finishes.

Anthropic describes this through agent evals built around tasks, trials, graders, transcripts and outcomes. Google’s Agent Platform now exposes metrics for tool use, trajectory quality, final-response quality, grounding and other dimensions.

The change is in scope.

Software testing is expanding from checking one output to measuring an entire AI behavior.

An Eval Turns Product Expectations Into a Testable Task

The word that keeps appearing across AI engineering is eval.

An eval is a structured test for an AI system.

The system receives an input or task. Then one or more graders measure whether the result meets the criteria the product team defined.

That sounds close to ordinary testing because the underlying idea is familiar.

Define success.

Run the system.

Measure the result.

The difference is that AI product requirements often need richer definitions of success.

A customer-support feature may need to resolve the request, use the correct policy source and communicate clearly. A research assistant may need accurate sourcing, sufficient coverage and a coherent synthesis. A coding agent may need the tests to pass while also producing maintainable code and using the available tools correctly.

OpenAI describes evals as a way to turn business objectives into measurable expectations. Anthropic similarly treats an eval suite as a collection of tasks designed around specific capabilities or behaviors.

The product specification becomes executable.

Instead of saying the AI should be ‘good,’ the team defines what good means and gives the system a test.

One AI Task Can Have Several Graders

A single pass-or-fail assertion is often only one part of an AI test.

Modern eval systems combine several kinds of graders.

Code-based graders can check exact values, schemas, state changes, tool calls, latency or ordinary software tests.

Model-based graders can use a rubric to score dimensions such as completeness, instruction following, groundedness or communication quality.

Human reviewers can calibrate the criteria and provide expert judgment for tasks where domain knowledge matters.

Anthropic groups agent-evaluation graders into these three broad families: code-based, model-based and human.

Google’s current Agent Platform follows a similar multi-metric direction. It includes deterministic metrics, adaptive rubrics, code-defined metrics and LLM-as-a-judge metrics inside one evaluation system.

The system combines these grader types.

A coding assistant can still be tested with pytest.

Then another grader can check whether the requested files changed.

Another can inspect tool-use quality.

Another can score the final explanation against a rubric.

The result is not less rigorous than ordinary software testing.

It is a larger measurement stack built around several forms of evidence.

Rubrics Let Teams Test Quality That Has More Than One Valid Answer

Some software behavior has one exact answer.

A JSON field should exist. A database record should have a specific state. A calculation should return a known number.

AI-generated content often has several valid forms.

Two good summaries can use different words. Two support responses can explain the same policy differently. Two research answers can organize the same verified facts in different structures.

Rubrics give product teams a way to test that kind of output.

Instead of requiring one exact string, the rubric defines the qualities that should be present.

Did the answer address the request?

Was it grounded in the supplied sources?

Did it include the required facts?

Did it follow the requested format?

Google’s adaptive-rubric system creates case-specific criteria from the evaluation case, developer instruction and tool declarations. Anthropic also recommends structured rubrics for open-ended behaviors and uses model-based graders when the task benefits from natural-language judgment.

That connects product requirements with repeatable evaluation criteria.

The team writes the quality standard in words.

The eval turns those words into repeatable measurement.

The Final Outcome Can Matter More Than the Final Sentence

Agents make software testing more interesting because they can change the environment around them.

Imagine an assistant that books a meeting.

The final message may say the meeting was scheduled.

The test can also verify whether the calendar event actually exists.

A coding agent may say it fixed the issue.

The test can inspect the repository, run the test suite and verify the resulting application state.

A support agent may say a request was processed.

The eval can inspect the corresponding backend state.

Anthropic explicitly separates the transcript from the outcome. The transcript records what the agent did; the outcome captures the state left in the environment after the trial.

This extends conventional end-to-end testing to include the resulting environment state.

The AI does not receive credit only because its final text sounds complete.

The product can verify the actual effect of the task.

That makes outcome checks especially important as AI features move from answering questions to taking actions.

Traces Turn the Agent's Journey Into Test Data

Traditional application logs already tell engineers what happened inside a system.

AI agents make that record even more valuable.

An agent trace can include prompts, model responses, tool calls, retrieved context, intermediate results and the sequence of actions taken before the final output appears.

Anthropic calls this record a transcript, trace or trajectory.

Google’s Agent Platform can evaluate production traces directly and includes Trajectory Quality among its available metrics.

That creates a second level of testing.

The final outcome answers: did the task finish correctly?

The trace answers: how did the system get there?

A team can measure the number of turns, tool-call patterns, grounding behavior, latency and other signals around the path.

This applies directly to long-running agents because the product experience is created across several steps.

The trace becomes a test artifact.

Developers can inspect it the way they already inspect logs, stack traces and test reports, but with the full AI workflow visible inside the same record.

Repeated Trials Measure Consistency Across Runs

AI evaluation also introduces the idea of trials.

The same task can be run more than once.

This is relevant because generative systems can produce valid variation across repeated executions.

A team can therefore measure the distribution of results instead of relying on one sample.

Anthropic defines each attempt at an eval task as a trial and recommends multiple trials when the product needs a clearer view of repeated performance.

This creates metrics that look different from the classic one-run unit test.

A system may be measured by first-attempt success.

Another workflow may care about whether at least one result across several attempts reaches the target.

A customer-facing process may care about how consistently the system reaches the expected outcome across repeated runs.

The test suite can match the product requirement.

This does not replace deterministic assertions where they fit.

It adds statistical measurement for behaviors that naturally have more than one possible path or phrasing.

Testing begins to describe not only whether the feature can succeed, but how consistently it performs across the evaluation set.

Simulation Lets Teams Test Conversations and Tool Environments

Some AI features need another actor before they can be tested properly.

A support agent needs a user to talk to.

A sales agent needs a conversation.

A tool-using agent needs APIs and external systems to interact with.

Simulation turns those dependencies into repeatable test infrastructure.

Google’s Agent Platform includes a case generator, user simulator and environment simulator. The user simulator can play a persona through a multi-turn interaction. The environment simulator can stand in for tools and backend systems with controlled responses.

This is similar to mocks and fixtures in traditional software engineering, but applied to conversations and agent environments.

The team can define the situation before the eval begins.

Then every model or prompt version can face comparable scenarios.

This is relevant because an agent is often defined by interaction rather than one isolated call.

Simulation makes that interaction testable.

Evaluation Is Moving Into CI and the Development Loop

One sign that evals are becoming part of software engineering is where they are being placed.

They are moving into the development loop.

Google says Agent Development Kit teams can define eval sets and run them locally during development, including through pytest in continuous integration.

Anthropic recommends eval-driven development: define planned capabilities through evals, then iterate against those measurements as the product evolves.

OpenAI describes a similar loop around specifying expectations, measuring results and improving the system using logged inputs, outputs and outcomes.

That creates an AI version of a familiar engineering pattern.

Change the code or prompt.

Run the suite.

Compare the metrics.

Inspect the traces.

Review the important cases.

Then ship when the product reaches the quality bar the team defined.

The eval is no longer an occasional research benchmark.

It becomes part of day-to-day product development.

Production Traffic Can Become Part of the Evaluation System

AI testing does not have to stop at deployment.

Production creates a new dataset: the tasks real users actually perform.

Google’s generally available agent-evaluation system can score collected traces and run online monitors against live traffic. The same metric registry can be used for offline experiments and online evaluation, which lets teams keep a consistent measurement language from development into production.

OpenAI recommends a data flywheel built from logged inputs, outputs and outcomes, with sampled cases routed into review and then added back into the evaluation process.

This changes the lifecycle of the test suite.

The evaluation dataset can grow with the product.

Early cases come from the specification and manual testing.

Later cases can come from real usage patterns.

The production environment becomes a source of new scenarios that improve the next development cycle.

That creates a loop instead of a finish line.

Build.

Evaluate.

Deploy.

Observe.

Add what was learned to the next eval set.

Google Has Turned Agent Evaluation Into a Production Platform

Google’s July 2026 release shows how quickly this category is becoming product infrastructure.

Agent and Model Evaluations in Gemini Enterprise Agent Platform are now generally available.

Google says the service includes more than 20 pre-built metrics spanning areas such as quality, grounding, agent tool use, trajectory and reference-based scoring for tasks including summarization and translation.

Teams can also define their own code-based metrics or LLM-as-a-judge criteria.

The same evaluation system can run in local experiments, server-side runs and online monitoring.

That is relevant because it brings several previously separate activities into one workflow.

Test cases live in datasets.

Metrics live in a versioned registry.

Traces can be inspected.

Simulation can generate interactions.

Online monitors can continue scoring after deployment.

AI evaluation is becoming less like a one-off benchmark and more like an observability and quality platform for intelligent software.

NIST Is Expanding TEVV for a Wider Range of AI Systems

The shift is also appearing at the standards and measurement level.

In August 2026, NIST published the initial public draft of its TEVV-Athlon Framework for Evaluating AI Systems.

TEVV stands for Test, Evaluation, Verification and Validation.

NIST describes the framework as extensible, adaptable and customizable across statistical machine learning, large language models, multimodal models, agentic systems and other AI technologies.

The framework uses a four-stage method for building assessments around an organization’s own evaluation objectives.

That reflects an evaluation approach in which different AI systems can use different measurement designs.

Different applications need different evidence.

A vision system may need one measurement design.

A language model may need another.

An agent that acts inside software may need environment state, tool use and trajectory evaluation.

NIST’s approach formalizes the idea that the evaluation method should fit the system and the real-world goal being measured.

AI testing is becoming a discipline with its own measurement frameworks.

The New Test Suite Mixes Software Engineering With Product Judgment

AI testing now combines several disciplines in the same evaluation workflow.

Software engineering still provides deterministic tests, schemas, state assertions, mocks, CI and observability.

Machine-learning evaluation adds datasets, repeated trials and statistical measurement.

Product teams add rubrics that define what a useful answer or completed task should look like.

Domain experts add judgment where specialized knowledge matters.

Telemetry adds traces from real interactions.

Together, those layers create a test suite that looks different from the one used for a normal button, API endpoint or database query.

The AI feature is being evaluated as a system.

Did it achieve the outcome?

Did it use the right information?

Did the tools behave as expected?

Did the trajectory stay aligned with the task?

Did the final response meet the product’s quality standard?

Those questions can all become measurable parts of the same evaluation run.

Software Testing Is Becoming the Measurement Layer for AI Products

AI is not removing software testing.

It is expanding what software testing can measure.

Unit tests still matter.

Integration tests still matter.

End-to-end tests still matter.

Now eval datasets sit beside them.

Code graders verify exact behavior. Rubrics score open-ended quality. Outcomes check what changed in the environment. Traces record the agent’s path. Repeated trials measure consistency. Simulation creates controlled conversations and tool environments. Production monitoring feeds real usage back into the next evaluation cycle.

Anthropic is formalizing these patterns for agent evals.

Google has turned them into a generally available evaluation platform with more than 20 pre-built metrics.

OpenAI is framing evals as a continuous measurement loop tied to business objectives.

NIST is building a customizable TEVV framework for a wide range of AI systems.

The direction is clear.

The software test is becoming more than a check on code.

For AI products, it is becoming the measurement layer for behavior itself.

That is the upgrade.