Claude Opus 5, T3 Connect, Conductor Cloud, and More: Dev News Weekly

The most important developer news this week was not one more benchmark win. It was a reminder that the systems around our models—the image processor, remote control plane, inference region, and pricing tier—often matter more than the model name.

Between Friday, July 24 and Friday, July 31, Anthropic released Claude Opus 5, xAI resurfaced a $30-for-three-months SuperGrok offer, T3 Code put coding agents on iOS and Android, Conductor moved subscription-backed agents into cloud microVMs, a critical Active Storage vulnerability landed, Kimi K3 gained a practical US-hosted route, and OpenAI cut GPT-5.6 prices only three weeks after launch.

This Friday-to-Friday edition was verified on July 31, 2026. It does not speculate about announcements that may arrive after that cutoff.

Maintaining a Rails app with untrusted image uploads and libvips? Jump to CVE-2026-66066. That is the item to act on today.

The week at a glance

Claude Opus 5: the practical frontier model

Anthropic released Claude Opus 5 on July 24 across Claude, Claude Code, and the API. It is now the default model for Claude Max and the strongest model available on Claude Pro.

The headline is not simply that Opus moved up a benchmark table. Anthropic is positioning Opus 5 as a model that verifies its work, stays with long tasks, and finds root causes instead of applying surface patches. That is exactly the behavior that determines whether an agent saves engineering time or creates a polished second bug.

Key details:

• API model ID: claude-opus-5
• Price: $5 per million input tokens and $25 per million output tokens
• Context window: 1 million tokens
• Effort levels: low, medium, high, xhigh, and max
• Default API effort: high
• Fast mode: about 2.5× the default speed at twice the base price

Anthropic reports state-of-the-art results on Frontier-Bench and several knowledge-work evaluations. It also says Opus 5 more than doubles Opus 4.8's Frontier-Bench performance at a lower cost per successful task. Those are vendor results, not a substitute for an evaluation on your repository.

Try Opus 5 without changing your whole stack

The smallest useful test is a task your team already understands: a resolved production incident, a difficult review, or a bug with a known root cause.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 4096,
    "output_config": { "effort": "high" },
    "messages": [{
      "role": "user",
      "content": "Review this incident report, find the root cause, and propose the smallest verified fix."
    }]
  }'

The Opus 5 effort guide recommends starting at high, moving to xhigh for demanding coding and agent work, and using low or medium wherever your evaluations show that quality holds. Changing effort controls thinking and tool use; it does not reliably make the visible answer shorter.

My take: Opus 5 looks most valuable as the model for ambiguous planning, deep debugging, and final review. Making it the default for every small edit would pay frontier prices for work a cheaper model can already do. Test the claimed improvement on hard tasks, then route selectively.

T3 Code Mobile and T3 Connect: your agent console leaves the desk

T3 Code describes itself as an open-source control plane for Claude Code, Codex, Cursor, Grok, and OpenCode. Its new iOS app and Android app bring most of the desktop workflow to a phone:

• start and continue agent runs;
• browse repositories and files;
• inspect diffs and version-control state;
• use the terminal;
• connect manually with a pairing code or through the managed T3 Connect tunnel.

The useful mental model is remote control, not remote execution. Your workstation or server still owns the repository, credentials, terminal, and coding-agent sessions. The phone controls that environment.

flowchart LR
  P["T3 Code Mobile"] -->|"one-time pairing"| C{"Connection"}
  C -->|"T3 Connect"| S["T3 Code server"]
  C -->|"LAN, Tailnet, or HTTPS"| S
  S --> A["Claude Code, Codex, Cursor, Grok, OpenCode"]
  S --> R[("Repository, git, and terminal")]

The quickest local trial is:

npx t3@latest

For a headless machine, T3 Code's remote-access guide supports a private Tailscale HTTPS endpoint:

npx t3 serve --tailscale-serve

The command prints a pairing URL, one-time token, and QR code. Scan it in the mobile app, then manage active sessions and revoke access later with t3 auth.

Remote agent control also expands the security boundary. A paired phone can reach source code, terminals, git operations, and provider sessions. Treat pairing URLs as passwords, prefer a private network or managed tunnel over a public port, revoke a lost device immediately, and keep approval gates on destructive actions.

My take: This release is more consequential than another chat interface. Long-running agents need a control plane that follows the developer without requiring an open laptop. The hard product problem is now safe interruption, approval, and recovery—not whether a model can produce another diff.

Conductor Cloud 0.78.0: subscription-backed agents move off the laptop

Conductor 0.78.0 launched Conductor Cloud on July 30. Instead of leaving a Mac awake, each cloud workspace runs in an isolated Vercel Sandbox microVM with the repository and development environment pre-installed. Agent work continues after the desktop app closes and can be reopened from Conductor, shared with collaborators, or controlled through the new Conductor API. A mobile app is announced but not yet available.

The cloud sandbox is more than a remote terminal. Conductor gives it the existing chat, diff, git, terminal, and pull-request workflow, plus multiplayer links and live prompting. The current machines run in us-east-1 with 8 vCPUs, 16 GB of RAM, and 32 GB of ephemeral NVMe storage. They sleep after four hours without agent or terminal activity and stop after a maximum of 23 hours and 50 minutes; files and chat history survive, but running processes do not.

What Conductor Cloud costs

Conductor's pricing FAQ says there is currently no additional cloud-workspace fee beyond an eligible plan, but usage-based cloud-compute pricing is planned. The public page does not quantify the included workspace hours, so teams should verify the allowance before budgeting sustained agent workloads.

Claude and Codex subscriptions work without provider API keys

This part is confirmed in Conductor's provider documentation:

• Claude Code can authenticate with a Claude Pro or Max subscription.
• Codex can use Codex sign-in and an existing OpenAI subscription or ChatGPT credits.
• Anthropic and OpenAI API keys remain optional alternatives, not requirements.
• Conductor does not resell model usage; it is charged to the selected provider account, subscription, credit pool, or API key.

During cloud setup, add a personal subscription token or provider API key for at least one agent. Version 0.78.0 can import credentials already configured in local Conductor and makes the claude setup-token flow copyable. For Codex, use the existing Codex sign-in path. Provider quotas and model availability still apply.

Be precise about the phrase "no API key required." It applies to Claude and Codex inference when using subscription authentication. Calling the Conductor API programmatically still requires a separate Conductor API key, and Cursor sessions still require CURSOR_API_KEY. Also remove ANTHROPIC_API_KEY from the Conductor environment when you intend to use a Claude subscription—the docs warn that its presence may switch Claude Code to API billing.

The smallest trial is:

1. update to Conductor 0.78.0 and subscribe to Pro;
2. create an organization and connect the Conductor GitHub App;
3. import a Claude or Codex subscription credential;
4. build the Cloud Computer, then start one real task in a cloud workspace.

My take: T3 Code Mobile and Conductor Cloud solve adjacent problems. T3 remotely controls sessions that still run on your machine; Conductor moves the runtime into a managed environment. At $50 per month, the interesting value is not another agent UI—it is removing laptop uptime from long-running work while reusing subscriptions you already pay for. The tradeoff is a wider trust boundary: unlike local sessions, cloud chat inputs and outputs are stored on Conductor's servers.

Rails CVE-2026-66066: patch Active Storage now

On July 29, the Rails team published CVE-2026-66066, a critical Active Storage vulnerability with a 9.5 CVSS score.

An application is affected when both conditions are true:

1. Active Storage uses libvips for variants—config.active_storage.variant_processor = :vips, the default since load_defaults 7.0.
2. Untrusted users can upload images.

The advisory explicitly says that generating a variant is not an additional requirement for exposure.

Active Storage allowed libvips operations marked "unfuzzed" to remain available for untrusted input. A crafted upload may invoke one of those operations and read arbitrary files available to the Rails process, including its environment. From there, exposed secret_key_base, database credentials, object-storage keys, or third-party tokens may enable remote code execution or lateral movement.

flowchart LR
  U["Untrusted upload"] --> V["libvips unfuzzed operation"]
  V --> F["Process-readable file or environment"]
  F --> K["Application secrets exposed"]
  K --> E["Possible RCE or lateral movement"]

Fixed Active Storage versions

Check the deployed application, not only your laptop:

bundle info activestorage
vips --version

Then update to a patched Rails release permitted by your Gemfile and verify the result:

bundle update rails
bundle info activestorage
vips --version

If Active Storage is managed independently, update activestorage directly. The patched gem also requires libvips 8.13 or newer. libvips versions below 8.13 cannot block the unsafe operations and have no equivalent workaround.

For an emergency mitigation on libvips 8.13+, set VIPS_BLOCK_UNTRUSTED before the process initializes libvips. Applications on ruby-vips 2.2.1+ can instead initialize:

Vips.block_untrusted(true)

That is a bridge to the patched release, not a reason to postpone it.

Patching is only half the incident response

The official GitHub security advisory says affected applications should treat every process-readable secret as potentially exposed. After closing the vulnerability:

1. rotate secret_key_base;
2. replace the Rails master key and every credential it decrypts;
3. rotate database, Active Storage, and third-party credentials;
4. expire sessions, signed cookies, signed global IDs, and old Active Storage URLs;
5. inspect upload and access logs for suspicious files or variant requests.

Do not retain an exposed value as a fallback during rotation. The Rails team is withholding the attack-chain details until no later than August 28 so administrators have time to patch.

My take: This is the week's only announcement that should interrupt planned work. The vulnerability crosses from an image upload into application secrets, and updating without rotating secrets assumes no one arrived before the patch.

Kimi K3 is now practical on US-hosted infrastructure

Two related Kimi events landed on July 27.

First, Moonshot AI released the full Kimi K3 model weights as promised. K3 is a 2.8-trillion-parameter mixture-of-experts model with 104 billion active parameters, native vision, and a 1-million-token context window. Moonshot's technical launch post is refreshingly direct that K3 still trails Claude Fable 5 and GPT-5.6 Sol overall.

Second, LM Studio made Kimi K3 available in Bionic on US-based servers, with zero data retention enabled by default. That distinction matters:

• it gives US users a domestic inference route;
• it is hosted cloud inference, not local execution;
• ZDR is a service policy, not proof that every compliance requirement is met;
• the model remains open-weight rather than fully open-source.

K3 is technically downloadable, but it is not a casual laptop model. Moonshot recommends supernode deployments with 64 or more accelerators. For most teams, a hosted provider or the API is the realistic evaluation path.

Direct Kimi API pricing is $0.30 per million cached input tokens, $3 per million uncached input tokens, and $15 per million output tokens. LM Studio lists the same K3 token prices for its US-hosted Bionic route.

To try K3 in the official coding client:

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash
kimi

Log in with /login, then select Kimi K3 with /model. The Kimi Code documentation also exposes OpenAI- and Anthropic-compatible endpoints for existing agent tools.

My take: The US-hosted option is the important product news; the weight release is the important ecosystem news. Open weights improve portability, research, and negotiating leverage even when almost nobody can afford to run the full model under a desk.

OpenAI cuts GPT-5.6 prices and adds Sol Fast mode

OpenAI closed the week with a direct response to the cost side of the agent race. On July 30 it cut GPT-5.6 Luna pricing by 80% and Terra pricing by 20%.

Prices are per million tokens. ChatGPT and Codex subscription prices and quota budgets did not change, but Luna and Terra now consume fewer credits.

OpenAI also replaced Priority Processing with Fast mode for GPT-5.6 Sol. It promises up to 2.5× Standard speed at twice the Standard price, with no change in model intelligence. Existing API requests tagged priority automatically use Fast mode:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "service_tier": "priority",
    "input": "Find the root cause, implement the smallest fix, and verify it."
  }'

The most useful example in OpenAI's announcement is an agent workflow that uses Sol to resolve ambiguity and plan, then Luna to implement a well-specified change and run tests. That is a better default than sending every step to the largest model.

My take: An 80% cut only three weeks after GPT-5.6's general release is a stronger market signal than any benchmark chart. Agent economics are moving from "which model is best?" to "which model is sufficient for this step?" Do not build a complex router first; run one evaluation set, find the cheapest tier that holds quality, and add routing only where the result pays for the complexity.

SuperGrok: three months for $30

This week's offer applies to the standard SuperGrok plan, normally $30 per month. A July 27 mobile checkout example showed one monthly payment covering three months. On July 31, the verified Grok account confirmed the $30-for-three-months promotion and described it as limited-time.

The economics are simple: $30 total instead of $90, effectively $10 per month and roughly 67% off over three months. The standard $30 monthly price resumes after the promotional period unless the subscription is canceled.

This is not a universal price cut. Grok says the offer may depend on account eligibility, previous subscription history, or region, and that it had been listed for new subscribers. Check the signed-in web, Apple App Store, or Google Play checkout and confirm that the offer covers the full three-month period before paying. Those platforms have separate billing management.

Do not confuse it with SuperGrok Heavy's separate promotion. Heavy is roughly $99 per month for its first three months and then returns to $300; the offer covered here is three months of standard SuperGrok for one $30 payment.

SuperGrok still uses a shared weekly usage pool. A paid plan does not mean unlimited chat, coding, image, or video generation, and xAI sells additional usage credits after the included allowance is exhausted.

My take: $30 for three months is a low-risk way to evaluate Grok 4.5, Expert mode, coding, and image or video generation against tools you already use. Measure the weekly allowance rather than the feature list, and set a reminder before the first full-price renewal.

What the prices look like after this week

These headline API prices are useful for orientation, but they are not apples-to-apples measures of task cost.

Reasoning tokens, retries, tool calls, cache-hit rates, long-context premiums, and successful-task rates can reverse the apparent ranking. Measure the complete workflow.

The bigger story: agents are becoming infrastructure

This week's seven stories fit together.

Claude Opus 5 pushes long-running capability forward. T3 Code makes the agent reachable from anywhere. Conductor Cloud removes the laptop from the runtime. Kimi adds another serious model and a US-hosted path. OpenAI makes routine agent work dramatically cheaper, while SuperGrok uses a targeted three-for-one offer to compete for paid users. Rails shows what happens when one native dependency sits inside a privileged workflow without a safe boundary.

The winning agent stack will not be the one with the most impressive model name. It will be the one that:

• uses the least expensive model that reliably completes each step;
• exposes the smallest possible set of files, credentials, and tools;
• keeps irreversible actions behind explicit approval;
• makes remote sessions easy to revoke and investigate;
• verifies outcomes instead of trusting a confident completion message.

Patch Rails first. Then run the same real task through Opus 5, Kimi K3, Terra, and Luna. The result will tell you more than this week's launch charts.

Primary sources

• Anthropic: Introducing Claude Opus 5
• T3 Code site and mobile downloads
• T3 Code remote-access documentation
• Conductor 0.78.0: Introducing Conductor Cloud
• Conductor Cloud pricing and FAQ
• Conductor: Configure model providers
• Conductor Cloud FAQ
• Rails security announcement for CVE-2026-66066
• Moonshot AI: Kimi K3 technical launch
• Kimi K3 technical report
• LM Studio: Kimi K3 on US-hosted Bionic
• OpenAI: GPT-5.6 price-performance update
• Grok: eligibility details for the $30 three-month SuperGrok offer
• Current SuperGrok offer shown in a mobile checkout
• xAI: Grok plan pricing
• Grok subscription plans
• xAI: Grok billing and usage FAQ