Cursor's pricing shakeup, OpenAI Codex internals, the famo.us postmortem, and when patterns betray you
Published on 19.03.2026
Cursor's Silent Pricing Change Drives Enterprise Churn, Claude Opus 4.6 Gets 1M Context
TLDR: Cursor quietly moved most models behind its Max mode paywall, causing enterprise credits to evaporate in days instead of lasting the month. Meanwhile, Claude Opus 4.6 shipped a 1M token context window and a Compaction API for long-running agents, and the wider AI landscape saw Spotify's internal agent merging a thousand PRs every ten days.
Summary:
Let me just say this plainly: if you change the pricing model and do not tell your paying customers, you deserve every bit of churn headed your way. Cursor took nearly all of its models and stuffed them behind Max mode without so much as a changelog entry or a blog post. Enterprise users are now watching their monthly credits drain in one to two days. That is not a pricing adjustment. That is a breach of trust, and trust is the only currency that matters when you are asking developers to hand over their workflow to your tool.
On the other side of the ring, Anthropic shipped Claude Opus 4.6 with a 1M token context window for Max, Teams, and Enterprise desktop users. That is a genuinely meaningful technical achievement. The Compaction API is designed specifically for long-running agentic workflows, the kind where you spin up an agent, let it chew through a codebase for hours, and you need context to survive the journey. Performance numbers are real too: 3.1x less memory, 4.8x faster startup, and 76% multi-needle retrieval accuracy at scale. Those are not marketing numbers. Those are the kind of benchmarks that change how you architect agent pipelines.
The broader landscape is just as interesting. MiniMax M2.7 launched with what they call self-evolution capabilities. Windsurf restructured its pricing and drove away cost-conscious users, echoing the exact same mistake Cursor is making. And the trust gap is widening: 80% of developers say they use AI, but only 29% trust its accuracy. That gap is where all the interesting product work will happen over the next year.
Perhaps the most underreported story is Spotify running an internal agent that merges a thousand pull requests every ten days. That is not a demo. That is production-grade agentic infrastructure inside one of the largest engineering organizations on the planet. If you are still debating whether agents are real, Spotify already answered that question for you. Oh, and Snowflake quietly patched a critical prompt injection vulnerability in Cortex. If you are running anything on Snowflake's AI stack, go check your patches. Now.
Key takeaways:
- Cursor's stealth pricing change is eroding enterprise trust and driving users to evaluate alternatives
- Claude Opus 4.6's 1M context window and Compaction API represent a real leap for long-running agentic workflows
- The 80% adoption vs. 29% trust gap in developer AI usage signals the next major product battleground
Why do I care: If you are building anything that depends on an AI coding assistant, this week is a wake-up call about vendor lock-in. The Cursor situation is a textbook example of why you need abstraction layers between your team's workflow and any single vendor's pricing decisions. Meanwhile, the 1M context window from Claude actually changes what is architecturally possible for agentic coding systems. Start thinking about how your CI/CD pipelines and code review processes could leverage agents that can hold an entire codebase in context.
Cursor's Silent Pricing Change Drives Enterprise Churn, Claude Opus 4.6 Gets 1M Context
How OpenAI Codex Works
TLDR: OpenAI Codex is a cloud-based coding agent built on codex-1, a fine-tuned variant of o3. The real engineering story is not the model itself but the three-layer orchestration system: an agent loop, prompt and context management with prefix caching, and a multi-surface architecture that runs everywhere from CLI to VS Code.
Summary:
ByteByteGo delivered one of the better technical breakdowns I have seen this year, and the punchline is exactly what experienced systems engineers would predict: the model is not the hard part. The orchestration layer is. Codex runs on codex-1, which is a fine-tuned o3 variant, but the engineering that makes it actually useful sits in three distinct layers that work together.
The first layer is the agent loop, an iterative cycle of inference and tool execution. This is where the agent decides what to do, does it, observes the result, and decides what to do next. Simple in concept, brutally difficult in practice. The second layer handles prompt and context management, and this is where it gets interesting. They are dealing with quadratic growth in context by using prefix caching, which lets them reuse computation across similar prompts, and context compaction to keep the working set manageable. If you have ever tried to build a long-running agent that does not degrade into hallucination soup after twenty steps, you know why this layer matters.
The third layer is the multi-surface architecture, a single codebase powering the CLI, VS Code extension, web interface, desktop app, and third-party IDE integrations. That is a real architectural commitment, and it is the kind of decision that either pays off enormously or becomes a maintenance nightmare. Time will tell.
Here is the part that should make every protocol enthusiast uncomfortable: when MCP proved insufficient for rich interactions like streaming progress updates and mid-task approvals, OpenAI built their own custom JSON-RPC protocol. That is not an indictment of MCP. It is an acknowledgment that real-world agent communication has requirements that no current standard fully addresses. The practical recommendations are worth noting too: write AGENTS.md files for your projects, keep task scopes narrow, and start fresh threads rather than letting context degrade. Those are hard-won lessons from people running agents at scale.
Key takeaways:
- The orchestration layer (agent loop, context management, multi-surface arch) is the real engineering challenge, not the model
- Prefix caching and context compaction are critical techniques for preventing agent degradation over long sessions
- MCP was insufficient for production needs, leading OpenAI to build a custom JSON-RPC protocol for richer agent interactions
Why do I care: If you are building or integrating agentic tools into your development workflow, this breakdown is a blueprint. The three-layer architecture is a pattern you will see replicated across every serious agent platform. Pay special attention to the context management techniques. Prefix caching and compaction are not optional optimizations; they are requirements for any agent that needs to operate for more than a handful of steps. And the MCP limitation is worth tracking. If you have bet on MCP as your agent communication standard, understand that the biggest players are already working around its gaps.
The Rise and Fall of famo.us
TLDR: Famo.us was a JavaScript rendering engine from 2012 that raised $30 million by promising native-like performance through GPU-accelerated CSS 3D matrix transforms. It collapsed when browsers caught up, React won the developer mindshare war, and the API demanded too much mathematical expertise from everyday developers.
Summary:
This is one of those stories that every frontend developer should study, not because famo.us was wrong about the problem, but because they were wrong about the solution's shelf life. Back in 2012, browser rendering was genuinely terrible. If you wanted anything approaching 60fps on mobile, you had to fight the layout engine with every trick in the book. Famo.us looked at that landscape and said: what if we just bypass the layout engine entirely and use GPU-accelerated CSS 3D transforms for everything? It was audacious. It was technically impressive. And it raised thirty million dollars.
The collapse happened for the most predictable reason in technology: the platform caught up. Browsers improved their own GPU compositing. The performance gap that justified famo.us's entire existence shrank every quarter. Meanwhile, React showed up and offered a completely different value proposition. React did not try to beat the browser at rendering. It made the developer experience so much better that raw performance advantages stopped mattering for ninety percent of use cases. Three.js captured the audience that actually needed GPU-powered graphics. Famo.us was left in no-man's land, too complex for mainstream apps and not specialized enough for the graphics-intensive niche.
The API complexity deserves its own discussion. Famo.us required developers to think in terms of matrix transforms and physics engines. That is fine for a demo that makes investors gasp, but it is lethal for adoption. Developers do not want to do linear algebra to center a div. The business model could not sustain itself because the total addressable market for "developers who want to write GPU-accelerated layout code by hand" was always smaller than the fundraising implied.
The legacy is genuinely important though. Famo.us pushed the entire industry's expectations for web performance forward. Every time you use a smooth CSS animation or a hardware-accelerated scroll, you are benefiting from the pressure that frameworks like famo.us put on browser vendors. The framework died, but the ambition it represented is alive in every modern web API.
Key takeaways:
- Platform improvements by browser vendors eliminated famo.us's core performance advantage
- React won by optimizing developer experience rather than raw rendering performance
- The API's mathematical complexity created an adoption ceiling that no amount of funding could overcome
Why do I care: This is a cautionary tale about building on gaps that the platform will eventually close. If your architecture depends on working around browser limitations, you need an exit strategy for when those limitations disappear. The famo.us story also illustrates why developer experience beats raw performance almost every time. When you are evaluating frameworks or tools, ask yourself: is this solving a problem that will exist in three years, or is it exploiting a temporary weakness in the platform?
A Proxy Manager, Self-Hostable Web Dashboard for Caddy/Traefik
TLDR: Proxydeck is an open-source, MIT-licensed web dashboard for managing Caddy and Traefik reverse proxies, built with Bun and React. It offers a single-pane-of-glass interface with Docker Compose deployment and optional bundled PostgreSQL.
Summary:
If you have ever managed more than two or three reverse proxy configurations by hand, you know the pain. YAML files multiply, configuration drift creeps in, and suddenly you are spending Friday evening diffing Caddyfiles because staging is routing to the wrong backend. Proxydeck is a straightforward answer to that problem: a self-hosted web dashboard that sits in front of your Caddy or Traefik instances and gives you a unified management interface.
The technology choices are interesting. Bun and React is a modern stack that signals the developer is optimizing for build speed and developer experience. PostgreSQL for state management means your proxy configurations survive container restarts and you get proper audit trails. The deployment story is sensible too: a bootstrap script or Docker Compose, with an optional bundled PostgreSQL so you are not forced to manage yet another database if you do not want to. Configuration lives in environment variables, which is exactly where it should be for containerized infrastructure.
What is missing from the pitch is the hardest part of proxy management: certificate lifecycle management, health checking, and failover. Those are the problems that make infrastructure engineers lose sleep, and it is not clear from the current documentation whether Proxydeck handles them or defers to the underlying proxy. That is not a criticism so much as a question that anyone evaluating this tool should ask before committing.
The MIT license is the right choice for infrastructure tooling. Nobody wants to audit license compliance on their reverse proxy dashboard. The project is early, with minimal community engagement so far, but the problem it solves is real and the approach is clean. Worth watching if you are in the self-hosting space.
Key takeaways:
- Proxydeck provides a unified web UI for managing Caddy and Traefik reverse proxies from a single dashboard
- Built on Bun and React with PostgreSQL for state, deployable via Docker Compose
- Certificate management, health checks, and failover handling remain open questions for evaluators
Why do I care: If your team manages any kind of microservices infrastructure with reverse proxies, a tool like Proxydeck can eliminate the configuration drift that plagues multi-environment setups. The real question is whether it handles the edge cases that matter in production: certificate rotation, graceful failover, and multi-cluster management. Evaluate it for your staging environment first. If it proves itself there, it could save hours of YAML wrangling every sprint.
A Proxy Manager, Self-Hostable Web Dashboard for Caddy/Traefik
When NOT to Use the Repository Pattern in EF Core
TLDR: EF Core's DbContext already implements the repository and unit-of-work patterns. Wrapping it in another repository layer often adds complexity without value, especially in CRUD apps, small projects, performance-critical systems, and microservices. The specification pattern is a lighter alternative when you need reusable query logic.
Summary:
This article picks a fight with one of the most cargo-culted patterns in the .NET ecosystem, and honestly, it is about time. The repository pattern has become one of those things that developers add to every project because the blog post from 2014 said to, without ever stopping to ask whether it actually solves a problem they have. Thomas Ardal from elmah.io lays out a clear case for when you should leave it on the shelf.
The core argument is elegant in its simplicity: DbContext with DbSet already is a repository. It already implements the unit-of-work pattern. When you wrap it in another abstraction layer, you are not adding value. You are adding indirection. And indirection has costs. It obscures what queries are actually being executed. It makes it harder to optimize performance. It creates a surface area for the kind of leaky abstractions that result in N+1 query disasters that only show up under production load.
The list of scenarios where the pattern hurts more than it helps is refreshingly specific. Basic CRUD applications do not need it. Small projects with a handful of tables do not need it. Performance-critical systems are actively harmed by it because the abstraction layer makes it harder to write and tune efficient queries. Microservices with minimal data requirements do not need it. And reporting or analytics scenarios that benefit from raw SQL are fighting against it.
The article is balanced enough to acknowledge when the pattern does earn its keep: complex domain logic that genuinely benefits from abstraction, multi-source data aggregation where you need to hide the plumbing, custom caching strategies, and unit testing in critical systems. The suggestion of the specification pattern as a lighter-weight alternative is practical advice. It gives you reusable query logic without the overhead of wrapping your entire data access layer in another abstraction.
Key takeaways:
- EF Core's DbContext already implements repository and unit-of-work patterns, making an additional repository layer redundant in most cases
- The pattern actively hurts performance-critical systems by obscuring query behavior and enabling N+1 query problems
- The specification pattern offers reusable query logic without the full overhead of the repository abstraction
Why do I care: If you work in a .NET shop, audit your projects for unnecessary repository layers this week. Chances are good that at least one project has a repository abstraction that adds nothing but complexity and makes performance tuning harder. The specification pattern is worth investigating as a replacement that gives you testability and reuse without the indirection tax. And the broader lesson applies beyond .NET: stop adding architectural patterns because a blog post told you to. Add them because you have a specific problem they solve.