Claude Opus 5: Hands-On with Code Generation, Agent Orchestration, and Cost Analysis

Anthropic quietly shipped Claude Opus 5 last week. Not a flashy announcement, but the numbers caught my attention: roughly 33% cheaper than Opus 4, better at code generation, and supposedly more reliable with tool calling.

I run a small cross-border e-commerce operation where we process product data from dozens of suppliers, generate multi-language descriptions, and manage order workflows. AI is already part of that pipeline. So I spent a weekend porting some of our codebase to Opus 5 and comparing it against what we were using.

This post covers three things: code generation quality, agent orchestration behavior, and whether the price cut actually changes how you'd design a system.

The first test was practical. I needed a currency exchange microservice that caches rates, handles fallbacks, and exposes a clean API. No novel problem, but the kind of task where a model either saves you time or wastes it with hallucinated imports.

I asked Opus 5 for a multi-file FastAPI project structure. Here's what it generated for the service layer:

import aiohttp
from decimal import Decimal
from app.cache import RateCache

class RateService:
    def __init__(self):
        self.cache = RateCache(ttl=300)
        self.api_url = "https://api.exchangerate.host/latest"

    async def get_rate(self, currency: str) -> Decimal | None:
        cached = self.cache.get(currency)
        if cached:
            return cached

        async with aiohttp.ClientSession() as session:
            params = {"base": "USD", "symbols": currency}
            async with session.get(self.api_url, params=params, timeout=5) as resp:
                if resp.status == 200:
                    data = await resp.json()
                    rate = Decimal(str(data["rates"][currency]))
                    self.cache.set(currency, rate)
                    return rate
        return None

It handled module separation well. The import paths were consistent across files, the cache layer was separated from the fetch logic, and error handling existed for missing currencies and timeouts. Not groundbreaking, but clean enough that I didn't need to restructure anything.

The real surprise was the cache layer. Opus 4 often generated an in-memory dict with no TTL logic. Opus 5 added TTL-based expiration by default:

from dataclasses import dataclass
from typing import Dict, Optional
import time

@dataclass
class CacheEntry:
    value: Decimal
    expires_at: float

class RateCache:
    def __init__(self, ttl: int = 300):
        self._data: Dict[str, CacheEntry] = {}
        self._ttl = ttl

    def get(self, key: str) -> Optional[Decimal]:
        entry = self._data.get(key)
        if entry and time.time() < entry.expires_at:
            return entry.value
        return None

    def set(self, key: str, value: Decimal):
        self._data[key] = CacheEntry(value, time.time() + self._ttl)

The key takeaway: Opus 5 is noticeably better at inferring production concerns that you'd otherwise have to prompt for explicitly. It assumes you want caching, error boundaries, and type safety. This reduces iteration loops when scaffolding new services.

The bigger question for me was tool calling. We run several automated agents that handle order reconciliation — fetching order data, checking inventory, updating tracking numbers. Tool-calling consistency has been the bottleneck, not model intelligence.

I tested Opus 5 with a simple agent framework pattern:

from typing import TypedDict, List, Optional
import json

class ToolCall(TypedDict):
    name: str
    arguments: dict

class Agent:
    def __init__(self, model: str = "claude-opus-5"):
        self.model = model
        self.tools = {}
        self.history: List[dict] = []

    def register_tool(self, name: str, fn: callable, description: str):
        self.tools[name] = {"fn": fn, "desc": description}

    def run(self, task: str) -> str:
        plan = self._plan(task)
        results = []
        for step in plan:
            tool = self.tools.get(step["tool"])
            if tool:
                try:
                    result = tool<a href="**step["args"]">"fn"</a>
                    results.append({"step": step["name"], "status": "ok", "data": result})
                except Exception as e:
                    results.append({"step": step["name"], "status": "error", "error": str(e)})
            else:
                results.append({"step": step["name"], "status": "skipped", "reason": "tool not found"})
        return self._summarize(results)

In my test scenarios — extracting order fields from unstructured email, routing items to the right supplier queue, and flagging price mismatches — Opus 5 extracted parameters more consistently than Opus 4. The failure mode shifted: instead of omitting required arguments, it occasionally added an extra optional parameter that the tool didn't expect. Annoying, but recoverable with a kwarg filter.

One concrete improvement: when a tool returned an error, Opus 5 was more likely to retry with adjusted parameters rather than giving up or hallucating a result. That matters for production pipelines where transient failures (rate limits, network blips) are normal.

Here's the table that matters for anyone running API calls at scale:

For a system processing thousands of product descriptions daily, the savings add up. But more importantly, the reliability improvement means fewer retries and less manual cleanup. That's where the real efficiency gain lives.

In our setup at Taocarts — where we handle product collection, order syncing, and multi-language content generation across dozens of suppliers — the cost reduction means we can afford to run AI on stages we previously skipped: automated translation quality checks, inventory description validation, and flagging pricing anomalies before they reach customers.

A cheaper model that's also more reliable changes the calculus on what's worth automating. Tasks that weren't worth the token cost at Opus 4's price point are now viable.

Would I switch everything to Opus 5 today? For code generation and structured tool-calling tasks, yes. For open-ended reasoning where I need the absolute best output quality regardless of cost, I'd still compare it against the previous generation on a case-by-case basis. But the gap has narrowed considerably.

Three things I'd tell another developer evaluating this model:

Opus 5 is better at anticipating production concerns. It adds caching, error handling, and type hints without being asked. This cuts scaffolding time noticeably.

Tool calling is more stable but not flawless. Parameter extraction improved, but you still need a validation layer. Don't trust the output blindly — build a schema check before the result hits production.

The price drop makes previously borderline automation viable. If you skipped a use case because the token cost seemed too high, it's worth revisiting that math.

The trend is clear: models are getting cheaper and more capable simultaneously. The bottleneck is shifting from "can the model do this" to "can we build the pipeline to handle it."

How are you handling the balance between model cost and automation scope in your stack? I'm curious what others are seeing with the new generation of models.