DEV Community: Nayim Imrit

Using MonkeyCode 30M Free Tokens and Asked It to Build Tic-Tac-Toe — Here's What Happened

Nayim Imrit — Sun, 30 Aug 2026 12:33:53 +0000

I tested MonkeyCode with its daily free token quota and DeepSeek-V4-Flash by giving it a complete front-end development task, then asked it to publish the result to GitHub.

What happens when you give an AI coding agent a fairly detailed software specification and let it actually build the project instead of just generating snippets?

I decided to find out.

For this experiment, I used MonkeyCode with DeepSeek-V4-Flash and its roughly 30M-free-token daily quota available in my account.

My goal was deliberately simple:

Build a complete Tic-Tac-Toe web application from scratch, make it functional, preview it, and then push the finished project to GitHub.

The interesting part wasn't the game itself.

It was watching how much work the agent could perform autonomously — from creating files and implementing the UI to testing the application and eventually publishing the project to my GitHub repository.

The experiment

I wanted to test MonkeyCode with something slightly more demanding than:

"Create a Tic-Tac-Toe game."

Instead, I gave it an actual development specification.

The requirements included:

Vanilla HTML
CSS
Modern JavaScript
No frameworks
No npm dependencies
Responsive design
Dark/light mode
Player vs Player
Player vs AI
Easy AI
Unbeatable Minimax AI
Undo functionality
Win detection
Draw detection
Persistent scoreboard
localStorage
Animations
Complete README documentation

And I explicitly asked it to create:

index.html
styles.css
script.js
README.md

The application also needed to work directly in a browser without a build process.

That made it a nice little benchmark for an AI coding agent.

The prompt

This is the exact prompt I used.

Act as a front-end web developer. Create a lightweight, single-page Tic-Tac-Toe web application using ONLY vanilla HTML, CSS, and modern JavaScript, and update the project's README.md file.

### Technical Guidelines & Rules
1. Tech Stack Constraints:
   - Use standard HTML5, CSS3, and modern Vanilla ES6+ JavaScript.
   - NO external frameworks (React, Next.js, Vue, Tailwind, etc.).
   - Keep it zero-dependency: output files must run directly in a standard web browser without build tools or npm dependencies.

2. File Structure:
   - index.html — Clean, semantic structure.
   - styles.css — Responsive design using Flexbox/Grid, CSS custom variables (for themes), smooth transitions, and a clean modern aesthetic (dark theme default).
   - script.js — Modular, cleanly formatted JavaScript handling game state, UI rendering, event listeners, and AI logic.
   - README.md — Complete documentation.

3. Core Gameplay & Features:
   - Game Modes:
     - Player vs. Player (Local 2-player)
     - Player vs. AI (Include a toggle for Easy AI vs. Unbeatable Minimax AI).
   - Game Mechanics:
     - Interactive 3x3 grid with hover indicators and clear click feedback.
     - Turn indicator display showing active player (X or O).
     - Move History / Undo last move functionality.
     - Automatic win detection with a visual highlight/line on winning cells.
     - Draw detection.
     - Scoreboard (X Wins, O Wins, Ties) persisted in browser localStorage.
     - Reset Board button & Clear Scoreboard button.
   - UI Polish:
     - Light/Dark mode toggle switch.
     - Smooth animations for marking X and O.

4. Documentation Requirement:
   - Create or completely update README.md in the project root containing:
     - Overview
     - Features
     - File Structure
     - How to Run
     - AI Logic Explained
     - Brief explanation of the Minimax decision algorithm.

Generate all files (index.html, styles.css, script.js, and README.md) with fully functional, clean, and well-commented code.

I intentionally made the prompt detailed.

I wanted to see whether the agent could follow a specification rather than simply produce something that looked like a Tic-Tac-Toe game.

What MonkeyCode did

After submitting the task, MonkeyCode started working through the requirements.

The workflow was interesting because it wasn't just one giant response containing four code blocks.

The agent went through individual tasks and file operations.

It started by planning the implementation and then created the project files.

Here it is in action:

Notice how the interface exposes individual steps as they execute: planning first, then each file in sequence, then running a preview. That stepped visibility is one of the things that makes an agent feel meaningfully different from a chatbot.

The workflow looked roughly like this:

Task
 ↓
Planning
 ↓
Create index.html
 ↓
Create styles.css
 ↓
Create script.js
 ↓
Create/update README.md
 ↓
Run / preview application
 ↓
Inspect result
 ↓
Publish to GitHub

You're not simply asking:

"Give me the code."

You're effectively delegating a development task.

The generated application

The result was a complete zero-dependency Tic-Tac-Toe application.

The repository contains:

tik-tak-toe_monkeyCode/
│
├── index.html
├── styles.css
├── script.js
├── README.md
└── LICENSE

The generated README documented the Minimax implementation and the different game modes.

The GitHub repository is publicly available here:

https://github.com/Nayim-Imrit/tik-tak-toe_monkeyCode

(Note: the repo slug uses "tik-tak-toe" — that's intentional, not a typo.)

And yes, the game actually worked

This was the most important part of the test.

The generated application wasn't just visually complete.

I could actually run it in the browser.

The preview worked, and the core functionality was there:

2-player mode
AI mode
Easy AI
Minimax AI
Score tracking
Undo
Reset
Dark/light theme
Persistent scores
Responsive interface

For a task that started with one natural-language instruction, that was a pretty good result.

The token consumption surprised me

This is where the experiment became more interesting.

The platform gave me approximately 30 million free tokens per day.

And I decided to actually use them.

You can see the live quota counter in the GIF above — at the point I captured it, the interface showed:

Daily quota: ~30M

By the time the full task completed — application created, previewed, and pushed to GitHub — the quota had dropped to approximately 27M, meaning the entire workflow consumed roughly 3 million tokens.

That sounds enormous for a Tic-Tac-Toe game.

And honestly, it is.

But there's an important distinction.

The token usage isn't simply:

My prompt → 3M tokens → Tic-Tac-Toe

An agent performing software-development work can repeatedly interact with its environment:

Read
 ↓
Think
 ↓
Edit
 ↓
Inspect
 ↓
Run
 ↓
Check
 ↓
Fix
 ↓
Repeat

Every one of those interactions can contribute to the total context and token consumption.

That's fundamentally different from asking a normal chatbot to generate four files once.

3 million tokens for a small project is still a lot. A more efficient agent should minimize unnecessary file re-reads, avoid redundant context and reduce iterations. This is something I'll be tracking closely in future experiments — token efficiency matters as much as output quality.

The GitHub test

After the application was working, I gave MonkeyCode another task:

Push the project to my GitHub repository.

The target repository was:

Nayim-Imrit/tik-tak-toe_monkeyCode

The agent handled the repository workflow and the finished project ended up on GitHub.

This was an important part of my test.

Generating code is one thing.

Getting an agent to work with an actual development environment and source-control workflow is another.

Why this feels different from ChatGPT generating code

This experiment made me think about the difference between an AI assistant and an AI coding agent.

A traditional coding assistant might do something like:

Developer
   ↓
Ask for code
   ↓
AI generates code
   ↓
Developer copies code
   ↓
Developer creates files
   ↓
Developer runs application
   ↓
Developer fixes errors
   ↓
Developer commits

An agent can potentially move more of that workflow into the AI environment:

Developer
   ↓
Specification
   ↓
AI Agent
   ├── Creates files
   ├── Edits files
   ├── Runs commands
   ├── Checks results
   ├── Iterates
   └── Publishes changes

That's the real thing I wanted to test.

Not:

"Can AI write JavaScript?"

We already know it can.

The more interesting question is:

How much of the development workflow can an AI agent actually execute for you?

DeepSeek-V4-Flash is an interesting model for this

The timing of this experiment was also interesting because DeepSeek-V4-Flash had recently been released.

DeepSeek describes V4-Flash as the faster, more cost-efficient member of the V4 family, built with a strong focus on agentic tasks — meaning it's designed for exactly this kind of multi-step, tool-using workflow rather than single-turn generation. In practice, that showed up in the planning phase: rather than immediately generating code, it broke the task down into discrete file operations first.

That's why I wanted to run an actual task instead of just reading the benchmark numbers.

My test wasn't a benchmark

I want to make this distinction very clear.

This wasn't a scientific comparison between:

DeepSeek
Claude
GPT
Gemini
GLM

I wasn't measuring:

tokens per second
latency
benchmark scores
coding accuracy across 100 repositories
cost per accepted pull request

It was a practical experiment:

Give an AI coding agent a realistic specification and see what happens.

And for that particular task, the result was surprisingly good.

What I liked

The agent understood a detailed specification

The prompt contained a lot of requirements.

It wasn't just:

"Make Tic-Tac-Toe."

It specified architecture, technology restrictions, features, documentation and AI behavior.

The generated repository followed those requirements reasonably well.

Zero-dependency development worked well

I deliberately prohibited:

React
Next.js
Vue
Tailwind
npm
build tools

The result remained:

HTML
CSS
JavaScript

That made the application extremely portable.

You can simply open:

index.html

in a browser.

The Minimax implementation was documented

This was a nice detail.

The README didn't simply say:

"The AI uses Minimax."

It explained the basic idea:

Current board
     ↓
Possible moves
     ↓
Opponent responses
     ↓
Future states
     ↓
Score positions
     ↓
Choose best move

For Tic-Tac-Toe, the game tree is small enough that exhaustive search is perfectly practical.

Token consumption is a real concern

Nearly 3 million tokens for a relatively small application is a lot.

Even though the daily quota is huge, developers should not automatically assume:

More tokens = better result.

Agent efficiency matters.

A better agent should ideally minimize unnecessary context, repeated file reads and redundant iterations.

This is something I've become increasingly interested in: token-efficient AI development workflows.

If an agent repeatedly reads the same files, re-evaluates the same architecture and regenerates context unnecessarily, the cost can grow very quickly.

For production use, this isn't just a curiosity — it's a real cost and performance factor.

The local agent idea is even more interesting

The part that really caught my attention is what happens when you move beyond a browser-based coding environment.

The broader idea is to run an AI development agent locally on your own machine, connect it to tools, repositories and services, and give it controlled permissions.

Conceptually:

                 ┌───────────────┐
                 │   AI Model    │
                 │ DeepSeek/GPT  │
                 │ Claude/GLM... │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
      Filesystem       GitHub          MCP
          │              │              │
          ▼              ▼              ▼
       Laptop         Repositories     Tools

Instead of:

"AI, tell me what command I should run."

You can move toward:

"AI, implement this feature, run the tests, inspect the result and create the commit."

Obviously, this comes with an important warning:

Don't give an autonomous agent unrestricted access to your machine.

Permissions matter.

Credentials matter.

Repository access matters.

Tool integrations can potentially give an agent the ability to do much more than edit a source file.

The principle should always be least privilege.

What about connecting other AI subscriptions?

This is another direction that I find interesting.

Instead of thinking:

"Which AI coding tool should I use?"

we can start thinking:

"Which model should handle which task?"

For example:

Simple coding task
        ↓
DeepSeek V4-Flash

Complex reasoning
        ↓
GPT / Claude

Large refactoring
        ↓
Another specialized model

Local/private task
        ↓
Local open-weight model

This creates the possibility of treating AI models almost like interchangeable compute providers.

The agent becomes the orchestration layer.

The model becomes the engine.

That separation is potentially much more interesting than simply choosing one AI subscription and using it for everything.

So, is MonkeyCode worth trying?

Based on this experiment:

Yes — if you're interested in AI agents rather than just AI chat.

The Tic-Tac-Toe project isn't impressive because Tic-Tac-Toe is difficult.

It's interesting because I gave the system a specification and it was able to turn that specification into:

Requirements
     ↓
Implementation
     ↓
Files
     ↓
Working application
     ↓
Documentation
     ↓
Git repository

with very little manual intervention from me.

That's the direction AI-assisted development is moving toward.

But there's still a long way to go

I wouldn't use this one experiment to conclude that AI coding agents can replace developers.

They can't.

At least, that's not what this test demonstrates.

The developer is still responsible for:

Defining the requirements
Reviewing the generated code
Validating behavior
Checking security
Reviewing dependencies
Managing credentials
Controlling permissions
Testing edge cases
Reviewing Git changes
Deciding whether the solution is actually production-ready

The agent can execute.

The developer still needs to judge.

And that distinction is important.

Final thoughts

My first MonkeyCode experiment was intentionally small.

A Tic-Tac-Toe game.

Four main files.

Vanilla JavaScript.

No backend.

No database.

No external APIs.

Yet the agent was able to take the specification, implement the application, provide a working preview and eventually get the project into GitHub.

The most interesting number wasn't actually the 30M token quota.

It was the fact that an AI agent consumed roughly 3 million tokens of that budget while doing real development work — planning, creating, iterating, previewing, committing.

That raises a much more interesting question for my next experiment:

What happens when I give the same agent a real full-stack application?

Something with:

Next.js
PostgreSQL
Authentication
APIs
Database migrations
Tests
Docker
GitHub
CI/CD

And then measure:

How many tokens does it take?

How many iterations does it need?

How much code does it generate?

How much of the work actually needs human intervention?

That's a much more interesting benchmark.

The project

GitHub: https://github.com/Nayim-Imrit/tik-tak-toe_monkeyCode

The repository contains the generated HTML, CSS, JavaScript and README documentation.

What should I test next?

I'm thinking of taking this experiment much further.

Instead of Tic-Tac-Toe, give an AI coding agent a real full-stack application and track the entire process.
If you'd like to see that experiment, let me know what kind of application I should throw at it. 🚀

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.