My AI Coding Setup, October 2026: Cursor, Grok, Codex and Gemini

Two of the model makers I use now put an invisible watermark in the text their models write, and both say it's to comply with the EU AI Act. Neither adds characters or hidden text. Both nudge which words the model picks, and both say detection is statistical.

Claude, already on. Anthropic's explainer says it uses a version of Google DeepMind's SynthID-Text, costs no extra tokens, and carries nothing that identifies you, your company or your chat. Its help article, updated this week, says Anthropic signed the EU's Article 50(2) Code of Practice on marking AI content. It covers the API, the Claude apps, Claude Code, Claude Cowork and Claude Tag worldwide, plus supported models reached through AWS, Google Cloud or Microsoft Foundry. As of November 2, its table shows text watermarks on Fable 5.1, Fable 5, Mythos 5.1, Opus 5.5, Opus 5, Opus 4.8, Sonnet 5.5, Sonnet 5 and Haiku 5.5, and Anthropic says it's adding them to models released before August 2, 2026. Files get a different mark: when Claude creates a file like a PNG or JPEG, it attaches signed Content Credentials (C2PA), which you can read with Anthropic's free Claude Content Checker.

Grok, starting November 7. This is the one that touches my setup, since Grok 4.7 is what I use almost all day. The company behind Grok, which now publishes as SpaceXSI, says in its API docs that starting November 7, 2026, text from grok-4.7, grok-4.6, grok-4.5, grok-4.3 and the three grok-4.20 models (reasoning, non-reasoning and multi-agent) is watermarked by default on every API endpoint. It covers normal replies, structured outputs and tool call arguments. That last one matters for coding, since tool calls are how agents hand over the files they write. SpaceXSI says there's no code change and no hit to quality or speed. A marked response comes back with an x-watermark: true header. Detection answers watermarked, not watermarked or uncertain, longer text gives a stronger signal, and access is by application. Team admins can opt out per model in the Console. Doing that means confirming a legal exception applies to them and that they're solely responsible for any marking or disclosure. Some models may be locked on. The page is about the API. It doesn't mention the Grok apps, and I haven't seen Cursor say whether Grok inside Cursor is watermarked.

Client copy. Anthropic says "light editing probably won't remove the watermark completely; a complete rewrite where every word is replaced will." So a lightly edited Claude draft on a client's site can likely be traced back to Claude later. I'd assume the same for Grok, though SpaceXSI hasn't said how well its mark survives edits. Right now only certain groups can check. Anthropic's detection API is in private preview for organizations named under EU law, like regulators, media, fact-checkers and researchers, plus companies that need it for their own compliance. SpaceXSI takes applications through a form. Going the other way, when Claude only proofreads your writing, Anthropic says there's "very little (if anything)" for the watermark to attach to.

Code and comments. Anthropic says code has "generally less watermarking," because exact code doesn't leave the model free word choices. Comments are different: it names "comments within code" as a place the watermark can show up. I'd assume the same for READMEs, docs and commit messages, since they're ordinary prose. Neither company has said that specifically, and SpaceXSI hasn't said how much signal code carries.

What I'm doing about it. Not much changes. Agents write a lot of my code and drafts, and I've never hidden that. Anthropic says the watermark doesn't change who owns the output or a user's rights under its terms. It only signals the model was likely involved. So: tell clients when AI helped with their copy, and edit it into their voice because their name is on it. If you build on the Grok API, whether to opt out is a call for your team and your lawyer, since SpaceXSI puts any marking and disclosure on the team once it's off. On the legal side, the European Commission says the Article 50 marking and labelling rules apply from August 2, 2026, with a transition until December 2, 2026 for AI systems already on the market. Its code of practice also covers labelling AI-generated text published to inform the public on matters of public interest, with room for human review and editorial responsibility. Anthropic tells anyone who builds Claude into a product to independently assess what Article 50 requires of them. If you publish for an EU audience, ask a lawyer, not a blog post.

Facts as of about 9:50 AM CST, November 2. I go deeper, including how to check a Grok response, in Claude and Grok now watermark AI text. Want help setting up an AI workflow for client work that you're comfortable being upfront about? Let's talk.

On the evening of October 29, Factory released Droid 1.0, the biggest update yet to the harness behind its coding agent. (The harness is everything around the model: the prompts, the tools and the loop that runs them.) You can get it as a desktop app for macOS and Windows, as a terminal app, or through the Droid SDK (@factory/droid-sdk), which runs the same Droid as the CLI.

What programmatic tool calling is. In a normal agent loop, the model calls one tool, waits, reads the result, then calls the next, and every request re-sends the instructions and the growing history. With programmatic tool calling, the model writes a small JavaScript program that makes the calls, does the looping and filtering in code, and only hands back what it prints. Droid calls this the Script tool, and Factory says one Script can make hundreds of tool calls in a single model request. Factory didn't invent the idea (it credits CodeAct research, Cloudflare, Anthropic and Codex), but Droid 1.0 makes it the default.

Why it matters: fewer round trips, less noise. Factory's headline example moved 151 Linear issues and verified each one, 312 tool calls in all. As a Script, that took 2 model requests and about 61,000 input tokens. Factory estimates direct calls would have taken 36 requests and about 3.1 million tokens. It also says Script mode cuts Droid's cost by 15% on Claude Opus 5.5.

The benchmarks are Factory's own. On its own Terminal-Bench 4 runs (October 23 to 28), Factory reports Droid scored 3.5 points higher than Codex at 12% lower cost on GPT-6.1 Sol, though it took 10% longer. On Claude Opus 5.5, it reports 3.0 to 7.6 points higher than Cursor, Claude Code, OpenCode and Devin at up to 24% lower cost. Cursor was only compared on Opus. A vendor's own benchmark is a reason to try something, not proof.

The caution: the sandbox is only half the story. Factory says the Script itself runs in a sandbox with no file, network or system access of its own. The tools it calls are a different story. Shell commands, file edits and connectors run with whatever you've allowed Droid to do, and one Script can be dozens of those calls. So:

• Keep the Autonomy Level low on real repos until you trust it. At Low, Droid can edit files but asks before riskier commands. Read the Script in the approval prompt instead of clicking through it.
• Turn on the OS-level sandbox for anything that matters. Factory's own docs say command rules can't inspect everything a script does.
• Scope the connections. Give Linear, GitHub and the rest an account that can only touch what the task needs. A 151-issue cleanup is great until it's the wrong 151 issues.

I've watched enough agents read files one at a time, like they're getting paid by the request, to think this is the right direction. Same rule as everything else on this list: a trial on low-stakes work first. If you want help setting up agents that do more per request without getting more access than they need, let's talk.

On October 29, Google launched the Plugin Marketplace in Antigravity, its agent-first coding platform. It's rolling out in both the Antigravity App and the Antigravity CLI. A plugin is one versioned bundle, described by a plugin.json file, that can hold up to five things: skills, MCP server connections, rules, lifecycle hooks, and custom agents or subagents. They install, update and switch on or off together.

What's in it at launch. Google's post names partners including Atlassian (Jira, Confluence and Bitbucket), Figma, Stripe, Datadog, Databricks, CrowdStrike, SentinelOne, Canva, Dropbox, monday.com, Ping Identity and Unity. Vercel announced its plugin the same day, and Linear publishes one on GitHub. Google's announcement doesn't say anything about pricing.

How to install one. In the App, open the Customizations tab in the left sidebar, switch to Marketplace and click + on a plugin. From a terminal it's agy plugin install <plugin-name>, or /plugin inside a CLI session. Plugins you add in the App show up in the CLI too.

The part I'd slow down on: hooks. Google's docs say hooks run shell commands at set points in the agent's loop, like session start or before and after a tool call, outside the model's reasoning. That's great for blocking a risky tool call or making the tests pass before the agent calls it done. It also means installing a plugin can mean installing scripts that run on your machine. So before you click +:

• Open the plugin's page first. The App shows its skills, MCP servers, agents and rules, plus the developer, version and a link to its repository. In the CLI, agy plugin list --json lists every installed component, hooks included.
• Treat the connection like an API key. A Stripe or Jira plugin gets whatever access the account you sign in with has. Use the most limited account or key the service offers that still gets the job done.
• Keep your setup somewhere you control. Plugins can live in an .agents/plugins/ folder in your repo, and agy plugin import pulls in existing Claude Code or Gemini CLI extensions. Setup that lives in the repo moves with you when a tool changes or goes away.

I'll be honest, "install in a click" is exactly the kind of sentence that gets me to skip reading what I'm installing. Same rule as any new tool: a trial on low-stakes work first. If you want help connecting agents to Jira, Stripe or your own systems without handing them the keys to everything, let's talk.

Google announced that Jules, its asynchronous coding agent, will wind down on December 31, 2026. You can keep finishing sessions until November 11. After that, Jules goes read-only until the end of the year. Google says what it learned from Jules is shaping Antigravity, its agent-first platform, but the notice doesn't describe any way to move your Jules sessions or settings into Antigravity. Plan on exporting, not migrating.

The export is a script, not a button. Google's instructions are to install Jules Tools (npm install -g @google/jules), run jules login, then paste a long prompt into a CLI coding agent such as Claude Code. That prompt has the agent run a Python script that saves your settings, environment variables, scheduled tasks, connected repos, memories, setup scripts and every session's prompt, plan, activity log and code patches into ~/jules-export. The prompt itself says some of the endpoints it calls are undocumented. Read it before you run it, and keep that folder out of every repo, because env-variables.json holds your real secret values.

Your code was never the part at risk. It's already in GitHub, with its branches and pull requests. What disappears with a tool is everything around the code: setup steps, test commands and the notes the agent built up about your repo. Here's what I'd check for any agent you depend on:

• Can you get your data out today? Run the export now, while you still have time to notice what's missing.
• Does the setup live in the repo? Setup scripts, test commands and agent instructions belong in files the next tool can read, not only in one tool's settings screen.
• What secrets does the tool hold? Once you've moved, delete them from the old tool and rotate the ones that matter. My key rotation guide covers doing that without downtime.
• What access did you grant it? If you installed the Jules GitHub app, remove it from your account or organization when you're done.

This is why new releases get a trial from me, not a switch, and why the work always flows through ordinary branches and pull requests. Then changing tools doesn't change how anything gets reviewed. If you need help moving an agent workflow off a tool that's going away, let's talk.

OpenCode, the open-source coding agent, shipped v2.2.1 overnight with /goal <objective>. The session keeps working, turn after turn, until a reviewer decides the objective is met. /goal pause, /goal resume and /goal clear control it. OpenAI's Codex has had a /goal command with the same controls since version 0.128.0, so this is turning into a standard feature.

Who the reviewer is. According to OpenCode's pull request, the reviewer is the session's own model. It reads the full conversation, including tool results, and is told not to call any tools. Its prompt says the assistant claiming the goal is met "is not evidence," and to answer "continue" when in doubt. That's a good prompt, but it's still the same model grading its own work.

What stops it. The shipped code pauses a goal after three stalled rounds in a row (no tool calls, or the same reason as last time), after 50 rounds, or after 30 minutes idle while waiting on background work. /goal resume starts a fresh 50-round allowance. I didn't find a cost or token budget. OpenAI lists a budget limit among Codex's stopping conditions.

How I'd use it. Only with a goal a command can prove. "Make composer test pass without editing the tests" works. "Clean up the billing module" doesn't. The test suite is the real reviewer. Spell out what it may not touch, run it on a branch or worktree, watch spend on your provider's dashboard, and read the final diff like a pull request from someone you just hired. A vague goal running 50 rounds on an expensive model gets you a big bill and a diff nobody wants to review.

Also new in v2.2.2: images are on by default. As of v2.2.2 (1:43 PM CDT), agents get an experimental_image_generate tool with no setup whenever a connected provider has an image model. OpenCode's default permissions allow every tool unless a rule says otherwise, so an agent can call your provider's image model without asking first. To turn it off, add { "action": "experimental_image_generate", "resource": "*", "effect": "deny" } to permissions in opencode.json, or use "ask" to approve each one.

If you want an agent workflow where tests, not the agent, decide when work is done, let's talk.

The day after /goal, OpenCode shipped v2.2.3 early on October 30 with a built-in Claude Agent provider. Install Claude Code (2.1.248 or later), run claude auth login, then pick Claude Agent in /connect. OpenCode runs your installed claude through Anthropic's Claude Agent SDK and uses whatever it's signed in with: a Claude plan, an Anthropic API key, or a cloud account like Bedrock, Vertex or Foundry. Per OpenCode's docs, Claude Code only calls the model. OpenCode's own tools, permissions and subagents do the rest, and your CLAUDE.md, hooks and Claude Code MCP servers don't load.

v2.2.4 landed just before noon CT. In the desktop app, picking Claude Agent now walks you through it: a copyable claude auth login, an Install Claude Code button, and a connection check before it says you're connected. It also makes desktop terminals survive server restarts, scrollback included, and adds opt-in artifacts: set "experimental": { "artifacts": true } in opencode.json and agents can publish HTML or static pages through a built-in local provider or a plugin.

The fine print on using your Claude plan. Anthropic's Claude Code legal page says developers building on the Agent SDK should use API keys, and that third-party developers can't offer Claude.ai login in their own apps or route requests through Free, Pro, Max or Ultra plan credentials on their users' behalf. The same page says that doesn't stop you from signing in to the unmodified Claude Code binary with your own subscription, and OpenCode's design leans on that: it runs your own claude and never handles your login. The Agent SDK docs add "unless previously approved," and the OpenCode team member who built the feature says they got permission from Anthropic. I couldn't find Anthropic saying that anywhere, and Anthropic says it can enforce these rules without notice. For context, OpenCode's older docs still say Anthropic "explicitly prohibits" the Pro/Max plugins OpenCode used to bundle. This works differently, but that's the history.

How I'd use it. For client work or anything a team depends on, sign Claude Code in with an Anthropic API key (or Bedrock, Vertex or Foundry) and the question goes away. You also get real cost numbers: OpenCode shows no cost at all on a subscription. Trying it on your personal plan? Keep it to side projects and expect the rules could change. Install Claude Code from Anthropic's own instructions, given this week's backdoored Claude Code extension in Cursor's marketplace. And leave artifacts off until you've decided where those pages live and who can see them.

Facts as of about 1:45 PM CDT, October 30. If you want help picking a setup where the model, the bill and the permissions are all ones you chose on purpose, let's talk.

On October 29, Mistral released the weights of Mistral Large 4, which it nicknames Le Chonk. It's the improved version of a model Mistral put in public preview earlier this month. The model card describes a mixture-of-experts model with about 1 trillion total parameters and about 52 billion active per token (49 billion, or 52 billion counting the embedding and output layers). It has a 1M-token context window and takes text and images. Mistral pitches it for agentic coding and defensive cybersecurity.

Mistral's benchmark claim checks out, with caveats. Mistral says it's the best open-weight model on Cognition's FrontierCode 2.0, which grades whether a maintainer would actually merge the agent's change. Cognition's leaderboard agrees: 19.7%, just ahead of DeepSeek V4.1 Flash at 19.3%. But Mistral's score was run in its own Mistral Vibe harness, while the open models closest to it were run in Devin CLI. And closed models are still well ahead. Grok 4.7, which I use for nearly everything, scores 28.6% on the same board, and the top score is 45.5%.

What running it yourself really takes. This is not a laptop model. Mistral's own vLLM example spreads it across 8 GPUs. Unsloth published compressed GGUF builds with day-zero access. Its guide says the smallest, a 1-bit build of about 233GB, should fit on 256GB of memory, including a Mac Studio. Unsloth claims that build keeps 91% of the full model's top-1 accuracy. That's the vendor's own number on a very heavy compression, so test it on your own code before you trust it.

The license is open, with one catch. It ships under the Mistral Ecosystem Open-Weight License, a modified MIT license that allows commercial use. The catch: if you run a Model-as-a-Service business, meaning you give third parties access to the model for inference or training, you need a separate commercial license from Mistral. Internal use is exempt, and so are products that only build the model into specific features.

Who should care. For most of my work I'll stay on hosted models. Running a GPU cluster isn't worth it for code that's allowed to leave the building. Open weights matter when code or data can't leave your network: health records, financial data, or a contract that rules out third-party AI. Running the model yourself takes one vendor out of the data path. It doesn't make you HIPAA compliant on its own. You still need access controls, audit logs and someone keeping the server patched. If self-hosting is more than you need, the other route is what I build for AI projects with sensitive data: a layer in front of the model that swaps names, identifiers and financial details for tokens before anything leaves. Same rule as any new model: a trial on low-stakes work first.

If you're weighing a self-hosted model for a team with sensitive data, or need HIPAA and SOC 2 ready software around it, let's talk.

At GitHub Universe on October 28, GitHub made Copilot Fusion generally available. You don't pick a model. You pick Copilot Fusion in the model picker, then an effort level: Standard, High or Max. For each prompt, Copilot decides which models to use. Sometimes that's one model. Sometimes an efficient model drafts and a quality check decides whether to escalate to a stronger one, or one model drafts and another reviews it.

GitHub's benchmark claim holds up, with caveats. GitHub says Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, at about half the cost per task. Artificial Analysis's own comparison lists it: 60 against 62, $5.59 against $11.42 per task, and 36 minutes against an hour. The headline leaves two things out. Fusion Max beats Claude Code on Terminal-Bench 4.0 but trails it on the index's other two benchmarks. And that cost is Artificial Analysis's estimate at pay-per-token API rates, not what your Copilot bill will show.

Where it runs and what it costs. GitHub says Fusion is on all Copilot plans, in VS Code, JetBrains IDEs, Copilot CLI and the new GitHub Copilot app. You're billed for each model it uses at that model's standard rate. For a limited time, paid plans get 30% off model costs when using Fusion. Admins choose which models it can use and can make it the default. Separately, GitHub announced that GitHub Enterprise customers can now use every Copilot feature without a separate Copilot subscription, paying for the AI credits they use. For now that goes through GitHub Sales. Self-serve is coming.

Fusion or your own pick? It's the same trade as Cursor's Auto mode, which I describe below. Letting the tool route keeps you from leaving an expensive model on for small tasks. Picking your own gives you one model whose habits you learn. I still pick mine. If your team already lives in Copilot, Fusion Standard is a sensible everyday default, and Max is worth a try on the hard tasks. It gets the same rule as any new model: a trial on low-stakes work first.

If you want help setting up a Copilot or Cursor workflow for your team, let's talk.