The Art of Browser Vibe Coding

Software engineering as a role is evolving yet again. Computer instructions are processed in binary and have gotten increasingly human readable through out the years with assembly language, C, and then finally python. In 2022, LLMs have entered into the tech world allowing us to generate code from natural language. This is the idea of vibe coding. A powerful tool that allows people without years of development experience to whip up functional products at a small scale. Emphasis on the scale. Because all though anyone can use codex or claude code, it takes someone experienced to make good choices on architecture and technical decisions. A naive user may make a static website using only one html file that just grows with each prompt. Although that works, an experienced developer understands that long term you need a tech stack and database for dynamic pages. With proper prompting, vibe coding is incredibly fast to develop. It just might cost you money or grow your code base at an ungodly rate. To really understand how to compete against this new wave of developers you need to know about tokens.

Edited: Here is my repo and chrome store link.

Tokens

Most users treat LLMs as a black box. You ask it a question and then it magically returns an accurate response. What happens behind the scenes is something called a transformer, first introduced in this paper by Google: Attention Is All You Need. Basically, every prompt you send is turned to a list of numbers that the neural network can understand. Then every response starts as a list of numbers that is then converted to words so you can understand. This switch from words to numbers is called encoding and decoding. More importantly, the numbers that make up the list are called tokens. Analogous to auto correct, a nueral network takes these tokens as input and produces a trailing token prediction as a result. Then that number is converted back to words. Viola! Then you know how many r’s are in the word strrawberry.

The spliting up of your prompt into tokens is really important here. Not because of any computer science theory or math, only nerds like me really care about that. Everyone should care about tokens because the cost of vibe coding is directly related to how many tokens you use. So how does that all work? I’ll go into it below, but for more information here’s a really good hugging face tutorial.

Types of Tokenization

Word based tokens is the most simple form. A sentence is given over and each word gets its own number or id. The issue with this is every word needs its own id, which takes up a lot of space. Whats worse is an unkown word confuses the AI model making it a fragile system. The main reason for this is that the id’s arent relational. The word “dog” and “dogs” have no inherent relationship when the neural network sees them.

Character tokenization combats this, now we split the sentence into characters. There are much less id’s now (around 256). There are also almost no unknown tokens since all words are made up of a finite list of characters. The only issue is that they are less meaningful because a character tells you less than a word does.

A happy medium between the two is called sub-word tokenization. This method is a little more complex, but works a whole lot better. Common words get an id, but any rare word gets broken up into multiple tokens. An algorithm is built to figure out how words are broken up based on rarity. This method is best because we can keep the relationships and drop the amount of id’s. ChatGPT uses a sub word tokenization technique called Byte Pair Encoding (BPE).

Optimizing Token Usage

At the moment, Claude Code is the king of AI development. So lets dive into their pricing. Most of the price plans depend on a usage cap which is a combination of how many tokens you send/recieve, which model you use, and the time of day.

• Free plan — Limited usage, not viable for coding.
• Pro plan — Starts at a flat fee of 20 dollars. You have a decent bit of usage on the browser with no exact token count.
• Max 5x — Costs 100 dollars a month with 5x the usage of pro plan.
• Max 20x — Costs 200 dollars a month with 20x the usage of pro plan.
• API — Input and output tokens charge you money when you go past the usage provided in the plans above. For example, Claude Opus 4.8 charges $5 / MTok and $25 / MTok. This adds up quickly.

The advantage of max plan is that more more Claude code prompts can be sent, but at the cost of more money. The reason people pay for max is because Claude code takes over and can open files or run commands all on its own. On paper, that’s cool and all, but for larger scale projects you loose out on understanding why it does things. Most importantly you lose track of functions no longer needed in the codebase which wastes space and adds unneeded complexity to your project. Using Claude on the browser is my personal choice. This method forces you to understand the codebase. You can’t throw the whole project in because providing too much information throws a context limit error. Intentionally limiting context and not intelligence makes vibe coding more beneficial.

Optimization

I tried for this project to include cave man mode to limit the output token usage. If you don’t know, caveman mode is basically a markdown file used to limit Claude codes output token usage by forcing it to talk in three words sentences. So you ask Claude to build me a file and it will respond “Starting to code. Me make file”. There is some controversy because it’s hard to evaluate the accuracy. Either way the pro plan users can’t enjoy this feature on the browser. I tried to add an instruction file for a project on claude, but caveman mode was usually forgotten by the model after one response. This was simplified markdown file I tried out:

Terse like caveman. Technical substance exact. Only fluff die.
Drop: articles, filler (just/really/basically), pleasantries, hedging.
Fragments OK. Short synonyms. Code unchanged.
Pattern: [thing] [action] [reason]. [next step].
ACTIVE EVERY RESPONSE.

You can create a Project on the browser and give it custom instructions that persist across every conversation in that group. This is the closest thing to CLAUDE.md in the browser. I would be interested to see if anyone got this to work.

Another classic strat is to use certain models based on the complexity of the task. Each model has it’s specialties. Sonnet is worse at reasoning, but costs less to use. Opus burns through your usage as its a heavier model, but is more intelligent and may be able to solve a problem when you hit a wall with Sonnet. So the general strat I use is to use Sonnet for planning and small coding tasks. When things aren’t working out, try out opus to bypass the issue. Then if that still doesn’t work, roll up the sleeves and figure it out manually.

Similarly, we want to be smart about how we prompt. A naive vibe coder would just throw their whole code base into an LLM and say to fix some issue. Often times a problem is isolated to a certain file. A more experienced developer only provides information that is needed for the task. This heavily limits token usage. Also create new conversations when prompts veer off the original message. Continuing a conversation compounds token usage because past prompts are used as context.

Token Watcher v1.0

I’ve been using Claude pro plan and paying 20 dollars a month for it. A small price to pay to keep up with the development speed of all the AI usage right now. The vibe coding meta has changed the game. Many people are trying out coding agents like cursor, codex, or the fan favorite of Claude code. But it also hits peoples pockets hard. Just take a look at this website that ranks developers based on the amount of tokens used paired with the money they spent to make it happen. The top developer has spent 56k dollars in tokens at the time of writing this. These numbers are hit through the use of API’s and claude code. I stick to the pro plan on the browser. Instead of losing track of my costs, it has a flat fee with a usage limit.

To get the most of my money, I want to use as many tokens as possible and basically max out my usage. Then that got me thinking. How many tokens can I use? So, I built a token analysis chrome extension that lets me track my weekly usage on the browser. This is as easy as parsing a json in the api version, but I am cheap and only use the browser.

Here is the file structure for the project.

manifest.json
├── background.js # Service worker: download interception + WASM tokenizer host
├── tokenizer.js # tiktoken WASM wrapper (countTokens export)
├── config.js # Per-site XPath/CSS selectors + active config resolver
├── content.js # Page scraper: orchestrates all four counting passes
├── supported_browsers/
│ ├── files_claude.js # Claude-specific input/output file handling
│ ├── files_chatgpt.js # ChatGPT-specific file handling
│ ├── files_gemini.js # Gemini-specific file handling
│ └── files_deepseek.js# DeepSeek-specific file handling
├── sidepanel.html # UI (shared markup)
├── sidepanel.css # Dark instrument-panel theme with per-site accent vars
├── sidepanel.js # UI logic: scan, count, progress, project storage
└── vendor/
├── tiktoken-lite/ # WASM tokenizer + encoder JSON files
└── jszip/ # JSZip (lazy-loaded for .zip extraction)

I’ll explain the project a bit, but check out the repo if you want to understand it more.

Most chatbots have the same structure based on the classic ChatGPT design with a few caveats. I wanted to collect the tokens used for coding with them so I broke the design into prompts, responses, and files. For example, I may ask a question about a file which claude gives a response for with a corrected file. My solution needs to handle all those different forms of text.

There are two ways I do this. One is a classic xpath that locates a html element and scrapes the text from them. That’s used to grab the prompt bubble or the output response. These methods are susceptible to breaking if the structure of the page changes. The best way I thought to combat this was setting global variables that can be changed in the future if needed. The second way of counting tokens is dealing with text from input or output files. My solution located the download button with an xpath and clicked it. The download is intercepted, the text inside is processed, and then quickly deletes the files before it saves to your computer. Zip files had caused an issue because they were treated as text which made the token count skyrocket. Those are now handled separately so that the intercepted download is extracted and then processed.

After all of the text is processed, I combine all the words pulled from the site. Some people enjoy exporting the files to save into planning applications like notion or obsidian. I made an option to do that. More importantly, I can run the text through tiktoken, an open source BPE tokenizer that was made for GPT-2. I originally found this via Peter Steinberger’s blog, the creator of OpenClaw. Tiktoken then creates an estimate of the token count for each conversation. Precision isn’t too important because I only want a general idea of how much I use on a weekly basis. Also, only text is processed so images or diagrams don’t have any impact on the total count.

The fun part comes from being able to save your conversation token counts. At the end of a coding session, my LLM usage can be broken down by models and number of tokens. Future projects will show me which models helped me the most or what strategies worked out the best. Finally, I can count the amount of tokens I spend in a week and aim to max out my claude usage to make the most out of my money!

Conclusion

I used a tokenizer github repo to track tokens on Claude and other LLM browser tools. Over the week I want to see how much I can get out of the pro plan. I want to push it to its limits! Top tier LLMs cost a lot of money so the goal is to limit token usage and keep costs down or else I may be forced to move to Ollama versions. They cost less money, but the tradeoff is they aren’t as intelligent unless you have a mac mini for ten thousand dollars. In the end, its about finding what works for you best. I never liked the idea of an LLM making files for me and having agents do sub tasks without my oversight. People are starting to run them overnight or walk around with their computer open. The browser method lets me take advantage of generating code without losing grasp of the project as a whole. I am still making the decisions of the architecture and algorithms to solve a problem. Side projects are inherently on a time crunch. They are on the side. Coding with LLMs helps speed up the hand writing code process and makes developing faster than ever!