Mervin Praison

The latest discussion around Claude Code, Codex, and Antigravity is not about which model is “best” in isolation. It is about which operating model fits your engineering workflow: interactive control, delegated execution, or agent-first orchestration.

This post includes a recreated infographic built from the shared LinkedIn analysis and official product documentation.

Why this comparison matters

We are moving from code completion to task execution. That shift changes the main decision from “which assistant writes code fastest” to “which control plane helps my team ship safely and consistently”.

Operating model breakdown

Evidence from official docs

• Claude Code docs emphasise context-window management and starting fresh sessions when conversation quality degrades.
• Codex AGENTS.md docs describe instruction-chain loading at session start, reinforcing a startup-configuration mindset.
• Google Antigravity launch materials position the product as agent-first, with manager and editor surfaces for asynchronous orchestration.

Decision framework for teams

Practical adoption pattern

• Start with one operating model per team, not all three at once.
• Define review and rollback protocol before increasing delegation depth.
• Track context drift and failed handoffs as first-class engineering metrics.
• Scale agent autonomy only where verification can remain cheap and reliable.

Bottom line: this is less a model race and more an execution-design choice. Teams that choose the right operating model for their delivery system will outperform teams that choose by hype alone.

Sources: LinkedIn post by Brij kishore Pandey, Anthropic Claude Code best practices, OpenAI Codex AGENTS.md guide, and Google Antigravity launch blog.

Multi-agent coding works best when each session starts with clean context, but teams still need reliable continuity across parallel runs. This post translates that tension into an operational handoff protocol grounded in official Claude Code and Codex guidance plus field patterns from the shared LinkedIn thread.

What the official docs actually say

The real failure mode in multi-session work

The hard part is not writing a handoff file. The hard part is quickly proving that a handoff is yours, current, and actionable before you spend tokens and time in the wrong branch. Once teams run parallel sessions, handoffs become distributed-systems state management, not personal notes.

Reference flow for fresh-session handoffs

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart TD
    A[Session N closes] --> B[Write HANDOFF file]
    B --> C[Set status and next-action]
    C --> D[Record do-not-repeat list]
    D --> E[Commit handoff on same branch]
    E --> F[Session N+1 starts fresh]
    F --> G[Validate branch plus status]
    G --> H[Execute next-action only]
    H --> I[Update handoff status]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A,F,H,I agent
    class B,C,D,E,G hook

Minimal handoff contract that scales

Example handoff template

---
status: active
branch: cursor/handoff-protocol
goal: ship deterministic handoff validation for parallel coding sessions
next-action: run handoff validator and fix filename collisions
---

## Context
- Last completed step: parser now reads frontmatter and branch fields.
- Current blocker: stale files from old branches still match topic names.

## Do-not
- Do not reuse topic-only filenames.
- Do not trust undated HANDOFF.md at repo root.
- Do not start implementation before branch and status check pass.

## Evidence
- Validation command: npm run handoff:check
- Failing file: handoffs/HANDOFF_auth.md

Risk matrix for teams running parallel agent sessions

Practical operating routine

• Start each major work item in a fresh session.
• Load durable project rules from CLAUDE.md or AGENTS.md only.
• Use one active handoff per branch and topic.
• Require status and next-action before any tool run.
• Archive or mark stale handoffs quickly to reduce ambiguity.

Bottom line: fresh sessions are not in conflict with continuity. They require continuity to move from chat history into operational artefacts. Treat handoffs as typed state, not prose, and multi-agent coding becomes predictable instead of fragile.

Sources: Anthropic best practices, Anthropic memory docs, OpenAI Codex AGENTS.md guide, OpenAI Codex features, and the shared LinkedIn post by Deepak Dhingra.

This deep research post analyses the paper Dive into Claude Code: The Design Space of Todays and Future AI Agent Systems, cross-checks the companion repository, and translates the findings into practical architecture guidance for teams building autonomous coding agents.

Source visual from the LinkedIn thread

Primary sources used for this analysis

• Paper: arXiv 2604.14228
• Paper HTML: Full section-level text
• Companion repository: VILA-Lab/Dive-into-Claude-Code

Executive findings

Architecture evidence from the paper figures

Figure reading: the paper decomposes the system into seven components: user, interfaces, agent loop, permission system, tools, state and persistence, and execution environment. This supports the claim that production agent quality depends on integration quality across these boundaries.

Figure reading: each turn routes through context assembly, model call, tool dispatch, permission gate, and execution feedback. This makes the permission and tool pipeline first-class runtime infrastructure, not side features.

Figure reading: the five-layer view clarifies why agent products are difficult to reproduce by only cloning a prompt loop; surface, safety/action, memory, and runtime layers have cross-cutting interactions.

Deep analysis: what this paper adds technically

Claude Code vs OpenClaw: architectural contrast

Critical reading notes and limitations

• The study is a source-level architectural analysis, not a controlled benchmark showing task win rates across multiple production datasets.
• The paper reports design mappings and subsystem decomposition; teams still need domain-specific evaluation for code quality, latency, and security outcomes.
• Comparative conclusions are strongest at architecture level and should not be over-interpreted as absolute performance rankings.
• For adoption decisions, pair this analysis with your own offline replay tests and guarded live trials.

Practical blueprint for agent builders

Bottom line: this paper is important because it reframes agent quality: model capability is necessary, but production value is decided by harness architecture. If two teams use similar base models, the team with better permissions, context engineering, execution isolation, and persistence design will usually ship the safer and more reliable agent product.

Chunk-heavy pipelines can lose document context, while vectorless retrieval keeps structure intact and routes reasoning to the right section before answer generation.

Architecture comparison

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart LR
    A[Document] --> B[Chunking]
    B --> C[Embedding]
    C --> D[Vector DB]
    D --> E[Top K chunks]
    E --> F[Answer generation]

    G[Document] --> H[Structured index]
    H --> I[Query routing]
    I --> J[LLM reasoning]
    J --> K[Precise section]
    K --> L[Answer generation]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A,B,E,F,G,L agent
    class C,D,H,I,K hook
    class J decision

Traditional vector RAG vs vectorless RAG

Where vectorless RAG fits best

• Regulatory and filing-heavy workflows where section boundaries matter.
• Legal contracts where exact clause retrieval is more important than semantic proximity.
• Multi-page reports where preserving hierarchy improves auditability and trust.

Implementation checklist

Bottom line: if your domain rewards precision over broad similarity, vectorless RAG can reduce infrastructure complexity while improving answer faithfulness. Benchmark numbers above are reported from the shared comparison visual and should be validated on your own corpus.

Source visual

GitHub CLI now includes gh skill (preview): a small package-manager-style surface to discover, pin, install, update, and publish agent skills straight from repositories—skills that follow the open Agent Skills specification and can target multiple coding-agent hosts from one workflow.

What “agent skills” are here

Skills bundle portable instructions, scripts, and assets so an agent host knows how to carry out a repeatable task (documentation style, release checklist, internal API patterns). Installations land in the correct host-specific directory; you can scope to user or project and select the host explicitly when it is not the default.

Flow from repository to running agent

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart LR
    R[Skills repo on GitHub] --> G[gh skill]
    G --> M[Provenance in SKILL.md frontmatter]
    M --> H{Agent host}
    H --> C[Copilot]
    H --> D[Claude Code / Cursor / Codex / Gemini CLI / …]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class R agent
    class G hook
    class M decision
    class C hook
    class D hook

Prerequisites

Upgrade GitHub CLI to v2.90.0 or newer before the subcommands appear. The feature ships as public preview and may change without notice.

Commands you will use daily

# Examples (from upstream documentation)
gh skill install github/awesome-copilot
gh skill install github/awesome-copilot documentation-writer@v1.2.0
gh skill install github/awesome-copilot documentation-writer@abc123def
gh skill install github/awesome-copilot documentation-writer \
  --agent claude-code --scope user

Pinning and provenance

Skills are executable policy: treat them like packages. --pin locks a skill to a tag or commit so broad update runs skip it until you deliberately bump the pin. Installs record the git tree SHA of the source directory; updates compare local and remote trees so you see real content drift, not cosmetic version bumps. Metadata is written into SKILL.md frontmatter so provenance travels if you copy the folder between machines or repos.

Publishing checklist for maintainers

Security posture (non-negotiable)

Upstream documentation is explicit: skills are not verified by GitHub and may contain prompt injection, concealed instructions, or hostile scripts. Use gh skill preview, read diffs like production code, and only install from organisations you trust—especially in CI images where a poisoned skill could exfiltrate tokens on the next agent run.

Supported agent hosts (install flag)

Alias: gh skills maps to the same command group—handy for muscle memory. Run gh skill --help after upgrading gh to see the exact subcommand set on your build.

Google’s Agents CLI packages the lifecycle around the open-source Agent Development Kit (ADK): scaffold an ADK Python project, wire tools and orchestration, run evaluation harnesses, and push builds to managed Google Cloud targets—whilst optional “skills” teach coding agents the same workflows end-to-end.

Where Agents CLI sits in the stack

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart TB
    subgraph dev [Developer machine]
        A[Coding agent with skills] --> B[agents-cli]
        B --> C[ADK Python project]
    end
    C --> D[Local run / Dev UI]
    C --> E[Eval sets + judges]
    E --> F{Ship}
    F --> G[Agent Runtime / Cloud Run / GKE]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class B hook
    class C agent
    class D hook
    class E decision
    class F decision
    class G agent

Install and prerequisites

# One-shot setup (installs CLI + skills bundle for coding agents)
uvx google-agents-cli setup

# Alternatives from upstream docs
# pipx install google-agents-cli && agents-cli setup
# pip install google-agents-cli && agents-cli setup
# Skills only: npx skills add google/agents-cli

Existing gcloud application-default credentials are picked up automatically when present—useful for iterative deploy loops without pasting keys into the agent transcript.

Bundled skills (what the coding agent learns)

Core commands

Relationship to ADK

ADK remains the framework: code-first agents, multi-agent graphs, rich tool surfaces (functions, OpenAPI tools, Google Cloud connectors), tracing, and “deploy anywhere” containers. Agents CLI is deliberately not a replacement for Gemini CLI, Claude Code, or Codex—it is the factory line those tools drive when they need opinionated Google Cloud paths for scaffolding, evaluation, and promotion to production.

Cloud vs local

Operational checklist

For teams already standardising on ADK, Agents CLI is best read as glue automation plus teaching artefacts: it shortens the distance between a natural-language brief and a repo that is structured the way Google’s own agent engineers expect—provided you still treat production gates as human-owned.

Xiaomi’s MiMo-V2-Flash is an open-weight mixture-of-experts language model pitched for reasoning, software engineering, and agentic tool use—released with permissive licensing and same-day open inference code so teams can self-host at throughput-oriented budgets.

Scale and routing

Architecture: hybrid attention for long jobs

The stack interleaves sliding-window attention with periodic global attention blocks—roughly a five-to-one cadence in public diagrams—so most layers attend locally for speed whilst global layers refresh cross-segment context. Reported training targets sit in the tens of thousands of tokens natively, with product messaging extending usable context toward six-figure token lengths for retrieval-heavy agents.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart TB
    subgraph layer [Representative hybrid block]
        L1[Sliding-window layers] --> L2[Global attention layer]
    end
    T[Token stream] --> layer
    layer --> R[Router → expert MLPs]
    R --> O[Hidden state out]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class T agent
    class L1 hook
    class L2 decision
    class R hook
    class O agent

Post-training: multi-teacher on-policy distillation

The team highlights Multi-Teacher On-Policy Distillation (MOPD)—a recipe meant to dampen the classic post-training seesaw where gains on mathematics or coding can erode safety or vice versa. The idea is to blend specialised teacher signals whilst staying on the student’s own sampling distribution, preserving behaviours that matter for tool-grounded agents.

Serving story

Who should adopt first

MiMo-V2-Flash is aimed at teams that want frontier-shaped capability with open weights and a story centred on agentic coding and long-context retrieval. If you only need lightweight instruction models, the operational cost of hosting a 300B-class MoE will be overkill—benchmark on a slice of your real traces before replatforming.

Alibaba’s Qwen team has shipped Qwen3.6-27B—the first dense open-weight entry in the Qwen 3.6 line—combining a hybrid linear-attention backbone, optional preservation of prior chain-of-thought across turns, and a 262K native context window stretchable into the million-token regime with YaRN.

Weights, licence, and runtimes

Layer geometry

The transformer stacks 64 layers with a repeating 3×(Gated DeltaNet → FFN) + 1×(Gated Attention → FFN) rhythm. Three quarters of sublayers use Gated DeltaNet linear attention (48 value heads / 16 QK heads in the public card), whilst every fourth sublayer uses conventional gated multi-head attention with a reduced KV head count to shrink cache footprint. Feed-forward blocks expand to an intermediate width of 17,408 dimensions.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart LR
    subgraph block [One macro-block]
        D1[DeltaNet] --> D2[DeltaNet]
        D2 --> D3[DeltaNet]
        D3 --> A[Gated attention]
        A --> F[FFN]
    end
    IN[Tokens + optional vision] --> block
    block --> MTP[Multi-token prediction head]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class IN agent
    class D1 hook
    class D2 hook
    class D3 hook
    class A decision
    class F hook
    class MTP agent

Context and “thinking preservation”

Native context is 262,144 tokens; YaRN scaling is advertised up to 1,010,000 tokens for experimental long-document jobs. For multi-turn agents, the release introduces thinking preservation—an API/template flag that keeps earlier chain-of-thought blocks in the visible history so the model does not pay to re-derive the same scratch work each tool round.

Reported benchmark snapshots

Deployment notes

Treat the FP8 checkpoint as the default path when VRAM is tight; validate perplexity and tool-call accuracy on your own eval harness because quantisation interacts badly with brittle JSON tool grammars. Pair the model with a sandbox that mirrors Terminal-Bench-style constraints if you plan to expose shell access—benchmark scores do not substitute for hardened ops reviews.

Two heavyweight open-model lines moved in the same news cycle: a Chinese phone OEM shipped a very large sparse “flash” language model aimed at reasoning, coding, and agentic workloads, whilst Alibaba’s Qwen team landed a dense 27B multimodal stack tuned for repository-scale agents—with both camps emphasising serving efficiency and day-zero inference tooling.

Two release archetypes

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
flowchart TB
    subgraph flash [Sparse flash LLM]
        A1[MoE backbone] --> A2[Hybrid attention]
        A2 --> A3[Post-train distill]
        A3 --> A4[Open weights + SGLang]
    end
    subgraph qwen [Dense hybrid LLM]
        B1[DeltaNet + full attention] --> B2[MTP speculative decode]
        B2 --> B3[Thinking preservation]
        B3 --> B4[HF + vLLM / SGLang]
    end

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A1 agent
    class A2 hook
    class A3 decision
    class A4 hook
    class B1 hook
    class B2 decision
    class B3 agent
    class B4 hook

Sparse “flash” foundation model

Qwen3.6-27B: dense hybrid for agents

Reported benchmark highlights (Qwen3.6-27B)

Why this pairing matters

One line doubles down on extreme MoE scale + throughput optics for frontier-style workloads; the other shows a mid-size dense hybrid can still punch above much larger MoE predecessors on agentic coding tables while staying deployable on commodity GPU farms. Together they reinforce that 2026 competition is as much about inference economics and tooling as about raw parameter counts.