DEV Community: Nayim Imrit

How I Cut LLM Token Usage with OKF, CLAUDE.md, and Skills

Nayim Imrit — Sun, 16 Aug 2026 06:35:00 +0000

Every time you ask an AI coding assistant a question, it often starts from scratch.

"Where is authentication implemented?"

"Who calls UserService?"

"How does this API flow work?"

Instead of remembering your architecture, the model crawls dozens of files again. That means more tokens, higher cost, slower responses, and more opportunities for hallucinations.

After experimenting with AI-assisted development, I found that the biggest optimization isn't choosing a different model --- it's changing what you send to the model.

This article covers a layered workflow for making AI agents dramatically more efficient using OKF, persistent project memory, on-demand skills, and token compression.

Why token optimization matters

LLMs don't read code the way humans do. Everything becomes tokens processed through transformer layers.

Every unnecessary file, log, or repeated explanation increases:

💰 Cost (for paid APIs)
⏱️ Latency
🧠 Context window usage
❌ Risk of losing important information

The goal isn't to provide less context. It's to provide better structured context.

Layer 1: Replace raw code with structured knowledge

The biggest improvement comes from avoiding repeated file reads entirely.

Instead of feeding an LLM your repository every session, generate a knowledge bundle once and let the agent query that instead. This is the core idea behind OKF (Optimised Knowledge Format). It extracts your project's architecture --- classes, functions, APIs, relationships, and modules --- into structured Markdown that both humans and AI agents can navigate efficiently.

Traditional workflow:

Question
│
▼
Read 40 files
│
▼
Understand architecture
│
▼
Answer

OKF workflow:

Question
│
▼
Read knowledge bundle
│
▼
Jump directly to implementation
│
▼
Answer

The difference is simple:

Without OKF	With OKF
Re-reads source files	Queries structured concepts
Large token usage	Small, focused context
Slower reasoning	Faster navigation
Architecture rediscovered every session	Architecture indexed once

Meet OKF Generator

The easiest way to generate these knowledge bundles is with OKF Generator, an open-source CLI that scans a repository and produces an OKF bundle using static analysis --- no LLM required. It supports incremental updates, agent integrations, and even a zero-LLM workflow where you can generate and query bundles entirely offline.

GitHub: https://github.com/UmairBaig8/okf-generator

Getting started:

pip install okf-generator

# Generate your first bundle
okf generate

# Update it after new changes
okf update

# Install integrations for AI agents
okf install all

Once generated, point your agent to the bundle instead of your entire repository. The bundle is plain Markdown, version-controllable, and designed to live alongside your source code.

Not Just Claude: OKF Works With Any Agent

OKF goes beyond token optimization. When onboarding developers to a large codebase, you can give any LLM the generated okf_bundle and ask it to explain the project, identify key components and their relationships, and generate a Mermaid diagram.

This provides a quick, high-level overview of the codebase and can significantly reduce onboarding time.

For this example, using a local LLM(gpt-oss20b), I asked it to analyze C:\Code\uigen\okf_bundle and generate a Mermaid diagram with an explanation of the project's key components and how they interact.

All the components, explanations, and web flow were generated in less than 2 minutes.

Layer 2: Give your project a memory (CLAUDE.md)

Most developers repeatedly explain the same things:

How to run the project
Coding conventions
Folder structure
Architectural decisions

That information belongs in CLAUDE.md, a persistent Markdown file automatically loaded at the beginning of every session. It eliminates repeated briefings and keeps foundational project knowledge available without bloating every prompt.

A good CLAUDE.md contains:

# Project Rules

- Use pnpm instead of npm

This project has an OKF knowledge bundle at ./okf_bundle/.
- Use `okf lookup <Name>` for full concept context.
- Use `okf lookup --type <Type>` to filter by type.
- Read `SUMMARY.md` for the full knowledge map.

Instead of repeating these instructions across conversations, they're loaded automatically.

File locations:

# Project-level
./CLAUDE.md
./.claude/CLAUDE.md
# User-level
~/.claude/CLAUDE.md

Layer 3: Load knowledge only when needed (Skills)

Not everything deserves permanent context.

Deployment guides, review checklists, compliance docs, and long API references are better stored as Skills. Skills are reusable SKILL.md files that stay out of the main context until the task requires them, keeping the default prompt lean while still making detailed workflows instantly available.

Good examples include:

/deploy
/release
/review
/database-migration

Your default context stays small, but expertise is always one command away.

File locations:

.claude/skills/<name>/SKILL.md
# or
~/.claude/skills/<name>/SKILL.md

Layer 4: Automate consistency with Hooks

Hooks aren't about saving tokens directly. They're about preventing expensive mistakes.

Examples:

Auto-format after every edit
Block dangerous shell commands
Notify you when an agent finishes
Run linting automatically

Since hooks fire at predefined lifecycle events, they remove repetitive instructions from your prompts entirely.

File locations:

.claude/settings.json
# or
~/.claude/settings.json

Keep your knowledge bundle up to date

A stale architecture is almost as bad as no architecture.

You can regenerate your OKF bundle automatically using GitHub Actions whenever someone pushes to main or opens a pull request. The workflow keeps your AI context synchronized with your codebase and can even generate impact summaries for reviews.

name: OKF Bundle

on:
  push:
    branches: [main]

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install okf-generator
      - run: okf generate . okf_bundle

Now your AI always understands the latest architecture.

Reduce output tokens too

Optimizing input is only half the story.

Two complementary tools solve different problems:

Tool	Optimizes
OKF	What the model reads
caveman	What the model writes
rtk	Terminal and tool output

If your context is filled with git diff, build logs, or test output, rtk trims that before it ever reaches the model. If your assistant tends to produce verbose explanations, caveman keeps responses concise. Together they reduce both sides of the token equation.

The complete token-efficient workflow

Each layer removes a different source of waste:

Layer	What it eliminates
OKF	Re-reading source files
CLAUDE.md	Repeating project briefings
Skills	Loading reference docs unnecessarily
Hooks	Repeating operational instructions
caveman / rtk	Verbose output and noisy logs

Final thoughts

The future of AI development isn't about endlessly increasing context windows. It's about making context intentional.

A well-structured repository gives AI assistants the same advantage it gives human developers: they spend less time searching and more time solving problems.

If you're already using Claude Code, Cursor, Copilot, or another AI coding assistant, try generating an OKF bundle for your next project. You'll probably notice the difference long before you notice the token savings.

Resources

If you've been experimenting with token optimization or AI developer workflows, I'd love to hear what's working for you in the comments.

Testing 3 Local LLMs on a CPU-Only Laptop — Here's What Actually Happened

Nayim Imrit — Wed, 05 Aug 2026 08:29:51 +0000

As developers, we keep hearing that powerful LLMs require expensive GPUs. I wanted to find out how far local AI could actually go on a modest machine — no cloud, no cost, no GPU.

So I ran a practical experiment using LM Studio on a 40 GB RAM laptop without a dedicated GPU, pitting three open-weight models against each other on a real coding task.

Test Environment

Hardware

Standard laptop
40 GB RAM
No dedicated GPU (CPU inference only)

Software

LM Studio (context length: 8192 tokens)
VS Code
100% local inference — no API calls, no internet required

Models tested

Qwen 3 14B
GPT-OSS 20B
Gemma 4 26B A4B QAT

The Experiment

Each model received the exact same prompt: generate a complete Snake Game using only HTML, CSS, and JavaScript — no frameworks, no external libraries.

I evaluated each result on:

⏱ Generation time
🪙 Token usage
🎨 Quality of the generated UI
🔧 Whether manual corrections were needed
🧑‍💻 Overall developer experience

Results

🟡 Qwen 3 14B

Generation took approximately 9 minutes and produced 3 separate files (HTML, CSS, JS).

After testing, the snake moved too fast. I had to send a follow-up prompt, which triggered another full 9-minute generation cycle — and only around five lines of code actually changed.

Pros

Functional game on the second attempt
Game instructions included
Low token usage (~651)

Cons

Slow generation
Required a second iteration to fix gameplay speed
Basic UI

🟢 GPT-OSS 20B

This was the biggest surprise of the experiment.

Generation completed in approximately 3 minutes, producing a single self-contained HTML file with all HTML, CSS, and JS included. Token usage clocked in at ~51 — significantly lower than the other models (worth noting: token counting may differ across models, so treat this as directional rather than a strict apples-to-apples comparison).

Unlike Qwen, the game worked correctly on the first attempt.

Pros

Fastest generation by far
Lowest token usage
No code changes required
Score displayed during gameplay
Instructions included

Cons

UI is functional but not the most polished

🔵 Gemma 4 26B A4B QAT

Gemma required some extra setup before running correctly — specifically, adding capability entries in LM Studio's model configuration. If you're not comfortable editing model configs, budget a few extra minutes here.

Generation took approximately 8 minutes and produced 3 files (HTML, CSS, JS).

The output was noticeably more polished visually than the other two models.

Pros

Best-looking interface of the three
Well-structured project output
Instructions included

Cons

Highest token usage (~2170)
Slower than GPT-OSS
Requires extra LM Studio configuration

Comparison Table

Model	Time	Files	Tokens	UI Quality	Needed Changes
GPT-OSS 20B	~3 min	1	~51	Good	❌ No
Gemma 4 26B	~8 min	3	~2170	⭐ Best	❌ No
Qwen 3 14B	~9 min	3	~651	Basic	✅ Yes

Key Observations

A few patterns stood out:

GPT-OSS prioritised efficiency — working code, fast, no fuss.
Gemma prioritised presentation — the cleanest interface, though it needs configuration upfront.
Qwen produced functional code but needed a second pass to be usable.
All three models completed a real coding task without touching the cloud.

Conclusion

For my workflow, GPT-OSS was the clear winner.

Gemma produced the most polished result, but GPT-OSS delivered the best overall developer experience:

✅ Fastest generation time

✅ Lowest token consumption

✅ Working solution on the first attempt

✅ Zero additional configuration

✅ Single-file output — easy to review and ship

On CPU-only hardware, these differences compound quickly. Waiting 3 minutes instead of 9 — and skipping multiple iterations — makes a real difference to your flow.

More broadly, this experiment shows how capable modern open-weight models have become. Even on a mid-range laptop with no GPU, you can generate complete applications locally, maintain full privacy, and avoid cloud inference costs entirely.

If you've tested local models on constrained hardware, I'd love to hear what you found — drop a comment below. 👇

Tested with LM Studio on a 40 GB RAM, CPU-only laptop. Models: GPT-OSS 20B, Qwen 3 14B, Gemma 4 26B A4B QAT.

Building a PHP Wedding Planner with Omniroute: My First Experience

Nayim Imrit — Sun, 26 Jul 2026 10:16:36 +0000

I tested an AI coding agent with a real university project spec — here's exactly what happened, token by token.

Artificial Intelligence is rapidly changing how we build software. Instead of spending hours scaffolding projects or writing repetitive boilerplate code, AI coding agents are now capable of planning, generating, and even refining applications with minimal input.

Recently, I had the opportunity to test Omniroute while helping a friend with her final-year university project. She already had a detailed project specification and needed a working PHP template to kick-start her development. Since I had never worked with Twig templating before, I decided this would be the perfect opportunity to see how far an AI-assisted development workflow could go.

This article shares my experience — from setting up Omniroute to generating a complete project and evaluating the results.

🛠️ Setting Up Omniroute

I already had an old Claude API key with approximately $0.20 of credit remaining, so I decided to use it for this experiment.

To install and configure Omniroute, I followed this setup tutorial:

After following the installation steps, my directory structure looked like this:

⚙️ Improving the AI's Coding Standards

One feature I particularly liked was Omniroute's ability to customise the AI's behaviour through the .agent configuration file.

I configured Claude with modern development guidance so that it would generate code following current best practices instead of relying on outdated programming patterns.

I used the following guide as inspiration:

🔗 How to Stop Your AI Coding Agent from Writing Outdated Code with Modern Web Guidance

Tip: Although this step is optional, I would highly recommend it. Small improvements to the agent's instructions can significantly improve the quality and consistency of the generated code.

📋 Preparing the Project

My friend had already written all of the project requirements, including both the functional and non-functional specifications.

I created a new project folder called wedmauritius inside my XAMPP htdocs directory and copied her requirements into a file named:

newProjectRequirement.txt

Once everything was ready, I simply asked Claude whether it could access and understand the requirements document.

Instead of immediately generating code, Omniroute analysed the project and asked whether I wanted it to create a development plan before executing the implementation.

I found this particularly impressive because it approached the project much like an experienced software developer would — understanding the requirements first before writing any code.

🚀 Generating the Application

After confirming the execution plan, Omniroute began building the project automatically.

The development process required very little manual intervention. It generated the project structure, organised the files appropriately, and implemented the requested functionality based on the specification document.

The final project directory looked like this:

📊 Omniroute Dashboard

When Omniroute starts, it automatically launches its web dashboard. From here you can:

Monitor development sessions
Configure quotas
Review usage statistics
Manage other application settings

⚠️ Security note: The default login password is CHANGEME. If you're installing Omniroute for the first time, remember to change this before using it regularly.

✅ The Results

Overall, I was pleasantly surprised by the quality of the generated application.

Metric	Value
Total tokens consumed	~250,800
Additional API cost	~$0.50
Manual interventions needed	1 (CSS fix)
Output quality	Production-ready starting point

Rather than producing a rough prototype, Omniroute generated a solid starting point that my friend could immediately continue developing. For anyone beginning a university project or building an internal prototype, this can save many hours of initial setup work.

🔢 Token Usage

One of the more interesting parts of this experiment was the token consumption.

Although my Claude account had virtually no remaining credit, Omniroute continued the development using available free-tier endpoints to complete the project.

An additional $0.50 worth of tokens was consumed during the process — remarkably cost-effective for what was generated.

🧪 Testing the Generated Website

Once the project had been generated, I tested the application manually. Overall, everything worked remarkably well.

The only issue I noticed was a small CSS problem — the navigation bar was not remaining sticky while scrolling.

Rather than fixing it manually, I simply opened another Omniroute session and asked Claude to correct the issue. It did so without any fuss, which demonstrates one of the biggest advantages of AI-assisted development: rapid iteration.

💭 Final Thoughts

This was my first real project using Omniroute, and I came away genuinely impressed.

What stood out most wasn't just its ability to generate code — it was the workflow. Omniroute analysed the requirements, proposed a development plan, and then executed that plan with very little guidance. That makes it feel less like an autocomplete tool and more like collaborating with a junior developer who can rapidly scaffold an application.

Of course, AI-generated applications still require testing, code review, and refinement. Minor issues — such as the CSS bug I encountered — are to be expected. However, those are small trade-offs considering the amount of time saved during the initial development phase.

If you're looking for a way to bootstrap small PHP applications, university projects, proof-of-concepts, or internal tools, Omniroute is worth exploring.

I don't see it replacing software developers anytime soon — but it certainly makes them significantly more productive.

Have you tried Omniroute or a similar AI coding agent? I'd love to hear about your experience in the comments below.