Anthropic: from model training to the Claude API

I would anchor it in a written policy like Anthropic's Responsible Scaling Policy. Define capability thresholds in risky domains, such as biology or autonomous replication, and map each to required deployment and security safeguards. Every candidate model runs a fixed evaluation suite with serious elicitation effort, plus red teaming and external testing. Results go to a decision owner who is separate from the product team, and the default if a threshold is crossed without safeguards is to hold or mitigate, not ship. I would log the decision, publish a model card, and re-run evals after significant post-training changes. The key design idea is that the gate is about measured capability, so a deadline cannot override it.

I'd split it into four planes. The data plane collects public web data, licensed data, opted-in user data and synthetic data, then filters and deduplicates it. The training plane pretrains a base model on large accelerator clusters and post-trains it with RLHF and Constitutional AI. The governance plane runs Responsible Scaling Policy evaluations, assigns an AI Safety Level and blocks release until the matching safeguards exist. The serving plane releases the model in stages, then handles Messages API traffic: key authentication, tiered rate limits, prompt caching, inference and streaming, usage metering and misuse monitoring. Enforcement findings feed back into safeguards and the next training cycle. Two invariants cut across every plane: capability never outruns safeguards, and tenants stay isolated.

Anthropic documents its limits as token buckets, which refill continuously up to a maximum rather than resetting at fixed intervals. For output tokens, admission uses an estimate based on the request's max_tokens, then reconciles against actual output when the response completes. Input tokens can be counted at admission, and for most current models cached reads don't count toward the input-token limit. The buckets live in a low-latency distributed store keyed by organisation and model. To keep latency down I'd allow small, bounded over-admission rather than a strongly consistent global counter. A rejection returns 429 with a retry-after header and rate-limit headers describing remaining capacity.

Make tenant identity part of the cache key, not a check performed after lookup. The key combines the isolation scope, which Anthropic documents as at least the organisation, with the model and a hash of the exact prefix up to the breakpoint. Two tenants with byte-identical prompts therefore get different entries. There is no cross-tenant cache to probe, so no timing side channel. Cache storage is in-memory or short-lived, with TTL eviction. Entries are never written to training data or logs as content. I'd add tests that send identical prefixes from different organisations and assert there are no cache reads, plus audits on the key-construction code, since a bug there would be a cross-tenant data leak.

Constitutional AI, described in Anthropic's 2022 paper, trains a model using a written set of principles. In a supervised phase, the model critiques and revises its own answers against those principles. In a reinforcement phase, a model compares pairs of responses according to the constitution, producing AI preference labels used to train a reward model, which is called RL from AI feedback. Human feedback is still valuable for helpfulness and nuance, but labelling large amounts of harmful content is slow, costly and hard on labellers. A constitution makes the target values explicit and editable, and it scales. The trade-off is that quality depends on the principles and on the judging model, so you still need human review and evaluations.

I would rate limit per organisation and tier on three axes: requests per minute, input tokens per minute and output tokens per minute, because GPU cost follows tokens. A token bucket at the gateway gives smooth enforcement, and over-limit calls get a 429 with a retry-after header, while overload returns a distinct error so clients can tell the difference. For caching, the client marks a stable prefix such as the system prompt, tools or a long document. The server hashes that exact prefix, scoped to the organisation, and stores the computed attention state with a short time-to-live. Matching requests skip recomputing it, cutting latency and cost. Usage responses report cache reads and writes separately, so developers can verify savings.

I'd run it as a batch pipeline over sharded object storage, with every stage writing versioned outputs so a run can be reproduced. Stage one handles provenance and policy: record source and licence, and honour crawler rules such as robots.txt and the exclusion of password-protected pages. Stage two is quality and safety filtering with heuristics and classifiers, plus PII handling. Stage three is deduplication: exact hashing for identical documents, then MinHash with locality-sensitive hashing for near-duplicates, run at document and paragraph level. Stage four decontaminates by removing overlap with held-out evaluation sets. I'd keep per-stage drop statistics and spot-check samples so that one filter bug can't silently remove whole domains or languages.

If evaluation items leak into training, scores go up through memorisation rather than real capability. For capability benchmarks that only flatters the model. For dangerous-capability evals it is worse, because it corrupts the measurement the release gate depends on. I'd register every eval set with canary strings and n-gram fingerprints, then scan the training corpus against them before training starts. Sensitive evals stay in access-controlled stores that are never crawled or exported. I'd also keep private, regularly refreshed held-out sets and compare performance on public and private variants. A large gap between them is a contamination signal and should trigger investigation before the result counts toward an ASL decision.

At this scale, hardware failure is routine, so the design has to assume it. I'd take frequent asynchronous sharded checkpoints of weights, optimizer state, data-loader position and RNG state to durable storage, so a restart resumes deterministically. Health checks and straggler detection find bad nodes, and a scheduler swaps in hot spares and restarts from the last checkpoint automatically. I'd watch for loss spikes and NaNs, with a playbook to roll back to an earlier checkpoint, skip the offending data and adjust the learning rate. Checkpoint frequency is a trade-off: checkpointing too often costs throughput and storage bandwidth, while checkpointing too rarely wastes compute on every failure.

Humans compare pairs of model responses. A reward or preference model learns to predict those preferences, and the policy is then optimised with RL against it, usually with a KL penalty that keeps it close to the supervised model. Reward hacking happens when the policy exploits weaknesses in the reward model: excessive length, sycophancy, confident-sounding but wrong answers, or gaming of test checks in coding tasks. Mitigations include a KL constraint, ensembles and periodic retraining of reward models on fresh comparisons, held-out human evaluation, and targeted evals for sycophancy and honesty. I'd also audit samples where reward is high but humans disagree, since those show exactly where the proxy diverges.

I'd build an isolated, access-controlled evaluation environment, because both the questions and the transcripts are sensitive. Tasks cover knowledge probes, multi-step agentic tasks in sandboxes with tools, and expert-graded uplift studies that compare people with and without model access. Each eval is versioned, has a pre-registered threshold tied to an RSP capability threshold, and runs on the final candidate and on any snapshot meant for release. Results go into a capability report that records the elicitation used, such as scaffolding, tool access and best-of-n sampling. Sandboxes for autonomy tasks need network egress controls and monitoring. Nothing produced in them should be able to touch production systems.

Anthropic's ASL-3 standard has two parts, which it publicly activated with Claude Opus 4 in 2025. Deployment safeguards aim to stop misuse for CBRN weapons. They include real-time constitutional classifiers on inputs and outputs, ongoing jailbreak monitoring, a bug bounty for universal jailbreaks, and rapid response to patch new attacks. Security safeguards aim to prevent theft of model weights. They include stronger access controls, two-party authorisation for sensitive access, and egress bandwidth controls that make large exfiltration hard to do and easy to detect. Both parts have to be judged adequate before deployment. A model that needs ASL-3 does not ship under ASL-2 protections just because the release date is near.

I'd treat the weights as a crown-jewel asset. Store them encrypted, with keys held in hardware-backed key management. Restrict access to a small, audited set of identities using least privilege, and require two-party approval for any sensitive operation, such as copying weights or accessing them in plaintext. Serving nodes load weights into hardened environments with no general interactive access. Egress bandwidth limits and monitoring on the networks that hold weights make a bulk copy slow and noisy. I'd add full audit logs, anomaly detection, supply-chain controls on serving software, and regular red-team exercises. Insider risk gets the same rigour as external risk, because one compromised credential shouldn't be enough.

Define stages as ring deployments: internal use, trusted testers under agreements, limited preview, then GA across the API, apps and cloud partners. Each ring has exit criteria: no unresolved severe safety findings, classifier and abuse metrics within bounds, error rates and latency within SLO, and enough capacity for the next ring. Model routing is controlled by configuration, so an organisation's access can be widened or pulled back without redeploying. Rollback means removing access to the new model ID or tightening safeguards. You don't silently swap weights behind a pinned model ID, because customers depend on stable behaviour. Release artefacts such as the system card and usage policy updates are finalised before GA, not after.

The client sends the key in the x-api-key header, alongside an anthropic-version header. At the edge, I'd hash the presented key and look it up in a replicated key store that maps it to organisation, workspace, tier and status, cached briefly so revocation propagates within seconds. Keys are shown once at creation, stored only as hashes, scoped to workspaces, and can be revoked from the console. Anthropic participates in secret-scanning programmes so that keys leaked to public repositories can be detected and deactivated. Every request is attributed to a key and organisation for rate limiting, billing and abuse investigation. Failed authentication returns 401 quickly, without touching inference capacity.

A 429 means this organisation exceeded its own rate limit. It is the caller's quota, and the fix is to slow down, respect retry-after, or move to a higher tier. A 529 overloaded_error means the service as a whole is temporarily overloaded, independent of the caller's quota. Clients should retry both with exponential backoff and jitter, cap total retries, and avoid synchronised retry storms. The official SDKs retry certain errors by default. On the server, load shedding should happen early and cheaply at admission, before tokens are processed, and priority or committed capacity can be protected while best-effort traffic is shed first.

The cacheable prefix is built in a fixed order: tools, then system, then messages, up to a block marked with cache_control. You can set up to four breakpoints. A hit requires the prefix to be identical up to that breakpoint, so any change earlier in the order invalidates everything after it. Editing a tool definition invalidates the system and message cache. Editing the system prompt invalidates the messages. Changes to some settings, such as images or tool_choice, can also break hits. Entries expire by TTL: five minutes by default, refreshed on each hit, with an optional one-hour TTL. The design advice is to put stable content first and volatile content last.

The Messages API streams over server-sent events with a typed sequence: message_start, content_block_start, repeated content_block_delta, content_block_stop, message_delta carrying the stop reason and usage, then message_stop, plus ping events. Typed blocks let text and tool-use JSON stream on the same channel. Errors can also arrive as an event mid-stream, after a 200 has been sent, so clients must handle in-stream error events. If the connection drops, the request does not resume. The client retries, and the prefix cache makes the retry cheaper. Server-side, generation should be cancelled when the client disconnects, to free capacity, and usage should be billed for the tokens actually processed.

Each request has a unique request ID, returned to the caller in a response header. At completion, the serving layer emits one usage event with organisation, workspace, key, model, input tokens, cache-creation tokens, cache-read tokens and output tokens. Events go to a durable log with at-least-once delivery, and consumers deduplicate on request ID, which gives effectively-once aggregation. Real-time counters for the console can be approximate. Invoices come from the reconciled ledger. I'd keep pricing in versioned rate tables applied at aggregation time, so a price change never rewrites history. Daily reconciliation compares serving logs, rate-limit counters and the ledger to catch dropped or duplicated events.

Use layers. Automated classifiers score traffic for high-severity categories in real time or near real time, and constitutional classifiers block certain CBRN content inline. Account-level signals, such as volume patterns and repeated flagged requests, feed trust-and-safety review, with enforcement that ranges from warnings to suspension. For understanding aggregate patterns, Anthropic has described Clio, which summarises and clusters conversations so analysts see aggregated trends rather than individual chats. Access to raw content is restricted, logged and justified case by case. Retention follows published policies and contractual terms such as zero-data-retention arrangements. I'd track classifier false positives carefully, because over-blocking legitimate developers is also a failure.

They fit scaling laws on smaller runs, which relate loss to parameters, data and compute, and use them to choose a compute-efficient model size and token budget for the target budget. During the run they track training loss and a suite of downstream evals at checkpoints, and compare the trajectory with the prediction. For safety, this trend tracking feeds the RSP: if checkpoints are on course to approach a capability threshold, the safeguards work has to start early rather than at release time. The key point is that the gate is only useful if capability is forecast ahead of time. Discovering a threshold crossing at the end leaves no time to build safeguards.

The upside is capacity and resilience. You aren't limited by one vendor's supply, you can place workloads where capacity and cost-efficiency are best, and you can serve close to cloud partners like Bedrock and Vertex AI. The cost is engineering complexity. Kernels, compilers, parallelism strategies and numerics differ by chip, so you need a portable model definition, per-backend optimisation, and strong numerical equivalence tests so the same weights behave the same on every platform. Performance tuning is duplicated, and debugging spans multiple toolchains. To manage this, I'd keep a single source of truth for model code, add hardware-specific backends behind it, and run cross-platform eval regression suites before any deployment.

The gate asks whether the model could provide dangerous capability, not whether it did so under a lazy prompt. If you under-elicit, you understate capability and might deploy with too little protection. Real attackers will use good prompting, agent scaffolds, tools, fine-tuning where it's available and many attempts. So evaluators should use strong prompts, chain-of-thought, tool use, multiple samples and, where it makes sense, helpful-only variants without refusal training. They should also add a safety margin for capability gains likely to come from better scaffolding after release. The conservative principle is that uncertainty about whether a threshold is crossed should push you toward assuming it is crossed.

Treat the model as an immutable versioned artefact: the same weights, tokenizer and default configuration, identified by a dated snapshot ID. Every surface gets a conformance test suite that checks outputs, tool-use formats, stop behaviour and safety behaviour against reference results. Usage policies and acceptable-use requirements apply on every surface, though the partner platforms run their own authentication, quotas and billing. Feature availability, such as particular beta features, can lag on partner platforms. So I'd publish a feature matrix rather than assume parity. I'd also monitor cross-surface metrics, so a numerical or configuration drift on one platform shows up as an anomaly instead of waiting for a customer report.

What gets reused is the attention key-value state computed for the prefix, so the model skips recomputing it. That state is large, so it lives in accelerator memory or a nearby fast tier, and routing needs to send requests to replicas that hold, or can quickly fetch, the prefix state. TTL is a cost and capacity trade-off. A longer TTL raises hit rates for bursty workloads but holds scarce memory longer. That is why the one-hour option has a higher write price than the five-minute default, and why the five-minute TTL refreshes on each hit. Eviction must be safe: a miss only costs recomputation, never correctness, so the cache can be dropped under pressure.

I'd state assumptions explicitly rather than quote real figures. Start with peak requests per second, average input and output tokens per request, and expected cache hit rate. Prefill cost scales with uncached input tokens, and decode cost scales with output tokens. Decode is usually the bottleneck because it runs token by token. Then measure a single replica's sustainable throughput at the target latency, for example time to first token and tokens per second per stream, under realistic batching. Divide peak load by per-replica throughput and add headroom for failures, deployments and burst. Caching mainly reduces prefill, so a high hit rate raises effective capacity for long-context workloads more than for short chatty ones.

Misuse findings mostly feed the safeguards first. New jailbreak patterns become classifier training data and red-team cases, and recurring harmful request types become eval items and post-training targets for the next model. Governance is strict about what can be used. By default, commercial API inputs and outputs are not used to train models. Consumer conversations are used only if the user opted in. Flagged content may be reviewed for trust and safety under published policy. In practice, I'd pass abstracted patterns and synthetic reproductions into training rather than raw customer data, tag every dataset with its provenance and allowed uses, and have the pipeline refuse data lacking a permitted-use tag.

Publish immutable, dated snapshot IDs and, optionally, aliases that move to newer snapshots. Production customers should pin snapshots, because the snapshot's behaviour is fixed. Aliases suit experimentation. Changes to a model's behaviour ship as a new snapshot rather than as silent in-place updates, apart from safety-critical safeguard changes in the classifier layer. Deprecation follows a published schedule with advance notice, deprecation status in docs and console, and a retirement date after which requests fail clearly. Anthropic has also published commitments about preserving retired model weights. Internally, I'd track usage by model ID so the team can contact remaining users before retirement.

Score the input before generation starts, since that is cheap relative to decoding and lets you block early. For outputs, run a streaming classifier over chunks as they are generated. If it fires, stop the stream and return a refusal instead of waiting for the full response. The classifier has to be fast and calibrated, so you tune thresholds per harm category. The aim is to block high-severity content such as CBRN uplift with high recall, while keeping false positives on legitimate science questions low. Apply the strictest inline checks only where the risk justifies them, rely on asynchronous monitoring for lower-severity policies, and measure added latency as a first-class SLO.

I'd turn the intended traits into concrete, testable behaviours and build an eval suite around them. Honesty evals check calibration, admitting uncertainty, and not inventing facts or citations. Sycophancy evals check whether the model changes a correct answer under user pressure. Refusal evals measure both sides: harmful requests should be declined, and benign but borderline requests should not be over-refused. Character consistency gets checked across long multi-turn conversations and personas. I'd combine automated graders with human review, track every metric per checkpoint, and treat a regression on either harmfulness or over-refusal as a release blocker. Optimising one side alone is the classic failure.

Give them access through a controlled channel rather than handing over weights. For example, an API endpoint to a specific pre-release snapshot, with logging, rate limits and scoped credentials that expire after the testing window. Agree in advance on the domains they will test, the timeline and how findings are reported, so their results arrive in time to inform the ASL decision rather than after launch. Sensitive test content and transcripts stay protected on both sides. Findings go into the same tracking system as internal red-team issues, with owners and resolutions. The value is independent scrutiny. The risk is leakage of an unreleased model, so isolation and auditing matter.

A system card describes what the model is and how it was tested. That covers training data at a high level, intended uses, capability benchmark results, safety evaluations including dangerous-capability results and the AI Safety Level decision, red-teaming and external testing, alignment and welfare-related findings where relevant, and known limitations. Publishing it creates accountability. Outsiders can scrutinise the evidence behind a deployment decision, developers learn where the model is weak, and the lab commits to a record it can be held to. The engineering implication is that eval pipelines must produce reproducible, reportable results. If a number can't be traced back to a versioned eval run, it shouldn't appear in the card.

Use batches for large workloads that aren't latency-sensitive, such as classification, evaluation runs, document processing or data generation. The Batches API processes requests asynchronously, typically completing within 24 hours, and is priced at a discount compared with standard calls. From the provider's side, batches are easier to schedule into idle capacity. That lets you smooth load and protect real-time traffic. Batches can also be combined with prompt caching for shared prefixes. The trade-offs are no streaming, no interactive tool loops, and result retrieval that must handle partial failures per request. Real-time calls remain the right choice for chat, agents and anything user-facing.

1. A5 minutes, refreshed each time the cache is readCorrect answer
2. B24 hours
3. CUntil the organisation clears it manually
4. D30 seconds, fixed

Why: The default ephemeral cache lasts five minutes and is refreshed on each hit. A longer one-hour TTL is available as an option at a higher write price.

1. ADo not deploy until the required safeguards are in place, or mitigate the modelCorrect answer
2. BPublish the results and let users decide
3. CShip on schedule and add safeguards later
4. DShip only to enterprise customers

Why: The RSP's core commitment is that a model is not deployed without the safeguards matching its capability level.

1. AWhether safeguards matching its assessed AI Safety Level are in placeCorrect answer
2. BWhether the training run finished on schedule
3. CWhether enterprise customers have signed contracts
4. DWhether it beats competitors on public benchmarks

Why: The RSP ties deployment to capability thresholds; a model that reaches a given AI Safety Level must have the corresponding safeguards before release.

1. AOnly paid human labellers
2. BA model judging responses against written principlesCorrect answer
3. CUser thumbs-up clicks in production
4. DKeyword filters on outputs

Why: RL from AI feedback uses a model guided by the constitution to compare responses, producing preference data that trains the reward model.

1. Asystem, messages, tools
2. Btools, system, messagesCorrect answer
3. COrder does not matter; matching is content-based
4. Dmessages, system, tools

Why: The prefix is built as tools, then system, then messages. A change earlier in that order invalidates the cache for everything after it.

1. Acache_creation_input_tokens
2. Bcache_read_input_tokensCorrect answer
3. Coutput_tokens
4. Dstop_reason

Why: cache_read_input_tokens counts tokens read from cache. cache_creation_input_tokens counts tokens written to cache on a miss.

1. ASliding log of every request
2. BFixed window counter reset every minute
3. CToken bucket with continuous replenishmentCorrect answer
4. DLeaky bucket with no burst capacity

Why: Anthropic's documentation says capacity replenishes continuously up to a maximum, which is the token bucket model, rather than resetting at fixed intervals.

1. ARotate to a different organisation's API key
2. BSwitch to a larger max_tokens value
3. CRetry immediately in a tight loop
4. DWait according to the retry-after header, using backoff with jitterCorrect answer

Why: The 429 includes a retry-after header, and backoff with jitter avoids synchronised retry storms. Using other tenants' keys would violate policy.

1. AThe model critiques and revises its own responses using constitutional principles, and is fine-tuned on the revisionsCorrect answer
2. BThe model is pretrained again on filtered web data
3. CA classifier deletes harmful tokens at inference time
4. DHumans write gold answers for every harmful prompt

Why: In the supervised phase the model critiques and revises its own outputs against the constitution, and is then fine-tuned on the revised responses. The RL phase uses AI feedback.

1. AImage generation and audio
2. BTranslation quality and summarisation
3. CCBRN weapons and autonomous AI research and developmentCorrect answer
4. DCode formatting and latency

Why: The RSP defines capability thresholds around CBRN weapons uplift and autonomous AI R&D, and those thresholds trigger stronger required safeguards.

1. ACaches are isolated so different organisations never share cache entriesCorrect answer
2. BCaches are shared within a cloud region
3. CIsolation applies only to the one-hour TTL
4. DIdentical prompts from any customer share one cache entry

Why: Anthropic documents that prompt caches are isolated between organisations, so identical prefixes from different tenants never produce cross-tenant hits.

1. AThe same API key and any prompt
2. BThe same conversation ID
3. CSemantic similarity above a threshold
4. DAn identical prefix up to the cache breakpointCorrect answer

Why: Caching uses exact prefix matching, so even small changes before the breakpoint cause a miss.

1. AgRPC bidirectional streams
2. BServer-sent eventsCorrect answer
3. CLong polling
4. DWebSockets

Why: Streaming uses server-sent events with typed events such as message_start, content_block_delta and message_stop.

1. AOnly for requests that hit rate limits
2. BYes, always
3. CNo, not by defaultCorrect answer
4. DOnly for cached prompts

Why: Anthropic's commercial terms state that it does not train on customer API data by default. Consumer data is used only when the user opts in.

1. AContent that changes per request sits before the cache breakpointCorrect answer
2. BThe API key is on a high usage tier
3. COutput tokens are too long
4. DThe model does not support streaming

Why: Caching matches an exact prefix, so any varying content before the cache_control breakpoint breaks the match and forces a fresh cache write each time.

1. AThe caller's API key is invalid
2. BThe caller exceeded its own rate limit
3. CThe service is temporarily overloaded across usersCorrect answer
4. DThe request body was malformed

Why: 529 signals service-wide overload. 429 is the per-organisation rate-limit response.

1. A4Correct answer
2. BUnlimited
3. C1
4. D2

Why: The API allows up to four cache breakpoints per request, which lets you cache tools, system and conversation segments separately.

1. AClaude 2
2. BClaude 3 Opus
3. CClaude Opus 4Correct answer
4. DClaude Instant

Why: In May 2025 Anthropic activated ASL-3 deployment and security standards alongside the launch of Claude Opus 4.

1. ANothing; tools are excluded from caching
2. BThe cache TTL is extended
3. COnly the tools segment misses; the system prompt still hits
4. DThe whole cached prefix is invalidated, because tools come firstCorrect answer

Why: Tools sit at the start of the prefix, so changing them alters every later part of the prefix and invalidates the system and message cache.

1. AAuthorization: Basic and X-Version
2. Bx-api-key and anthropic-versionCorrect answer
3. CCookie and User-Agent
4. Dapi-token and model-version

Why: Direct API calls send the key in x-api-key and require the anthropic-version header.

1. AA way to bypass rate limits for real-time chat
2. BA fine-tuning endpoint
3. CSynchronous, streamed responses at premium pricing
4. DAsynchronous processing of many requests, typically within 24 hours, at a discountCorrect answer

Why: Batches are processed asynchronously, usually within 24 hours, at a discount compared with standard calls, which suits latency-tolerant bulk work.

1. ATo make training non-deterministic
2. BTo increase the total token count
3. CTo reduce memorisation, wasted compute and evaluation contaminationCorrect answer
4. DTo remove every non-English text

Why: Duplicates encourage memorisation, waste compute and can leak evaluation items. Deduplication improves data efficiency and makes measurement more trustworthy.

1. ARaising API rate limits
2. BPublishing weights for transparency
3. CEgress bandwidth controls and two-party authorisation for sensitive accessCorrect answer
4. DRemoving all access logs to protect privacy

Why: Anthropic described egress bandwidth controls and multi-party access controls among its ASL-3 weight-protection measures.

1. AScreening inputs and outputs to block harmful content such as CBRN uplift, including jailbreak attemptsCorrect answer
2. BRouting requests to the cheapest model
3. CComputing billing totals
4. DTokenising input text

Why: Constitutional classifiers are trained from a constitution of allowed and disallowed content and screen inputs and outputs. They are a key ASL-3 deployment safeguard.

1. AThe policy exploiting weaknesses in the learned reward to score highly without truly being betterCorrect answer
2. BHumans labelling too slowly
3. CRewards overflowing numerically
4. DAttackers stealing the reward model

Why: The policy optimises a proxy reward, so it can learn behaviours such as verbosity or sycophancy that the reward model overrates.

1. AAbout 10% of base inputCorrect answer
2. BTwice base input
3. CFree with no charge
4. DThe same as base input

Why: Cache reads are billed at a fraction of base input, published as 0.1x. Five-minute cache writes cost 1.25x base input.

1. Acache_control is only allowed on messages
2. BThe prefix is below the model's minimum cacheable length, so it is processed without cachingCorrect answer
3. CCaching requires the Batches API
4. DThe anthropic-version header disables caching

Why: Each model has a minimum cacheable prompt length, for example 1,024 tokens for many models. Shorter prefixes are processed normally without caching.

1. ADeduplicate events on a unique request ID before aggregationCorrect answer
2. BBill an average per day
3. CIgnore events that arrive late
4. DSwitch to at-most-once delivery

Why: Idempotent consumers keyed on request ID turn at-least-once delivery into effectively-once aggregation without losing events.

1. ABy advancing through usage tiers based on spend, or by arranging custom limits with salesCorrect answer
2. BBy creating many free accounts
3. CLimits are identical for everyone
4. DBy sending more 429-triggering traffic

Why: Rate limits increase automatically as organisations move up usage tiers, and custom limits are available through Anthropic's sales team.

1. AThey count only toward requests per minute
2. BThey count toward output tokens
3. CThey count double
4. DThey do not count toward the input-tokens-per-minute limitCorrect answer

Why: Anthropic documents that cached input tokens read from cache do not count toward ITPM for most models, so caching also increases effective throughput.

1. AIt guarantees zero jailbreaks
2. BIt lowers training cost
3. CIt exposes the model to progressively wider use, so real-world issues surface while access is still limited and reversibleCorrect answer
4. DIt removes the need for evaluations

Why: Staged rings limit the blast radius and give time to detect misuse and failures before broad deployment.

1. AOnly internal teams
2. BGovernment AI safety institutes in the US and the UKCorrect answer
3. CRandom customers selected by lottery
4. DCloud partners' billing teams

Why: Anthropic has published that the US and UK government AI safety and security institutes tested models before deployment.

1. AA privacy-preserving system for analysing aggregate patterns of Claude usageCorrect answer
2. BA rate-limiting service
3. CA tokenizer
4. DA model-weights encryption tool

Why: Clio summarises and clusters conversations so analysts can study usage and misuse trends in aggregate without reading individual chats.