If you're preparing for AI engineering interviews, you probably spend a lot of time on DSA, prompt engineering, RAG, and the usual stuff.

But when you actually work with LLMs in production, you run into a different problem pretty quickly: context gets messy and expensive.

You can have a 50k token context that still gives you a good answer, but you're also paying for a lot of unnecessary stuff. It can increase latency, increase token costs, and hurt the model's ability to focus on the information that actually matters.

That got us thinking about something.

In normal software engineering, you don't just care whether your code produces the correct output. A brute-force O(N²) solution might work perfectly, but it's still considered worse than a more efficient solution.

We think context should be treated the same way.

There wasn't really a good way to objectively measure the structural health of an LLM context before inference, so we built ContextOps, a deterministic structural analyzer, and then built ContextBench on top of it.

The easiest way to describe ContextBench is probably LeetCode for context engineering.

We created 1,500 pre-built context windows that act as the problem set.

You write an optimize_context() function that takes a broken context and returns an improved version.

The ContextOps engine then evaluates it using a 100% deterministic score based on structural efficiency, rather than semantic guessing.

The scoring is:

• Quality: 50%
• Compression: 35%
• Latency: 15%

You then get ranked on the ContextBench Leaderboard.

The 1,500 samples are split into five categories, with 300 problems in each:

1. Optimal Architectures: 300

These test whether you can avoid false positives on healthy pipelines.

2. Structural Failures: 300

Things like system prompt bloat and retrieval flooding.

3. Redundancy Failures: 300

Near-duplicate clusters and boilerplate explosion.

4. Agent Architecture Failures: 300

Multi-agent context explosion and tool chain bloat.

5. Temporal Context Drift: 300

Stale memory injection and invalidated historical state.

Every problem has a ground truth.

So if you flag redundancy where there isn't any, your score goes down. If you miss density bloat, your score also goes down.

The point isn't to blindly delete as many tokens as possible. You need to actually improve the context while preserving what's useful.

We also added a security track called ContextSecBench.

It's an adversarial CTF with 300 attack payloads covering things like:

• Truncation smuggling
• Prompt injection hiding
• Semantic Denial of Service (SDoS)

The idea is to test whether your optimizer can deal with malicious context as well, similar to testing an algorithm against adversarial inputs.

We think this is becoming relevant for AI engineering because just knowing how to put documents into a vector database isn't much of a differentiator anymore.

Understanding context architecture, redundancy, retrieval quality, token usage, agent context, and how all of that affects an LLM is becoming much more important.

So we wanted to make something where you can actually practice this and get an objective score instead of just saying you know context engineering.

If you're interested, give ContextBench a try, see how your optimizer performs, and try to get on the leaderboard. All of this is for free. There is no payment wall hidden anywhere. Star the repo so that you can comeback when preparing for interviews.

Would be interested to see what approaches people come up with.

I recently realized something that seems obvious in hindsight.

Every time you start a Claude Code session, your CLAUDE.md is loaded into the model's context before you've even written your first prompt.

That means every line in that file becomes a recurring cost. Every redundant instruction, duplicate guideline, and outdated note gets paid for over and over again.

So I wanted to measure how much it actually matters.

I built a deterministic context linter called ContextOps. Think of it as ESLint for an LLM's context window. Instead of checking code style, it analyzes context quality by looking at redundancy, information density, structure, concentration, duplication, and other deterministic signals. It runs locally, doesn't use an API, and finishes in a couple of seconds.

To test it, I collected the instruction files from several well known repositories including Vercel, Cloudflare's workers-sdk, Prisma Next, and Vercel Turbo. I also created a prepared CLAUDE.md optimized using ContextOps.

I measured two scenarios.

Load
Only the instruction file that Claude Code reads when a session starts.

End of session
The instruction file plus a real 14 turn agent session with around 30 retrieval chunks.

Instruction file	Load score	Load tokens	End score	End tokens	Lines
Vercel Turbo	96	1,043	65	4,358	53
CLAUDE.contextops.md	95	608	64	3,923	74
AGENTS.contextops.md	95	614	64	3,929	74
Cloudflare workers-sdk	95	3,326	60	6,641	184
Prisma Next	95	2,661	63	5,976	96
Vercel monorepo	95	1,020	65	4,335	129

The first thing that surprised me was that almost every repository scored between 95 and 96 when analyzed by itself.

These are good instruction files.

ContextOps isn't saying they're poorly written.

The second thing surprised me even more.

The recurring token cost varies massively.

Some projects load around 600 tokens every session.

Others load more than 3,300 tokens before you've even started working.

If you're using Claude Code all day, that cost is paid again and again.

What happened during a real agent session?

The interesting part wasn't the instruction file.

It was what happened after the session grew.

On the benchmark session, ContextOps classified 95.5% of the accumulated context as redundant, duplicated, low density, or structurally unnecessary according to its deterministic analysis.

After pruning the unnecessary parts, total context size dropped by about 93%.

I then ran the exact same tasks against multiple Claude models.

Some observations from this benchmark:

• The baseline referenced four nonexistent files. The pruned context referenced only files that actually existed.
• Answer quality improved by roughly 0.6 to 1.65 points out of 5, depending on the model and evaluation rubric.
• Responses became much shorter while still answering the same question.
• The strongest models were already fairly robust. Their improvements were smaller than the smaller models.

The biggest win wasn't making Claude "smarter."

It was making the answers more grounded and reducing unnecessary context.

What about cost?

For a workload similar to this benchmark, assuming roughly 100k input tokens per query:

• Around 95.5k tokens were classified as unnecessary.
• On Claude Fable pricing, that's roughly $0.30 to $1.00 saved per query, depending on prompt caching.
• Outputs also became significantly shorter, reducing output token costs as well.

Obviously this depends on your workflow, model, prompt caching, and how much context your agent accumulates.

If your sessions stay small, the savings will also be small.

One interesting observation

One thing I noticed while looking through popular repositories was that many don't keep large instruction files at all.

Instead, their CLAUDE.md is often just a single line:

u/AGENTS.md

The actual instructions live in AGENTS.md, while CLAUDE.md simply points to it.

Simple, clean, and easy to maintain.

What I do now

Before starting a large refactor or an agent session with lots of tool calls, I lint the context first.

pip install contextops

contextops inspect .contextops/snapshot.json --explain

contextops check .contextops/snapshot.json --min-score 80

It's deterministic, runs locally, doesn't call any APIs, and usually finishes in under two seconds.

I already lint my code. Now I lint my context too.

Curious if anyone else has looked into context quality rather than just increasing context length. Most discussions I see are about getting larger context windows, but much less about whether the information inside those windows is actually useful.

link : https://github.com/Abhijeet777ui/contextops

Why am I getting roasted by a context tool 😭😭🥲

Here is the link to get roasted too : https://github.com/Abhijeet777ui/contextops

About a year ago, I had one goal.

I wanted to build an open source project, not because it would look good on my CV or LinkedIn. I just wanted to know what it felt like to create something that people I'd never met would actually use.

I've spent years using amazing open source software built by engineers I really admire. Every time I used one of those tools, I had the same thought in the back of my mind.

"What would it feel like if one day someone used something that I built?"

At the time, I had no idea what that project would be.

Fast forward to today.

I'm an MSc student in the UK, and I finally launched my first serious open source project called ContextOps.

It's a deterministic static analyzer for LLM context. Honestly, if you had told me a year ago that this would be the project I'd end up building, I probably wouldn't have believed you.

The biggest thing I learned wasn't about AI or Python. It was about open source itself.

Writing the code turned out to be only one part of the journey.

You have to explain your ideas clearly as its a proof that you understand it yourself ....

Document everything.

Decide what your project should do and more importantly, what it should never try to do.

Accept criticism from strangers.

Fix bugs that only other people can find.

Build something that someone else can understand without you standing next to them explaining it.

That changed the way I think about software.

After making the project public, something happened that I never expected. Someone spent hours reading the repository and reached out to discuss a potential role based entirely on the project.

Whether that opportunity goes anywhere honestly doesn't matter.

The moment that stayed with me was realizing that an open source project can communicate how you think far better than a list of technologies on a CV ever could.

I know ContextOps is still tiny.

It has a handful of stars, a few users, and a long road ahead.

But one of my biggest dreams is to build an open source project that thousands of developers genuinely use, not because I want a number next to my repository, but because every star represents someone who thought ........ "This solved a problem for me."

The thought that one day an engineer whose work I've looked up to might install one of my tools and use it in their own workflow is honestly what keeps me building.

This project is only the beginning.

No matter what happens with ContextOps, I'm incredibly grateful that I finally stopped waiting for the "perfect idea" and just started building.

If you're sitting on an idea you've been putting off, this is your sign to start. It probably won't be perfect. Mine certainly isn't. But you'll learn more by putting your work out into the world than by keeping it on your laptop forever.

I'm curious, what was the project that made you fall in love with open source or finally convinced you to build something of your own?

here is the link to contextops if you are curious : https://github.com/Abhijeet777ui/contextops

About a year ago, I had one goal.

I wanted to build an open source project, not because it would look good on my CV or LinkedIn. I just wanted to know what it felt like to create something that people I'd never met would actually use.

I've spent years using amazing open source software built by engineers I really admire. Every time I used one of those tools, I had the same thought in the back of my mind.

"What would it feel like if one day someone used something that I built?"

At the time, I had no idea what that project would be.

Fast forward to today.

I'm an MSc student in the UK, and I finally launched my first serious open source project called ContextOps.

It's a deterministic static analyzer for LLM context. Honestly, if you had told me a year ago that this would be the project I'd end up building, I probably wouldn't have believed you.

The biggest thing I learned wasn't about AI or Python. It was about open source itself.

Writing the code turned out to be only one part of the journey.

You have to explain your ideas clearly as its a proof that you understand it yourself ....

Document everything.

Decide what your project should do and more importantly, what it should never try to do.

Accept criticism from strangers.

Fix bugs that only other people can find.

Build something that someone else can understand without you standing next to them explaining it.

That changed the way I think about software.

After making the project public, something happened that I never expected. Someone spent hours reading the repository and reached out to discuss a potential role based entirely on the project.

Whether that opportunity goes anywhere honestly doesn't matter.

The moment that stayed with me was realizing that an open source project can communicate how you think far better than a list of technologies on a CV ever could.

I know ContextOps is still tiny.

It has a handful of stars, a few users, and a long road ahead.

But one of my biggest dreams is to build an open source project that thousands of developers genuinely use, not because I want a number next to my repository, but because every star represents someone who thought ........ "This solved a problem for me."

The thought that one day an engineer whose work I've looked up to might install one of my tools and use it in their own workflow is honestly what keeps me building.

This project is only the beginning.

No matter what happens with ContextOps, I'm incredibly grateful that I finally stopped waiting for the "perfect idea" and just started building.

If you're sitting on an idea you've been putting off, this is your sign to start. It probably won't be perfect. Mine certainly isn't. But you'll learn more by putting your work out into the world than by keeping it on your laptop forever.

I'm curious, what was the project that made you fall in love with open source or finally convinced you to build something of your own?

here is the link to contextops if you are curious : https://github.com/Abhijeet777ui/contextops

I built this thing called ContextOps over the past few days and finally decided to open source it.

The idea came from working on RAG pipelines and AI agents, where it felt like we spend a lot of time evaluating model outputs but almost no time looking at what actually goes into the prompt in the first place.

Over time, prompts quietly accumulate duplicated retrieval chunks, bloated system prompts, oversized conversation history, repeated tool outputs, and other forms of token waste. Those things increase costs and can make model behavior less consistent, but they're surprisingly hard to notice until they become a problem.

So I built ContextOps.

It runs before anything gets sent to the model and analyzes the structure of the context. It produces a deterministic Context Health Score (0–100) and points out issues like redundancy, token waste, structural imbalance, and source concentration.

I deliberately kept the scope narrow. It makes no model calls, uses no embeddings, requires no API keys, runs completely offline, and always produces the same result for the same input.

It also intentionally doesn't try to judge prompt quality, reasoning, semantic similarity, or hallucinations. The goal is simply to make the context itself observable before inference.

The closest comparison I can think of is ESLint, but for LLM context.

Right now it includes:

• A CLI (contextops inspect)
• Python API
• LangChain integration
• JSON output for CI/CD
• A roast mode that insults your context when it's particularly terrible

I'm still improving it, so I'd genuinely appreciate feedback especially from people building RAG systems, agents, or other LLM infrastructure.
I have added different modes as context from tool call is different from a RAG so there are multiple modes.
I'd appreciate if y'all try this out guys ..... it would mean the world to me. And I appreciate contributions too !!!!

And my favourite feature is Roast mode .... It will roast your context. I have added JJK, Harry Potter and Naruto reference roast . Try that out too .

One thing I'm particularly curious about: Is structural analysis of context something you've found yourself wanting, or am I solving a niche problem that just happened to annoy me?

GitHub: https://github.com/Abhijeet777ui/contextops

PyPI: https://pypi.org/project/contextops/