The number that matters is this one: how many of your Lambda functions can actually run on ARM64 today — not in theory, not on a clean greenfield stack, but with your actual dependencies, your actual Python version, and your actual C extensions.

For Parjanya, an ML-powered image quality pipeline, the answer started at 1 out of 4. That gap — between what Graviton promises and what your stack allows — is almost entirely explained by a single, under appreciated concept: the ARM wheel.

This article explains what ARM wheels are, why they are the gatekeeper to Graviton savings, how the Parjanya re-architecture navigated them, and how to build a framework for evaluating Graviton readiness in any product.

First, an Honest Framing of the 34% Number

AWS’s stated price-performance advantage for Graviton Lambda comes from two compounding factors:

Pricing: ARM64 Lambda is priced approximately 20% lower per GB-second than equivalent x86 Lambda. This is a direct line-item discount.

Performance: For SIMD-heavy workloads — image processing, compression, media encoding — ARM NEON instruction sets often complete work faster than x86 AVX-512 for the same memory allocation, which effectively reduces billed duration.

In Parjanya’s $10 POC (running PIL-based image processing against Graviton4 and Intel x86), the empirical result was a 24% cost delta — Intel x86 cost 24% more for identical or worse performance. AWS’s 34% claim holds at the higher end because it accounts for the full price-performance package including EC2 and container workloads.

The savings are real. The caveat is that they only materialise if your software stack is compatible.

What Is an ARM Wheel?

Before evaluating Graviton readiness, you need to understand what a Python wheel is and why the ARM variant specifically matters.

A wheel (.whl) is a pre-built binary distribution of a Python package. When you run pip install numpy, pip looks for a wheel that matches your platform. If it finds one, it downloads and installs it directly — no compilation required. If it does not, pip falls back to downloading source code and compiling it locally.

For pure Python packages, this distinction is irrelevant. The bytecode runs anywhere.

For packages with native C/C++ extensions — NumPy, Pillow, OpenCV, PyTorch, SciPy, and most of the ML ecosystem — a wheel is architecture-specific. A wheel built for x86_64 will not install on aarch64. The package must publish a separate wheel for ARM64.

The naming convention tells you exactly what architecture a wheel targets:

numpy-1.26.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl   # x86
numpy-1.26.4-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl  # ARM64

The aarch64 suffix is what you are looking for. If it exists, installation is clean. If it does not, you are in source-build territory — and source builds in Lambda container images introduce a layer of complexity that breaks most “just change the architecture flag” migration plans.

The Four States of a Dependency

When evaluating a Python service for ARM64 migration, every dependency falls into one of four categories:

This matrix is the actual output of a Graviton readiness assessment. Not a benchmark. Not a cost model. The wheel matrix.

The Parjanya Case Study: From 1/4 to 3/4

Parjanya’s pipeline had four compute stages, each containerised and isolated. When the first Graviton migration attempt was made, only one — the deduplication stage — made it onto ARM64. The other three were blocked.

Here is what happened at each stage:

Stage 1: RAW Processing (Blocked → Eventually Bypassed)

Canon CR3 RAW files require binary parsing to extract embedded JPEGs. The dependency chain pulled in native image parsers without clean aarch64 wheels. Compilation from source failed or produced unstable binaries in the Lambda container environment.

Resolution: The stage architecture changed. Rather than fight a fragile native dependency chain, the pipeline design shifted to extract JPEG previews at ingest — earlier in the flow — reducing the surface area where native RAW parsing was required.

Stage 2: CLIP-IQA Scoring (Blocked → Replaced)

CLIP-IQA was being used for visual quality scoring. It had two problems, not one:

1. Wheel problem: The ARM64 wheel chain for its dependencies was incomplete. Installing it in a Graviton Lambda container was unreliable.

2. Model problem: CLIP-IQA was trained on stock photos, not professional RAW captures. It accepted only ~1% of professional images, making it useless for the actual curation use case.

Resolution: The entire stage was replaced with a rule-based technical validator — exposure clipping detection, blur scoring, sharpness scoring, and perceptual hashing. No ML forward pass. No compiled extensions in the hot path. The new validator ran in pure Python, deployed cleanly on ARM64, and executed in under 100ms per image.

This is the single most important insight from the Parjanya migration:

The fastest path to ARM64 is sometimes not to migrate the workload. It is to replace the workload.

The new parjanya-technical_validator runs on arm64 with Python 3.12 and 512 MB memory. It is not a compromise — it is measurably better: faster, cheaper, more correct, and production-verified.

Stage 3: GPU Inference (Intentional Hard Boundary)

The VLM inference stage runs Qwen3-VL-8B-Instruct and requires CUDA. CUDA is the hard architectural boundary.

CUDA is NVIDIA’s parallel computing platform. It runs on NVIDIA GPUs, which are paired with x86_64 hosts in most production setups including AWS g5 instances. There is no ARM64 CUDA story in Lambda.

Resolution: The GPU inference stage was not migrated. Instead, the control plane was separated from execution:

• A lightweight Lambda — ARM64 — handles scheduling logic: when to scale the GPU fleet, when to drain it

• The actual VLM inference runs on EC2 g5 instances in an Auto Scaling Group

• The Lambda no longer needs ML libraries, so it migrated to Graviton without any dependency issues

This is architectural isolation — moving the ARM64-compatible logic (scheduling, orchestration) onto Graviton and leaving the ARM64-incompatible logic (GPU inference) exactly where it belongs.

Stage 4: Deduplication (Original Success)

Small, CPU-bound, dependency-light. Perceptual hashing with no native C extensions in the hot path. This was the function that migrated cleanly from day one, and it remains the model for what “Graviton-ready” looks like: pure logic, minimal native dependencies, well-supported Python ecosystem.

The Current State

Three of four Lambda functions on Graviton (+1 scheduler). The remaining x86 workload is the one that genuinely belongs there.

Why ARM Wheels Fail: The Root Causes

Understanding why a package lacks an ARM64 wheel helps you predict and resolve failures faster.

1. The package maintainer hasn’t built it yet

Many packages added aarch64 wheel support in 2022–2024 as AWS Graviton gained adoption. Packages that haven’t been updated since then may still not publish ARM64 wheels. This is solvable by checking the current release on PyPI — support often appears in later versions.

2. GLIBC version mismatch

Lambda’s ARM64 runtime uses Amazon Linux 2023. A wheel built against an older GLIBC version (manylinux2014) may not install cleanly in that environment. When you see installation errors that reference GLIBC, this is the cause. The fix is to build your container image from the correct ARM64 base image and verify wheel compatibility inside it — not on your development machine.

3. Transitive dependencies break the chain

Even if the top-level package publishes an ARM64 wheel, its transitive dependencies may not. OpenCV is a canonical example: opencv-python may install, but a transitive dependency on a specific image codec library may not have an ARM64 wheel. The failure surface is the entire dependency tree, not just the packages you explicitly listed.

4. ABI incompatibility

Some packages have version-specific ABI contracts. A package pinned to an older version may have published an x86_64 wheel for that version but not an ARM64 one. When you pin for stability and the pinned version predates ARM64 support, you are stuck — until you unpin.

5. Build-time assumptions in C extensions

Some C extensions were written with x86 assumptions baked into SIMD code paths, memory alignment behaviour, or endianness handling. These may compile on ARM64 but behave incorrectly at runtime. This is rare but dangerous — it is the category where correctness testing matters most.

A Practical Evaluation Framework for Any Product

The following process translates the Parjanya experience into a repeatable assessment for any Lambda-based system.

Phase 1: Dependency Audit (Before Touching Infrastructure)

For every Lambda or containerised service, generate the full dependency tree including transitive dependencies:

pip install pipdeptree
pipdeptree --warn silence

Then, for every package with a native C extension (you can identify these by checking if the installed package contains .so files):

find /path/to/site-packages -name "*.so" | sort

Classify each package against the four-state matrix above. The output is your wheel matrix — one row per native dependency, one column per state.

Phase 2: Build Environment Test (Before Assuming Local Results)

Do not test ARM64 compatibility on your development machine. Build inside an ARM64 environment:

# Docker on an Apple Silicon Mac or a Graviton EC2 instance
docker build --platform linux/arm64 -f Dockerfile.arm64 .

The Lambda execution environment is Amazon Linux 2023 on aarch64. Your build environment should match this exactly. A dependency that installs cleanly in a generic ARM64 Docker image may still fail in the Lambda runtime — validate inside the correct base image.

Phase 3: Runtime Validation (Beyond Installation)

Successful installation is not the same as correct runtime behaviour. For packages that made it through the build:

• Run your actual workload, not a smoke test

• Measure latency and memory usage under ARM64 — they may differ from x86 even when the package installs cleanly

• For any package in the “source build required” category, verify that the compiled binary links against the correct system libraries at runtime

Phase 4: The Three-Question Decision Gate

For each service in your stack, answer these three questions:

1. Does every native dependency have an ARM64 wheel for my Python version and target runtime?

   • If yes: proceed to migration

   • If no: go to question 2

2. Can I build from source reliably in CI, in the correct ARM64 environment, with the correct GLIBC version?

   • If yes: proceed with source-build path; add a CI gate that fails if compilation regresses

   • If no: go to question 3

3. Can I replace the dependency or the entire stage with something ARM64-compatible?

   • If yes: replace it — this is often the better outcome anyway

   • If no: this stage stays on x86; isolate it intentionally rather than blocking the rest of the migration

This decision tree is what the Parjanya migration followed, even if it was not formalised until the second iteration.

Phase 5: Architectural Boundary Declaration

For every stage that cannot move to ARM64, declare the boundary explicitly in your architecture documentation:

• What is the technical reason it stays on x86 (CUDA dependency, missing wheel, untested behaviour)?

• What would need to change for it to become migratable?

• Is the x86 stage fully isolated so that the ARM64 migration of other stages is not blocked by it?

The goal is intentional architecture, not incomplete migration. A GPU inference stage that stays on x86 by design is not a failure. It is a correct architectural boundary.

What This Means for New Products: Building for ARM Portability

If you are building a new product and want to default to Graviton for cost efficiency, the considerations are different from migration. The choices you make at the start of your architecture will determine how much of the system can run on ARM64.

Choose dependency-light stages where possible

The deduplication stage in Parjanya worked on Graviton from day one because it had minimal native dependencies. When designing a new service, ask whether a pure-Python or well-supported-wheel implementation can solve the problem before reaching for a heavier ML or native library.

Treat CUDA as a hard architectural boundary from the start

If a stage requires GPU inference, isolate it behind a clean interface from day one. The scheduling logic, the orchestration, the result handling — all of that can run on ARM64. Only the GPU execution itself needs x86. Design for that split explicitly rather than letting the GPU requirement contaminate surrounding stages.

Version-pin with ARM64 wheel availability in mind

When locking dependency versions for reproducibility, verify that your pinned versions ship manylinux_aarch64 wheels. A version that was pinned for stability before the package added ARM64 support will block migration silently — you will not know until you try to build.

Build in CI on ARM64 from day one

Adding ARM64 build validation to your CI pipeline when you start a project costs almost nothing. Adding it after 18 months of x86-first development costs weeks of debugging. Many packages add and remove ARM64 wheel support across versions; having a CI gate that verifies ARM64 builds on every dependency update catches regressions immediately.

Use the 20% Lambda pricing delta as a design signal

AWS prices ARM64 Lambda at approximately 20% less than x86. That is not just an operational saving — it is a signal about where to route compute. If a function is trivially portable (pure Python, well-supported wheels), choosing x86 without evaluating ARM64 first is a deliberate decision to pay a 20% premium for no benefit.

The AWS-Specific Caveat

Everything in this post is calibrated to AWS. The cost numbers, the Lambda architecture flag, the Graviton family of processors, the manylinux_aarch64 wheel availability for AWS runtimes — these are AWS-specific.

Other cloud providers offer ARM compute. Azure has Ampere A1-based VMs. GCP has Tau T2A. But:

• Serverless ARM support (equivalent to Lambda arm64) is not uniformly available or mature across providers

• The degree of AWS-specific optimisation in the Python scientific and ML ecosystem — particularly for Graviton NEON instructions — is not replicated elsewhere

• Cost structures differ; the 20% pricing delta is an AWS Lambda figure and does not translate directly to other billing models

If you are building a multi-cloud or cloud-agnostic system, treat Graviton optimisation as an AWS-specific tuning layer rather than a foundational architectural decision. The portability of your ARM64-compatible stages will transfer. The AWS-specific performance characteristics will not.

The Real Cost Model

The standard framing of Graviton savings is “20% cheaper Lambda.” That is accurate but incomplete. The full savings model for an architecture like Parjanya’s has four components:

1. Lower per-invocation Lambda cost on ARM64 (~20% pricing delta, compounding with every invocation)

2. Avoided NAT data-path spend — VPC gateway endpoints route S3 and DynamoDB traffic without NAT tax; this is infrastructure rather than ARM64, but it compounds with the migration

3. Reduced ML over-processing — a rule-based pre-filter like parjanya-technical_validator rejects bad images before they reach the GPU queue; every rejected frame is a GPU invocation that never happens

4. Lower operational overhead — fragile native builds create deployment failures, cold start issues, and CI complexity; removing them reduces engineering time

For a high-volume pipeline, component 3 often dominates. The ARM64 savings from the validator are real. But the savings from not running expensive GPU inference on images that would have been rejected anyway are an order of magnitude larger.

This is the correct way to think about Graviton adoption: not as a compute cost reduction in isolation, but as an opportunity to reconsider stage design, dependency choices, and processing flow in ways that compound the savings.

Summary

The ARM wheel is the gatekeeper to Graviton savings. Not the hardware, not AWS support, not your application code. The compiled binary distribution of your Python dependencies — and whether it exists for aarch64 — is what determines whether a given Lambda function can run on Graviton.

The practical conclusions from Parjanya’s full migration arc:

• Audit your wheel matrix before you plan your migration. The output tells you which functions migrate, which need source builds, and which need architectural changes.

• Build in an ARM64 environment that matches your Lambda runtime. Local results on x86 do not predict ARM64 install success.

• Replacement is often faster than migration. A fragile ML stage replaced by a dependency-light rule-based implementation solves the ARM64 problem, the reliability problem, and often the correctness problem simultaneously.

• Isolate x86 hard boundaries explicitly. CUDA is the cleanest example — design around it rather than pretending it is temporary.

• Partial adoption is architecture, not failure. Running 3 of 4 Lambda functions on Graviton with an intentional x86 boundary at the GPU stage is a correct outcome.

Graviton adoption is not a hardware decision. The hardware is already ready. It is an ecosystem decision — and the ARM wheel matrix is where that decision lives.

Further Reading

• AWS Graviton Getting Started – Python — The canonical reference for why Python version and GLIBC version matter for wheel compatibility

• Migrating AWS Lambda functions to ARM-based Graviton2 — AWS’s official guide; read between the lines for what is assumed about dependency simplicity

• AWS Graviton Technical Guide — Deep reference on runtime support and ecosystem maturity by language

• Why We Could Only Use AWS Graviton for 1 of Our 4 ML Lambdas — First Parjanya post: the ecosystem reality check

• From 1/4 to 3/4: Re-architecting an ML Pipeline for Graviton — Second Parjanya post: the re-architecture and cost analysis

• AWS Graviton4 vs Intel x86: From $10 POC to Production Validation — The original POC that established the cost and performance baseline

Abstract

Resilient AI infrastructure is not defined only by model quality, throughput, or scaling efficiency. In production, the harder problem is reconciliation: keeping durable state, requested work, and actual execution aligned when workers fail, queues drift, storage paths change, policies evolve, and control planes become blind. Let me present TBIE, a practical operating model for distributed systems: Truth, Belief, Intent, and Execution. TBIE separates the authoritative record of what is true from the operational view of what seems to be happening, the replayable journal of work that should occur, and the stateless workers that realize side effects.

I have used Parjanya v2.0, an image ingestion and GPU-based visual scoring platform, as a detailed case study. Parjanya’s architecture spans immutable uploads, DynamoDB workflow state, SQS-based intent, event-driven replay, GPU autoscaling, browser-side uploads, policy regrading, and infrastructure drift. Across these layers, TBIE proved useful not as a slogan but as a diagnostic and design framework. It clarified why transient worker failure should not destroy replayable work, why pending state without corresponding intent is a reconciliation gap, why wrong-bucket routing can be deterministically wrong, why policy changes should be handled as controlled replay, and why control-plane blindness is more dangerous than isolated worker failure.

The central claim of this is that resilient AI platforms should be designed as reconciliation systems rather than one-way pipelines. A pipeline moves data forward. A reconciliation system continuously repairs the alignment between truth and work until intended outcomes are actually realized. That distinction changes how we design queues, retries, autoscaling, observability, IAM boundaries, tenant onboarding, model packaging, browser uploads, and recovery runbooks.

1. Introduction

Modern AI systems are often described in terms of model choice, hardware selection, vector stores, and inference efficiency. Those concerns are important, but they are not usually what breaks production systems. In practice, systems fail because they lose work, duplicate work, misroute work, or misinterpret what is actually happening. A queue may look healthy while the underlying work has already vanished. A worker may crash without leaving a replayable record. A browser upload may fail after the backend has already committed a pending state. An autoscaling group may be configured correctly while the reconciliation control plane that should activate it is blind.

These failures are not unusual edge cases. They are the normal shape of distributed systems under stress. The question, then, is not whether a system will experience drift between state and execution, but whether the architecture is built to detect, explain, and repair that drift. TBIE was developed as a response to that question.

TBIE stands for Truth, Belief, Intent, and Execution. It is a practical decomposition of distributed systems that helps separate durable facts from operational signals, requested work from realized work, and recoverable failures from terminal ones. The model is especially useful in asynchronous AI pipelines, where storage, metadata, queues, workers, and control planes all operate independently and can fail independently.

Parjanya v2.0 is an ideal case study because it combines all of those surfaces in a single system. Images are uploaded to S3. Metadata is written to DynamoDB. GPU work is performed asynchronously through SQS. Lambda functions handle technical validation and replay orchestration. GPU workers consume intent, perform visual-language inference, and write enriched truth back to the database. Autoscaling responds to queue depth. Browser uploads interact with tenant-specific buckets and CORS policies. Policy changes require historical reprocessing. Infrastructure drift can occur in launch templates, AMIs, model packages, and endpoint configuration.

Let’s deep dive how TBIE behaves in practice.

2. The TBIE Model

TBIE divides a distributed system into four layers that must remain conceptually distinct.

2.1 Truth

Truth is the durable record of what is actually true. It should survive worker restarts, deploys, transient outages, and runtime drift. In Parjanya, Truth lives in immutable S3 objects, DynamoDB workflow rows, hashes, status fields, curation metadata, and derived state that has been durably committed. Truth answers questions such as: What object exists? What stage of the workflow is this image in? What has already been computed? What is the authoritative record of the tenant, batch, or image?

2.2 Belief

Belief is the operational view of reality. It is derived from Truth and current signals, but it may lag, be partial, or be noisy. In Parjanya, Belief includes queue depth, in-flight message counts, worker health, GPU availability, desired ASG capacity, scaling activity, and alarm state. Belief is what operators see first, but it must not be confused with source-of-record truth.

2.3 Intent

Intent is the durable record of work that has been requested. It is the journal of “please do this work.” In Parjanya, SQS messages represent Intent. Replay jobs, regrade jobs, and retry workflows are all forms of Intent. The critical property of Intent is replayability. If Intent can be lost too early, then transient failures become permanent failures and manual rescue becomes necessary.

2.4 Execution

Execution is the stateless work that turns Intent into side effects and updated Truth. In Parjanya, Execution includes Graviton Lambdas for EXIF extraction and technical validation, GPU workers for VLM scoring and image quality analysis, replay jobs that reconstruct missing Intent, and autoscaling actions that wake the worker fleet when work appears. Execution is where work happens, but in a resilient system it must never be allowed to erase the record of what was supposed to happen.

3. Why Reconciliation Matters

The key insight behind TBIE is that a distributed system is not healthy merely because its components are running. Health depends on reconciliation. A system can be superficially alive while still being functionally stuck. A database row may say pending_vlm_enrichment while no SQS message exists. A queue may be empty while worker work is still pending in truth. A control plane may be scheduled while unable to read the signals it needs to act.

Reconciliation is the process of bringing Truth, Intent, and Execution back into alignment. In the TBIE model, reconciliation is not a background nicety; it is the core operating principle. Systems should not rely on humans noticing a stale queue and manually fixing it. They should be able to repair the missing relationship between truth and work on their own.

This is why the distinction between a pipeline and a reconciliation system matters. A pipeline assumes a mostly linear progression from input to output. A reconciliation system assumes that progression can be interrupted, delayed, partially completed, or invalidated by failure. It therefore builds explicit mechanisms to recover the intended outcome rather than merely continue from the last known step.

4. Event-Driven Reconciliation in Parjanya v2.0

Parjanya initially used a scheduled polling model. A timer would wake the replay Lambda periodically, the Lambda would scan for pending work, and if appropriate it would emit SQS messages and trigger GPU autoscaling. This worked, but it introduced avoidable latency, wasted invocations, and operational ambiguity. The system could not react immediately when Truth changed, and operators had to reason about whether the queue was empty because the system had genuinely caught up or because the next poll had not yet occurred.

The move to DynamoDB Streams changed that architecture fundamentally. Now, when a workflow row reaches pending_vlm_enrichment, the stream emits an event immediately. An event source mapping filters for relevant writes, batches records briefly, and invokes the replay Lambda. The Lambda discovers missing or retriable work, emits Intent into SQS, and kicks the GPU ASG when necessary. This turns reconciliation from periodic discovery into event-driven reaction.

The result is a lower-latency, more honest architecture. Truth changes, the control plane notices, Intent is created, and Execution follows. The system no longer waits for a timer to rediscover what should already be known.

5. Parjanya v2.0 as a TBIE Case Study

Parjanya’s architecture maps neatly onto TBIE. S3 holds immutable uploads and preview artifacts. DynamoDB holds workflow state, curation metadata, and hashes. SQS holds replayable intent. Lambdas handle validation, replay, and orchestration. GPU workers perform inference and write enriched state back to DynamoDB. Autoscaling follows queue pressure and worker demand.

What makes the case study valuable is not the existence of those components, but the failure modes they exposed. Parjanya demonstrated that many production issues are really reconciliation issues in disguise. Some failures were caused by deleting intent too early. Others were caused by truth existing without intent. Some were caused by the wrong bucket being referenced correctly. Others were caused by the control plane being unable to read queue state. Still others came from stale image tags, missing model files, CORS misconfiguration, or API schema drift. TBIE made those failures legible.

5.1 Transient GPU failure should not destroy Intent

One of the earliest and most important incidents involved GPU workers deleting SQS messages before the retry window had been exhausted. A worker could encounter a temporary S3 download failure or an out-of-memory condition, write a failure state, and still remove the only replayable message. At that point, Truth said the work had failed, but Intent no longer existed and the system had no automatic path to try again.

TBIE made the problem obvious. Execution had destroyed Intent prematurely. The fix was to return explicit execution outcomes: retry, terminal_failure, or completed. A retry preserves the message and lets visibility timeout and receive count determine whether the work should be attempted again. A terminal failure writes durable failed truth and then deletes the message. Success writes final truth and deletes the message. That separation preserves replayability while still allowing durable failure when necessary.

5.2 Truth can be pending while Intent never existed

Another recurring failure mode was the mirror image of the first. Rows in DynamoDB would remain in a pending VLM state, but no corresponding queue message had been created. Queue depth fell to zero and the system appeared idle, yet the backlog still existed in Truth.

This is a reconciliation gap, not a worker bug. The response was to introduce replay mechanisms that scan for pending rows without Intent, regenerate queue messages, and kick the GPU fleet when work is emitted. In other words, the platform needed a control plane that could restore missing Intent from Truth automatically.

5.3 Replaying retryable failures requires resetting Truth deliberately

Not every failure should be treated as terminal. Some failures, such as S3 download errors or temporary GPU OOM events, are retryable if the underlying condition is corrected. But a simple re-enqueue is not enough when the workflow row itself still contains partial or stale derived fields.

TBIE clarifies the difference between retry and replay. A retry is another attempt at the same execution. A replay is a deliberate reset to a pre-execution boundary, removal of stale derived state, and emission of fresh Intent. This distinction matters because the second form is a controlled reconstruction of the workflow, not merely another attempt on top of corrupted state.

5.4 Wrong bucket, right key

One of the most instructive incidents involved an SQS payload that pointed to a valid preview key but the wrong bucket. The worker repeatedly failed with S3 download errors, even though the preview existed. The issue was not flaky execution. It was deterministic misrouting.

This is a classic distributed systems failure: the object key is correct, but the address is wrong. TBIE makes that failure visible because Intent is not just “some work exists.” Intent must encode the correct target. The fix was to force preview keys to use the uploads bucket as the source of truth and to tighten eligibility so only objects suitable for GPU work are enqueued.

5.5 Policy changes should be handled as replay, not patching

When the content policy changed to more strictly reject non-photographic content such as screenshots, banners, infographics, social cards, slides, illustrations, and mockups, the platform needed to reprocess historical images under the new rules. TBIE made the solution obvious: reset the affected Truth fields to a pre-VLM boundary, set the rows back to pending, and emit new Intent so GPU workers can re-grade under the revised policy.

This is one of the most powerful properties of replay-native systems. They allow policy evolution without manual data surgery. A change in judgment does not require a one-off correction script. It becomes a controlled reprocessing event with clear before-and-after semantics.

5.6 Execution drift can occur below the application layer

Parjanya also surfaced failures where the application code was correct but the execution environment was stale. One launch template continued to point to an old image tag. Cloud-init failed while pulling the nonexistent container image, and the GPU instance came up without ever starting the worker.

A separate incident involved an AMI missing the Python files required by a model that relied on remote code. The container started, but the model loader crashed because the local artifact was incomplete. These are both Execution-layer failures, but they occur at different depths: one at instance boot, the other at model runtime. TBIE is useful because it keeps both cases in the same conceptual category: the execution environment drifted away from the declared source of truth.

5.7 CORS and browser execution are part of the resilience story

The ingestion path introduced another class of split-state failure. The backend could write a pending upload record and generate a presigned URL, but the browser’s PUT could still fail because the bucket CORS policy or endpoint routing was incorrect. In that case, Truth at the API layer looked correct while Execution at the browser layer never completed.

Later investigations revealed that multiple independent layers could be wrong at once. A bucket might reject wildcard origins under restricted public bucket settings while the client simultaneously used a global S3 endpoint that returned a redirect browsers would not follow on OPTIONS preflight. TBIE helps here by forcing the diagnostic question: is Intent missing, or is Execution unable to realize it? In this case, Intent existed. Execution was blocked by infrastructure and configuration drift.

5.8 The control plane itself can fail silently

One of the most dangerous incidents in the system occurred when the replay Lambda lacked the permission it needed to read queue attributes. The function was still scheduled and invoked, but it could not inspect Belief and therefore crashed before it could emit Intent or kick the GPU ASG. From the outside, everything looked enabled. In reality, the control plane had gone blind.

This is a crucial TBIE lesson. The component that repairs work is itself a first-class reliability surface. If the control plane silently fails, then every other safety net becomes weaker. That is why control-plane observability must be stronger than ordinary worker observability.

5.9 Dynamic tenant discovery and queue retention are part of reconciliation

As the platform grew, static tenant lists became a bottleneck. Reconciliation could not depend on manually editing Terraform every time a new tenant was onboarded. The control plane therefore moved toward dynamic tenant discovery from DynamoDB, with tenant registry markers written by the upload path and discovered by the replay Lambda at runtime.

Queue retention was another important operational detail. If the GPU fleet is scaled to zero for cost savings, Intent must survive long enough for work to be processed after a weekend or holiday gap. Retention policy is therefore part of resilience design, not a generic queue setting.

6. Operational Model and Runbook Thinking

TBIE becomes truly useful only when it changes how incidents are diagnosed.

By the time Parjanya matured into an event-driven reconciliation system, the debugging approach itself had changed. Operators no longer began by asking whether “the queue is healthy” or whether “the GPU workers are running.” Those signals mattered, but they were no longer treated as authoritative.

Instead, every investigation began with a simpler and much more precise question:

Is the system waiting because Intent is missing, or is Intent present but Execution cannot realize it?

That distinction dramatically narrowed the search space during incidents.

If Truth showed a growing backlog while Intent remained near zero, the issue was usually in reconciliation: replay Lambda failure, queue emission failure, stale tenant discovery, or control-plane blindness.

If Intent existed but Execution failed repeatedly, the problem shifted toward realization: bucket routing, IAM permissions, runtime drift, stale launch templates, model incompatibility, or endpoint mismatch.

The architecture became easier to reason about because TBIE transformed debugging from improvisation into classification.

7. Guardrails and Maintenance as Part of the Architecture

Parjanya’s history shows that resilient systems are built by converting incidents into guardrails. Transient worker failures should not destroy intent. Replay logic should reset truth cleanly before re-emitting work. Dependency drift should be prevented with lockfiles and build assertions. CORS origin drift should be rejected at plan time. Tenant discovery should be dynamic rather than manually maintained. Launch templates should refresh when image tags change. Model artifacts and container versions should be treated as a compatibility pair. API contracts and frontend types should not be allowed to drift silently. Queue retention should match the actual outage window, not an idealized one.

This is the practical meaning of reliability engineering. Incidents become permanent controls. The architecture evolves by accumulating constraints, validations, and replay paths that encode what the system has already learned.

8. Implications for AI Platform Design

TBIE generalizes beyond Parjanya. Any AI platform that spans storage, metadata, asynchronous work, GPU execution, and policy evolution can benefit from the same model. The key is to stop thinking of the system as a one-way pipeline and instead treat it as a reconciliation loop that continuously restores alignment between durable truth and intended work.

That shift affects architecture choices. Queues become journals of intent rather than temporary transport. Replay becomes a first-class product capability rather than an ops workaround. Autoscaling becomes a consequence of work existing, not a heuristic guess. Model packaging becomes part of execution correctness. Browser upload behavior becomes part of the end-to-end reliability model. And policy change becomes a replay event rather than a manual repair task.

When the System Hangs at 02:00 AM

At 02:00 AM, the queue may look empty while customers are still waiting for images to process. GPU instances may exist while no workers are actually running. A replay Lambda may still appear scheduled while silently crashing on every invocation. Dashboards may continue showing green infrastructure while the control plane itself has already gone blind.

This is where TBIE stopped being an architectural abstraction and became an operational model.

The first step was no longer restarting workers or increasing autoscaling limits. The first step became identifying which reconciliation boundary had failed.

The investigation usually began with Truth.

Was DynamoDB accumulating rows in pending_vlm_enrichment? If so, the platform still believed work should exist, regardless of what the queue appeared to show. Truth backlog became the first signal because Truth is the authoritative record of unfinished work.

The next step was Intent.

Did SQS actually contain replayable work items? A high Truth backlog combined with near-zero queue depth usually indicated a reconciliation failure rather than an execution failure. In those cases, the replay Lambda itself became suspect. Either the control plane had stopped emitting Intent, or it had lost the ability to discover the work that needed to exist.

That distinction mattered enormously because the operational response changed completely depending on the answer.

If Intent existed but the backlog still did not move, attention shifted toward Execution health. GPU worker logs became critical. Sometimes the workers were healthy but repeatedly failing with deterministic download errors caused by bucket routing drift. Sometimes GPU instances launched successfully while containers never started because a stale launch template pointed to a nonexistent image tag. In other cases, the instance booted correctly but the model loader crashed because required runtime artifacts were missing from the AMI.

One of the most revealing operational signals turned out to be complete silence.

An empty GPU log group was rarely a good sign. More often, it meant execution had failed before the application layer even started. Cloud-init failures, image pull failures, IAM denial during bootstrap, or launch-template drift frequently surfaced first as absence rather than explicit failure.

The replay Lambda introduced another category of silence.

If queue visibility remained unchanged while pending Truth continued growing, the control plane itself became the focus. One of the most dangerous incidents in the system occurred when the replay Lambda lost permission to read queue attributes. The function was still scheduled. It was still being invoked. But it crashed before emitting Intent or triggering autoscaling. From the outside, everything looked operational while reconciliation had effectively stopped.

That incident permanently changed the operational philosophy of the platform.

Worker failures became treated as recoverable noise.

Control-plane blindness became treated as a systemic risk.

Eventually, the debugging process itself evolved into a TBIE classification exercise:

• Truth backlog revealed whether unfinished work existed.

• Intent backlog revealed whether reconciliation was functioning.

• Queue visibility revealed whether work was flowing.

• GPU log silence revealed bootstrap or execution drift.

• Replay Lambda silence revealed control-plane failure.

• IAM checks validated whether orchestration still had authority to act.

• Launch-template validation confirmed whether execution environments still matched declared infrastructure state.

The system stopped being debugged as “a pipeline.”

It began being debugged as a continuously reconciling distributed system.

That distinction changed how incidents were understood, how recovery was automated, and ultimately how the platform itself evolved.

9. Conclusion

Parjanya v2.0 demonstrates that resilient AI infrastructure depends on more than good models or fast workers. It depends on a clear model for distinguishing what is true, what is believed, what work is intended, and what execution can actually accomplish. TBIE provides that model.

The value of TBIE is not just conceptual. It changes how systems are built, how retries are designed, how control planes are monitored, how infrastructure drift is prevented, and how policy changes are reapplied. Most importantly, it turns production failure from a confusing mystery into a structured reconciliation problem.

That is why the right mental model for modern AI infrastructure is not merely “build a pipeline.” It is “build a system that can continuously reconcile truth and intent until intended work is actually realized.”

Appendix A. Maintenance Checklist

That checklist is not a substitute for architecture. It is how architecture remains trustworthy over time.

1. The Observation That Started This

A few weeks ago I noticed something in my Claude Code session trace: Haiku 4.5 was being invoked as a subagent while my main session was running on Opus 4.7.

My first instinct was: is this personalisation? Has Claude learned my patterns? Is this a new adaptive router?

It was none of those things. But chasing the answer led me into a deep audit of my actual usage data — and what I found changed how I think about AI session economics entirely.

The short answer: Claude Code has a built-in subagent architecture where the main orchestrator (Opus 4.7 in my case) delegates read-only codebase work to the Explore subagent, which runs on Haiku 4.5 by default. It is deterministic product behaviour, not personalisation. The model matching is happening at the subagent dispatch boundary, not through learned routing.

But the longer answer — what I found when I actually pulled my usage data — is the more important story.

2. What the Data Actually Showed

Running /cost in my Claude Code terminal revealed the real picture, however it is only 3% of usage, 33 sessions, complete details are found using ccusage, still showing the important metrics:

Favorite model:  Opus 4.7        Total tokens: 22.0M
Sessions: 33                     Longest session: 7d 2h 33m

● Opus 4.7  (53.3%)   In: 118.2k  · Out: 11.6M
● Opus 4.6  (18.2%)   In: 118.3k  · Out: 3.9M
● Haiku 4.5 (20.6%)   In: 363.5k  · Out: 4.2M
● Sonnet 4.6  (7.9%)  In:  63.0k  · Out: 1.7M

Combined Opus usage: 71.5% of all tokens.

Sonnet — the model I publicly advocated as the benchmark — was only 7.9% of my actual usage.

Running ccusage session revealed the concentration problem:

Two sessions accounted for 50.9% of all costs.

The small sessions with $0.16–0.22/M cost-per-token are my manual Haiku sessions — git commits, README updates, simple lookups. Haiku routing was working correctly there.

The two expensive sessions are a different story entirely. And the cost-per-million ratio is the key signal: at $0.53–0.63/M blended, those sessions were Opus-orchestrated with some subagent delegation, but the token volume itself was the problem — not the model choice.

3. Naming the Problem: Context Debt

Before getting to solutions, I want to name what I observed, because it needs a name.

Context Debt is the accumulation of tokens in a session that compound the cost of every future turn without adding proportional value to the reasoning quality of those turns.

It behaves like technical debt in one critical way: it is invisible when it is forming, and expensive when you finally notice it. Unlike technical debt, it has an immediate dollar cost that compounds within the same session.

Here is the mechanics:

Turn 1:   Opus reads inference_config.yaml    → context: 3k tokens
Turn 10:  Opus reads vlm_pipeline.py          → context: 40k tokens
Turn 30:  Opus reads cuda_kernels/, manifests  → context: 180k tokens
Turn 50+: Every API call sends 180k input     → paying full price
          even if your prompt is 50 words

At Opus pricing (~$15/M input tokens), 200 subsequent turns × 180k context = 36M input tokens = $540 in input alone, before a single output token is generated.

This is what those two sessions were doing. It was not that Opus was the wrong model. It was that the session carried everything it had ever read into every subsequent turn — and paid Opus prices for all of it, repeatedly.

Three forces compound context debt:

Prompt cache expiry. Claude caches the static prefix of your context for 5 minutes (up to 1 hour for some configurations). In a session spanning hours or days, that cache expired repeatedly. Each expiry means paying full Opus input price for the entire accumulated context again. My 7-day session paid full price for a 400k+ context many times over.

Compaction tax. When context compacts (the default fires at ~95% capacity), Claude writes a summary and prepends it to all future turns. In a very long session with multiple compactions, those summaries stack — each subsequent turn carries all of them as mandatory context.

Speculative file reads. Opus tends to read files “to understand the broader context” before answering, even when the current task doesn’t require them. In an ML infrastructure repo, this means model configs, environment files, pipeline definitions, deployment scripts, and CUDA configurations all end up in context — and stay there.

4. The Constraint I Cannot Engineer Away

Before presenting the framework, an honest acknowledgment of constraints.

My primary workload is VLM (Vision-Language Model) inferencing, infra-heavy automation, and ML optimisation pipelines. For this work:

• Minimum viable context is ~300k tokens. Multiple model configs, inference scripts, pipeline definitions, and infrastructure manifests need to be simultaneously present for coherent cross-file reasoning.

• Sonnet 4.6 has only recently gained a 1M context window (now GA, worth testing for execution phases). But adaptive thinking — structurally required for deep VLM reasoning — was absent from Sonnet until recently and is still maturing.

• For the reasoning-heavy phases of this work, Opus 4.7 at 1M context is the correct model. This is a technical requirement, not a preference.

The insight that changes everything: the model being correct does not mean the context footprint needs to be what it currently is.

Opus 4.7 is the right reasoning engine. Sending it 400k tokens of raw source code when it only needs 40k tokens of structured summaries is waste. That is the distinction the framework targets.

5. Context Engineering: The Framework

Context Engineering is the practice of deliberately managing what enters an AI session’s context window, when it enters, and in what form — to maximise reasoning quality per token rather than total tokens.

It has four mechanisms.

Mechanism 1: Pre-Summarisation (Haiku as Reader)

The default pattern:

Opus opens session
Opus reads 30 files to orient itself
All 30 files sit in context for the rest of the session
Cost: 150k input tokens × every subsequent turn

The engineered pattern:

Before session opens:
  @ml-context-loader reads all 30 files (Haiku, separate context)
  Returns: 12k token structured dependency map

Opus main session receives:
  The 12k map, not the 150k raw files
  Opus never directly holds the source files
Cost: 12k input tokens × every subsequent turn

The work output is identical. The context footprint is ~12x smaller.

Subagent configuration (~/.claude/agents/ml-context-loader.md):

---
name: ml-context-loader
description: Pre-read ML pipeline files, model configs, inference scripts,
  and VLM configurations before complex optimisation work. Returns a
  structured dependency map for the main session. Invoke this BEFORE
  starting any ML or infra work in the main session.
model: haiku
tools: Read, Grep, Glob
---
You read ML infrastructure files and produce a structured summary covering:

1. Model architecture and config paths
2. Inference pipeline entry points and key functions
3. CUDA/GPU configuration and memory constraints
4. Cross-file dependencies relevant to the stated task
5. Files that need to change to accomplish the goal

Return a structured map. Do not return raw file contents.
Maximum output: 15k tokens. Be precise and omit irrelevant files.

Paired subagent for infrastructure (~/.claude/agents/infra-scanner.md):

---
name: infra-scanner
description: Scan infrastructure configs, Terraform files, CI/CD pipelines,
  deployment manifests, and environment configs before optimisation work.
  Returns dependency map and change surface for the stated task.
model: haiku
tools: Read, Grep, Glob, Bash
---
Read infra files and return:
- Resource dependencies and environment configs
- Critical paths that affect the stated task
- Files that need to change
- Current state of relevant resources

Compact output only. Omit files irrelevant to the task.

Mechanism 2: Targeted Loading via CLAUDE.md

Even with pre-summarisation, Opus will add raw files to context during execution if not explicitly instructed otherwise. CLAUDE.md is the right place to install session-level context discipline.

Project-level .claude/CLAUDE.md additions:

## Context Discipline

Before reading any file, state why it is needed for the current task.
Never read files speculatively to "understand the broader context."

Use @ml-context-loader before starting any ML or infra work.
Use @infra-scanner before starting any infrastructure work.
Use @explorer for any file discovery or codebase search.

If a file has been summarised by a subagent this session, 
use that summary rather than re-reading the raw file.

Maximum 5 files in direct context at any point during implementation.
For architecture decisions, request a structured summary first.

When asked to fix a bug, read only the file containing the bug
and its direct imports. Do not read the broader codebase unless
the fix requires understanding something not in those files.

This changes Opus’s default behaviour from breadth-first file reading to targeted loading. In practice, this alone reduces speculative reads by 50–60% in long sessions.

Mechanism 3: Session Chunking by Reasoning Type

The most expensive sessions — the two that consumed 50.9% of total costs — mixed two fundamentally different cognitive modes in a single long-running context:

• Reasoning mode: Architecture decisions, bottleneck analysis, choosing optimisation strategies. Needs Opus depth. Short turns, modest context.

• Execution mode: Implementing the decided approach across many files. Needs large context. Lighter per-turn reasoning.

When mixed, the session context grows to serve both needs simultaneously — and every turn pays the full cost of the combined footprint.

Separated:

# Session 1: Architecture planning
# Opus, focused context (summary only), ~15–20 turns
claude --model opus
# Prompt: "Given this summary [paste ml-context-loader output],
#   design the memory optimisation strategy for the VLM dataloader.
#   Output a structured implementation plan."
# → Session ends with a plan document. Context: ~30k tokens throughout.

# Session 2: Implementation
# Sonnet 4.6 at 1M (or Opus if VLM-specific reasoning needed)
# Longer, but following a decided plan — execution, not discovery
claude --model sonnet
# Prompt: "Implement this plan [paste plan].
#   Start with [specific file]. Read only the files listed in the plan."
# → Context grows with implementation files, but no re-discovery overhead.

The Opus session stays short because it worked from a summary, not raw files. The implementation session can run on Sonnet 4.6 at 1M context if the per-turn reasoning does not require Opus depth — which it often does not, once the architecture decision is made.

The practical test for session split: If your current turn is deciding something, you are in reasoning mode. If your current turn is doing something already decided, you are in execution mode. Different sessions.

Mechanism 4: Cache Warming on Re-entry

The single most expensive moment in a long session is returning after a break.

Prompt cache TTL is 5 minutes by default for most Claude Code request types (up to 1 hour in some configurations). When you step away for 30 minutes and return to a 300k-token context, the first turn back pays full Opus input price for all 300k tokens. If your session had 20 such re-entries across a workday, you paid for that 300k context twenty times.

Before taking any break longer than a few minutes:

/compact

This forces a clean compaction summary before the cache goes cold. The next turn back pays for a 5–10k summary re-warm, not a 300k context re-warm.

Prevent the problem structurally by setting aggressive autocompaction:

In .claude/settings.json:

{
  "env": {
    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "60"
  }
}

Compacting at 60% context capacity means the session never accumulates a context large enough to be expensive to re-warm. The compaction summary costs a few thousand tokens once. The alternative is paying full input price for a massive context every time the cache expires.

6. The Escalation Model

With context engineering in place, the tier routing becomes:

The key principle: Tier selection is determined by reasoning depth required per turn, not by task complexity overall. A complex ML task still has Haiku turns (reading files), Sonnet turns (writing implementations), and Opus turns (designing the approach). The same task should not require every turn to be Opus.

Environment defaults that enforce this without manual switching:

# In ~/.zshrc or ~/.bashrc

# Subagents default to Sonnet, not parent model
export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-6"

# Haiku slot pinned explicitly
export ANTHROPIC_DEFAULT_HAIKU_MODEL="claude-haiku-4-5-20251001"

7. Complete Subagent Stack

For teams adopting this framework, the full subagent configuration:

~/.claude/agents/explorer.md — Universal read-only search

---
name: explorer
description: Search files, grep for symbols, read code structure, find
  usages, locate definitions. Use for any read-only investigation
  before editing. Never use for file modification.
model: haiku
tools: Read, Grep, Glob, Bash
---
You are a fast read-only code explorer. Search thoroughly and return
a concise structured summary. Never modify files. Optimise for finding
the minimum set of files relevant to the stated question.

~/.claude/agents/git-helper.md — Repository operations

---
name: git-helper
description: Handle git commits, branch management, README updates,
  changelog entries, and documentation formatting. Use for all
  repository hygiene tasks.
model: haiku
tools: Bash, Read, Write
---
You handle git operations and documentation updates efficiently.
Use conventional commits format. Commit messages: type(scope): description.

~/.claude/agents/code-writer.md — Standard implementation

---
name: code-writer
description: Implement features, write new functions, refactor existing
  code, add tests. Use for code generation and editing tasks that
  do not require architectural reasoning.
model: sonnet
tools: Read, Write, Edit, Bash, Glob, Grep
---
You are a focused implementation engineer. Read the minimum required
files before editing. Make one logical change per invocation.
Follow the plan provided; do not redesign unless asked.

~/.claude/agents/ml-context-loader.md — ML pre-summarisation (See Mechanism 1 above)

~/.claude/agents/infra-scanner.md — Infrastructure pre-summarisation (See Mechanism 1 above)

~/.claude/agents/architect.md — High-stakes reasoning only

---
name: architect
description: Design system architecture, resolve complex multi-file bugs,
  make technology decisions, plan major refactors requiring cross-system
  understanding. Only invoke when deep reasoning is genuinely required.
  Receives summaries, not raw files.
model: opus
tools: Read, Grep, Glob
---
You make high-level decisions from structured summaries.
Think deeply before proposing changes.
Output a structured plan that code-writer can execute step by step.
Request specific raw files only when the summary is insufficient.

8. Before and After: The Numbers

Based on actual session data from this audit:

The two expensive sessions ($625.72 combined API equivalent):

Output tokens are unchanged because the actual work product — the code written, the analysis produced — is identical. The saving is entirely in the context overhead that was being sent to the Opus API on every turn without contributing to reasoning quality.

Across all sessions:

9. What Is Still Missing (Community Ask)

This framework works within current Claude Code capabilities, but several gaps remain that limit how far it can go without manual configuration:

GitHub #44976 — Auto model routing by task type. Currently, there is no native content-aware router in the main session. The routing that exists (Explore → Haiku) operates at the subagent dispatch boundary only. Automatic routing based on turn type — planning turns to Opus, execution turns to Sonnet — requires manual setup or explicit model switching. This feature request, if shipped, would make context engineering automatic rather than configured.

GitHub #43869 — Subagent model routing bugs. On some Max plan configurations, subagents silently run on the parent session’s model despite explicit per-agent configuration. If your Haiku-configured subagents appear to cost Opus rates, this ticket is the reference. Check env | grep CLAUDE_CODE_SUBAGENT_MODEL and verify Haiku is actually firing.

JSONL token counts are unreliable. The ccusage tool reads from JSONL files where input tokens are undercounted by 100–174x due to a streaming placeholder issue. For accurate token accounting, use /cost inside Claude Code (reads from the statusbar, which is accurate) and treat ccusage cost estimates as relative comparisons only.

Sonnet 4.6 at 1M + adaptive thinking. Both are now GA but recently so. For workloads requiring 300k+ context but not frontier VLM reasoning, Sonnet 4.6 at 1M is worth testing as a drop-in replacement for Opus in execution sessions. One session test against a known task will answer whether the quality holds for your specific workload.

10. Best Practices Summary

Before starting any ML or infra session:

• Run @ml-context-loader or @infra-scanner first

• Start with the plan document from a prior architecture session, not a blank slate

• Launch on Sonnet unless you know the first turn needs Opus-depth reasoning

During a session:

• /compact before any break longer than 5 minutes

• Never read files speculatively — enforce this in CLAUDE.md

• Split sessions when you shift from designing to implementing

For VLM and large-context ML work specifically:

• Opus 4.7 at 1M is still the correct model for reasoning-heavy phases

• The saving is in context footprint, not model choice

• Pre-summarise with Haiku; Opus only sees the structured output

On model selection:

• Default: Sonnet 4.6 (set CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-6")

• Start sessions with claude --model sonnet unless the first task earns Opus

• Use opusplan for sessions that need Opus for planning and Sonnet for execution

On measuring progress:

• Use /cost for accurate token and model-split data

• Use ccusage session --breakdown to track model mix per session over time

• Watch cost-per-million-tokens ratio: $0.20/M = healthy Haiku/cache mix, $1.00+/M = context debt accumulating

Closing Thought

The observation that started this — Haiku 4.5 being spawned during an Opus 4.7 session — turned out to be Anthropic’s own answer to the problem I had been creating. The built-in subagent architecture already encodes the right instinct: read cheap, reason expensive, never conflate the two.

Context Debt is what happens when that separation breaks down at the session level. Context Engineering is the practice of maintaining it deliberately.

The framework is not about using cheaper models. It is about using the right model for each cognitive operation — and never making the expensive model carry the weight of the cheap one’s job.

Related posts:

• The Hidden Runtime Failure Behind Claude’s Recent Regression

• When Adaptive Thinking Goes Off the Rails

• Sonnet Becomes My New Benchmark

• Why you should chose Haiku as Default model and escalate if needed

• Building with Opus 4.6

Additional references:

• GitHub #27665 — Intelligent model routing / 93.8% Opus usage issue

• GitHub #43326 — Auto-select model and effort level based on task complexity

• GitHub #44077 — Skill model field not propagated to Agent sub-invocations

• GitHub #45228 — SendMessage ignores model specified at Agent creation

• GitHub #50574 — Auto model switch

I did not set out to replace a scoring engine with a rule engine. I set out to make the system cheaper, easier to explain, and less fragile as I was not keen on moving to g5.xlarge or g6.xlarge due to prompt sizes increased and would be lot of churn in terms of architectural and infra changes, comes with re testing every functionality and the increase in the costs both the dev costs as well as instances cost even more if non-availability of spot and on-demand, currently using 75/25 for spot and OD for g4.mdn.xlarge (and 2xlarge).

What I eventually learned was that the original design had an architectural flaw: it asked a single opaque model score to do too many jobs at once. It had to decide whether an image was technically valid, whether it was worth sending to the expensive VLM path, whether it should be accepted or rejected, and how to justify that decision later. That worked until it did not. So I split the pipeline into two deterministic layers: a Tier-0 technical validator before the model, and a rule engine after the model. That change dropped cost, improved explainability, and made policy iteration much faster.

The system I started with

Before Parjanya v2.0 architecture v5.3, the pipeline was basically this:

The problem was not that the model was “bad.” The problem was that I had turned a rich decision into a number. Two images with the same score could be fundamentally different: one might be a sharp wildlife shot with a minor distortion, while another might be a soft-focus landscape with no clear subject. The number hid the nuance. Prompt changes also shifted the score distribution, which meant calibration drift could silently change the policy. And when someone asked why an image was rejected, a floating-point score was not a useful answer.

What I changed

I made two structural changes.

How the new decision layer works

The rule engine is deliberately boring in the best possible way. It is not trying to be clever. It is trying to be consistent.

Here is the decision logic in plain language:

Every verdict also gets a version tag and a reason string, so I can audit what happened later. That is a huge shift from the old system, where the final answer was essentially “the score was 0.41.”

Why this mattered operationally

The first benefit was cost.

Here is the cost comparison I care about most:

On my typical tenant workload, GPU spend still dominates the bill, so every image I keep out of the GPU queue is real leverage. I also found one non-obvious cost: at single-tenant scale, about half of the per-drain cost was NAT Gateway egress, not GPU. In the measured v25 drain, NAT cost was actually larger than GPU cost. That means the rule engine improved the decision layer, but infrastructure tuning still matters separately.

The second benefit was iteration speed.

I moved the rule engine through several versions in days, not weeks. The workflow became: edit the rule file, test it on canaries, inspect the reasons, then run the full re-curation if it looked good. No GPU redeploy. No prompt-engine rebuild. No waiting for model infrastructure to churn. In practice, that made policy iteration feel like software engineering again instead of model ops. The v25 drain took 7 hours 41 minutes end to end, but the rule-engine pass over 3,427 rows took less than a minute.

The third benefit was explainability.

I finally had a decision layer that could say things like:

• “reject — subject-critical motion blur”

• “reject — 3 slight defects stack”

• “review — weak subject dominance; technically clean”

That may sound small, but it changes everything when a user asks why something was rejected. A reason string is much more useful than a numeric score.

The fourth benefit was robustness to prompt drift.

When the IQA prompt changed from v16 to v17, the score distribution shifted. Under the old design, that meant threshold recalibration and potential policy drift. Under the new design, the rule engine sat on top of structured fields whose meaning stayed stable across prompt versions. The model could change in ways that improved extraction without forcing me to rethink the whole decision layer.

The measured validation run

The clearest proof came from the v25 rescore.

I had 2,426 images drained through the pipeline, and then 3,427 rows reprocessed by the rule engine. This was not a synthetic benchmark. It was the first large enough live run to give me defensible numbers.

Pipeline results

What stood out to me was not just that the run completed, but that it completed cleanly. There was no message loss, the DLQ stayed at zero, and the autoscaler shut down correctly after the queue emptied.

Rule-engine results

The most interesting transitions were:

That last part mattered to me because it showed the rule engine was not trying to force certainty where none existed. It preserved uncertainty instead of masking it.

Why this architecture works

This pattern is not new in spirit. It is a cascade: a cheap stage rejects obvious failures, and the expensive stage only handles what survives. That reduces inference cost and keeps the scarce GPU path for cases that actually need it. The broader literature supports the same idea, especially for VLM and moderation workloads.

For me, the more important pattern was extract-then-decide. The VLM is the extractor. The rule engine is the decider. Once I separated those roles, the system became easier to reason about. The model could be probabilistic and flexible. The policy could remain deterministic and auditable.

What I watch for now

I did not trade away all the hard problems. I just moved them into better places.

That last item is still open: infrastructure cost can easily dominate the apparent model cost, so I do not want to fool myself into thinking the architecture alone solved everything.

What is next

The next steps are pretty clear to me. Dedup is still shipped but not yet used as a hard gate in production. The rule engine will likely get a v5 cleanup once the remaining fallback paths are collapsed. And I want a dashboard that breaks out cost by Tier-0 reject reason, because it would be useful to know exactly how much pure margin I am saving when corrupt files, blank frames, and blown exposures are filtered early.

The takeaway

I did not move from “AI” to “rules.” I moved from one opaque score to a more honest pipeline.

Now the model extracts structure, the rule engine makes the decision, and the cheap gate keeps obvious failures away from the GPU. That gave me lower cost, faster iteration, and a system I can actually explain to another human without hand-waving. For a production image pipeline, that is the architecture I trust more.

One thing I appreciated only after moving to the rule engine was how much the user experience improved once the system stopped behaving like a black-box scorer.

Previously, the output was essentially a number hidden behind a threshold. After the re-curation architecture, every image started carrying an explainable pipeline trail: technical validation status, VLM enrichment state, structured distortion analysis, composition signals, subject analysis, and finally a deterministic curation verdict with explicit reasoning. The gallery stopped feeling like “an AI guessed a score” and started feeling like a traceable review system.

In the image below, for example, the pipeline clearly shows the two-stage flow: Tier-0 technical validation first, followed by VLM enrichment and structured analysis. The system identifies slight sharpness and focus issues, explains where they occur (“subject lacks critical sharpness on head and eye area”), records composition attributes like framing and depth layers, and still accepts the image because the final rule evaluation determined the defects were minor enough relative to subject structure and overall composition quality.

That distinction matters. Under the old scoring engine, this image could easily have landed near a threshold boundary and become another opaque 0.62 vs 0.58 decision. Under the new architecture, the reasoning is visible, deterministic, and debuggable.

The biggest realization for me was this: the rule engine did not make the system less intelligent. It made the intelligence easier to operationalize.

The VLM still does the hard perceptual work — understanding composition, defects, subject prominence, and scene semantics. But the final decision layer is no longer probabilistic glue hidden behind one floating-point number. It is now an auditable policy system built on top of structured perception.

That separation ended up becoming the real architectural shift.

A few months ago, I wrote about why I believed in a Haiku-first strategy: start with the cheapest and fastest model possible, then escalate only when the task genuinely becomes harder. That idea still makes sense in principle.

But over the last few weeks, while working deeply on my VLM control plane / IQA platform, I realized something important:

For my current workload, Sonnet 4.6 has become the model I now measure everything against.

Not because it is the smartest model Anthropic offers. Not because it is the cheapest. But because it currently sits at the most practical intersection of:

• reasoning quality

• long-context reliability

• infra-heavy debugging

• ML-heavy orchestration

• coding consistency

• operational cost

• and sustained throughput

That combination matters a lot when you are building systems where the model is not simply “answering questions,” but continuously operating across orchestration, debugging, inferencing workflows, infrastructure decisions, and large-context reasoning.

The original Haiku-first thesis still holds

I still believe the core idea behind the earlier post was correct:

Default to the cheapest model that can reliably complete the task.

Anthropic’s pricing still makes that logic compelling.

At scale, these economics matter enormously.

If you are running:

• agentic workflows

• multi-step debugging

• recursive orchestration

• long-context analysis

• or VLM-heavy pipelines

…output-token costs become very real very quickly.

That is exactly why Haiku originally made so much sense.

But my workload changed

The problem is not that Haiku became “bad.” (also the gap across the models become evident due to version differences, Haiku is still at 4.5 with 200k context, whereas Sonnet and Opus at 4.6 and 4.7 with 1M Context)

The problem is that my workload evolved into something much more infra-heavy and ML-heavy.

The VLM control plane is no longer just lightweight orchestration or simple extraction work. The workflows now involve:

• larger context retention

• deeper architectural reasoning

• distributed infra debugging

• inferencing orchestration

• stateful workflows

• code + infra + ML reasoning in the same session

• long-running debugging loops

• and increasingly large operational context

This is where Sonnet 4.6 started to outperform Haiku dramatically in practical usefulness.

Why Sonnet 4.6 became my benchmark

Anthropic positions Sonnet 4.6 as the “best combination of intelligence, speed, and cost,” and honestly, that aligns closely with my own experience.

Sonnet 4.6 currently provides:

• 1M-token context window

• adaptive thinking

• fast latency

• significantly improved coding quality

• stronger instruction following

• much better long-context coherence

Anthropic also mentioned that in Claude Code testing:

• users preferred Sonnet 4.6 over Sonnet 4.5 roughly 70% of the time

• and even preferred it over Opus 4.5 in many workflows

That honestly tracks with what I have seen.

Sonnet 4.6 feels much more stable in:

• sustained coding sessions

• infra debugging

• architectural iteration

• and orchestration-heavy workflows

without becoming economically painful the way Opus can become.

Haiku 4.5: still useful, but no longer my default

This is probably the most important nuance in the entire post.

Haiku 4.5 is still:

• extremely fast

• extremely cheap

• very capable for its price tier

• excellent for parallelized execution

• strong for extraction/tagging/routing

• surprisingly good on coding benchmarks

Anthropic reports:

• 73.3% on SWE-bench Verified

• 40.21% / 41.75% on Terminal-Bench

Those are genuinely strong results.

But benchmark scores alone do not determine operational usefulness.

In my own experience, Haiku 4.5 now feels degraded for my specific workload.

Not degraded universally.

Degraded for this class of infra-heavy, ML-heavy systems work.

What I started noticing:

• unnecessary follow-up questions

• command thrashing locally

• context drift during debugging

• inefficient iteration loops

• loss of architectural continuity

• excessive operational churn

Sometimes it felt like the model was spending more effort “doing activity” than actually advancing the task.

That was the turning point for me.

Sonnet became the operational center of gravity

So the strategy evolved.

I no longer think in terms of:

“Haiku everywhere unless proven otherwise.”

Now the stack looks more like this:

This feels significantly more stable operationally.

Where Opus still matters

I still escalate aggressively to Opus for:

• architectural redesigns

• distributed systems debugging

• ML-heavy reasoning

• difficult infra changes

• large-context synthesis

• high-stakes production decisions

This is where the Opus models still separate themselves.

Anthropic’s published numbers are notable:

• Opus 4.6: 81.42% SWE-bench Verified

• 90.2% BigLaw Bench

• strong long-context retrieval

• better reasoning across hundreds of thousands of tokens

Opus 4.7 improves further:

• 13% improvement on a 93-task coding benchmark

• solved 4 tasks neither Sonnet 4.6 nor Opus 4.6 could solve

• 3× more production-task resolutions on Rakuten-SWE-Bench

• 21% fewer errors on OfficeQA Pro

You can actually feel some of these improvements during long debugging sessions.

Especially:

• reduced context drift

• better continuity

• fewer reasoning collapses

• stronger architectural consistency

Adaptive thinking changes the workflow significantly

One under-discussed improvement is adaptive thinking.

Sonnet 4.6 supports it.
Opus 4.6 supports it.
Opus 4.7 uses it exclusively.

This matters because:

• the model dynamically allocates reasoning effort

• easier tasks complete faster

• harder tasks receive deeper reasoning automatically

For infra-heavy workflows, this is a huge operational improvement.

Especially when the same session moves across:

• infra

• application logic

• orchestration

• ML behavior

• and debugging

without explicit model switching every few minutes.

Something interesting I noticed about Haiku switching automatically

One thing I still need to investigate further:

I occasionally noticed Claude seemingly switching into Haiku behavior automatically during sessions.

I initially thought this happened only at the beginning of sessions, but after more usage I suspect it can happen mid-session as well.

Anthropic’s Claude Code docs actually support this possibility:

• model switching can happen dynamically

• subagents can use Haiku automatically

• planning/execution layers may use different models internally

That would explain some of the behavior I observed:

• sudden increases in unnecessary questioning

• lightweight command loops

• simplified reasoning paths

• or execution-style interactions appearing inside longer workflows

I do not think this is inherently bad.
It actually makes sense architecturally.

But on infra-heavy workflows, it can sometimes become noticeable.

The timing of this shift matters for me personally

This transition is happening at an important moment.

I am currently preparing:

• dev + prod environment separation

• launch readiness

• infrastructure stabilization

• ML inferencing orchestration

• and final architectural refinement

ahead of launch in roughly two weeks.

That timing matters because the recent Anthropic infrastructure and limit improvements are actually having a practical operational effect.

Anthropic recently:

• removed dedicated 1M-context rate limits for supported models

• expanded higher-usage limits

• improved capacity availability

• and publicly discussed large-scale compute partnerships

I do not want to get into commercial details.

But practically speaking:

• peak-hour friction has reduced significantly

• longer debugging sessions feel more reliable

• large-context sessions are more usable

• and the additional headroom gives much more leverage for coding and debugging

That matters a lot when your workflows involve:

• long-context infra debugging

• VLM inferencing orchestration

• architecture synthesis

• and recursive engineering sessions

Bottom line

My original Haiku-first idea still solid and would try working on enhancing further in future versions. (Plan is to leverage, multiple models across the frontier models, both models like Claude, codex and free versions like Gemma4, Qwen3.6 etc.)

But the center of gravity moved.

Today:

• Haiku 4.5 is my narrow execution layer

• Sonnet 4.6 is my operational benchmark

• Opus 4.6 is my deep reasoning escalation

• and Opus 4.7 is the model I reserve for the hardest architectural and ML-heavy problems

The real lesson is not:

“Always use the smartest model.”

And it is also not:

“Always optimize for cost.”

The real lesson is:

The best model is the one that remains operationally useful under your actual workload.

For my current stack, Sonnet 4.6 is now that benchmark.

References & Further Reading

Anthropic Documentation & Official Notes

1. Anthropic Claude Models Overview
   Official model capabilities, context windows, adaptive thinking, latency tiers, and supported features for Haiku, Sonnet, and Opus.

2. Anthropic Pricing Documentation
   Current pricing for Haiku 4.5, Sonnet 4.6, Opus 4.6, Opus 4.7, prompt caching, batch processing, and 1M-context usage.

3. Claude Code — Costs & Model Usage Patterns
   Useful for understanding model switching, subagents, orchestration strategies, and practical guidance on when to use Haiku vs Sonnet vs Opus.

My Related Notes & Blogs

1. Why You Should Choose Haiku as Default
   My earlier thesis on why a Haiku-first strategy originally made sense economically and operationally.

2. Opus 4.7 — Initial Practical Observations
   Early notes on context retention, hallucinations, workflow behavior, and operational observations while testing Opus 4.7.

3. Jagadeesh Rampam — Substack Archive
   Broader writing on infra-heavy systems, AI engineering workflows, AWS architecture, ML systems, and long-context operational patterns.

Engineering & Long-Context Best Practices

1. OpenAI — Prompt Engineering Best Practices
   Strong reference for practical orchestration, structured prompting, decomposition, and reliability strategies across long workflows.

2. AWS Well-Architected Framework
   Essential reading for scalability, operational excellence, cost optimization, reliability, and architectural trade-offs in infra-heavy systems.

3. Google SRE Workbook
   One of the best operational references for debugging culture, monitoring, production reliability, incident management, and long-running system operations.

When I developed the Parjanya v2.0 frontend on localhost, I ran into a series of issues that only became obvious later in deployment: CORS and preflight failures, mixed-content blocks, proxy quirks, and security leaks. To solve this and get closer to production-parity, I moved toward a server-to-server pattern: serving the SPA through Amazon CloudFront (with an S3/CloudFront static origin or Lambda@Edge) and serving the API through an Application Load Balancer (ALB) in a VPC. This gives me global caching, TLS/WAF protection, single-origin consistency that removes CORS pain, and lower egress costs.

In this post, I go deep into the localhost development pitfalls, CORS mechanics and misconfigurations, localhost vs cloud-hosted trade-offs, and the migration plan I would follow, along with code snippets, architecture diagrams, tables, and references.

TL;DR

I originally wrote a primer of Parjanya v2.0’s move from localhost-first development to a production-shaped AWS architecture. This shorter repost is the key lesson: localhost is great for iteration, but it hides the boundaries that matter in production. CORS failures, presigned upload issues, and origin mismatch kept pointing to the same conclusion — the right model for modern cloud apps is server-to-server.

Serve the frontend from CloudFront, route backend services through ALB, and let the backend control S3 access and tenant isolation. Production-shaped architecture is not a nice-to-have; it is the difference between a system that merely works locally and one that is actually built to scale.

Background & Context: Parjanya v2.0

Parjanya v2.0 is a multi-tenant SaaS system where each tenant has its own storage and its own backend API. In development, the frontend runs on localhost while talking to AWS services for file uploads and API calls. In production, I intend to serve the SPA from a CDN (CloudFront) and the API behind an ALB.

That split introduced problems for me: local development deviated from production in origin and protocol, which led to CORS and mixed-content issues. The prod parity gap was wide. I often saw developers disable CORS checks or use wildcards on S3 buckets for convenience, but that broke strict production settings and weakened security. LocalStack even ignored S3 CORS rules in some versions, which meant bugs were not caught until deployment.

My setup here is that the Parjanya v2.0 backend is AWS-based (ECS/Fargate or EC2 behind an ALB, with S3, IAM, and related services), and that the frontend is a static app that can be hosted on S3 + CloudFront.

Localhost Development Pitfalls

Switching from localhost to AWS exposed several hidden traps for me. The main issues were:

CORS Preflight Failures

Browsers enforce the same-origin policy, so any cross-domain AJAX or fetch request triggers CORS checks. On localhost, I often used Access-Control-Allow-Origin: * or disabled checks (DISABLE_CORS_CHECKS=1 with LocalStack), which masked issues. In production, the SPA origin, such as https://<cloudfront-id>.cloudfront.net, must exactly match S3 bucket CORS rules; otherwise S3 returns 403 Forbidden.

For example, if only https://api.parjanya.com is in AllowedOrigins, a request from https://<cloudfront-id>.cloudfront.net gets blocked. The root cause is simple: dev used wildcards or localhost origins, while prod locked to the CDN domain.

Origin Drift (Dev vs Production)

A subtle pitfall is that the frontend origin differs in dev (http://localhost:3000) versus prod (CloudFront domain or a custom domain). Code that relies on window.location.origin or environment variables can compute the wrong URLs in production. This drift also means the correct CORS origin and cookie domains can be wrong in prod.

Mixed-Content Blocks (HTTPS vs HTTP)

Browsers on https:// pages block any http:// resources. On localhost, I might use plain HTTP without SSL, but once the SPA is on CloudFront over HTTPS, calls to an unsecured origin, or an S3 HTTP URL, are blocked as mixed content. My fix is to use HTTPS everywhere in AWS (ALB and CloudFront) and enforce redirect-to-HTTPS policies.

Dev Proxy vs True Environment

Many dev setups use a proxy, such as npm proxy settings or a simple NGINX layer, to avoid CORS. For example, NGINX on localhost:8001 forwarding /api/ to the real backend means the browser sees only one origin. That hides CORS, but only in development. In production, the CDN fronts the API with a different host unless I unify the route.

IAM / Bucket Policy Surprises

In dev, a single IAM role or default credential set can accidentally be used for all S3 uploads. That can hide cross-tenant access problems. In AWS, I need separate IAM roles and strict bucket policies per tenant. Bucket policies may also imply a deny if conditions are not met; for example, a presigned URL can 403 if the request is not over HTTPS or if the Host header does not match an allowed VPC condition. These issues usually do not appear until I hit real AWS.

LocalStack / Emulator Mismatch

Tools like LocalStack do not always fully honour CORS. In one case, even with CORS configured on the bucket, LocalStack ignored it, and DISABLE_CORS_CHECKS=1 had no effect. That means a workflow that appears to work in dev can fail in prod. LocalStack may also default to HTTP endpoints instead of HTTPS, which introduces mixed-content issues.

Credentials & Cookies

On localhost, cookies are often not sent cross-origin. If my app relies on cookie-based auth (fetch with credentials: 'include'), it can work locally but fail once domains differ. Browsers also forbid Access-Control-Allow-Origin: * when withCredentials is true, so production needs specific origins and Access-Control-Allow-Credentials: true.

Presigned URL Expiry and Caching

Some dev workflows use very short-lived presigned URLs or assume uploads happen instantly. In AWS, CloudFront may cache redirects by default unless configured otherwise, and ALB/CloudFront caches need invalidation after deploys. A misconfigured max-age or missing invalidation can make users see stale JS bundles. Presigned URLs can also expire during multi-part uploads if they are not refreshed.

Other Environmental Mismatches

Hardcoded environment values, such as REACT_APP_API_URL=http://localhost:8080, can cause build issues. Differences in Node versions, npm proxy settings, or TLS certificate trust on developer machines can also produce odd errors that I do not see in production.

Each of these issues comes from the same root problem: development on localhost is not the same as the deployed cloud environment. A major cause is the separate-origin problem. When the frontend and API live under different schemes or hosts, the browser’s SOP and CORS rules start to matter, and preflight requests fail if any method or header is not whitelisted.

Pitfall Comparison Table

CORS Deep Dive: Browser Enforcement & Misconfigurations

CORS (Cross-Origin Resource Sharing) is an HTTP header-based protocol that lets servers whitelist allowed origins for resource sharing. Browsers enforce it like this: when a script on https://frontend.com makes a cross-domain request, the browser adds an Origin: https://frontend.com header. If the request is simple, the browser checks the response for Access-Control-Allow-Origin. If it is missing or does not match, the browser blocks the response in JavaScript and shows a console error such as “CORS request blocked.”

For non-simple requests, like PUT, custom headers, or requests with Content-Type: application/json, browsers first send a preflight OPTIONS request with Origin and Access-Control-Request-Method/Headers. The server must return the correct Access-Control-Allow-* headers. If the preflight fails, the browser aborts without sending the real request.

A missing or mismatched header causes CORS errors that are often hard to debug. Because the browser hides details for security, the console often gives only a generic block message, so I need to inspect the network tab or devtools to see the headers.

Key Headers and Rules

• Access-Control-Allow-Origin: Specifies which origin or origins are allowed. It cannot be * if Access-Control-Allow-Credentials: true is required.

• Access-Control-Allow-Methods: Lists which HTTP methods the server accepts. If my SPA does a PUT but the server only allows GET and POST, preflight fails.

• Access-Control-Allow-Headers: Lists which custom request headers, such as Authorization, are allowed.

• Access-Control-Allow-Credentials: If true, cookies or credentials can be sent. Browsers do not allow * origin when this is true.

Common Misconfigurations

• Wrong Origin Whitelist: If the SPA is served at https://app.example.com but S3 CORS only includes http://localhost:3000, production will fail.

• Forgetting OPTIONS Handling: Some backends only handle GET/POST and ignore OPTIONS. Preflight then returns 403 or 404.

• Missing Response Headers: The resource may respond, but if it does not include CORS headers, the browser blocks it. CloudFront response headers or edge functions can help.

• Credentials & Wildcards: Enabling Access-Control-Allow-Origin: * globally and then using credentials will fail.

• Case or Slash Mismatch: Origins are exact strings, so protocol, port, and trailing slash matter.

• Tooling Oversights: Some clients send headers that trigger preflight. JSON and Authorization almost always do.

By understanding CORS this way, I can configure AWS correctly. For example, on S3 I can apply a bucket CORS configuration like this:

<CORSConfiguration>
 <CORSRule>
   <AllowedOrigin>https://d8sqejhsq49zo.cloudfront.net</AllowedOrigin>
   <AllowedMethod>GET</AllowedMethod>
   <AllowedMethod>PUT</AllowedMethod>
   <AllowedHeader>*</AllowedHeader>
   <ExposeHeader>ETag</ExposeHeader>
 </CORSRule>
</CORSConfiguration>

In practice, I whitelist the specific CloudFront or app domain in AllowedOrigins and include every method I need.

CloudFront also offers features that help with CORS. I can use a Response Header Policy that automatically adds Access-Control-Allow-Origin, or I can use a CloudFront Function to dynamically echo the Origin. The simplest pattern is still to use CloudFront + ALB with the same origin, so CORS becomes mostly unnecessary.

CloudFront + ALB Architecture: Pros & Cons

Moving the frontend to CloudFront and the API behind an ALB gives me a lot of benefits, but it also adds complexity.

What I Gain

• Global Performance & Latency: CloudFront has a global edge network, and static assets can be cached at the edge. That reduces TTFB and improves performance for distant clients.

• Security & Compliance: CloudFront gives me DDoS protection and a clean place to attach AWS WAF. I can also isolate the ALB inside a private VPC and allow access only from CloudFront.

• Single-Origin Domain: By serving the SPA from CloudFront and routing API calls through the same CloudFront distribution or domain, I remove most CORS issues entirely.

• Cost Optimisation: CloudFront can reduce outbound bandwidth costs by caching content closer to users and lowering load on the ALB and backend.

What I Trade Off

• Architecture Complexity: I now manage CloudFront, Lambda@Edge or CloudFront Functions if needed, the ALB, Route 53, ACM certificates, and deployment automation.

• Debug and Deploy Overhead: Changes are slower to test because I need deploys and cache invalidations.

• Cache Invalidation Hassles: SPA releases can leave stale files behind unless I use hashed filenames or invalidate the right paths.

• Session & Auth Handling: Cookie-based auth needs careful CloudFront forwarding rules and secure cookie settings.

• Extra Hop Latency: There is an extra network hop, but cache hits usually outweigh that cost.

• CDN Cost: CloudFront and related services have a cost, although caching and egress savings can offset it at scale.

High-Level Architecture Diagram

This is the architecture I want: the browser hits CloudFront, static content comes from S3 through CloudFront, and dynamic requests hit the ALB. Both S3 and ALB stay secured, and only CloudFront acts as the public entry point.

Migration Strategy & Checklist

Step 1: Preparation & Planning

I first audit the current deployment: all domains, SSL certificates, DNS records, WAF rules, IAM roles, and the existing frontend and API endpoints. Then I define the target state: a single CloudFront distribution, for example with an alternate domain like app.example.com, fronting an internal ALB and S3 origin. I also estimate the work and categorise risk so I can separate simple changes from business-critical flows.

Step 2: Provision Infrastructure

• Create the CloudFront distribution. If I use Terraform, I need a custom_origin_config for the ALB origin so it is not treated like an S3 origin.

• Configure cache behavior. I point routes to the ALB origin for API calls and to S3 for static routes. I forward the Origin header and the relevant CORS headers so the origin sees them.

• Set up TLS certificates. I use ACM for the frontend domain and attach the certificate to CloudFront. The ALB also needs HTTPS.

• Restrict ALB access. I create a security group that allows inbound 443 only from CloudFront IP ranges or a trusted origin header setup.

• Configure S3 CORS and bucket policy. I allow my frontend domain and enforce HTTPS via aws:SecureTransport.

• Update CI/CD. After uploading SPA artifacts to S3, I trigger a CloudFront invalidation for the changed paths.

Step 3: Testing & Validation

• Smoke tests in staging: I point a test domain to the new distribution and verify that static assets, API calls, and auth flows work.

• Performance and security verification: I check cache hit ratios, enable WAF metrics if used, and confirm that direct access to the old ALB is blocked.

• Staged DNS cutover: I move traffic gradually using Route 53 weighted records or a similar approach.

Step 4: Full Cutover and Rollback Plan

Once I am confident, I point the production app domain to CloudFront. I keep rollback simple by preserving the old config and having a direct path back to the ALB if needed. Because the ALB is restricted to CloudFront traffic, rollback needs to be planned carefully.

Code & Config Snippets

Amazon S3 Bucket CORS (example JSON)

{
  "CORSRules": [
    {
      "AllowedOrigins": ["https://your.frontend.domain"],
      "AllowedMethods": ["GET", "PUT", "POST", "DELETE", "HEAD"],
      "AllowedHeaders": ["*"],
      "ExposeHeaders": ["ETag", "x-amz-version-id"],
      "MaxAgeSeconds": 3600
    }
  ]
}

Terraform: AWS CloudFront Distribution (ALB origin)

resource "aws_cloudfront_distribution" "cdn" {
  origin {
    domain_name = aws_lb.api.dns_name
    origin_id   = "api-origin"
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  default_cache_behavior {
    target_origin_id         = "api-origin"
    viewer_protocol_policy   = "redirect-to-https"
    forwarded_values {
      headers = ["Origin", "Access-Control-Request-Method", "Access-Control-Request-Headers"]
      cookies { forward = "all" }
      query_string = true
    }
    allowed_methods = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods  = ["GET", "HEAD"]
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate.certificate.arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }
}

NGINX Reverse Proxy (Dev Example)

server {
  listen      8001;
  server_name localhost;
  location / {
    proxy_pass http://127.0.0.1:3000;
  }
  location /api/ {
    proxy_pass http://127.0.0.1:8080/;
  }
}

CloudFront Function (or Lambda@Edge) to Add CORS

async function handler(event) {
  var request = event.request;
  var response = event.response;
  if (request.headers.origin && !response.headers['access-control-allow-origin']) {
    response.headers['access-control-allow-origin'] = { value: request.headers.origin.value };
  }
  return response;
}

Sample IAM Policy (Bucket HTTPS Enforce)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RequireTLS",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }]
}

Localhost vs Cloud-Hosted Frontend

Monitoring, Logging & Testing Tools

Once the system is live, I want to rely on:

• Metrics & Logs: CloudWatch metrics for CloudFront and ALB, plus access logs.

• Real-User Monitoring: CloudWatch RUM for client-side metrics and errors.

• Tracing: AWS X-Ray if the backend is complex.

• Error Tracking: A frontend JS error reporter such as Sentry.

• Testing Tools: Postman or curl with an Origin header for CORS validation, and load tools like Apache Bench or JMeter for performance testing.

Community Insights & References

AWS Official Guidance

• Optimizing application performance: CloudFront + ALB strategic benefits
  Covers CloudFront in front of ALB, performance improvements, origin protection, and migration considerations.

• Introducing Amazon CloudFront VPC Origins
  Explains private VPC origins, CloudFront-to-private-ALB architecture, and stronger origin isolation.

• Restrict access to Application Load Balancers from CloudFront only
  AWS guidance for protecting ALB origins using CloudFront custom headers and origin restrictions.

• CORS configuration through Amazon CloudFront
  Deep dive into forwarding CORS headers, OPTIONS caching, and CloudFront cache/origin request policies.

• Accelerate and protect dynamic workloads with CloudFront
  Focuses on performance, persistent connections, and origin offload for dynamic applications.

MDN Documentation

• MDN — Cross-Origin Resource Sharing (CORS) Guide
  The foundational browser-side explanation of CORS, preflight requests, and browser enforcement.

• MDN — CORS Errors Guide
  Excellent debugging reference for interpreting browser CORS failures.

• MDN — Access-Control-Allow-Origin Header
  Detailed explanation of the most important CORS response header.

• MDN — Practical CORS Configuration Guide
  Security-oriented implementation guidance for configuring CORS correctly.

• MDN — CORS Glossary
  Concise overview of same-origin policy and cross-origin access.

AWS Documentation

• Amazon S3 — Using CORS
  Official S3 documentation for configuring and understanding CORS.

• Amazon S3 — Troubleshooting CORS
  Extremely useful for diagnosing 403s, AllowedOrigins mismatches, and missing methods.

• Amazon S3 — Configuring CORS Examples
  Shows JSON examples for S3 bucket CORS policies.

• Amazon S3 — Elements of a CORS Configuration
  Detailed breakdown of AllowedOrigins, AllowedMethods, AllowedHeaders, etc.

• AWS re:Post — Resolve “No Access-Control-Allow-Origin” errors in CloudFront
  Useful troubleshooting walkthrough for CloudFront + CORS setups.

• AWS re:Post — Configure and confirm CORS in Amazon S3
  Practical debugging examples using curl and OPTIONS preflight checks.

Community Q&A

• Stack Overflow — S3 Access-Control-Allow-Origin Header discussion
  One of the classic threads on S3 CORS response handling.

• Stack Overflow — S3 not returning Access-Control-Allow-Origin headers
  Useful troubleshooting thread for bucket/object-level CORS confusion.

• Express.js CORS Middleware Docs
  Good explanation of browser-enforced CORS vs server-side behavior.

• AWS re:Post — Intermittent CORS errors even with Allow-Origin configured
  Helpful for understanding cache and header propagation edge cases.

Case Study Blogs & Practical Guides

• StormIT — CloudFront Distribution for EC2 & ALB
  Practical CloudFront + ALB deployment walkthrough.

• Using AWS CloudFront to improve performance, security & availability
  Covers caching, origin groups, availability, and performance patterns.

• Handling CORS Issues in Amazon S3
  Community-written debugging guide with real-world examples.

• Adding a CORS Policy to an S3 Bucket
  Lightweight and practical S3 bucket CORS reference.

• Prepare and run performance tests for CloudFront using RUM
  Great reference for validating CloudFront improvements in production.

Closing Thought

What I learned is simple: localhost is great for speed, but it is not production. If I want fewer surprises, fewer CORS headaches, and better security, I need to design the frontend and backend like they will live in production from the beginning.

Lessons from Parjanya v2.0 and the v5.4 architecture revision

I never treated localhost as the target architecture. It was simply the default starting point for local development, as it is for most full-stack systems. But as I built Parjanya v2.0, I kept running into a recurring class of failures: CORS errors, origin mismatch, presigned upload friction, and the widening gap between development-time assumptions and production-time behaviour. That experience forced me to step back and re-evaluate the system from first principles. What emerged was not a localhost fix, but a stronger production-shaped model: server-to-server architecture for cloud-based full-stack applications and distributed systems.

Why localhost stopped being enough

Local development is useful because it is fast. But speed can hide architecture debt.

In Parjanya v2.0, the real problem was not that localhost was broken. The problem was that localhost encouraged a development loop that was too far removed from the actual production trust boundary. The browser, S3, IAM, and backend services each enforce different rules, and local development often smooths those rules away just enough to create false confidence. Then the system reaches the real deployment path and the hidden assumptions come apart.

That became especially clear with browser-based uploads. A local setup may appear functional, but the moment the frontend starts speaking directly to tenant-specific buckets in S3, the browser becomes an active participant in the security model. The result is not just a technical inconvenience; it is a signal that the architecture itself needs to be shaped more deliberately.

The first real signal: CORS was exposing the architecture gap

CORS was one of the clearest signs that the local development experience was drifting away from the real system.

In theory, CORS is straightforward. In practice, it is one of the fastest ways to reveal that the frontend and backend are too loosely coupled. In Parjanya, browser uploads to S3 were not talking to a generic bucket. They were talking to tenant-scoped storage with strict policy boundaries. That meant every origin, method, and header mattered. A local proxy or permissive dev configuration might make the request succeed temporarily, but that success did not mean the architecture was correct. It only meant the browser had not yet been forced to tell the truth.

The architectural implication was obvious: if the browser has to fight the security model just to upload a file, the development workflow is revealing a deeper mismatch. In my case, that mismatch was not merely about CORS syntax. It was about the location of trust.

What Parjanya v2.0 architecture v5.4 actually changed

Architecture v5.4 is an architecture revision inside Parjanya v2.0, not a separate product. That revision was shaped by one principle: move trust out of the browser and into the backend.

The S3 architecture notes show the core design clearly: one bucket per tenant, IAM-scoped permissions, bucket policies, presigned URL generation in the backend, and lifecycle rules for cost control. The model is intentionally infrastructure-enforced. Tenant isolation is not left to frontend conventions or prefix hygiene. It is built into the storage boundary itself.

That design changes the system in a fundamental way. Instead of letting the frontend improvise access, the backend becomes the authority that validates identity, determines tenant ownership, constructs the object key, and issues a time-bound signed capability. The browser no longer owns authorization. It simply executes what the backend has already allowed.

Why server-to-server architecture made more sense

Once I looked at the problem that way, the answer became much clearer.

For a cloud-native application, especially a multi-tenant one, the frontend should not be the place where trust decisions live. The frontend should be delivered through a stable edge layer, the backend should own policy and identity, and object storage should be accessed through signed backend-issued capabilities. That is why I started favouring a server-to-server model for real production systems.

In practice, that means serving the frontend from CloudFront, exposing backend services through ALB, and letting the backend own S3 access through presigned URLs. The browser becomes a client, not a policy engine. The backend becomes the control point. The trust boundary becomes explicit. And the deployment path starts to look like the real system instead of a local approximation.

That shift also made debugging easier. When a request fails, there are fewer places to guess. Is it a policy issue? A bucket issue? A signature issue? A CORS issue? A routing issue? With a server-to-server design, the failure surface becomes narrower and more legible.

Multi-tenant storage is an infrastructure problem, not just an application problem

One of the strongest lessons from Parjanya’s architecture revision was that multi-tenant storage cannot be treated as an application afterthought.

The architecture notes show a per-tenant bucket model with explicit role and bucket policy enforcement. That is the right direction because it reduces ambiguity. Tenant isolation should not depend entirely on code discipline or naming conventions; it should be enforced by the infrastructure boundary itself.

This matters because multi-tenant systems fail in subtle ways when storage is shared too casually. A shared bucket can work, but it increases the burden on prefix logic, object ownership rules, and application-layer checks. A per-tenant bucket model is cleaner to reason about and easier to audit. It also aligns better with the way the rest of the Parjanya stack is already designed: backend validation, signed upload paths, explicit bucket policies, and lifecycle management.

Presigned URLs are capability tokens, not shortcuts

Presigned URLs were another major lesson.

A presigned URL is not just a convenience feature. It is a capability token that allows a very specific action for a very specific scope and time window. That makes it a very strong fit for Parjanya because the backend can validate the request first and then issue a constrained upload path. The browser does not need broad credentials. It only needs the signed permission to perform the exact operation the backend allowed.

That is the right security model for a SaaS system with tenant isolation. It reduces exposure, tightens the trust boundary, and lets the backend remain the source of truth for who can upload what and where. It also makes the system far easier to evolve because the upload flow is now a controlled protocol, not a loose browser-side improvisation.

Production-shaped development is the real goal

The biggest shift in my thinking was this: the goal is not to make localhost feel like production forever. The goal is to make local development reveal the same architectural boundaries that production will enforce.

That means treating origin boundaries, identity boundaries, and policy boundaries as first-class concerns from the beginning. It means avoiding development shortcuts that erase those boundaries too early. It means designing the system so that local development is still useful, but not misleading. And it means accepting that some friction is not a bug in the workflow — it is the architecture trying to tell you something.

In Parjanya v2.0, that lesson showed up everywhere: in CORS behavior, in presigned URL flows, in per-tenant bucket design, and in the decision to move toward a cleaner CloudFront + ALB + backend-controlled storage path. The architecture revision in v5.4 was not just an optimization. It was a correction toward a more honest production model.

What I would tell another engineering team

If I were explaining this to another team building a cloud-native product, I would say this:

localhost is fine for iteration, but it should not define the architecture. For distributed systems, especially multi-tenant SaaS, the real system lives in the boundaries: frontend delivery, backend authority, object storage policy, and signed capabilities. If those boundaries are blurred during development, the application will pay for it later in debugging time, security risk, and operational complexity.

The better pattern is production-shaped from the start:

the frontend should be served from CloudFront, backend services should sit behind ALB, the backend should generate presigned URLs, and S3 access should be governed by infrastructure-enforced tenant isolation. That design is cleaner, more secure, and much closer to how real cloud applications behave in production.

Closing thought

Parjanya v2.0 taught me that architecture is often revealed through friction.

CORS failures were not just browser noise. They were evidence that trust boundaries needed to be sharper. Presigned URLs were not just an implementation detail. They were the correct way to move capability into the backend. Per-tenant buckets were not just a storage choice. They were the cleanest way to enforce isolation. And localhost, while useful, was never the architecture — only the starting point.

The end result is simple: I now think in terms of production-shaped systems, not localhost-shaped workflows. For me, that is the difference between a prototype that merely works and a system that is actually ready to scale.

Good catch — here’s a clean, copy-paste ready References section with actual links (kept high-signal and aligned to your architecture themes).

📚 References & Further Reading

☁️ AWS (Core to this architecture)

• Multi-tenant S3 design patterns (must read)
  AWS Storage Blog
  https://aws.amazon.com/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/

• Dynamic routing with CloudFront (multi-tenant edge patterns)
  AWS Architecture Blog
  https://aws.amazon.com/blogs/architecture/dynamic-request-routing-in-multi-tenant-systems-with-amazon-cloudfront/

• CloudFront + origin patterns (edge → backend)
  AWS Docs
  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html

• Restricting ALB access via CloudFront (edge-controlled backend)
  AWS Docs
  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html

• Presigned URLs (backend-controlled access model)
  AWS Docs
  https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html

• CORS troubleshooting (why browser uploads fail)
  AWS Docs
  https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors-troubleshooting.html

• AWS Well-Architected Framework
  https://aws.amazon.com/architecture/well-architected/

These patterns are consistent across modern cloud-native systems:
move trust to the backend, enforce isolation at the infrastructure layer, and design for production boundaries early.

It wasn’t subtle.

It read less code.
It reasoned less deeply.
It stopped early.

And yet—nothing “official” had changed.

When Anthropic finally published their postmortem, they called it a set of bugs.

After digging through the data and my own usage, I don’t think that tells the full story.

Adaptive Thinking Gone Wrong

Why Claude’s Silence Broke My Trust

For months, Claude Code with Opus 4.6 was the backbone of my engineering workflow.

With Opus 4.7—and the rise of “adaptive thinking”—that same assistant began to feel unreliable, opaque, and, most concerning of all, quietly downgraded.

Anthropic’s April 23 postmortem confirmed something many of us already felt: Claude Code did get worse for weeks.

https://www.anthropic.com/engineering/april-23-postmortem

But the explanation—and the framing—left me with a deeper concern:

This wasn’t just a bug. It was a runtime failure of adaptive thinking.

This is a first-person account of what changed, what the data shows, and why this moment broke trust for me—even though I’m still not walking away.

1. When It Worked: Opus 4.6 as a Force Multiplier

My earlier experience with Opus 4.6 was very interesting.

Claude Code behaved like a senior engineer embedded in my workflow:

• It read deeply before editing

• It maintained context across long sessions

• It handled multi-step refactors with caution and coherence

Under the hood, this was already powered by adaptive thinking—a system that dynamically allocates reasoning effort per task.

But here’s the key:

It worked quietly and reliably.

2. When It Broke: Opus 4.7 Regression

With Opus 4.7, the experience flipped.

What I observed:

• Shallower reasoning

• More hallucinated structure

• Premature stopping or avoidance

• Worse tool usage

• Increased repetition

All while adaptive thinking was being positioned as the primary reasoning mode.

At the same time:

• Usage limits tightened

• Sessions became less predictable

From a user perspective:

It felt like a silent downgrade.

3. Anthropic’s Explanation

https://www.anthropic.com/engineering/april-23-postmortem

Anthropic attributes the regression to three issues:

Effort downgrade (March 4)

Default reasoning dropped from high → medium

Thinking cache bug (March 26)

Thinking history cleared after idle periods

Verbosity constraint (April 16)

Artificial limits reduced output quality

All three are now reverted.

Their position:

The model wasn’t degraded—only the application layer was.

4. What the Data Shows

Independent telemetry and analysis revealed:

• Files read before editing: 6.6 → 2.0

• Thinking length: ~2200 → ~600 characters

• Stop/avoidance behaviors: spiked significantly

These are not isolated anomalies.

They indicate systemic changes in:

• Reasoning depth

• Context retention

• Decision consistency

5. The Real Problem: A Runtime Failure

All three issues converge on one layer:

Adaptive thinking at runtime

• Lower effort → less reasoning

• Cache bug → lost reasoning

• Verbosity cap → suppressed reasoning

This creates a cascade:

Adaptive Thinking Failure Chain

6. Why the Framing Matters

Anthropic’s framing:

“A few issues, now fixed”

User reality:

“Core reasoning behaviour degraded for weeks”

That gap is where trust erodes.

Because for power users:

The runtime layer is the product

7. Bad Timing Made It Worse

This regression coincided with:

• Tighter usage limits

• Pricing pressure toward higher tiers

• Source-code leak incident

• Mythos leak

Together:

Reduced capability + reduced transparency + increased constraints

8. Why I’m Still Using Claude

I’m not leaving.

Because when it works:

It’s still one of the best engineering copilots available.

To Anthropic’s credit:

• Detailed postmortem

• Fixes implemented

• Public acknowledgment

But:

Benefit of the doubt ≠ restored trust

9. What Needs to Change

To rebuild trust, adaptive thinking must become:

Observable

Expose reasoning allocation

Controllable

Allow effort overrides

Stable

Test long-session behavior

Transparent

Treat runtime changes like model updates

Final Thought

Adaptive thinking isn’t just a feature.

It is the system between the user and the model.

When that system changes silently:

• Behaviour shifts

• Expectations break

• Trust erodes

I’ll keep using Claude.

But not as a black box anymore. In fact, exploring the options like Orchestrators like a battle-tested Cursor code and in future LiteLLMProxy along with Claude, gpt-4o, Gemma4:31b and Qwen-3.6 and/or Kimi k2.6

This is the simplest way to understand what actually broke:

What the Diagram Shows

At first glance, these look like three unrelated issues:

• Effort downgrade

• Cache bug

• Verbosity constraint

But they all hit the same underlying system:

How the model thinks, remembers, and explains

The Chain Reaction

Effort ↓ → Thinking ↓  
Cache Bug → Memory ↓  
Verbosity Cap → Visibility ↓  

= System Behavior Collapse

Each step compounds the next:

• Less effort → shallower reasoning

• Broken cache → lost continuity

• Lower verbosity → hidden reasoning

Individually manageable.
Together:

A collapse in perceived intelligence

Why This Matters

From a system design perspective, this is the real insight:

Reasoning quality is not just a model property.
It is an emergent property of the runtime.

That runtime includes:

• Effort allocation (adaptive thinking)

• Memory persistence (thinking cache)

• Output constraints (verbosity rules)

When all three degrade—even slightly—the system doesn’t fail gracefully.

It fails behaviourally.

The Key Takeaway

The model didn’t get worse.
The system deciding how it thinks did.

And that distinction is exactly why this episode matters.

References

1. Claude Code Regression Update: Anthropic’s April 23 Postmortem Changes the Story

2. Clients Were Right: Anthropic Admits Claude Code Got Dumber
   https://kingy.ai/ai/clients-were-right-anthropic-admits-claude-code-got-dumber-not-claude-post-mortem/

3. An update on recent Claude Code quality reports
   https://www.anthropic.com/engineering/april-23-postmortem

4. Deep News — Superlinear Academy
   https://yage.ai/share/

5. The Claude Code Nerf: An Invisible, Unilateral Downgrade
   https://yage.ai/share/claude-code-runtime-regression-en-20260407.html

6. Adaptive thinking - Amazon Bedrock
   https://docs.aws.amazon.com/bedrock/latest/userguide/claude-messages-adaptive-thinking.html

7. Claude Opus 4.6 adaptive reasoning
   https://www.infoq.com/news/2026/03/opus-4-6-context-compaction/

8. Adaptive thinking - Claude API Docs
   https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking

9. Opus 4.7 overview
   https://artificialanalysis.ai/articles/opus-4-7-everything-you-need-to-know

10. Did Anthropic Secretly Nerf Claude?
    https://thedroidguy.com/anthropic-nerf-claude-quality-degradation-explained-1273110

11. Anthropic source code leak (NDTV)
    https://www.ndtv.com/feature/2026-just-got-crazy-internet-erupts-after-anthropics-claude-source-code-leak-shakes-ai-industry-11294628

12. Anthropic leaked its own Claude source code (Axios)
    https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai

13. Claude Code leak analysis (Dev.to)
    https://dev.to/varshithvhegde/the-great-claude-code-leak-of-2026-accident-incompetence-or-the-best-pr-stunt-in-ai-history-3igm

14. Claude Mythos leak https://absolutelyagentic.com/p/claude-mythos-the-ai-model-anthropic-won-t-release-to-the-public

15. Mythos leak coverage (Fortune)
    https://fortune.com/2026/03/26/anthropic-says-testing-mythos-powerful-new-ai-model-after-data-leak-reveals-its-existence-step-change-in-capabilities/

16. Mythos summary (Mashable)
    https://mashable.com/article/claude-mythos-ai-model-anthropic-leak

17. Anthropic second security lapse (Fortune)
    https://fortune.com/2026/03/31/anthropic-source-code-claude-code-data-leak-second-security-lapse-days-after-accidentally-revealing-mythos/

18. Reddit discussion
    https://www.reddit.com/r/ClaudeAI/comments/1s9ai45/anthropic_leaked_512000_lines_of_claude_code/

19. Alignment Forum discussion
    https://www.alignmentforum.org/posts/K8FxfK9GmJfiAhgcT/anthropic-repeatedly-accidentally-trained-against-the-cot

20. Claude Code leak breakdown
    https://www.felamity.com/post/claude-code-leak-2026-what-happened-and-why-it-matters-for-ai-security

21. Mythos video

1. Japanese coverage of quality regression
   https://innovatopia.jp/ai/ai-news/98588/

Three weeks ago,

I wrote about how Claude Opus 4.6—with its 1M context window—felt like a genuine breakthrough for my workflow:

That post built on a broader recommendation I had been advocating: start with lighter models and escalate only when needed. I wrote about that approach here:

That strategy worked when the model ladder felt consistent. But in practice today, the gap between versions has widened enough that this escalation model is far less reliable.

In my workflow—infra-heavy, ML-heavy, multi-repo—the bulk of the system was actually built by Opus 4.6 within 3–4 days. What followed were incremental improvements:

• Prompt updates for stricter IQA

• Docker build refinements

• CLIP-IQA deprecation

• Graviton migrations

• SageMaker removal → EC2 migration (Spot vs on-demand)

• Handling infra quirks (e.g., g4dn.xlarge unavailability in ap-south-1)

These are not “greenfield” tasks—they depend heavily on accurate recall of current system state and few of them were encountered earlier and have documented in the architecture review (23+ sections, Appendix of 6 detailed sections) with enough context and thorough deep dive and always handy at the root folder of workspace.

Since moving to Opus 4.7, that’s exactly where things started breaking.

For the past 18 days, I’ve been dealing with usage limits, context drift, and behavior changes I never asked for and now hit weekly limits to be completely locked out for the next 5 days —enough to pause my subscription and evaluate alternatives.

you can see from my usage chart, I tried leveraging different models based on the usecase/component/task and complexity

Going into the details…

The 4.6 Honeymoon: 1M Context Without the Drama

My setup with Opus 4.6:

• Multiple repos (ML, backend, frontend, shared libs, infra)

• Plan → execute workflows

• Heavy context, but usually <200k tokens

And yet, it behaved like a disciplined senior engineer:

• Stayed within plan boundaries

• Maintained architectural coherence

• Delivered steady, compounding progress

It hit the long-context sweet spot: large memory, without instability.

What Changed with Opus 4.7

With adaptive thinking enabled by default, the behaviour profile shifted significantly.

1. One-Prompt Runs That Burn an Hour

• Prompts run excessively long

• Usage limits hit faster

• Thinking increases, output doesn’t

It feels like over-analysis replacing execution.

2. Context Bloat and Losing the “Current State”

In long sessions:

• Old decisions override new ones

• Recent corrections get ignored

• Model behaves as if it’s working on stale code

In a poly-repo system, this is critical failure—not inconvenience.

3. Hallucinated Behaviour (Real Production Risk)

The most concerning issue: unsolicited behaviour changes

Example 1: Image Rotation

• Final testing stage

• Behaviour already agreed

• Suddenly: vertical images rotate

No prompt. No plan. No instruction.

Instead of reverting, the model:

• Expanded the problem

• Designed rotation logic

• Introduced new edge cases

Even explicit instructions like

“Never rotate images”
didn’t cleanly undo prior drift.

Example 2: Hardcoded Aspect Ratio Logic (Half an Hour Later)

A second example happened shortly after, while fixing the same issue.

The model proposed:

• Portrait → 1366×2048

• Landscape → 2048×1366

• “No rotation logic, just libraw defaults”

This sounds reasonable—but it’s wrong.

The real requirement is aspect-ratio-aware handling, because RAW files can be:

• 16:9

• 4:5

• 1:1

• others

Even though my current dataset (1000+ images) includes 1:1, the model ignored that variability and jumped to a hardcoded assumption.

These are “small” issues—but in production, they are trust breakers:

• They introduce silent regressions

• They require manual detection

• They increase review overhead before launch

And also not sure, how many of these issues (small/high/max) are persists, including IQA logic which is a ship-blocker, infra changes (burns my pocket!) etc.

This Isn’t a Single-Model Issue

One important detail: this is not happening in isolation.

I’ve actively used:

• Opus 4.6

• Opus 4.7

• Sonnet 4.6

• Haiku 4.5

The attached usage snapshot reflects this multi-model workflow.

That actually makes the issue more concerning—because:

• The regression isn’t tied to a single model

• Switching models doesn’t reliably stabilize behaviour

• The “escalation strategy” becomes inconsistent

What Others Are Seeing

Across blogs, Reddit, and developer communities:

• Prompt regressions vs 4.6

• Higher sensitivity to phrasing

• Increased hallucinations in coding workflows

• Faster quota exhaustion

There are positive reports—but the split is real.

Here are 7 solid, diverse sources (Reddit, GitHub, news, blogs, HN) that reinforce the exact patterns you’re describing—context drift, adaptive loops, hallucinations, and regression concerns. I’ve curated them so you can directly reference them in your appendix or when sharing with Anthropic.

🔴 1. Reddit – Developer discussion on adaptive thinking behavior

• Claude Opus 4.7 Changed How Thinking Works (Reddit)

Key takeaway:

• Developers discuss how reasoning flow changed, including issues around tracking context and understanding where reasoning goes wrong.

🔴 2. GitHub Issue – Adaptive thinking inconsistency

• Claude 4.7 Opus thinking inconsistency issue (#5153)

Key takeaway:

• 4.7 behaves differently from 4.6

• Thinking visibility missing / inconsistent in real integrations

• Confirms behavioural differences at system level, not just UX perception

🔴 3. GitHub (Anthropic / Claude Code) – Real workflow regression data

• Claude Code regression issue (complex workflows degraded)

Key takeaway (this one is gold for your thesis):

• Increase in reasoning loops and contradictions

• “Edits without reading context” jumped significantly

• Model choosing “simplest fix” instead of correct fix

• 12× increase in user interruptions

This directly maps to:

• Context drift

• Adaptive loops

• Hallucinated or low-quality edits

🔴 4. News (Business Insider) – Token burn + backlash

• Claude Opus 4.7 backlash and token usage issues

Key takeaway:

• Users report:

  • Higher token consumption

  • Slower / less useful outputs

  • Regressions vs earlier versions

• Adaptive reasoning cited as a possible cause

🔴 5. News (TechRadar / AMD AI Head criticism)

• AMD AI head: Claude cannot be trusted for complex engineering

Key takeaway:

• Large-scale real-world usage (6,800+ sessions)

• Reports:

  • Ignoring instructions

  • Contradictions

  • Reduced reliability

• Explicit claim: decline in engineering trustworthiness

🔴 6. Blog / Analysis – Token inflation + adaptive thinking shift

• Claude Opus 4.7 analysis (token inflation + adaptive thinking)

Key takeaway:

• New tokenizer → ~1.0–1.35× more tokens per task

• Shift to adaptive thinking instead of fixed budgets

• Explains:

  • Faster quota exhaustion

  • Less predictable compute behavior

🔴 7. Hacker News – Forced adaptive thinking model behaviour

• HN discussion: adaptive thinking mandatory in 4.7

Key takeaway:

• Adaptive thinking is no longer optional

• Traditional “controlled reasoning” approaches removed

• Developers experimenting with effort tuning to avoid issues

🧠 Blog / Analysis – performance + regression narrative

• Claude Opus 4.7 flaky performance analysis

• Reports:

  • Self-contradictions

  • Degraded reliability

Why Adaptive Thinking Might Be Backfiring

Conceptually:

Let the model decide when to think more.

In practice:

Unbounded Initiative

Model “improves” things you didn’t ask for

Token Hunger

High effort → excessive reasoning

Plan Violations

“Plan mode” isn’t strictly enforced

This creates a system that is:

• More powerful

• But less predictable

• And harder to trust

Where This Leaves Me

Over 18 days:

• Frequent limit hits

• Context instability

• Silent behaviour drift

Result:

• Progress stalled

• Subscription paused

• Alternatives being evaluated

• And completely locked out with weekly limits hit (I’m on Max plan: $200 + $20 top-up)

This is a deal-breaker for me!

It’s:

4.7 is powerful—but volatile for long-running workflows.

What I’d Love to See

1. Strict Execution Mode

No deviation from plan

2. Hard Thinking Budgets

Tokens + time caps + visibility

3. Context Hygiene Tools

Detect stale vs current state

4. Strong Plan Guarantees

“Plan only” must mean no execution

Closing Thought

Adaptive thinking is a sharp tool.

Right now, it feels like:

• Extremely capable

• But lacking guardrails

And for production systems:

Capability without predictability is risk.

Appendix: External Signals Worth Noting (with sources)

This is the factual trail I would attach when sharing this with Anthropic. These are not isolated anecdotes—they reflect consistent patterns across GitHub issues, news coverage, and independent analyses.

1. Adaptive thinking & token usage changes

• Opus 4.7 introduces adaptive thinking and removes earlier budget-based controls, replacing them with effort tuning and task budgets

• Token usage can increase significantly due to tokenizer changes (~1.0–1.35× for the same task)

👉 Relevance:
Explains why usage limits are hit faster and why compute behavior feels less predictable.

2. Higher quota burn and cost impact in real workflows

• Measured reports show Opus 4.7 consuming ~2.4× quota compared to 4.6 in real API usage scenarios

• News coverage confirms user complaints about higher token consumption and slower outputs

👉 Relevance:
Directly supports the adaptive loop + quota exhaustion issue.

3. Reasoning loops, shallow edits, and workflow degradation

• GitHub issue analysis shows models shifting toward:

  • “edit without reading”

  • “simplest fix instead of correct fix”

  • increased need for human intervention

👉 Relevance:
Matches:

• Adaptive loops

• Reduced execution quality

• Loss of disciplined workflow behavior

4. Silent failures and stuck execution loops

• Reports of sessions staying active without progress (no tool execution, no response advancement)

👉 Relevance:
Real-world evidence of non-converging loops—exactly what you observed with long-running prompts.

5. API and behavior inconsistencies across environments

• Errors due to thinking mode changes and removed parameters (e.g., thinking.type.enabled no longer supported)

• Regression reports where previously working setups fail in 4.7 environments

👉 Relevance:
Explains instability across toolchains (Bedrock, Claude Code, etc.)

6. Broader user backlash and reliability concerns

• Reports of:

  • poorer performance

  • inaccuracies

  • unexpected reasoning behavior

  • increased cost
    across Reddit and developer communities

• Coverage highlighting growing frustration among power users and perceived regressions

👉 Relevance:
Confirms your experience is not isolated

7. Mixed positioning: improved capability, but inconsistent execution

• Opus 4.7 is described as:

  • more capable in theory

  • better at long-running tasks

  • but still inconsistent in real-world workflows

👉 Relevance:
Captures the core tension:

More powerful ≠ more reliable

👉 Food for thought

The patterns described in this post—context drift, adaptive loops, and hallucinated behaviour changes—are not isolated observations.

They are consistently reflected across:

• GitHub issue logs

• API migration changes

• News reports

• Independent developer analyses

Which suggests this is not a prompt problem or a single workflow issue—

but a system-level behavioural shift in how the model operates under adaptive thinking.

A few weeks ago, I wrote that I could only run 1 of my 4 ML Lambdas on AWS Graviton. At that point, the pipeline had four compute stages and only one—the deduplication stage—was cleanly portable to ARM64. The other three were blocked by native dependencies, ML scoring instability, or CUDA hard requirements.

Since then, I shipped a major re-architecture. I am now at 3 of 4 instances migrated to Graviton and an additional orchestration layer on ECS using Graviton

This is technical deep dive on what changed, what stayed stubborn, and how the cost model looks after the migration.

The original four functions

Before the rework, the image pipeline had four compute stages:

Only the deduplication function was small, CPU-bound, and dependency-light—the exact profile Graviton rewards. Everything else was tied to the ML ecosystem: compiled C extensions, missing ARM64 wheels, or a hard CUDA dependency.

What made it to the final cut!

Final changes were not a simple port. It was a structural rewrite of the pipeline.

1) I consolidated CLIP-IQA and dedup into a single technical validator

Originally, I had two separate concerns:

• CLIP-IQA for visual quality scoring

• Perceptual hashing for duplicate detection

That split created two problems. First, CLIP-IQA had ARM64 compatibility gaps because the required wheel chain was incomplete. Second, the model was miscalibrated for my dataset: upon a research, learned the CLIP-IQA was trained on old stock photos, which doesn’t fit the bill for my usecase (it accepted only about 1% of professional RAW captures, which made it unusable for real curation.)

Rather than keep forcing an ML model into a role that did not justify its operational cost, I replaced both stages with a lightweight rule-based Lambda:

• exposure clipping detection

• blur and sharpness scoring

• perceptual hashing for deduplication

• no ML forward pass

• no compiled extensions in the hot path

This is no longer just a design simplification. Deduplication is now live in production, computing perceptual hashes and performing ANN-style lookups in DynamoDB. The validator is not only replacing the old stages—it is actively enforcing them.

That became parjanya-technical_validator, and it runs on ARM64.

Architecture: arm64
Memory: 512 MB
Runtime: python3.12

This was the biggest unlock in the whole migration. I did not port a fragile ML stage to ARM64. I replaced it with something that never needed x86 in the first place.

2) I moved VLM inference off Lambda entirely

The GPU inference stage was never a candidate for Lambda ARM64. CUDA remains the hard boundary.

Instead of trying to force the issue, I separated control plane from execution:

• the scheduling logic runs in a lightweight Lambda

• the actual VLM inference runs on EC2 g5 instances in an Auto Scaling Group

• the worker image runs Qwen3-VL-8B-Instruct

That means the Lambda only decides when to scale and when to drain. It does not need ML libraries, CUDA, or any heavy inference runtime. That Lambda is ARM64.

This separation matters. I gained another Graviton function by moving the intelligence of orchestration into ARM64 and leaving the GPU workload where it belongs.

3) I moved the ECS backend to ARM64

The backend API tier also moved to ARM64.

It handles uploads, scoring orchestration, gallery queries, and DynamoDB reads. None of that needs x86. It is I/O-heavy, memory-efficient, and a good fit for Graviton.

The current state: 3 of 4

Three Lambda functions now run on Graviton. The ECS backend is on ARM64 too. The only x86 compute left is the GPU worker fleet, and that is an intentional architectural boundary, not an unfinished migration.

The technical validator is now running deduplication in production with DynamoDB-backed ANN lookup.

Current state:

• ~714 images processed

• 2,856 phash records

• 2,856 dhash records

• 5,712 total hash entries

Each 64-bit perceptual hash is split into 4 × 16-bit chunks and indexed via GSI, enabling efficient Hamming-distance queries without full table scans.

Duplicate detection is executed at ingest time using a Hamming threshold of 8. This is not approximate in theory—it is running against real image uploads and returning consistent matches.

Why the GPU stage will stay off Graviton

This is the part people usually ask about.

The VLM worker runs on NVIDIA g5 instances, which means CUDA. CUDA is the boundary, not convenience. The ARM64 story for GPU inference is still not a drop-in replacement for a standard PyTorch + CUDA workflow.

The alternatives exist, but they come with real trade-offs:

• AWS Inferentia requires model compilation and Neuron SDK integration

• operator compatibility can become a bottleneck

• debugging and deployment pipelines become more specialized

• parity testing is mandatory if scores are used for curation decisions

For a variable-resolution VLM workload, I decided the migration effort was not worth the operational complexity today.

How I think about ARM64 wheels

This is the practical section that matters if you are trying to do the same migration.

An ARM64 wheel is the precompiled binary distribution of a Python package for the aarch64/arm64 architecture. If a package publishes an ARM64 wheel, I can usually install it without compiling from source. If it does not, I may fall back to source builds, missing dependencies, or outright installation failures.

That is why ARM64 adoption is often not blocked by AWS itself. It is blocked by the package ecosystem.

What I check before switching a workload to ARM64

I treat every dependency as one of four categories:

1. pure Python, safe everywhere

2. ARM64 wheel available, usually safe

3. source build required, needs validation

4. native dependency missing or unstable, likely blocker

For a Lambda or container image, I check:

• whether the package publishes manylinux_aarch64 wheels

• whether transitive dependencies also support ARM64

• whether C extensions link cleanly on Graviton

• whether the package is pinned to a version that still ships ARM64 wheels

How I track ARM64 readiness for my use case

My workflow is simple:

• I maintain a lockfile or constraints file for the exact runtime image

• I test installs inside an ARM64 build environment, not just my laptop

• I verify wheel availability against the exact Python version I deploy

• I keep a dependency matrix for each service: pure python, wheel available, source build, blocker

• I add a deployment gate that fails fast if a native package starts compiling from source unexpectedly

For ML and image-processing workloads, this matters more than people expect. A single dependency such as Pillow, OpenCV, raw image parsers, or a scientific library can flip a Lambda from “portable” to “fragile.”

A useful rule of thumb

If I cannot answer these three questions quickly, I do not move the workload yet:

• Does every native dependency have an ARM64 wheel for my Python version?

• If not, can I build from source reliably in CI?

• If not, can I replace the dependency or the stage entirely?

In my case, the answer to the last question was the real unlock.

Cost analysis

VPC Gateway Endpoints

I added four VPC gateway endpoints to stop routing S3 and DynamoDB traffic through NAT.

Gateway endpoints are free. That means the traffic path to S3 and DynamoDB no longer pays NAT tax.

For an image pipeline moving large media sets, that is not noise. It is structural savings.

NAT Gateway cost sink

My production environment still uses NAT Gateways for general outbound traffic. That cost persists because the system still needs egress, but the higher-volume internal traffic no longer needs to pass through NAT.

A realistic next step is to collapse production NAT from 3 gateways to 1, which would save roughly $65/month in the current setup.

GPU backfill cost

ARM64 Lambda savings

AWS ARM64 Lambda pricing is typically around 20% lower than x86 for equivalent duration.

That matters because my architecture is event-driven:

• the EXIF extractor runs on every ingest

• the technical validator runs on every upload

• the scheduler ticks every 2 minutes

Those invocations compound. The bigger the event volume, the more the ARM64 delta matters.

A stronger way to express savings

The right way to think about the savings is not just “cheaper compute.” It is:

That is the real gain.

In practical terms, the migration gives me four layers of savings:

1. lower per-invocation Lambda cost on ARM64

2. fewer NAT-passed requests to S3 and DynamoDB

3. deduplication alone prevents re-processing identical or near-identical RAW frames, directly reducing GPU inference cost

4. fewer operational failures caused by missing native wheels

The most important one is the third. Every frame rejected by the technical validator is a frame that never reaches the GPU queue. That reduces both cost and latency.

Performance and latency

Technical validator latency

Replacing CLIP-IQA and the old dedup path with a rule-based validator removed model loading, warmup, and forward-pass overhead.

The new validator runs in pure Python and is typically sub-100 ms per image.

This includes hash computation and ANN indexing, which now runs inline without introducing measurable latency overhead.

VLM throughput

The Qwen3-VL-8B-Instruct worker processed 320 images in the backfill run with clean score clustering and no rejects on this dataset. The reject threshold is set to 0.4, but the dataset was too clean to trigger it.

That is fine for now. I still need a more difficult validation set before I can trust the threshold under harsher conditions.

ECS backend behaviour

The ARM64 backend shows the expected pattern for a control-plane service: stable, low-error, and efficient for I/O-bound work.

The ecosystem lesson

The lesson is the same one I started with, but sharper now:

The fastest path to ARM64 is sometimes not to migrate the workload. It is to replace the workload.

I did not port a broken ML stage to ARM64.
I removed it.

I did not force the GPU inference stack onto Lambda.
I isolated it.

I did not keep a dedup stage alive because it existed historically.
I collapsed it into the validator where it belonged.

That is what made the architecture cleaner and cheaper.

The validator is not just simpler—it is now measurably correct under production load.

What is still ahead

1. Terraform reconciliation: my live state now diverges from the earlier config, so I need to align infra state with reality.

2. NAT reduction: production can likely collapse from 3 NAT gateways to 1 after reconciliation.

3. Better validation data: I need deliberately low-quality images to test the reject threshold properly.

4. Inferentia2 feasibility: worth revisiting only if VLM inference becomes steady-state instead of bursty.

TL;DR

Three of four Lambda functions now run on Graviton. The remaining x86 workload is the one that genuinely belongs there: GPU inference.

How I track ARM64 wheel readiness before I migrate a service

The main point is that ARM64 migration is usually decided by wheel availability, transitive dependencies, and build reproducibility—not by the chip itself.

Core structure

1) Start with the dependency graph

I map every package into one of four states:

• pure Python

• ARM64 wheel available

• source-build required

• blocker

2) Test inside an ARM64 build environment

I do not trust local x86 installs for this. I build in CI or in an ARM64 container so I can see what actually happens on Graviton.

3) Pin Python and package versions

ARM64 support can appear or disappear across versions. I lock both the Python runtime and the package set.

4) Track failure modes

I record whether the failure is:

• missing wheel

• missing system library

• compiler issue

• ABI mismatch

• runtime behaviour difference

5) Decide whether to port or replace

If the package stack is fragile, I replace the workload. That is often cheaper than fighting the dependency chain.

Further Reading

AWS Graviton (Official)

• Migrating AWS Lambda functions to ARM-based Graviton
  Covers practical considerations when moving Lambda workloads to ARM64, including compatibility and performance trade-offs. AWS reports up to 34% better price-performance, reinforcing why this shift compounds over time.

• AWS Graviton Technical Guide
  A deep reference on runtime support, Python wheels, and ecosystem maturity. Useful for understanding why some workloads “just work” while others fail due to native dependencies.

ARM64 in Practice (Real-world engineering)

• Migrating a GenAI pipeline to AWS Graviton (ARM blog)
  A strong parallel to this post: highlights the need to build from source when wheels don’t exist and to restructure pipelines for ARM64 compatibility rather than forcing migration.

• AWS Graviton usage guide (2025)
  A broader view of where Graviton fits: microservices, data pipelines, and cost optimization. Also calls out the exact blockers I hit—x86-native binaries and dependency gaps.

Python + ARM64 (Critical for ML workloads)

• AWS Graviton Python getting started guide
  This is the underrated one. Explains why:

  • Python version matters (wheel availability changes across versions)

  • GLIBC mismatches break installs

  • Some libraries require source builds or distro packages

  If you’re debugging “why does this work on x86 but not ARM64?” — this is where the answer usually lives.

  ---

Closing thought

If there’s a single takeaway across all of these:

ARM64 adoption fails less because of compute—and more because of dependencies.

That’s the thread connecting every resource above—and the reason this migration worked only after changing the pipeline itself.

Most teams first meet cloud cost as a surprise.

The reflex is familiar: AWS is getting expensive. But that framing is too shallow to be useful. Cloud platforms are not mysterious in how they bill. They charge for what is consumed, and they do so with predictable rules. The real mystery is why the consumption pattern often looks irrational only after the bill arrives.

The answer is time.

Cloud bills are not leading indicators. They are lagging indicators. They reveal what the system has been doing for weeks or months after the design decision was made. By the time cost becomes visible, the architectural cause is already buried beneath new work, new releases, and new assumptions.

That is why cloud cost is better understood as a signal of design debt.

And in ML infrastructure, that debt is rarely singular. It usually appears in three forms at once: infra debts, context debts, and AI debts. Each one hides differently. Each one compounds differently. And each one demands a different kind of correction.

The First Debt: Infra Debt

Infra debt is the most visible kind of debt because it eventually shows up directly in the bill.

It begins with missing guardrails. A team enables S3 versioning to protect against accidental deletion, but no lifecycle policy is added. Logs are useful during development, so DEBUG logging continues into production. CloudWatch retention is left at default. Idle resources stay alive because nobody encoded expiration into the system.

None of these choices is obviously wrong in isolation. In fact, each one is defensible at the moment it is made. Versioning improves safety. DEBUG helps troubleshooting. Extra endpoints help experimentation. The mistake is not the decision itself. The mistake is the decision without a boundary.

That is what makes infra debt so common. It is created by omissions, not dramatic failures. A retention policy was not defined. A lifecycle rule was not added. A default was not set.

The cost curve is then slow and silent. Storage grows. Logs accumulate. Compute idles. Bills rise before teams notice the pattern.

This is why infra debt is the easiest debt to understand and the easiest to prevent. It belongs in infrastructure-as-code, in template defaults, and in policy enforcement. The goal is not to eliminate flexibility. The goal is to make the safe path the default path.

When that does not happen, cloud bills become the receipt of missing guardrails.

The Second Debt: Context Debt

Context debt is less visible, but often more dangerous.

It does not begin with storage or logs. It begins with assumptions. A team believes it understands the system, but the understanding is incomplete, undocumented, or no longer shared. The architecture starts drifting away from the mental model that originally justified it.

The Graviton example is a good one. On paper, ARM-based infrastructure promises savings. In practice, that promise depends on compatibility across Python wheels, native libraries, build pipelines, container images, CI runners, and fallback logic. A team that assumes “Graviton will work everywhere” without checking those dependencies is not making a cost optimization. It is making a context assumption.

That assumption can fail quietly at first. A wheel does not compile. A container image behaves differently. A CI job passes on one architecture and fails on another. The team then either falls back to x86, overprovisions for safety, or spends time debugging a problem that should have been discovered earlier.

That is context debt.

Unlike infra debt, context debt cannot be fixed by setting a lifecycle rule. It requires documentation, explicit trade-off decisions, shared ownership, and a memory of why the system is shaped the way it is. It is the debt of forgotten rationale.

This debt matters because cloud cost is often not caused by inefficient compute alone. It is caused by teams repeatedly paying for architectural uncertainty. When people no longer share the same model of the system, they build cautiously, duplicate resources, or choose the most conservative option available. Cost rises because confidence falls.

Context debt is where engineering and organizational memory collide.

The Third Debt: AI Debt

AI debt is the most compounding form of debt because it changes over time even when the system appears stable.

ML systems drift. Data changes. Labels shift. Models degrade. A pipeline that performed well last quarter may begin losing accuracy this quarter without any obvious operational failure. The system still runs. The endpoints still respond. The logs still look normal. But the model’s relationship to reality has weakened.

That is where AI debt begins.

It includes data debt, model debt, and configuration debt. Data debt appears when training data is stale, incomplete, or insufficiently versioned. Model debt appears when there is no clear registry, no retraining signal, and no disciplined lifecycle. Configuration debt appears when inference pipelines become too complex, too wide, or too fragmented to reason about.

The financial impact is not always immediate. Sometimes the team compensates by increasing compute. Sometimes they add more endpoints. Sometimes they rerun experiments more often because confidence in the current model declines. Cost rises as a side effect of trying to keep the system trustworthy.

This is why AI debt is especially expensive. It does not merely create infrastructure spend. It creates repeated spend in response to lifecycle failure.

AI systems need more than deployment. They need governance, monitoring, versioning, and retraining discipline. Without that, the bill does not just reflect compute. It reflects the hidden cost of model decay.

Parjanya 2.0 and the Shape of the Debts

The Parjanya 2.0 work made these debt types visible in practice in the first month of production before the public launch.

S3 versioning was enabled to protect checkpoint uploads, but expiration was not configured, so old versions accumulated. That was infra debt. CloudWatch logs were verbose because DEBUG was convenient during development, but the logging policy was never tightened for production. That was infra debt again. Graviton was treated as a simple optimization, but dependency compatibility had not been fully validated. That was context debt. SageMaker endpoints were created for experimentation and then forgotten. That was a mix of infra debt and AI debt, because the experimental infrastructure had no lifecycle discipline.

The point of the case study is not that AWS behaved badly. AWS behaved exactly as designed.

The point is that the system behaved exactly as the team allowed it to behave.

That is what design debt means. The bill is not the cause. The bill is the evidence.

Designing Guardrails Instead of Chasing Bills

Once these debts are understood, the response becomes clearer.

The solution is not to chase lower cloud bills as a separate exercise. That often turns into cleanup theater. Delete a few things. Reduce a few logs. Switch a few instances. The bill improves temporarily, but the pattern remains.

The better approach is to design guardrails.

Guardrails make cost-aware behaviour the default. Versioned S3 buckets get lifecycle policies by template, not by memory. Log groups get retention defined by policy, not by hope. Production logging defaults to INFO, not DEBUG. Endpoint ownership is tagged, expiration is explicit, and idle resources can be terminated automatically. ARM migration is treated as a compatibility project, not a migration slogan. ML models are registered, versioned, and monitored as living assets rather than static artifacts.

This is the crucial shift: cost control stops being reactive once the system itself carries the discipline.

That is what sustainable ML infrastructure looks like. Not a promise of cheaper cloud, but a design where cloud cost is structurally constrained.

The Operating Lesson

If there is one lesson across infra debts, context debts, and AI debts, it is this:

Cloud bills are delayed signals of system intent.

They tell you what your system actually did after the memory of the decision has faded. They show whether your guardrails were real, whether your assumptions were valid, and whether your ML lifecycle was under control.

That is why the right question is not “Why is AWS so expensive?”

The right question is:

Which debts are we carrying into production, and which ones are we choosing not to see yet?

That question changes the conversation from billing to design. From cost reduction to system maturity. From cleanup to prevention.

And once you see cloud bills that way, you stop treating them as a nuisance. You start treating them as architecture feedback.

That is the real value of the receipt.

Additional metrics

Further Reading

My work:

• Why We Could Only Use AWS Graviton for 1 of Our 4 ML Lambdas

• VLM Batch Inference — 4-bit Quantization Deep Dive

• The Silent Storage Bomb: What S3 Versioning Doesn’t Tell You

External resources:

• Amazon S3 noncurrent version expiration

• CloudWatch Logs retention

• AWS Graviton getting started

• SageMaker endpoint management

• Characterizing Technical Debt and Antipatterns in AI-Based Systems

A simple rule of thumb: Graviton works beautifully when your dependencies are simple. It struggles when your stack isn’t.

The Promise That Looked Obvious

Every few years, infrastructure gives you one of those deceptively simple promises:

Flip a switch. Save money. Get better performance.

AWS Graviton felt like one of those moments.

ARM64 support for Lambda came with a clear narrative: better price-performance, lower cost, and a migration path that looked almost mechanical. Change the architecture flag, rebuild your containers, and you’re done.

We believed that story.

And then we tried to run a real system on it.

The System That Refused to Cooperate

We built Parjanya 2.0, an ML-powered image pipeline for photographers. It processes RAW images, generates previews, evaluates image quality using CLIP, removes duplicates, and runs semantic analysis through a vision-language model.

It is not an exotic system. It is exactly the kind of modern, modular ML pipeline you would expect to benefit from better compute economics.

We had four compute stages. Each was isolated. Each was containerized. Each looked like a good candidate for migration.

So we made the call early: everything would run on ARM64.

That decision lasted about a week.

What Actually Happened

After debugging builds, testing containers, and validating runtime behaviour, the outcome was surprisingly simple:

Only one of our four Lambda functions could run on Graviton.

Not because Graviton failed.
But because our assumptions did.

The deduplication function — small, CPU-bound, dependency-light — migrated cleanly. It behaved exactly as promised and delivered the expected cost savings.

Everything else stopped us, each in a different way.

The RAW processing stage collapsed under native dependency issues. The ML scoring stage raised too many unanswered questions about performance and stability. The GPU-backed stage never had a path in the first place.

The pattern wasn’t random. It was consistent.

The Moment the Model Broke

At some point during the migration, the question shifted.

We stopped asking:

“Why isn’t Graviton working?”

And started asking:

“Why does this work for AWS, but not for us?”

That question turned out to be the real story.

AWS Isn’t Using Graviton the Way You Are

When AWS says services like S3 or RDS run on Graviton, it’s easy to assume you’re playing the same game.

You’re not!

AWS builds those systems with full control over:

• the language runtime

• the dependency graph

• the compiled binaries

• the performance tuning

• the execution model

They are not dealing with fragile Python bindings, missing wheels, or uncertain ML performance characteristics. They are not discovering at deploy time that a C-extension doesn’t compile on ARM64.

They removed the entire class of problems before Graviton ever entered the picture.

We, on the other hand, inherit those problems by default.

That is the difference.

The Real Constraint Isn’t Hardware

Graviton works.

The cost advantages are real. The performance gains are real.

But those benefits only show up when your software stack allows them to.

In our case, the limiting factor was not compute. It was the ecosystem:

• Native dependencies that don’t support ARM64 cleanly

• ML workloads without production-grade ARM benchmarks

• GPU requirements that lock entire stages to x86

None of these are edge cases. They are normal parts of a modern ML pipeline.

Which leads to an uncomfortable but important conclusion:

Graviton adoption is not a hardware decision. It is an ecosystem decision.

The Economics That Didn’t Scale

We did get Graviton working — just not where it mattered most.

The deduplication stage migrated cleanly and delivered cost savings. But it was also one of the least expensive parts of the pipeline.

The expensive parts — RAW processing, ML inference, GPU workloads — stayed exactly where they were.

So while Graviton worked technically, the overall impact was small.

Not because the savings were fake, but because the wrong parts of the system were portable.

What We Learned the Hard Way

Looking back, the mistake wasn’t trying Graviton. That was the right call.

The mistake was assuming that infrastructure capability translates directly into application readiness.

It doesn’t.

A system is only as portable as its most fragile dependency. And in ML pipelines, those dependencies tend to run deep — often below the level where you first notice them.

We also learned that architectural decisions should start from reality, not optimism. It is far easier to selectively adopt ARM64 where it works than to force it everywhere and backtrack.

And most importantly, we learned that partial adoption is not failure. It is often the correct outcome.

A Better Mental Model

If there is one thing I would carry forward from this experience, it is this:

Do not ask:

“Can I move my system to Graviton?”

Ask instead:

“Which parts of my system are already compatible with Graviton?”

That subtle shift changes everything.

Because once you frame the problem that way, the answer becomes obvious much earlier — and with far less wasted effort.

The Ending That Actually Makes Sense

We migrated one out of four functions.

That number sounds underwhelming until you understand what it represents.

It represents the boundary between what our system wanted to be and what it actually was. It represents the difference between infrastructure capability and ecosystem readiness. It represents an architecture that now reflects reality instead of assumptions.

And in the long run, that is a much more valuable outcome than forcing a full migration that never quite fits.

Graviton is not the wrong tool.

But like most powerful tools, it only works when the rest of the system is ready for it.

📚 Further Reading & References

AWS Foundations (What AWS Tells You)

Start here to understand the official narrative and supported capabilities:

• AWS Graviton Overview
  https://aws.amazon.com/ec2/graviton/

• AWS Lambda – ARM64 Architecture Support
  https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html

• Amazon EC2 Graviton Instances (C6g, C7g, etc.)
  https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html

• AWS Fargate ARM64 Support
  https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-arm64.html

These give you the “happy path” — where workloads are expected to benefit from ARM.

AWS Engineering Blogs (What AWS Actually Does)

These are far more practical than product pages:

• Best Practices for Running Applications on AWS Graviton
  https://aws.amazon.com/blogs/compute/best-practices-for-running-applications-on-aws-graviton-processors/

• Migrating to AWS Graviton2: Performance and Cost
  https://aws.amazon.com/blogs/compute/migrating-to-graviton2/

• Optimizing Workloads for ARM-Based EC2 Instances
  https://aws.amazon.com/blogs/architecture/optimizing-applications-for-arm64/

If you read closely, you’ll notice something important:
Most examples assume tight control over dependencies and runtime.

ML Ecosystem Reality (What You Actually Face)

This is where things diverge from AWS expectations:

• PyTorch ARM64 Support
  https://pytorch.org/get-started/locally/

• ONNX Runtime (ARM builds)
  https://onnxruntime.ai/docs/build/eps.html

• Hugging Face Transformers
  https://huggingface.co/docs/transformers/index

These tools work on ARM — but production characteristics (latency, memory, stability) are often undocumented.

The Hard Boundary: GPU

• NVIDIA CUDA Platform
  https://developer.nvidia.com/cuda-zone

If your pipeline depends on CUDA, that stage remains tied to x86_64 in most production setups.

A Practical Way to Evaluate Graviton

Before committing to migration:

• Spin up a Graviton EC2 instance (e.g., c7g.medium)

• Install your full dependency stack

• Run your real workload (not a toy benchmark)

• Measure cold start, latency, and throughput

This single step is more valuable than hours of reading.

Closing Thought

AWS documentation shows you what Graviton can do.

Your system will show you what it actually allows.

The difference between those two is where architecture decisions are made.

Parjanya 2.0 — an AI-powered photography curation platform that combines CLIP-IQA for real-time scoring with Qwen3-VL-8B for deep visual understanding.

Today I would like to delve into the tooling story: how a single developer, working across five repositories, multiple AWS services, and a custom ML inference pipeline, managed to ship the entire VLM integration in under two weeks. I had been using various AI coding assistants for months. But this build was different. This was the first time I felt like I had a genuine engineering partner — one that could hold the full architecture in its head across multi-hour debugging sessions, reason about GPU memory layouts, and catch serialization bugs buried three abstraction layers deep.

This post is about what I learned using Claude Opus 4.6 with its 1M token context window for production ML infrastructure work. Not benchmarks. Not synthetic tests. Real observations from a real build, with real production failures at 2 AM.

The Build: What Is Being Built

Parjanya’s VLM pipeline is a SageMaker Batch Transform system that runs nightly inference on thousands of wildlife and nature photographs.

The model — Qwen3-VL-8B-Instruct — evaluates each image for quality, composition techniques (rule of thirds, leading lines, symmetry), and generates natural-language descriptions. The results feed back into DynamoDB and surface in a React frontend with a two-track pipeline visualization.

The infrastructure spans five repositories:

- **parjanya-ml** — Lambda handlers, SageMaker container, IQA engine, batch orchestration

- **parjanya-frontend** — React + Vite with VLM enrichment UI, pipeline status, score panels

- **parjanya-backend** — FastAPI with DynamoDB integration

- **parjanya-ops** — Terraform modules for IAM, networking, storage

- **parjanya-shared-libraries** — Python package with schemas and constants

Getting a custom Docker container with a quantized 8-billion parameter VLM running on SageMaker Batch Transform involved touching every single one of these repositories. The changes cascaded: the inference script needed GPU-aware dtype selection, the Dockerfile needed pinned dependency versions, the batch trigger Lambda needed DynamoDB Decimal serialization, the poller needed composition field propagation, the frontend needed new TypeScript interfaces, and the Terraform modules needed updated IAM policies.

This is the kind of cross-cutting work where context is everything.

The 1M Context Window: What It Actually Means in Practice

Let me be direct about something: I used ~10% of the 1M context window in any given session. That number sounds damning until you understand what it represents!

It Is Not About Filling the Window

The 1M context window is not a bucket you fill. It is a safety net that changes how you work. With a 128K or even 200K window, you are constantly managing context — summarizing, re-explaining, re-pasting code. You develop an anxiety about context loss. You start breaking problems into artificially small pieces not because the problem demands it, but because your tool demands it.

With 1M tokens, that anxiety disappears. And its absence changes your behaviour in ways I did not expect:

You stop pre-optimizing your prompts. Instead of carefully crafting minimal context windows, you just work. Paste the full Dockerfile. Include the entire inference script. Share the complete CloudWatch log dump. The model handles it.

Debugging sessions become continuous. Our VLM deployment failed eight times before succeeding. Each failure was a different root cause — OCI manifests, S3 permissions, Decimal serialization, instance quotas, transformers version drift, missing torchvision, BF16-on-T4 memory overflow, and finally, CPU offloading performance.

In a smaller context window, I would have lost the thread by failure three. With 1M, the model remembered every previous fix attempt and could reason about why this failure was different from the last.

Cross-repository reasoning becomes natural. When debugging why the batch trigger submitted zero images despite 4,942 records being in DynamoDB, the model held the Lambda handler code, the DynamoDB schema, the JSONL manifest format, and the CloudWatch error logs simultaneously. The root cause — Python’s `json.dumps` choking on DynamoDB’s `Decimal` type — was buried three abstraction layers deep. Finding it required connecting dots across files that no human would hold in working memory at once.

The Session Continuity Effect

Perhaps the most under appreciated aspect of 1M context is session continuity. When I hit the context limit after a particularly dense debugging session, the model generated a comprehensive session summary that captured not just what we had done, but the state of every in-flight problem. The next session picked up exactly where we left off — no re-explanation, no context rebuilding, no lost nuance.

This matters enormously for ML infrastructure work where debugging is inherently stateful. The GPU memory calculation that informed our quantization decision depended on understanding six previous failed deployments. Strip that history away, and you lose the reasoning chain.

Opus 4.6 for ML Infrastructure: Where It Excelled

GPU Memory Reasoning

The single most impressive moment in this build was the 4-bit quantization diagnosis. The VLM container was running — inference was succeeding — but each image took eight minutes instead of the expected thirty seconds. The CloudWatch logs showed a single warning line buried among hundreds of info messages:

WARNING Some parameters are on the meta device because they were offloaded to the cpu.

Opus immediately understood the implication chain: Qwen3-VL-8B in FP16 consumes approximately 16GB (8 billion parameters at 2 bytes each). The T4 GPU has exactly 16GB VRAM. That leaves zero headroom for the KV cache and attention buffers. Hugging Face’s `accelerate` library, configured with `device_map=”auto”`, silently offloads overflow layes to CPU. CPU inference is orders of magnitude slower. Therefore, the fix is not a timeout adjustment or a retry — it is a fundamental memory reduction via 4-bit NF4 quantization.

This was not a lookup. It was multi-step reasoning across hardware specifications, library behaviour, model architecture, and deployment configuration. The model then produced a complete `BitsAndBytesConfig` with parameter-by-parameter justification — why NF4 over FP4, why double quantization, why float16 compute dtype specifically for the T4’s lack of native BF16 support.

The result: 13x speedup. Eight minutes per image dropped to thirty-eight seconds. The entire batch cost projection went from an impractical $340 down to $27.

Dependency Chain Debugging

ML infrastructure has notoriously deep dependency chains. Our container failed five times before reaching the performance issue, each time for a completely different reason. Opus tracked the full history and used it productively:

By attempt five, a smaller context model would have lost the thread of attempts one through four. Opus used the full failure history to eliminate hypotheses. When the `AutoProcessor` crashed, it did not suggest re-checking S3 permissions — it knew those were already fixed. It went straight to the `transformers` version as the novel variable.

Cross-Repository Code Generation

When we added composition analysis (detecting rule of thirds, leading lines, symmetry, etc.), the change touched four repositories simultaneously: the VLM inference prompt, the batch poller’s field propagation, the frontend TypeScript interfaces, and the React visualization components. Opus generated all four changes in a single coherent pass, with the field names aligned across Python, DynamoDB, and TypeScript — no mismatches, no forgotten fields.

The Model Tier Strategy: Opus, Sonnet, and Haiku

I did not use Opus exclusively. Over the course of the build, I developed an informal tiering strategy based on task complexity:

The critical observation: Sonnet 4.6, even with 1M context, was noticeably less effective for operations-heavy tasks like debugging SageMaker deployment failures or reasoning about GPU memory hierarchies. It would sometimes suggest re-trying the same approach that had already failed, or miss the implication of a warning message that Opus caught immediately. For pure code generation — writing a React component, implementing a Lambda handler — Sonnet was efficient. But for the diagnostic work that dominated this build, Opus was the difference between a one-hour fix and a one-day rabbit hole.

Haiku served a narrow but valuable role: quick validation checks. “Is this the right AWS CLI flag?” “What’s the torchvision version that matches torch 2.5.1?” For these atomic lookups, Haiku’s speed justified the quality tradeoff.

My rough allocation across the build: Opus handled about 80% of the work, Sonnet about 15% (mainly frontend component generation), and Haiku about 5% (quick checks during debugging). against originally planned in the month of January 2026

Claude Code vs. Cowork: A Solo Developer’s Perspective

I used both Claude Code (the CLI tool) and Cowork (the desktop agent) during this build. My experience as a solo developer working on poly-repo infrastructure was nuanced.

Where Cowork Felt Right

Visual task tracking. The todo list widget showing task progress was genuinely useful for multi-step deployments. When you are running through a seven-step build-push-deploy-submit cycle, visual confirmation of what is done and what is next reduces cognitive load.

File creation workflow. Generating documentation, cost spreadsheets, and configuration files felt natural in Cowork’s file-oriented interface. The ability to create and present files with download links was seamless.

Conversational debugging. Pasting CloudWatch logs, discussing error messages, iterating on solutions — the chat interface was more comfortable than a terminal for this back-and-forth.

Where It Hit Limits

Sandbox isolation. Cowork runs in a sandboxed environment. It cannot access local environment variables, AWS credentials, or push to GitHub directly. For infrastructure automation — where the whole point is interacting with external services — this creates friction. Every Docker push, every SageMaker API call, every git operation required copying commands to a terminal. The sandbox is a sensible security boundary, but for a solo developer doing infra work, it adds a context-switching tax.

No persistent shell state. Environment variables set in one Bash invocation do not persist to the next. For infrastructure work where you are building up state (`JOB_NAME`, `ACCOUNT_ID`, container digests), this means re-setting variables or passing them inline every time. Network restrictions. The sandbox cannot reach GitHub, AWS, or Docker registries directly. This is by design — security — but it means Cowork excels at reasoning and code generation while the developer handles execution. For pure software engineering (writing code, designing architectures), this split works. For DevOps/MLOps where execution is the work, it is more limiting.

The Verdict

For poly-repo infrastructure work as a solo developer, I would recommend Cowork for planning, code generation, documentation, and debugging analysis — then Claude Code or manual terminal work for execution. The combination leverages each tool’s strengths. Cowork’s 1M context and visual interface for the thinking; your terminal’s full system access for the doing.

Best Practices: Getting the Most from 1M Context

After this build, I have developed a set of practices specifically for leveraging large context windows in complex infrastructure projects:

1. Do Not Summarize Prematurely

The instinct from smaller-context models is to summarize aggressively. Resist it. When debugging a SageMaker deployment, the raw CloudWatch logs — all of them — are more valuable than a summary. The model can pattern-match across hundreds of log lines in ways that summaries destroy. I found that pasting full error outputs, complete Dockerfiles, and entire handler files produced dramatically better results than curated snippets.

2. Let Failures Accumulate in Context

Our eight-attempt deployment journey would have been impossible to navigate without the full failure history in context. Each failure informed the next diagnosis. When the model could see that attempts one through four had already ruled out permissions, serialization, and quota issues, it could focus attempt five on the novel variable (library version). This cumulative elimination process is the 1M window’s killer feature for debugging.

3. Work in Long Sessions for Complex Problems

Context windows reward sustained engagement. A two-hour debugging session where the model accumulates understanding of your infrastructure is far more productive than five separate twenty-minute sessions that each start cold. The model develops what I can only describe as situational awareness — it knows your AWS account structure, your naming conventions, your DynamoDB key schema, which fixes have already been applied. This accumulated context is irreplaceable.

4. Use the Full Poly-Repo Context

Do not silo your work by repository. When I shared both the Python inference script and the TypeScript frontend interface in the same session, the model generated perfectly aligned field names across languages. When I included the Terraform IAM policy alongside the SageMaker deployment script, it caught permission gaps before they became runtime errors. The 1M window exists precisely for this kind of cross-cutting visibility.

5. Document as You Go, Not After

With the full build context available, the model generates remarkably accurate documentation. Our optimization deep-dive — covering the problem statement, root cause analysis, solution, performance comparison, and the complete deployment journey — was generated from the live session context. Every number, every timing, every error message was drawn from actual CloudWatch logs still in the conversation. Waiting to document after the session would have lost this fidelity.

6. Match Model Tier to Task Complexity

Not every task needs Opus. Use Haiku for quick lookups, Sonnet for straightforward code generation, and reserve Opus for the hard problems: multi-step debugging, architecture decisions, cross-repository changes, and performance optimization. This is not just about cost — it is about matching the model’s reasoning depth to the problem’s reasoning requirements.

The Quantization Story: Why This Needed Opus

I want to close with the optimization that made the entire pipeline viable, because I genuinely doubt it would have happened — or at least, not this efficiently — without Opus 4.6’s reasoning capabilities.

The problem: our VLM batch inference was technically working but taking eight minutes per image. At that rate, processing 5,000 images would take 27 days and cost over $300. The pipeline was functionally useless.

A less capable model might have suggested increasing the instance size, adding more memory, or splitting the batch into smaller chunks. These are reasonable suggestions that would have been wrong and a bomb(costs). The T4 GPU had enough raw compute — the issue was memory layout, not compute capacity.

Opus identified the real problem from a single log line, traced the implication chain through PyTorch’s memory management, Hugging Face’s `accelerate` library, and the T4’s hardware capabilities, then prescribed a specific quantization configuration with four interdependent parameters — each chosen for a concrete technical reason tied to our specific GPU.

The result was not incremental. It was a 13x speedup that transformed the pipeline from impractical to production-ready. The batch now runs in roughly 52 hours for $27. That is the kind of optimization that comes from deep technical reasoning, not pattern matching.

Looking Forward

Parjanya 2.0’s VLM batch is currently processing its first successful run as I write this — 4,942 images, ticking along at 38 seconds each, zero errors. The composition analysis, the quality assessments, the natural-language descriptions are all flowing into DynamoDB, ready for the frontend to surface.

What strikes me most about this build is not any single technical achievement. It is the shift in how I worked. For the first time, the limiting factor in a complex infrastructure project was not context management, re-explanation, or lost thread. It was the actual engineering problems. And with 1M tokens of context, even those became more tractable than I expected.

The 1M context window does not make hard problems easy. It makes hard problems addressable by removing the artificial constraint of forgetting. In ML infrastructure work, where every failure builds on the last and every fix informs the next, that is the difference between shipping and stalling.

📚 Further Reading & References

🧠 Large Context Models & Reasoning

• Anthropic — Claude System Card & Capabilities
  https://www.anthropic.com/news/claude-3-family

• Lost in the Middle: How Language Models Use Long Contexts — Liu et al. (2023)
  https://arxiv.org/abs/2307.03172

• RoPE (Rotary Position Embeddings)
  https://arxiv.org/abs/2104.09864

• ALiBi: Train Short, Test Long
  https://arxiv.org/abs/2108.12409

⚙️ Quantization & Efficient Inference

• QLoRA: Efficient Finetuning of Quantized LLMs
  https://arxiv.org/abs/2305.14314

• BitsAndBytes Documentation
  https://github.com/TimDettmers/bitsandbytes

• HuggingFace Accelerate — Big Model Inference
  https://huggingface.co/docs/accelerate/main/en/usage_guides/big_modeling

• AWQ (Activation-aware Weight Quantization)
  https://arxiv.org/abs/2306.00978

• GPTQ: Accurate Post-Training Quantization
  https://arxiv.org/abs/2210.17323

🖼️ Vision-Language Models (VLMs)

• Qwen-VL Technical Report
  https://arxiv.org/abs/2308.12966

• CLIP: Learning Transferable Visual Models — OpenAI
  https://arxiv.org/abs/2103.00020

• BLIP-2: Bootstrapping Language-Image Pretraining
  https://arxiv.org/abs/2301.12597

☁️ ML Infrastructure & SageMaker

• AWS SageMaker Batch Transform
  https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html

• AWS ML Pipelines — Prescriptive Guidance
  https://docs.aws.amazon.com/prescriptive-guidance/latest/ml-ops-pipelines/welcome.html

• Docker Image Manifest V2 vs OCI
  https://docs.docker.com/registry/spec/manifest-v2-2/

• DynamoDB Data Types & JSON Serialization
  https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DataModel.html

🧩 Debugging Distributed & ML Systems

• Designing Data-Intensive Applications — Martin Kleppmann https://dataintensive.net

• Google SRE Book
  https://sre.google/sre-book/table-of-contents/

• The Tail at Scale — Dean & Barroso
  https://research.google/pubs/pub40801/

⚡ GPU Systems & Performance

• NVIDIA T4 Architecture Overview
  https://www.nvidia.com/en-us/data-center/tesla-t4/

• PyTorch CUDA Memory Management
  https://pytorch.org/docs/stable/notes/cuda.html

🧪 Real-World Engineering Blogs

• HuggingFace Blog
  https://huggingface.co/blog

• AWS Machine Learning Blog
  https://aws.amazon.com/blogs/machine-learning/

• BitsAndBytes / Tim Dettmers Work
  https://timdettmers.com

If you're building ML infrastructure in production, these resources go far beyond benchmarks — they explain the failure modes, trade-offs, and system behaviors that actually determine whether your pipeline ships or stalls.

Date: 4 April 2026
Model: Qwen3-VL-8B-Instruct
Instance: ml.g4dn.xlarge (NVIDIA T4, 16 GB VRAM)
Batch size: 4,942 images

📌 TL;DR

• FP16 “fit” → but caused CPU offloading

• CPU offloading → 100x slowdown per layer

• 4-bit NF4 → solved memory + performance

• bitsandbytes → made it practical

• Result → 13x faster, 12x cheaper, production viable

🚨 The Problem: When “Fits in VRAM” Still Fails

At first glance, everything looked fine.

• 8B parameter model

• FP16 → ~16 GB

• GPU → 16 GB VRAM

It should fit. It didn’t work.

We observed:

• ~8 minutes per image

• GPU underutilized

• CPU spikes

• Warning:

Some parameters are on the meta device because they were offloaded to the cpu.

👉 The system was technically “working” — but practically unusable.

🔍 Root Cause: The Hidden Cost of “Almost Fitting”

The issue wasn’t model size — it was runtime memory dynamics:

What actually happens:

1. Weights (FP16) → ~16 GB

2. KV cache + activations → +2–4 GB

3. Available VRAM → 0 headroom

4. Accelerate kicks in → CPU offloading

5. Result → GPU waits on CPU → massive slowdown

💡 Key insight:

Even 10–15% of layers on CPU → entire pipeline becomes CPU-bound

That’s how you get:

• GPU sitting idle

• 8-minute inference times

⚙️ The Fix: 4-bit Quantization

Instead of scaling hardware, we changed representation.

Quantization reduces precision:

PrecisionBitsMemoryFP16161x4-bit4~0.25x

👉 Result: ~4x reduction in VRAM

🧠 What is NF4 Quantization (and why it matters)

NF4 (Normal Float 4-bit) is not just “smaller numbers”.

It’s distribution-aware quantization.

Why this matters for transformers:

Neural network weights follow a normal (Gaussian-like) distribution:

• Most values near 0

• Few extreme values

NF4 optimizes for this:

• Non-uniform buckets

• Higher resolution near 0

• Lower resolution at extremes

👉 Compared to naive FP4 / INT4:

• Better information retention

• Lower accuracy loss

• Stable inference behavior

Intuition:

NF4 spends precision where the model actually “cares”.

🔧 bitsandbytes: The Enabler

The real hero here is bitsandbytes.

What it provides:

• Drop-in quantization for Hugging Face models

• 4-bit (NF4, FP4) + 8-bit support

• GPU-optimized kernels

• Seamless integration with transformers + accelerate

Why it’s widely used:

• No retraining required

• Works at load time

• Production-friendly

• Proven across LLM + VLM workloads

💡 In practice:

bitsandbytes is what makes “run 8B models on small GPUs” actually feasible.

⚙️ Configuration

from transformers import BitsAndBytesConfig

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True,
)

Key design decisions:

• NF4 over FP4 → better accuracy

• FP16 compute → T4 compatibility

• Double quantization → extra memory savings

📊 Results: Before vs After

📈 Quality Impact

The natural question: what did we lose?

Observations:

• Score variance: ~1–3%

• Ranking preserved ✅

• Distribution intact ✅

• No collapse in quality bands ✅

👉 For curation pipelines:

Relative ranking > absolute precision

NF4 preserves what actually matters.

🧪 Real Output Behavior

Post-quantization:

• Stable latency (~38s ± small variance)

• Healthy score distribution

• No long-tail slowdowns

• Zero CPU fallback

This is what “production-ready” looks like.

🛠️ Engineering Journey (Condensed)

This wasn’t a one-step fix.

We hit:

• Docker manifest incompatibility

• IAM permission gaps

• Decimal serialization bugs

• Instance quota limits

• Transformers version breakage

• Torchvision dependency issues

• Finally → FP16 memory wall

👉 The key lesson:

Infrastructure failures often mask core ML system design issues

💰 Cost Implications

🚀 What This Unlocks

With 4-bit quantization:

• Run 8B VLMs on T4

• Eliminate CPU bottlenecks

• Maintain quality

• Achieve production-scale throughput

🔮 Future Optimizations

• A10G (24 GB) → FP16 viable

• Flash Attention → 2–3x speedup

• Batched inference → better utilization

• GPTQ / AWQ → offline quantization

• Horizontal scaling → linear throughput

🧠 Final Takeaway

This wasn’t just a performance fix.

It was a mindset shift:

❌ “Does the model fit in memory?”
✅ “Does the system run efficiently under load?”

And the answer came from representation, not hardware.

📚 Further Reading

• QLoRA: Efficient Finetuning of Quantized LLMs — foundation of NF4 https://arxiv.org/abs/2305.14314

• bitsandbytes documentation — practical 4-bit implementation https://github.com/bitsandbytes-foundation/bitsandbytes

• Hugging Face Accelerate — device mapping and offloading https://huggingface.co/almog2441Org/Transformers

• FlashAttention — memory-efficient attention https://github.com/dao-ailab/flash-attention

• GPTQ / AWQ — next-gen quantization approaches (Furure versions) https://arxiv.org/abs/2210.17323 https://github.com/mit-han-lab/llm-awq

Enabling S3 versioning without lifecycle rules is like turning on a faucet without a drain.

We discovered this the hard way.

A bucket that showed ~2,000 objects actually contained 100,000+ hidden versions. What should’ve been a quick cleanup turned into a multi-hour purge.

This isn’t just a technical oversight.
It’s a new class of failure:

Infrastructure Debt — silent, compounding, and invisible until it hurts.

The Setup

We’re building Parjanya — a multi-tenant image QA platform for professional photographers.

Each tenant gets:

• Their own S3 bucket

• Versioning enabled (because losing originals is unacceptable)

• Multiple derived assets:

  • Raw uploads

  • Previews (200px, 800px, 2048px)

  • ML metadata (EXIF, embeddings, manifests)

Everything looked standard:

• Versioning ✅

• Encryption ✅

• Public access blocked ✅

Ship it.

The Wake-Up Call

Months later, we tried to clean up dev buckets for a V2 rollout.

Simple script:

• list-object-versions

• Batch delete (500 at a time)

Expected: a few minutes
Reality: hours

Why?

Because the AWS console was lying (or rather, hiding the truth).

• Console showed: ~2,000 objects

• Actual: 100,000+ versions

What we found underneath:

• Non-current versions (every overwrite)

• Delete markers (every delete)

• Multipart leftovers

All of them:

• Billed

• Counted

• Required explicit deletion

The Hidden Mechanics

Every S3 operation creates more than you think:

None of this is visible in the default console view.

But all of it:

• Costs money

• Slows operations

• Complicates cleanup

The Cost (This Is Where It Gets Real)

Let’s quantify it.

Scenario:

• 100,000 versions

• Avg size: 5 MB

→ ~500 GB of hidden storage
→ ~$12.50/month
→ ~$150/year

For dead data

Now scale it:

👉 You’re paying 8× more than you think

And that’s per tenant.

This Isn’t Just a Bug — It’s Debt

We categorize this into four types:

1. Tech Debt

“We’ll add lifecycle rules later.”

Later never comes.

• Versioning enabled

• Cleanup missing

• Cost grows silently

2. Infrastructure Debt (The Real Killer)

This is where it escalates:

• No lifecycle rules → storage bloat

• No inventory → no visibility

• No alarms → no signal

• Terraform defaults → debt replication

Infrastructure debt doesn’t fail loudly.
It accumulates quietly.

3. Context Debt

When the original engineer leaves:

• Why is versioning enabled? ❓

• What’s the retention policy? ❓

• How do we purge safely? ❓

Nobody knows.

4. AI Debt (Underrated)

ML pipelines make this worse:

• EXIF outputs

• Embeddings

• Batch manifests

These are:

• Frequently overwritten

• Rarely reused

• Fully versioned

You end up paying long-term storage for temporary compute artifacts

The Pattern (Across the Industry)

This isn’t rare.

It’s everywhere:

• Buckets growing 5× silently

• Bills spiking unexpectedly

• Cleanup scripts failing at scale

The pattern is always:

Enable versioning → forget lifecycle → discover too late

The Fix: Lifecycle Rules (Non-Negotiable)

We now treat lifecycle rules as mandatory.

1. Originals → Intelligent-Tiering

• Auto-optimize cost

• Keep 2 backup versions

• Expire others in 7 days

2. Previews → Aggressive Cleanup

• Regenerable

• Keep 1 version

• Expire in 1 day

3. Metadata → Disposable

• Expire current in 30 days

• Versions in 1 day

4. Multipart Cleanup (Critical)

• Abort incomplete uploads after 1 day

5. Global Safety Net

• Max 3 versions

• Expire after 30 days

• Clean delete markers

Monitoring: Don’t Trust the Console

We added 3 layers:

1. S3 Inventory

• Source of truth

• Includes versions

2. Prefix Metrics

• Track raw/, previews/, etc. separately

3. Alerts

• Bucket size

• Object count

• Error rates

The Checklist

Before you ship versioning:

• Lifecycle rules exist (no exceptions)

• Non-current expiration configured

• Delete markers cleaned

• Multipart uploads aborted

• Inventory enabled

• Prefix-based policies applied

• Intelligent-Tiering evaluated

• Purge tested

• Alerts configured

• Documentation written

When Things Go Wrong (The Nuke Strategy)

You cannot just run:

aws s3 rm --recursive

It only deletes current objects.

You must:

1. Suspend versioning

2. Delete all versions + delete markers

3. Delete current objects

4. Delete bucket

And yes — it’s painful at scale.

The Takeaway

S3 versioning is:

• A safety feature

• A cost trap

• An operational hazard

Without lifecycle rules, it will hurt you.

So treat this as a rule:

Versioning without lifecycle = production bug

And more importantly:

This is Infrastructure Debt — not a configuration detail.

Final Thought

The most dangerous systems aren’t the ones that fail loudly.

They’re the ones that:

• Look fine

• Cost little (at first)

• And quietly compound

Until one day:

• Your bill spikes

• Your scripts hang

• Your team scrambles

All because of a checkbox you enabled months ago.

Sources & Further Reading

If you want to go deeper, these are worth your time — they highlight how widespread (and costly) this issue is:

• SnapShooter — The Tale of the Versioned S3 Bucket
  → Real-world recovery: 5.5 TB → 16 GB after fixing lifecycle rules

• DEV.to — Taming S3 Versioning Before It Blows Up Your Bill
  → Practical breakdown of version bloat patterns

• DoiT — Why Did My S3 Costs Go Up?
  → Versioning listed as a top cause of unexpected cost spikes

• Medium — Why Your S3 Bill Just Hit $47,000
  → Extreme case of mismanaged storage + versioning

• Infracost — S3 Non-Current Version FinOps Policy
  → Automated detection for missing lifecycle rules

• Gart Solutions — Infrastructure Debt: Complete Guide
  → Conceptual grounding for “infrastructure debt”

• AWS Docs — Troubleshooting S3 Versioning
  → Official guidance (including 503 risks at high version counts)

• AWS re:Post — S3 Versioning Impact
  → Real developer discussions and pitfalls

• Eon — How to Cut Your S3 Costs
  → Broader cost optimization strategies

• AWS — S3 Pricing
  → Baseline for cost calculations

What it is

Atlas is a dual-mode application: Manual Mode (select a component → prompt → refine → save) and Auto-Research Mode (define a research brief → autonomous agent loops → human review → finalize). The app is built for long-horizon research workflows — think multi-document analysis, codebase reasoning, film storyboarding, and deep stock due diligence.

How it works (high level)

• User defines goal & success criteria.

• Agent builds context from the 1M token window, fetches research (Perplexity), runs analysis (Claude), generates component drafts, and saves versions.

• The human reviews flagged uncertainties, edits, accepts final components, and exports (MD, PDF, blog).

Why now?
Two recent trends make this exciting:

1. Anthropic’s broader 1M-token context support (so agents can hold massively more context while working) 1M token, and

2. Karpathy’s autoresearch pattern that demonstrates autonomous, auditable experiment loops. https://github.com/karpathy/autoresearch

Open source + license

This repo will be released under MIT. Expect: architecture diagrams, the AI orchestration service, context window helpers, RAG & caching patterns, agent loop examples, and export pipelines.

How you can help / contribute

• Star/watch the repo when it goes live

• Try the demo & file issues for use cases you need

• Contribute connectors (other LLMs, cloud storage, export formats)

TL;DR

This tool turns long, messy research into an auditable, iterative loop where humans are always in control of decisions. Early release to contributors in 2–3 weeks; public repo launch shortly thereafter.

DISCLAIMER: This article is part of my personal learning journey and is meant purely for educational and informational purposes. I have drawn insights from Prof. Aswath Damodaran’s publicly available teachings and financial information available in the public domain.

While preparing this write-up, I referred to platforms such as Screener and AI-based study tools to better understand the concepts and validate publicly available data such as company filings and information available for investors from the company domain. The interpretations and conclusions shared here are entirely my own, and any errors or misunderstandings are solely my responsibility.

This is not investment advice or a recommendation to buy, sell, or hold any securities. I encourage readers to do their own research and consult a SEBI-registered investment advisor before making any investment decisions.

The Synergy Paradox

In April 2023, India witnessed it’s largest banking merger when HDFC Limited and HDFC Bank combined to create a financial behemoth with assets exceeding INR 17.87 lakh crore. The market cheered & stock prices surged, analysts projected massive synergies, and management promised transformational value creation.

Fast forward to January 2026: The combined entity’s market cap has indeed grown by 48%, but synergies have materialized at only 35-40% of targets. EPS is 28% below projections, and ROE has contracted by 8-9 percentage points.

Meanwhile, in October 2025, Tata Motors executed the opposite strategy, splitting into two separate entities (passenger vehicles + JLR, and commercial vehicles). The market punished this decision with a 33% decline in combined market capitalization within three months, despite operational metrics showing +24.7% growth in passenger vehicles and +28.6% in commercial vehicles.

What explains these seemingly contradictory outcomes?

The answer lies in applying Aswath Damodaran’s acquisition and demerger valuation framework - a systematic approach that separates wishful thinking from rigorous value analysis. This article applies Damodaran’s methodology to both cases, revealing why synergy value is so difficult to capture in practice and what investors should watch for in corporate restructurings.

Understanding the Damodaran Framework

The Core Equation

Damodaran’s approach to valuing mergers and demergers rests on a deceptively simple foundation:

For Mergers:

V(Combined) = V(A) + V(B) + Synergy Value - Execution Risk

For Demergers:

V(Parent) = V(Spun-off) + V(Remaining) + SOTP Premium - Separation Costs

As Damodaran writes in his seminal paper “The Value of Synergy”: Synergy, to have an effect on value, has to influence one of the four inputs into the valuation process

The Four Critical Components

1. Standalone Entity Valuations: Calculate DCF-based free cash flow to equity (FCFE) using business-specific assumptions
2. ROIC Analysis: Determine if the combined entity earns more than its weighted average cost of capital (WACC)
3. Synergy/Control Premium: Quantify operating, financial, and strategic value sources with specific timelines
4. Execution Risk: Assess probability of synergy realization based on integration complexity

The framework’s power lies in its brutal honesty:

Case Study 1 - HDFC Bank Merger (When Convergence Disappoints)

The Deal at a Glance

• Transaction Date: April 2023

• Deal Structure: HDFC Limited merged into HDFC Bank (reverse merger)

• Combined Assets: Rs 17.87 lakh crore

• Strategic Thesis: Cross-selling opportunities (70% non-overlapping customers), lower cost of funds, capital efficiency

• Market Initial Response: +48% appreciation over 2.75 years

Applying the Damodaran Framework: Step-by-Step Valuation

Step 1: Standalone Valuations

HDFC Limited (Pre-Merger):

• Loan Book: Rs 6.2 lakh crore (79% individual mortgages)

• Net Interest Margin: 2.26%

• ROE: 17–18%

• ROIC: 20%

• DCF Assumptions: 18% growth, 10.5% cost of equity, 6% terminal growth

• Standalone Fair Value: Rs 2.17 lakh crore

HDFC Bank (Pre-Merger):

• Loan Book: Rs 4.50 lakh crore (diversified portfolio)

• Net Interest Margin: 3.4%

• ROE: 35%+

• ROIC: 25%

• DCF Assumptions: 18% growth, 9.5% cost of equity, 6% terminal growth

• Standalone Fair Value: Rs 22.64 lakh crore

Combined Value (No Synergy): Rs 24.81 lakh crore

Step 2: Synergy Estimation

Following Damodaran’s methodology of identifying specific synergy mechanisms:

Operating Synergies:

1. Cross-selling: Expected Rs 15,000 crore annual value from activating 70% non-overlapping HDFC customers

2. Cost of Funds Reduction: HDFC’s 5.83% to 4.8% via CASA deposits = Rs 10,000–15,000 crore value

3. Economies of Scale: Minimal (both already lean) = Rs 2,000–4,000 crore

Financial Dissynergies (The Hidden Killer):

1. SLR Requirements: 22% of deposits in government securities = Rs 80,000 crore in low-yield assets

2. CRR Requirements: 4–6% in RBI deposits = negative carry

3. Priority Sector Lending: 40% in prescribed sectors (lower yields) = Rs 10,000–15,000 crore annual opportunity cost

Net Synergy Value: + Rs 2.19 lakh crore (but regulatory drag reduced realized value to Rs 0.10–0.15 lakh crore)

Fair Value (April 2023): Rs 9.63–9.85 lakh crore (market priced at Rs 9.50 lakh crore — fairly valued)

Step 3: Real-World Outcome (January 2026)

Current Status (2.75 Years Post-Merger):

Why the Gap? The Damodaran Diagnosis

Root Cause 1: Regulatory Dissynergies Exceeded Operating Synergies

As Damodaran emphasizes in his CFA Institute talk:

“The problem with synergy is that it is easier to compute on paper than to create in practice.” - The value of Synergy

HDFC Bank discovered that converting HDFC’s housing finance book into bank assets triggered:

• Statutory Liquidity Ratio obligations locking Rs 80,000+ crore in low-yield government securities

• Cash Reserve Ratio requirements creating negative carry

• Priority Sector Lending mandates forcing 40% of loans into lower-yielding segments

Annual regulatory drag: Rs 10,000–15,000 crore — effectively wiping out cross-selling synergies.

Root Cause 2: Cross-Selling Execution Delay

Expected synergy of activating 5–6 crore HDFC mortgage customers for banking products has taken 2–3 years instead of the projected 12 months. Behavioral change is hard — customers do not automatically switch banks just because of a merger.

Root Cause 3: Conglomerate Discount Emerged

Pre-merger, HDFC traded at 25–30x P/E (mortgage premium) and HDFC Bank at 20–22x P/E (banking premium). Post-merger: 18.92x P/E. The market now values it as a diversified bank, not a focused housing finance powerhouse.

The Damodaran Framework Score: 7/10

What It Got Right:

• Identified potential synergy sources (cross-selling, funding cost)

• Quantified regulatory dissynergies (prescient warning)

• Valued both entities independently first

What It Missed:

• Underestimated timing of synergy realization (3–5 years versus 12 months)

• Did not fully anticipate market valuation multiple compression

• Regulatory environment changes were directionally correct but magnitude was underestimated

Case Study 2 - Tata Motors Demerger (When Separation Creates Opportunity)

The Deal at a Glance

Demerger Effective Date: October 2025 (3 months ago as of analysis)

New Entities:

• TMPV (Tata Motors Passenger Vehicles): PV + JLR + EV

• TMLCV (Tata Motors Commercial Vehicles): CV + Iveco integration

Strategic Thesis:
Unlock pure-play multiples, separate high-ROIC from low-ROIC businesses, and enable focused capital allocation.

Market Response:

• 33% decline in combined value despite 25% operational growth

Applying the Damodaran Framework: SOTP Valuation

Step 1: Pre-Demerger ROIC Analysis

This is where Damodaran’s framework shines. As he notes:

When ROIC < WACC in a conglomerate, separation can help if each entity improves ROIC through focus.

Pre-Demerger Combined Entity

• TMPV Segment ROIC: 6.6% (below WACC of 8–9%) → Destroying value

• TMLCV Segment ROIC: 14.5% (above WACC of 8%) → Creating value

• Problem: Strong CV business subsidizing weak JLR/PV transition

Step 2: Standalone Valuations

TMPV (Passenger Vehicles + JLR + EV)

• Revenue: Rs 4.26 lakh crore (FY2025)

• Current ROIC: 6.6% (JLR drag from cyberattack)

• Normalized ROIC: 10–12% (post-JLR recovery by 2027–28)

• DCF Assumptions: 10% growth, 10% cost of equity, 5% terminal growth

• Standalone Fair Value: Rs 5.83 lakh crore

TMLCV (Commercial Vehicles)

• Revenue: Approximately Rs 2.2 lakh crore

• Current ROIC: 14.5%

• Sustainable ROIC: 16–18% (post-Iveco integration)

• DCF Assumptions: 14% growth, 9.5% cost of equity, 6% terminal growth

• Standalone Fair Value: Rs 7.75 lakh crore

Combined Sum-of-Parts: Rs 13.58 lakh crore

Step 3: Separation Premium and Dissynergies

Separation Premium Sources

For TMPV:

• Focused capital allocation for EV: + Rs 0.10–0.15 lakh crore

• Luxury/EV multiple re-rating (18–20x vs 14–16x blended): + Rs 0.08–0.12 lakh crore

• Management focus: + Rs 0.05–0.08 lakh crore

• Total TMPV Premium: + Rs 0.35 lakh crore

For TMLCV:

• Pure-play CV investor base (higher multiples): + Rs 0.05–0.08 lakh crore

• Iveco integration value: + Rs 0.08–0.12 lakh crore

• Dividend capacity unlocked: + Rs 0.03–0.05 lakh crore

• Total TMLCV Premium: + Rs 0.30 lakh crore

Separation Costs

• One-time costs: - Rs 0.02–0.03 lakh crore

• Lost economies of scale: - Rs 0.03–0.05 lakh crore

• Duplicate corporate overhead: - Rs 0.02–0.04 lakh crore

• Lost cross-funding flexibility: - Rs 0.01–0.02 lakh crore

• Total Dissynergies: - Rs 0.12–0.20 lakh crore

Fair Value Post-Demerger

• TMPV: Rs 5.98 lakh crore (Rs 420–450 per share)

• TMLCV: Rs 7.85 lakh crore (Rs 440–480 per share)

• Combined SOTP: Rs 13.83 lakh crore

Current Market Cap (Jan 2026): Rs 1.67 lakh crore

Valuation Gap: 88% undervaluation

Step 4: Why the Market Is Wrong (Or Is It?)

Operational Reality (January 2026)

• TMPV Production: +21.71% YoY (Q3 FY26)

• TMPV Domestic Sales: +24.73% YoY

• TMLCV CV Volumes: +28.6% YoY (November 2025)

Yet the market has hammered both stocks. Why?

Market Concern 1: JLR Cyberattack Overhang

In September 2025, JLR suffered a massive cyberattack that disrupted production. Phased restart only began in Q1 FY26. Market is pricing in a 50% probability that JLR recovery will be delayed or incomplete, which would reduce TMPV fair value by Rs 0.15–0.20 lakh crore.

Market Concern 2: CV Cycle Peak Fears

November 2025 CV growth of +28.6% looks like a cyclical peak. Commercial vehicle demand is inherently cyclical (4–5 year cycles). If the cycle turns in FY26–27, TMLCV fair value drops Rs 0.20–0.30 lakh crore.

Market Concern 3: Iveco Integration Risk

Tata Motors acquired Iveco’s bus and truck business for international expansion. Cross-border integrations have a 40–60% failure rate. Market is applying a 50–60% haircut to the estimated Rs 0.08–0.12 lakh crore Iveco synergies.

Market Concern 4: Investor Adjustment Period

Institutional investors need 3–6 months to rebalance portfolios after demergers. This creates temporary selling pressure and a 10–15% psychological discount.

The Damodaran Framework Score: 9/10

What It Got Right

• Clearly separated value creation (ROIC > WACC) from value destruction (ROIC < WACC)

• Quantified SOTP accurately using independent DCF models

• Identified market timing risk

What It Struggled With

• Difficult to quantify black swan events (JLR cyberattack one month before demerger)

• Investor sentiment swings in a 3-month window are hard to model

The Comparative Analysis

Synergy Quality Greater Than Synergy Quantity

As Damodaran emphasizes in his blog “Winning at a Loser’s Game”:

“The problem with acquisitions is not that synergy does not exist. The problem is that it is much more difficult to create synergy than to talk about it.”

When Mergers Make Sense (Damodaran’s Four Tests)

Drawing from Damodaran’s acquisition framework, mergers create value when:

1. Operating Synergy Test: Combined entity achieves lower costs or higher growth than sum of parts

   • HDFC Bank: Passed on paper, failed in execution (regulatory offset)

2. ROIC Improvement Test: Combined ROIC greater than standalone ROIC

   • HDFC Bank: Failed (20% + 25% resulted in 18–20% combined)

3. Financial Synergy Test: Cheaper capital or better use of cash

   • HDFC Bank: Partial pass (lower cost of funds, but SLR/CRR drag)

4. Control Premium Test: Better management creates value

   • HDFC Bank: Not applicable (both already optimally managed)

When Demergers Make Sense (The ROIC Separation Principle)

Demergers unlock value when:

1. ROIC Divergence Test: Businesses have radically different ROIC profiles

   • Tata Motors: Strong pass (6.6% vs 14.5% = 8 percentage point gap)

2. Capital Structure Test: Businesses need different leverage or capital allocation

   • Tata Motors: Passed (TMPV needs growth capital for EV, TMLCV can return cash via dividends)

3. Multiple Re-rating Test: Pure-play entities command higher multiples

   • Tata Motors: Expected (luxury 18–20x, CV 14–15x vs blended 14x), but market has not recognized yet

4. Focus and Execution Test: Separate management improves operational performance

   • Tata Motors: Validated (+25% operational growth post-separation)

Investment Implications and Recommendations

HDFC Bank: The Fairly Valued (Hold)

Current Valuation (February 2026):

• Price: Rs 915.80

• P/E: 18.92x (vs sector 16.35x)

• P/B: 2.65x

• Fair Value Range: Rs 1,000–1,100

• Upside: +3.7% to +9.2%

Investment Thesis:

• Stock has re-rated from merger euphoria (48% gain) to fundamental value

• Synergies are slowly materializing but the 3–5 year timeline remains

• Regulatory environment stable but unlikely to improve materially

• Growth trajectory reset to 11–12% (from 18%+ pre-merger)

Recommendation: HOLD for long-term investors (5+ years)

• Catalyst Watch: Q4 FY26 guidance (March 2026) for CASA deposit trends

• Risk: Growth remains structurally stuck at 11–12% (not temporary)

• Positioning: Core holding for dividend income (1.2% yield growing 15–18%) plus steady 8–10% capital appreciation

Tata Motors: The Mispriced Demerger Opportunity

TMPV (Passenger Vehicles + JLR + EV)

• Current Price: Approximately Rs 375.70

• Fair Value: Rs 420–450 (12-month target)

• Upside: +20–28%

• Bull Case (JLR recovery plus EV ramp): Rs 520–580 (+48–65%)

TMLCV (Commercial Vehicles)

• Current Price: Approximately Rs 403

• Fair Value: Rs 440–480 (12-month target)

• Upside: +9–19%

• Bull Case (Iveco success plus cycle extension): Rs 520–580 (+29–44%)

Investment Thesis:

• Market is pricing in excessive pessimism on JLR (50% probability of failure)

• CV cycle fears appear overdone — structural demand from infrastructure and logistics remains strong

• Operational metrics (+25% growth) validate the demerger strategy

• SOTP discount of -33% appears irrational given fundamentals

Recommendation:

• TMPV: BUY on dips below Rs 330 (high-risk, high-reward; binary outcome based on JLR)

• TMLCV: ACCUMULATE for dividend yield and value (lower risk, steady returns)

• Portfolio Strategy: 60% TMPV / 40% TMLCV for optimal risk-adjusted returns

Key Catalysts:

• TMPV: Q4 FY26 results (May 2026) showing JLR recovery trajectory

• TMLCV: Q3 FY26 guidance (January 2026) on Iveco integration progress

Timeline to Value Realization: 12–24 months (much faster than HDFC Bank’s 3–5 years)

What Damodaran’s Framework Teaches Us

The Three Meta-Lessons

Lesson 1: Synergy Is a Story, Valuation Is a Number

As Damodaran writes:

HDFC Bank claimed Rs 0.40–0.60 lakh crore in synergies. The framework forced discipline: “Show me the mechanism. Show me the timing. Show me the probability.”

Result: Only Rs 0.10–0.15 lakh crore was truly defensible.

Lesson 2: ROIC Is the North Star

The single most powerful diagnostic in both cases was ROIC analysis:

• HDFC Bank: Combined ROIC decline (20% and 25% down to 18%) signaled value destruction risk

• Tata Motors: ROIC divergence (6.6% vs 14.5%) clearly indicated the businesses should be separated

If ROIC does not improve materially, the restructuring is financial engineering, not value creation.

Lesson 3: Markets Eventually Recognize Value, But Timing Is Everything

• HDFC Bank: Market ignored synergy shortfalls for more than 2 years due to sector tailwinds

• Tata Motors: Market focused on short-term fears (JLR, CV cycle) despite operational strength

For investors: Damodaran’s framework identifies intrinsic value, but realizing that value requires patience and catalysts.

When to Use This Framework

Optimal Use Cases

1. Mega-mergers where synergies are the deal’s core value proposition (HDFC Bank)

2. Conglomerate demergers where ROIC profiles diverge strongly (Tata Motors)

3. Control changes where operational improvements are promised

4. Financial engineering deals involving capital structure optimization

Limitations

1. Difficulty quantifying execution risk (50%? 70%? Hard to know precisely)

2. Regulatory environment changes are difficult to model (for example, SLR and CRR surprises)

3. Market sentiment can override fundamentals for 6–12 months (Tata Motors post-demerger)

4. Black swan events (such as the JLR cyberattack) are inherently unpredictable

Damodaran’s framework is necessary but not sufficient. Combine it with(My 2 cents):

• Market sentiment analysis (VIX, sector rotation, institutional flows)

• Industry and cycle analysis (CV cycle position, mortgage market health)

• Regulatory horizon scanning (anticipating policy changes)

• Management track record assessment (integration and execution capability)

Conclusion: The Paradox of Value Creation

The HDFC Bank merger and Tata Motors demerger present a fascinating paradox:

HDFC Bank: Combined entities with strong standalone performance resulted in less value creation than expected, yet the market still rewarded it (+48%).

Tata Motors: Separated value-destroying from value-creating businesses, operational metrics validated the strategy, yet the market punished it (-33%).

Damodaran’s framework explains both outcomes:

1. For HDFC Bank: Synergy was overestimated because regulatory dissynergies were not fully anticipated. The market’s +48% gain reflects sector multiple expansion, not merger synergies — a key distinction the framework helps clarify.

2. For Tata Motors: The SOTP valuation is clear (Rs 13.83 lakh crore fair value vs Rs 1.67 lakh crore market cap). The -33% gap reflects timing and sentiment, not fundamentals. The framework identifies this as a temporary mispricing.

The Final Verdict

Damodaran’s acquisition and demerger framework is the most rigorous tool for separating value creation from value destruction in corporate restructurings.

But as Damodaran himself cautions:

“The problem is not with the valuation. The problem is with human nature — we want to believe in synergy, even when the numbers do not support it.”

For Investors

• Use the framework to value restructurings independently

• Identify where market price diverges from intrinsic value

• Have the patience to wait for catalysts (HDFC: 3–5 years, Tata: 12–24 months)

• Recognize when markets are temporarily wrong (Tata Motors today) versus when fundamentals disappoint (HDFC Bank’s synergy shortfall)

The best corporate restructurings are not the ones with the biggest synergy claims — they are the ones where ROIC improves materially and management can clearly demonstrate how.

Appendix: Key Metrics at a Glance

HDFC Bank (February 2026)

• Price: Rs 915.80 | Fair Value: Rs 1,000–1,100 | Upside: +3.7% to +9.2%

• P/E: 18.92x | P/B: 2.65x | ROE: 23–24% | Loan Growth: 11.9%

• What I’m doing: HOLD | Time Horizon: 3–5 years

TMPV (February 2026)

• Price: Approximately Rs 350 | Fair Value: Rs 420–450 | Upside: +20–28%

• P/E: 1.53x (distorted) | P/B: 1.20x | ROE: 9.95%

• What I’m doing: BUY on dips | Time Horizon: 12–18 months

TMLCV (February 2026)

• Price: Approximately Rs 403 | Fair Value: Rs 440–480 | Upside: +9–19%

• EV/EBITDA: 4.47x | ROE: 23.96% | CV Growth: +28.6%

• What I’m doing: ACCUMULATE | Time Horizon: 18–24 months

References and Further Reading

[1] HDFC Bank Q3 FY26 Results (January 2026). HDFC Bank reports first double-digit loan growth post-merger at 11.9% YoY. Economic Times, January 2026.

[2] Tata Motors Demerger Impact Report (October 2025). TMLCV CV volumes surge +28.6% in November 2025. Business Standard, October 2025.

[3] Damodaran, A. (2005). The Value of Synergy. Stern School of Business Working Paper.
Available at: https://pages.stern.nyu.edu/~adamodar/pdfiles/papers/synergy.pdf

[4] Damodaran, A. (2024). Acquisition Valuation. NYU Stern Teaching Materials.
Available at: https://pages.stern.nyu.edu/~adamodar/pdfiles/AcqValn.pdf

[5] Manickaraj, M. and Roy, A. (2023). The Merger of HDFC Limited with HDFC Bank: Synergy or Concentration? NIBM Working Paper. Notes regulatory obligations (SLR 22%, CRR 4–6%, Priority Sector 40%) create Rs 10,000–15,000 crore annual drag.

[6] CFA Institute. (2019). Aswath Damodaran on Acquisitions: Just Say No. CFA Institute Blog, February 27, 2019.
Available at: https://blogs.cfainstitute.org/investor/2019/02/28/aswath-damodaran-on-acquisitions-just-say-no/

[7] HDFC Bank Annual Report FY2025. CEO Sashidhar Jagdishan notes cross-selling activation slower than expected, targeting completion by FY2027. HDFC Bank Investor Relations, July 2025.

[8] Damodaran, A. (2002). Investment Valuation: Tools and Techniques for Determining the Value of Any Asset (2nd edition). Wiley Finance. Chapter on demergers and spinoffs emphasizes ROIC improvement as primary value driver.

[9] Tata Motors Q3 FY26 Production Report. TMPV production volumes increase +21.71% YoY with domestic PV sales +24.73%. Tata Motors Press Release, January 2026.

[10] Tata Motors JLR Cyberattack Impact Analysis (September 2025). Phased restart announced for Q1 FY26 with full recovery expected post-holiday season February–March 2026. Reuters, October 2025.

[11] Damodaran, A. (2015). Winning at a Loser’s Game? Control, Synergy and the ABInBev-SABMiller Merger. Musings on Markets blog, October 22, 2015.
Available at: https://aswathdamodaran.blogspot.com/2015/10/winning-at-losers-game-control-synergy.html

[12] Damodaran, A. (2024). Valuing Synergy. NYU Stern Spring 2024 Session Materials.
Available at: https://pages.stern.nyu.edu/~adamodar/podcasts/valspr24/session25slides.pdf

[13] HDFC Bank Merger Analysis by Prime Investor (2024). Analysis - Impact of the HDFC merger and our recommendation. Prime Investor Research Report, July 5, 2024.
Available at: https://primeinvestor.in/reports/analysis-impact-of-hdfc-merger-our-recommendation/

About This Analysis

This analysis was prepared using Aswath Damodaran’s published valuation frameworks, publicly available financial statements, analyst reports, and market data as of February 17, 2026. All DCF calculations use standard corporate finance assumptions (WACC, terminal growth 5–6%, industry-standard reinvestment rates) and are based on Damodaran’s teaching materials from NYU Stern School of Business.

Disclaimer: This analysis is for educational and informational purposes only. It does not constitute investment advice. Readers should conduct their own due diligence and consult with financial advisors before making investment decisions. I have a vested interest in doing the analysis as I am long term holder of these stocks and would like to evaluate once in a half year for building conviction on holding or exiting or partial exit.

Changelog and Updates:

• February 17, 2026: Initial publication with data through January 2026

• Future updates will track Q4 FY26 results for both HDFC Bank and Tata Motors entities

DISCLAIMER

The content published in this post is intended solely for educational and informational purposes. I am not registered with SEBI as an investment advisor, research analyst, broker, or financial influencer, and nothing in this post should be construed as investment advice, stock recommendations, or solicitation to buy, sell, or hold any securities.

This analysis is part of my personal learning journey in finance and valuation, heavily influenced by academic frameworks and publicly available material from Aswath Damodaran, particularly his work on Synergies and valuation.
The post reflects my own interpretation and application of these concepts as a finance student and practitioner, and any errors or assumptions are entirely my own.

The valuation models, assumptions, scenarios, and conclusions presented here are illustrative learning exercises, not predictions. They do not account for individual financial circumstances, risk tolerance, tax considerations, or investment objectives.

Readers are strongly encouraged to perform independent due diligence and/or consult a SEBI-registered financial professional before making any investment decisions. I shall not be responsible for any financial losses or outcomes resulting from reliance on this content.

🔍 Holdings & Transparency Disclosure

Disclosure of Personal Holdings

Where applicable, I disclose my personal holdings in the discussed securities, including approximate portfolio allocation percentages and unrealized profit/loss as of the mentioned date, purely in the interest of transparency.

Such disclosure does not constitute a recommendation or endorsement. My positions may change at any time without notice, and I am under no obligation to update previous disclosures or analyses.

My personal holdings of HDFC Bank & Tata Motors(PV &CV) dated on 19th Feb 2026 (against overall Portfolio)

Every developer has been there. You’re scrolling through your project’s commit history, and you see something

git commit -m “stuff”
git commit -m “fixed it”
git commit -m “update”

Now imagine if Instagram captions were written the same way. Your stunning sunset photo accompanied by “pic”?

A 10-day adventure summed up as “travel”?

It would completely miss the magic, the context, and the story that makes your content worth sharing.

Your commit messages deserve the same care and attention as your best Instagram posts.

The Instagram Parallel: Why It Actually Makes Sense

Think about what makes an Instagram post successful. A great Instagram post tells a story. It captures a moment, explains its significance, and engages your audience. Your commit messages should do exactly the same—except your audience is other developers (including your future self).

When you post a photo on Instagram, you don’t just throw it up without a caption. You craft a message that explains:

• What you captured (the subject)

• Why it matters (the context)

• What makes it special (the details that set it apart)

Your commits need the same thoughtfulness. A commit is a moment in your codebase’s history. Future developers—or you, three months from now—will read that commit message trying to understand what changed and, more importantly, why.

Breaking Down the Instagram Post Formula for Commits

The Hook (Subject Line)

Instagram posts start with a strong opening line that makes people stop scrolling. Your commit subject line does the same thing in your repository’s history.

Instagram: “Just witnessed the most incredible sunset at Uttarakhand(Himalayas) 🌅”
Git (weak): “changed the view”
Git (strong): “feat(ui): Add dynamic theme switching for wildlife content gallery”

The strong version is like a great Instagram caption—it’s clear, specific, and immediately tells you what’s important about this change1.

Follow the 50-character rule (yes, it’s short, but constraints fuel creativity—Instagram knows this better than anyone). Limit your subject to a single, punchy line that could complete this sentence: “If applied, this commit will…” 23

Instagram tip: Your first line is what appears in feed previews. Your first 50 characters are what appear in git logs

The Story (Body/Description)

Instagram’s best posts don’t stop at the headline. They dive deeper with a well-crafted caption that explains the “why”—why this moment matters, what led to it, what you learned.

Your commit body should do exactly this. A commit should explain:4

• What you changed and why it was necessary

• Why you made this decision (not how—your code shows that)

• Context that helps future developers understand the reasoning

Instagram (weak caption): “Love this photo”

Instagram (strong caption): “Spent three weeks planning this shot during the perfect monsoon season. The Beautiful sunset at Chakumba peak is a pure magic. This represents the intersection of nature and heritage that inspired our WilderhoodTV project.”

Git (weak): “fixed performance issue”

Git (strong):

fix(image-processing): Optimize IQA pipeline memory usage

The previous implementation loaded entire image batches into memory before processing, causing Lambda timeout errors on large uploads (>100MB). Refactored to use streaming chunks of 5MB, reducing memory footprint by 60%. This change enables the pipeline to handle 4GB+ batches without exceeding Lambda’s 10GB limit, critical for high-resolution wildlife photo processing in production. 

Related to: Parjanya feature request #234

Notice how the strong example provides context? Future developers understand not just what changed, but why. 5

The Hashtags and Tags (Commit Type/References)

Instagram uses hashtags to categorize content and increase discoverability. Git has something similar: commit types.

Just as Instagram has specific hashtags (#wildlife, #nature, #architecture), Git has commit types:

• feat: Introducing a new feature

• fix: Addressing a bug

• docs: Documentation changes

• refactor: Code restructuring without changing functionality

• perf: Performance improvements

• test: Adding or updating tests

• chore: Maintenance tasks

Using commit types is like using the right hashtags—they help people find relevant commits, they work with automation tools, and they tell a quick story about what kind of change this is. 6

Instagram:

#wildlife #nature #photography #india #Uttarakhand (max 5 allowed)

Git:

feat(api): Add support for create coupons

The type + scope format makes your commit instantly searchable and understandable.

Engagement (Frequency and Thoughtfulness)

The most successful Instagram accounts post consistently and thoughtfully. They don’t save up a year’s worth of photos and post them all at once. They understand the value of regular, meaningful engagement.

Your commits should follow the same principle. Commit frequently with clear, focused changes. One well-crafted commit that adds a feature is better than five commits saying “stuff,” “more stuff,” “fixed it,” and “I think this works now.” 7

Why? Because:

1. Small, focused commits are easier to understand and review

2. Frequent commits create a narrative of your work

3. Meaningful commits make it easy to revert a specific change if needed

Instagram analogy: It’s better to post one stunning, well-captioned photo once a week than to spam five mediocre ones daily.

The Imperative Mood: Commands, Not Confessions

Here’s a subtle but critical difference that separates amateur commit messages from professional ones. Use the imperative mood—write as if giving a command. 8

Weak (past tense):

• “Fixed the login bug”

• “Added new user validation”

• “Updated the styling”

Strong (imperative):

• “Fix the login bug”

• “Add new user validation”

• “Update the styling”

Why does this matter? Because imperative mood completes the sentence: “If applied, this commit will fix the login bug.” It’s action-oriented, clear, and aligns with how Git itself describes your changes.

Think of it like Instagram captions. Would you caption a sunset photo “I watched the sunset” (past tense) or “Watch the golden hour unfold” (imperative, engaging)? The second draws people in.

The Perfect Commit Message Template

Here’s your Instagram-inspired commit template:

[type](scope): Brief, imperative description (≤50 chars) 

More detailed explanation of what changed and why. Wrap at 72 characters. Explain the problem you solved, the approach you took, and why this matters. 

Reference any relevant issues, PRs, or discussion: 
Fixes #123. 
Related to: Feature request #456

Example (strong):

feat(content): Add interactive chapter markers for wildlife docs 

Implemented clickable timeline markers that allow viewers to jump to key moments in documentary chapters. Used Server-Sent Events (SSE) for real-time position tracking across devices.

This addresses viewer feedback that long-form content (25+ mins) needed better navigation. Analytics show 40% of viewers skip to the middle—this feature aims to guide discovery.

Closes #89

See how that reads?

It’s a story. It’s professional.

It’s something you’d be proud to put your name on—just like a great Instagram post.

Why This Matters for Your Career

Here’s something that separates junior developers from senior ones: commit history literacy.

Your commits are a portfolio piece. They show:

• Communication skills: Can you explain technical decisions clearly?

• Professionalism: Do you take care with details?

• Thoughtfulness: Do you consider future readers?

• Debugging ability: Can you provide context others can use?

Companies value developers who write good commits. Open-source projects are more likely to merge PRs from people with clear commit histories. Your future self will thank you when you’re trying to understand why a decision was made six months ago.

Common Mistakes (And How Instagram Teaches Us Better)

Mistake 1: Vague messages

• Bad: “Update” | Instagram equivalent: “Photo”

• Fix: “refactor(parser): Simplify JSON extraction logic”

Mistake 2: Too much in one commit

• Bad: “feat: Rewrote entire auth system, refactored database, updated UI, added tests”

• Instagram equivalent: A 30-image carousel when people want one stunning photo

• Fix: Break it into logical, related commits

Mistake 3: Assuming people know the context

• Bad: “Fix bug in endpoint”

• Instagram equivalent: “Check this out” with no context

• Fix: “fix(api): Prevent null reference in user details endpoint when profile photo is missing”

Mistake 4: Writing messages for yourself

• Bad: “Did the thing”

• Instagram equivalent: An inside joke only you understand

• Fix: Remember, you’re writing for collaborators and future-you

Making It a Habit

Like any skill, writing great commits gets easier with practice. Here’s how to build the habit:

Start small: On your next project, pick one rule and focus on it. Maybe it’s just using imperative mood. Then add another rule next week.

Use tools: Configure your editor to open a template on commit. Set up hooks that validate your commit format. Use conventional commit tools like  commitizen  that guide you through the process.

Study great commits: Look at open-source projects you admire. Read their commit histories. See what makes them tick. Just like studying great Instagram photographers teaches you about composition, studying great commits teaches you about code communication.

Review your own history: Look at commits you made three months ago. Can you understand why you made each change? If not, that’s your signal to improve.

The Bigger Picture

Your commits tell the story of your code. Instagram tells stories with images; your repository tells stories with commits. Both require the same ingredients: clarity, context, care, and consistency.

When you write a thoughtful commit message, you’re not just documenting code—you’re building a bridge between your intent and someone else’s understanding. You’re making future debugging easier. You’re showing respect for your collaborators’ time.

And honestly? In a world where code is read far more often than it’s written, that’s one of the most valuable skills you can develop.

So next time you’re about to commit with a message like “fix stuff,” pause. Ask yourself: Would I post this on Instagram? Would it tell a story? Would people understand and appreciate what I’m sharing?

If the answer is no, take another minute and craft something better. Your future self will thank you. Your team will appreciate it. And your commit history will be something you’re actually proud of—just like your best Instagram posts.

Key Takeaways:

• Commit messages are communication, not code. Treat them with the care you’d give an Instagram post

• Use structure: subject line (≤50 chars), blank line, body (explain “what” and “why”), and references

• Write in imperative mood (“Fix” not “Fixed”)

• Commit frequently with focused changes—it tells a better story

• Your commits are a portfolio piece that reflects your professionalism and thoughtfulness

The best commits, like the best Instagram posts, tell a story that resonates long after they’re posted.

Make yours count.

Most teams deploy AI as a single endpoint.

One model.
One cost tier.
One reasoning depth.

That works — until:

• Costs spike

• Latency increases

• Complex tasks fail silently

• Critical workloads get underpowered models

• Or simple tasks get massively over-engineered

Parjanya 2.0 introduces a smarter pattern:

Treat AI like cloud infrastructure — dynamically route requests to the lowest capable model, enforce SLA rules, and escalate only when necessary.

For startups, small teams, and independent developers, this changes everything.

You don’t need a massive AI budget to build production-grade intelligence.
You need governance.

One Size Fits All Is an Anti-Pattern

In distributed systems, we learned:

• One database doesn’t fit all workloads

• One instance size doesn’t fit all traffic

• One cache strategy doesn’t fit all latency needs

Yet in AI systems?

Teams deploy:

One model. For every request.

This is architecturally wrong.

This has been first-principal at Phagyul AI,

Here is the excerpt “4-Tier Inference Scaling”

Problem Statement

AI Agent Systems at Scale Face:

• 🚨 Escalating inference costs

• 🧠 Overuse of frontier models

• 🐢 Latency variability

• ❌ Unreliable reasoning on critical workloads

• 📉 No governance layer

Startups and teams building AI agents are:

• Paying hyperscale prices

• Without hyperscale orchestration

Market Shift

AI is moving from:

Prompt Engineering —> Multi-Agent Distributed Systems

Agent coding frameworks now:

• Call tools

• Spawn subtasks

• Execute workflows

• Interact across repos

• Debug and refactor codebases

But routing remains naive.

┌──────────────────────┐
│     AI AGENT HUB     │
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│   ONE LARGE MODEL    │
│   (For Everything)   │
└──────────────────────┘

Problems:

• Cost explosion

• No workload classification

• No SLA awareness

• No intelligent escalation

Our Strategy

A Complexity-Aware AI Routing Layer

Instead of one model:

We introduce:

• Workload classification

• Complexity scoring

• SLA enforcement

• Budget-aware routing

• Confidence-based escalation

AI becomes governed infrastructure.

Architecture Overview

                 ┌──────────────────────────────┐
                 │        INCOMING AGENT        │
                 │       TASK / REQUEST         │
                 └───────────────┬──────────────┘
                                 ▼
                  ┌──────────────────────────────┐
                  │     REQUEST ANALYZER         │
                  │  • Complexity Score          │
                  │  • Context Volume            │
                  │  • SLA Tier                  │
                  │  • Budget Level              │
                  └───────────────┬──────────────┘
                                  ▼
                  ┌──────────────────────────────┐
                  │        ROUTING ENGINE        │
                  │  Cost + SLA + Risk Aware     │
                  └───────────────┬──────────────┘
                                  │
        ┌─────────────────────────┼─────────────────────────┐
        ▼                         ▼                         ▼
 ┌────────────────┐       ┌────────────────┐       ┌────────────────┐
 │  Low Tier      │       │  Mid Tier      │       │  High Tier     │
 │  Fast / Cheap  │       │  Balanced      │       │  Research      │
 └────────────────┘       └────────────────┘       └────────────────┘
                                 │
                                 ▼
                ┌──────────────────────────────┐
                │       CONFIDENCE CHECK       │
                └──────────────────────────────┘

How It Works

Step 1: Compute Complexity (1–10)

Weighted dimensions:

• Structural depth

• Cognitive reasoning

• Context size

• Ambiguity

• Risk/SLA

Step 2: Route to Lowest Capable Tier

Step 3: Evaluate Confidence

If < threshold → escalate once.

This mirrors:

• Auto-scaling

• Load balancing

• Risk-aware distributed design

The Intelligence: Complexity Computing

| Dimension      | Weight | Measures                |
| -------------- | ------ | ----------------------- |
| Structural     | 25%    | Multi-step depth        |
| Cognitive      | 25%    | Reasoning complexity    |
| Context Volume | 20%    | Token & file load       |
| Ambiguity      | 15%    | Novelty / unclear scope |
| Risk / SLA     | 15%    | Business sensitivity    |

Parjanya 2.0 assigns each request a score from 1 to 10.

Complexity = (0.25 × Structural)
+ (0.25 × Cognitive)
+ (0.20 × Context)
+ (0.15 × Ambiguity)
+ (0.15 × Risk)

Why This Wins for AI Agent Coding

In agent coding systems:

Yet most systems use high-tier models 100% of the time. I strongly recommend, workload-aware routing.

Winnings(projected)

Typical results:

• 40–70% cost reduction

• 25–40% latency improvement

• Reduced failure cascades

• Predictable SLA compliance

• Lower risk in critical flows

Competitive Positioning

| Approach                | Problem                         |
| ----------------------- | ------------------------------- |
| Single-model deployment | Cost inefficient                |
| Manual routing rules    | Brittle                         |
| Static tiering          | Non-adaptive                    |
| Parjanya 2.0            | Adaptive, governed, intelligent |

We are:

The orchestration layer for AI agent systems.

The routing and governance standard for AI reasoning workloads.

Here are couple of Real world examples

📚 References & Prior Art

Below are the key bodies of work that support the orchestration-first approach.

1️⃣ AWS Well-Architected Framework

Authority: Amazon Web Services

The AWS Well-Architected Framework emphasizes workload-aware design and right-sized infrastructure. Two pillars are especially relevant:

• Performance Efficiency

• Cost Optimization

Core principle:

Select the appropriate resource type and size based on workload characteristics.

This directly parallels model tier selection in AI systems.
Using the most powerful compute for every workload is considered poor architecture in cloud systems — the same logic applies to AI models.

References:

• AWS Well-Architected Overview
  https://aws.amazon.com/architecture/well-architected/

• Performance Efficiency Pillar
  https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html

• Cost Optimization Pillar
  https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html

2️⃣ AWS Auto Scaling & Right-Sizing

Authority: AWS Compute Engineering

AWS strongly promotes dynamic scaling and workload-based resource allocation.

Core principle:

Do not statically provision the largest instance for all traffic.

This is structurally identical to avoiding a single frontier AI model for every request.

Reference:

• Amazon EC2 Auto Scaling
  https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

3️⃣ AWS Step Functions — Orchestration Pattern

Authority: AWS Serverless Architecture

AWS Step Functions formalizes the separation of orchestration logic from execution logic.

Core principle:

Decouple coordination from execution to improve reliability and scalability.

Parjanya applies this same architectural pattern:

• Models perform execution.

• The routing layer governs orchestration.

Reference:

• AWS Step Functions
  https://aws.amazon.com/step-functions/

• Developer Guide
  https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html

4️⃣ AWS Builders’ Library — Load Shedding

Authority: Amazon Engineering

The AWS Builders’ Library provides deep technical insight into how Amazon designs resilient systems.

Particularly relevant:

“Using Load Shedding to Avoid Overload”

Core insight:
Not all requests should be treated equally under stress.

This aligns with:

• SLA-tier routing

• Critical-path prioritization

• Confidence-based escalation policies

Reference:

• Using Load Shedding to Avoid Overload
  https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/

5️⃣ Google SRE — Service Level Objectives & Error Budgets

Authority: Google Site Reliability Engineering

Google’s SRE model introduced error budgets and differentiated reliability tiers.

Core principle:

Not all traffic deserves equal reliability guarantees.

This supports:

• SLA-aware routing

• Risk-weighted orchestration

• Guardrails for high-sensitivity workloads

References:

• SRE Book (Free Online)
  https://sre.google/books/

• Service Level Objectives Chapter
  https://sre.google/sre-book/service-level-objectives/

6️⃣ Martin Fowler — Microservices Architecture

Authority: Martin Fowler

Microservices architecture formalized the idea that different services have distinct scaling and performance characteristics.

Core principle:

Avoid monolithic systems; separate concerns based on workload.

Applying this to AI:
Different reasoning tasks require different levels of compute and reasoning depth.

Reference:

• Microservices Article
  https://martinfowler.com/articles/microservices.html

7️⃣ Mixture of Experts (MoE) — Google Research

Authority: Google Brain

Seminal paper:

“Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer”

This research demonstrates that even inside large neural networks, not all parameters are activated for every input. Instead, tokens are routed dynamically to specialized experts.

In other words:
Frontier AI models themselves reject the “one size fits all” paradigm internally.

Parjanya extends this idea externally — at the system architecture level.

Reference:

• Mixture of Experts Paper (arXiv)
  https://arxiv.org/abs/1701.06538

8️⃣ AWS Bedrock — Multi-Model Strategy

Authority: AWS AI/ML

AWS Bedrock promotes selecting foundation models based on workload characteristics and cost/performance tradeoffs.

Core principle:
Model selection should be contextual.

Reference:

• Amazon Bedrock
  https://aws.amazon.com/bedrock/

9️⃣ LangChain — Routing & Agent Orchestration

Authority: LangChain

LangChain includes explicit routing constructs for selecting chains, tools, or agents based on task classification.

Core principle:
AI systems require orchestration layers, not monolithic execution.

Reference:

• Routing Use Cases
  https://python.langchain.com/docs/use_cases/routing/

🔟 Microsoft Semantic Kernel — Planning & Skill Routing

Authority: Microsoft AI

Semantic Kernel introduces planners and skill orchestration for AI workflows.

Core principle:
Complex AI applications require controlled coordination between components.

Reference:

• Semantic Kernel Documentation
  https://learn.microsoft.com/en-us/semantic-kernel/

Distributed systems engineering has long rejected monolithic resource allocation.

Cloud architecture evolved to embrace:

• Workload-aware scaling

• Cost optimization per task

• SLA differentiation

• Orchestration layers

• Risk-aware decision systems

Modern AI systems are now at a similar inflection point.

Parjanya 2.0 applies proven distributed systems principles to AI reasoning infrastructure — transforming model selection from a static choice into a governed, adaptive system.

How Parjanya Extends Prior Art

The works cited above establish a consistent architectural truth: distributed systems must be workload-aware, cost-sensitive, and reliability-governed.

However, most AI systems today still operate as monoliths — routing every request to a single model tier without classification, SLA differentiation, or escalation control.

Parjanya 2.0 extends prior art by:

• Applying right-sizing principles to AI model selection

• Externalizing orchestration beyond the model layer

• Introducing complexity scoring as a governance mechanism

• Enforcing SLA-aware routing policies

• Implementing confidence-based escalation guardrails

In essence:

The “API lock-in” problem affects Claude Code users who accidentally switch from subscription billing to API billing and cannot revert1. This costs teams $600+/developer/year in unexpected charges2. This guide provides prevention strategies and recovery paths based on January 2026 Anthropic updates.

The Problem

What Is API Lock-in?

Claude Code (VS Code extension/CLI) supports two authentication modes3:

• Subscription mode: OAuth with Claude Pro/Max account ($20-200/month fixed)

• API mode: API key with pay-as-you-go billing ($3-75 per million tokens)

Once Claude Code accepts an API key, it may permanently switch to API billing—even after removing the key, logging out, and restarting1. Users report being unable to revert to subscription limits despite active Pro/Max subscriptions.

Why It Happens

Anthropic deliberately separated subscription and API usage in January 2026 to prevent pricing arbitrage4. Subscription tokens now only work in official clients. The lock-in is aside effect of this enforcement mechanism.

Financial Impact