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

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. 🚀