Inspiration
Large language model applications often send huge amounts of source code, logs, conversation history, tool schemas, and documentation with every request. This increases token usage and cost.
Context compression can solve that problem, but compression introduces another risk: the model may lose the one piece of evidence it needed to produce the correct answer.
Most optimization tools answer only one question:
How many tokens were removed?
I built LensOpsAI to answer the more important question:
Did removing those tokens damage the result?
What it does
LensOpsAI is a Paritok-powered developer tool for evaluating LLM context compression.
It runs the same debugging task through two paths:
Full-context baseline
The complete task context is sent directly to Groq.Paritok-optimized run
The same context is routed through the local Paritok proxy and Paritok's hosted GPU compression service before being sent to the same Groq model.
LensOpsAI then compares:
- original and optimized prompt tokens;
- Paritok-processable context before and after compression;
- total tokens saved;
- percentage reduction;
- diagnosis accuracy;
- evidence retained;
- critical identifiers;
- proposed fix;
- overall answer quality.
A deterministic task-specific rubric scores both answers. LensOpsAI then produces a verdict such as:
- SAFE TO DEPLOY
- REVIEW REQUIRED
- NOT SAFE / QUALITY REGRESSION
This prevents teams from treating token reduction as an automatic success.
Real measured result
The real checkout API debugging evaluation uses Groq and Paritok end to end.
For the verified Safe-policy run:
- Groq full-context prompt: 5,968 tokens
- Groq optimized prompt: 4,949 tokens
- Provider-level saving: 1,019 tokens, or 17.1%
- Paritok original compressible context: 4,260 tokens
- Paritok optimized context: 2,230 tokens
- Paritok tokens saved: 2,030
- Paritok reduction: 47.7%
- Full-context quality: 100/100
- Optimized quality: 100/100
- Final verdict: SAFE TO DEPLOY
LensOpsAI also preserved a real earlier quality-regression result. That run achieved similar compression but scored only 51.3/100, so the application marked it as NOT SAFE.
This comparison demonstrates the core idea of the project:
Savings alone are not enough. Compression must also preserve quality.
How I built it
LensOpsAI is built with:
- Next.js and React;
- TypeScript;
- Tailwind CSS and shadcn/ui;
- Zustand for local run state and history;
- Recharts for analytics;
- Groq using an OpenAI-compatible API;
- Paritok's local proxy and hosted GPU compression service;
- Docker for production packaging;
- Render for the public deployment.
The production application runs as one Docker service. The Next.js application is publicly exposed, while the Paritok proxy runs privately inside the same container.
The real evaluation API performs the full-context Groq call and the Paritok-optimized call sequentially. Paritok statistics are captured before and after the optimized request so the application can display measured compression values rather than estimated savings.
The outputs are scored using a deterministic rubric covering root cause, evidence, required identifiers, file references, and the proposed fix.
Challenges I faced
One of the biggest challenges was separating different token measurements correctly.
Paritok reports the context it actually compresses, while the model provider reports the complete final prompt. These numbers answer different questions, so LensOpsAI displays both instead of presenting them as the same metric.
Another challenge was preventing concurrent evaluations. Paritok's statistics counters are cumulative, so overlapping runs could corrupt the before-and-after measurement. The real evaluation therefore runs one request at a time and includes rate limiting.
I also had to keep simulated interface features clearly separated from measured results. LensOpsAI labels preview and simulated data explicitly and does not mix it into real-run analytics.
Accomplishments that I am proud of
- Integrated Paritok into a genuine LLM debugging workflow.
- Measured a real 47.7% reduction in Paritok-processable context.
- Preserved 100/100 quality in the verified Safe run.
- Built a deterministic quality gate rather than using another LLM as the judge.
- Detected and preserved a real compression regression instead of hiding it.
- Separated provider-level savings from Paritok-level savings.
- Deployed the Next.js application and private Paritok proxy in one Docker container.
- Added sample reports so judges can inspect results without running the application.
What I learned
I learned that token optimization should not be evaluated using compression percentage alone.
A smaller prompt is useful only when it still contains the information required for the task. Measuring quality, evidence retention, and functional correctness alongside token savings gives developers a safer way to adopt context compression.
I also learned the importance of distinguishing provider token accounting from middleware compression accounting and of clearly labelling measured, local, preview, and simulated data.
What's next for LensOpsAI
The next stage is to expand LensOpsAI from one fixed real debugging evaluation into a broader compression-testing platform.
Planned improvements include:
- more real developer-task fixtures;
- automated policy comparison;
- repository and CI integrations;
- exportable optimization reports;
- custom evaluation backends;
- persistent team-level run history;
- a verified multi-step debugging agent.
The long-term goal is for LensOpsAI to become a quality-control layer that teams can use before enabling context compression in production AI agents.
Built with Paritok
LensOpsAI was built with Paritok for real hosted-GPU context compression.
Log in or sign up for Devpost to join the conversation.