Executive Summary

secd3v Claude Code Service usage in high compliance environments organises into two foundational patterns, DevSecOps (Brownfield) and Agentic (Greenfield), with a third mode, Spec-Driven Development, that modifies how Agentic sessions run. All three operate across Haiku 4.5, Sonnet 5 and Opus 4.8, with Sonnet 4.6 and Opus 4.6 retained for validated legacy workloads. Every cost carries the 10% premium that Australian endpoints attract, which is the price of keeping inference onshore and is not optional for a customer operating to the ISM PROTECTED baseline.

Prompt caching is the largest single lever, cutting cost by 38 to 63% against an uncached baseline. TTL selection within it is a second-order decision that favours the 5-minute default, and section 07 sets out the evidence. Spec-driven development adds a structural second lever. It front-loads reasoning into a stable cached specification, cuts regular input per execution turn by approximately 48%, and removes the most expensive tail-cost scenario in the model, the wrong-direction agentic session.

Overall, a heavy agentic developer costs $151 per month and a heavy DevSecOps developer $66 before that allowance, provided the service enforces the configuration in section 10.

Platform & Pricing

secd3v pins all inference to Australian Amazon Bedrock endpoints in ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne), reached through the AU cross-region inference profile or, in Melbourne, through direct in-region routing. Both options carry a 10% premium over the global endpoint, and that premium is included in every figure in this document. Anthropic's Bedrock documentation states the premium and names the AU inference profile as the mechanism for routing across Australian regions within the geography.

AU rate card

Per million tokens (MTok), on-demand rates, Australian endpoints. Rates derive from Anthropic's published rate card with the 10% Australian endpoint premium applied. Confirm the effective rate in the AWS console, or through the AWS Price List API, before using these figures for contracted forecasting.

Per-model cache limits

AWS publishes the operative limits for the Bedrock API, and all five models in the catalogue support both TTL options with up to four cache checkpoints per request.

The tokenizer difference between generations

Claude 4.7 and later models use a newer tokenizer that produces approximately 30% more tokens for the same text, and Sonnet 4.6 and earlier use the previous one. In the current catalogue this separates Sonnet 5 and Opus 4.8 from Sonnet 4.6, Opus 4.6 and Haiku 4.5. Rate cards do not reflect it, so the effect lands entirely on token volume and stays invisible in a price comparison.

Endpoints and regions

Both Australian regions serve the catalogue, and they differ in how a request reaches them. Sydney routes through the AU cross-region inference profile. Melbourne supports the AU profile and also direct single-region routing without a profile. Both attract the 10% premium.

Context window and quotas

Sonnet 5, Opus 4.8 and Sonnet 4.6 carry a 1M token context window at standard rates with no long-context surcharge. A larger window delays auto-compaction, so sessions accumulate more context before summarisation and per-turn regular input rises even though the per-token rate does not. Treat this as a token-volume effect rather than a pricing effect.

The default Bedrock quota is 2 million input tokens per minute, extensible to 4 million on request without additional Anthropic approval, with requests-per-minute limits enforced separately by AWS. Cache hits are not deducted against rate limits, which makes caching a throughput lever as well as a cost lever.

Overall, the Australian rate card carries a 10% sovereignty premium and a 30% tokenizer effect on the two current-generation models, and cross-region routing can raise cache-write volume independently of developer behaviour.

Development Patterns & Session Definitions

Why DevSecOps is a brownfield pattern

Brownfield development means working on an existing production system with live users, an established architecture, years of accumulated code, technical debt and security constraints under active enforcement. A developer cannot start fresh, cannot discard a wrong implementation without consequence, and cannot hold broad autonomous permissions without risk. In government, defence and high compliance contexts this describes the overwhelming majority of daily work.

DevSecOps is the direct response to those constraints rather than a methodology that happens to sit alongside them. Where a codebase has a security posture that cannot be accidentally degraded and a production environment where mistakes have immediate consequences, the human-gated, incremental, review-at-every-step workflow becomes mandatory rather than optional discipline.

This shapes how the CLI gets used. The developer says "look at auth.py lines 42 to 89 and identify any SQL injection risk" rather than "explore this codebase and make the changes you think are needed". Sessions run short, targeted and bounded, because the work demands precision over autonomy.

Why Agentic is primarily the greenfield pattern

Greenfield development builds a new service, module or application, with no live users to disrupt, no established architecture to break and no accumulated constraints to misunderstand. A wrong-direction implementation gets discarded cheaply, so the cost of an incorrect autonomous attempt stays low. Claude explores, plans and implements, reading many files and building its own context map over long sessions.

Agentic development also suits specific brownfield scenarios, including large-scale migration sprints, comprehensive test generation and automated documentation, provided the developer enters plan mode before any execution, works in a git worktree for isolation, and treats every checkpoint as a safety gate. It does not suit routine brownfield maintenance, security operations, or any work where an incorrect autonomous change reaches production. The session risk profile determines the fit, not the label.

Spec-Driven Development as a structured variant SDD

Spec-driven development overlays the Agentic pattern. The developer authors a structured specification covering interface contracts, data shapes, acceptance criteria, file layout, security constraints and test coverage, then executes against the spec rather than exploring freely.

SDD front-loads the reasoning cost. Reasoning concentrates in a short spec-writing session and every subsequent execution session becomes cheaper and more predictable. Wrong-direction errors surface at spec review, costing roughly 500 tokens to correct, rather than after twenty agentic turns. Regular input per execution turn falls by approximately 48%.

Spec-driven development matters in high-compliance, government and defence work because it establishes the specification as the authoritative source of truth and treats code as a derivative artefact. It replaces loose, non-deterministic prompting with unambiguous, executable contracts grounded in architectural and security constraints. It supports the traceability the Australian Information Security Manual (ISM) and ISO 27001 require, validating every change against documented requirements through automated gates in CI/CD. Security corrections propagate across future regeneration cycles, which mitigates architectural drift and preserves individual human accountability for AI-enabled outcomes in mission-critical environments.

Pattern contrast

Session type definitions: DevSecOps Brownfield

Session type definitions: Agentic Greenfield

Daily usage tier definitions

Permission mode

Overall, the pattern determines the dominant cost driver: DevSecOps spends on cache reads across many short sessions, while Agentic spends on regular input inside a small number of long ones.

Token Modelling & Fixed Context

Claude Code's context is cumulative. Every API call processes the full conversation history to date. The fixed system context is the prime candidate for prompt caching, written once per session and read cheaply on every subsequent turn.

Daily token volumes

Session overheads outside the table above

Seven behaviours consume tokens outside the session shapes in section 03. Three of them bill a full-context turn while the developer is doing nothing. Budget for them at the tier level and control them at the gateway.

Overall, the fixed context is cheap to cache and expensive to ignore, and the six background drivers above are the difference between a modelled budget and an actual invoice.

Model Access Policy & Recommended Splits Service-enforced

Opus costs 2.5 times Sonnet 5 per input token, and 3.25 times once the tokenizer difference is included. Two developer tiers define access. The secd3v Claude Code Service enforces both by role-based routing, per user, per team and organisation wide.

Spec authoring opens Opus access to standard developers on amortisation grounds. A single Opus 4.8 spec session amortises across 40 to 65 Sonnet 5 execution turns. The overhead recovers within the first execution session through reduced file-exploration turns and eliminated wrong-direction corrections. The service implements a spec-write session profile that permits Opus and enforces Sonnet-only for subsequent sessions in the same sprint.

The Haiku share differs between patterns for a reason grounded in task shape. In DevSecOps a substantial fraction of daily interactions, including documentation strings, pipeline status checks, dependency lookups and boilerplate, genuinely do not require Sonnet-level intelligence. In standard Agentic sessions even simple tasks involve sustained multi-turn reasoning where Haiku creates quality drag and more wrong-direction attempts. In spec-driven Agentic, Phase 3 conformance review is pattern matching against defined criteria and Haiku handles it at a third of the cost.

Where the current generation is better, and when to stay put

Sonnet 5 and Opus 4.8 improve on their predecessors on measurable grounds, and the recommendation to select them is not a preference for the newer label.

Overall, the standard-developer split costs 18% less than the senior split on DevSecOps and 22% less on Agentic, and the difference is entirely the Opus share.

Complete Cost Reference

Cost per developer per month (USD), 22 working days, 5-minute TTL, Australian endpoint rates, with the tokenizer multiplier applied to Sonnet 5 and Opus 4.8. Standard = no-Opus split. Senior = limited-Opus split. Per-model pure costs shown only for building custom blends.

How the figures are derived

Each monthly figure applies the section 02 rates to the section 04 daily token volumes across 22 working days, then blends the per-model results by the section 05 splits.

Two assumptions sit behind the volumes and should be stated rather than left implicit. The opening turn of each session carries its context as a cache write rather than as regular input, which is why both the cache-read and regular-input derivations subtract the session count from the turn count. Cache writes then exceed the simple product of sessions and fixed context, because caching writes incrementally as the conversation grows, and that increment is the residual in the cache-write column. On that basis the section 04 volumes follow from the section 03 session definitions as set out below.

DevSecOps (Brownfield): use case A (no MCP)

DevSecOps (Brownfield): use case B (with GitLab MCP)

Agentic (Greenfield): use case A (no MCP)

Agentic (Greenfield): use case B (with GitLab MCP)

Pattern comparison: standard developer policy

Scope of these figures, and the complementary activity allowance

Every figure in this document models software development: reading and writing code, reviewing changes, generating tests, auditing for security defects, and building services against a specification. The session definitions in section 03 are drawn from that work and nothing else.

Developers also use the agent for content activities that sit alongside development and are not costed above. These include long-form documentation, release notes and changelogs, merge request and release summarisation, architecture and sequence diagrams, commit message drafting, incident write-ups, runbooks, onboarding material, and open-ended explanations of unfamiliar code. Some of this work appears in the model only incidentally, through the documentation update and quick explanation examples in the DevSecOps micro session, and the rest is absent.

These sessions carry a different token shape from development work. They run short, they read a bounded amount of context, and they produce a great deal of output, which is the most expensive token category at five times the input rate. One such session per day, modelled at 6 turns with 4,000 tokens of regular input per turn and 1,500 tokens of output per turn on the standard developer split, costs approximately $5.22 per month.

Overall, spec-driven development delivers the largest single return on investment available in the model, cutting heavy agentic spend by 28% for the cost of one authoring session per sprint, and a 10% allowance covers the content activities these figures exclude.

Prompt Caching & TTL Selection

Prompt caching is the largest cost lever in this model. Without it, the fixed system context bills as full-price regular input on every API call. Prompt caching is enabled by default on the Bedrock API, and the 5-minute TTL applies unless a request specifies otherwise.

Caching against a no-cache baseline

Standard developer blend, 5-minute TTL, AU regional.

The 5-minute TTL is the correct default, and the evidence is the vendors' own

AWS and Anthropic both publish the same guidance, and both frame the 5-minute cache as the default for regularly used prompts rather than as a limitation to be worked around.

A Claude Code session is a tool-use loop in which one conversational turn issues many API requests seconds apart, so the gaps that matter are genuine idle periods rather than turn boundaries. That is precisely the regular cadence the vendor guidance describes. Production telemetry agrees: cache hit rates exceed 90% on the 5-minute TTL across Claude Code and Claude Code Service usage.

What the 1-hour TTL costs when expiry does not occur

When to select the 1-hour TTL

Cache misses a longer TTL will not fix

Where residual misses come from invalidation rather than expiry, a longer TTL buys nothing and costs the premium. Six documented causes apply.

Overall, caching delivers 38–63% against an uncached baseline, and the 5-minute default captures that saving with no configuration and no premium.

Developer Cost Optimisation Factors

After model policy and caching configuration, developer behaviour controls cost. Each factor below is validated against Anthropic's Claude Code best practices documentation.

Overall, prompt specificity, plan mode and spec authoring carry the highest return of the twelve factors, and the remainder protect that return rather than add to it.

Opus Approval Guide Senior Access

Opus is justified where the task requires novel reasoning under genuine ambiguity, sustained autonomous operation over many turns, or where downstream error costs are high enough that a reasoning gap materially changes outcomes. Source the current benchmark comparison from Anthropic's model cards before quoting figures in a business case.

Spec authoring introduces an Opus justification that applies to all developer tiers. A single Opus 4.8 spec session producing a tight 1,500–2,500 token specification amortises across 40–65 Sonnet 5 execution turns, and the cost recovers within the first execution session.

Overall, four scenarios justify Opus outright, two are conditional on Sonnet 5 failing first, and seven do not justify it at any tier.

Mandatory Service Configuration

Overall, the agent teams flag carries the largest single financial risk at roughly 7 times token usage, and the caching default carries the largest recurring one.

Telemetry & Cost Attribution

Claude Code sends no usage metrics to Anthropic, so attribution comes from the request path. Because every inference request passes through the CCS gateway, the gateway is the natural and complete point of measurement, and the accounting planes described in the CCS gateway high level design are where per-user consumption is recorded. The gateway also assumes its upstream role per user with session tags, which carries the same attribution into the AWS audit trail, so CloudTrail corroborates the gateway record rather than substituting for it.

Telemetry signals

Every signal below derives from request metadata recorded at the gateway, apart from the CLAUDE.md check, which is endpoint-side.

Overall, customers should conduct a recurring 30-day telemetry review against the signals above, restating the estimated inputs in this model from measured data and reissuing the affected tables.