handyai.tools

A token counter is a tool that splits a piece of text into the tokens an LLM actually processes and reports how many there are, usually alongside the model's context window and a per-call cost estimate. Use one whenever you need to know whether a prompt, document, or conversation fits a model's context limit or what a call will roughly cost. On HandyAI's LLM Token Counter, you paste text, pick a model, and read token counts and cost estimates side by side for Claude, GPT, and Gemini — all processed in the browser with no sign-up.

Why token counts differ from characters and words

Models don't read characters or words; they read tokens, which are subword chunks produced by each vendor's tokenizer. A common English word is often one token, but punctuation, code, unusual names, and non-English text can split into several. That's why a 1,000-character paragraph is not a fixed number of tokens, and why the same paragraph can count differently under Claude, GPT-4o, and Gemini — each family uses its own tokenizer.

Practical consequence: never estimate cost from character or word counts when accuracy matters. Count tokens with the model you'll actually call.

How to use a token counter

1. Paste your input. Include the full prompt, system instructions, and any documents or conversation history you plan to send — the counter only sees what you give it.
2. Select the target model. The tool shows Claude 3.5 Sonnet (200K context), GPT-4o (128K context), Claude 3 Haiku (200K context), and Gemini 1.5 Flash (1,000K context) side by side, so you can compare the same text across providers.
3. Read the token count and context usage. Check how much of the model's window your input consumes. If you're near the limit, trim history or split the task.
4. Check the per-call cost estimate. The counter shows a cost figure per call for each model, which you can multiply by expected call volume.
5. Verify with the official tokenizer when precision is critical. For billing-sensitive or production work, confirm counts with the provider's own tokenizer library or API usage response.

Comparing models at a glance

The counter's default comparison set, based on the site's listed models:

Context length alone doesn't decide the model — a long-context model may still be the wrong cost trade-off for short prompts, and a cheaper model may be adequate for simple tasks. Use the side-by-side counts to match the model to the job.

Common mistakes to avoid

• Treating words as tokens. Word counts systematically undercount tokens for code, JSON, and multilingual text.
• Counting only the user message. System prompts, few-shot examples, and prior turns all consume context and cost.
• Assuming one count fits all models. Re-count when you switch providers; tokenizers differ.
• Ignoring output tokens. Cost estimates usually cover input; budget for the response length too.
• Pasting sensitive text into unknown tools. HandyAI's counter runs client-side in the browser, which keeps text local — a meaningful advantage over tools that upload your prompt. Still, avoid pasting secrets or private data into any tool you don't control.

When a browser counter is enough — and when it isn't

A client-side counter like HandyAI's is well suited to quick sizing: checking whether a prompt fits, comparing providers, and rough cost planning during development. For production billing, exact quota enforcement, or debugging tokenizer edge cases, use the provider's official tokenizer or read token usage from API responses. The counter is a fast estimate, not a billing source of truth.

For related work, HandyAI also offers a live AI Cost Calculator for projecting monthly API costs across Claude, GPT, and Gemini, and lists upcoming tools such as a JSON Schema → Claude Tool converter and a Claude System Prompt Analyzer.

Claude tools are small, single-purpose utilities that help developers work with Anthropic's Claude models — counting tokens, estimating API cost, converting JSON Schema into a tool-use definition, and auditing prompts. On HandyAI, a set of these tools runs entirely in the browser with no sign-up, and several more (schema conversion, prompt diffing, system prompt analysis) are listed as upcoming. You reach for them when you need a quick, verifiable number or a correctly formatted payload before you send a real request to the Claude API.

The four categories that matter

Claude-specific developer utilities cluster into four jobs. Each answers a different question you'd otherwise answer by trial and error against the API.

The distinction from general LLM tools is scope: a token counter that only handles one model tells you less than one that shows Claude, GPT, and Gemini side by side, because model choice changes both tokenization and price.

Token counting and cost estimation before you send a request

The live token counter on HandyAI is the entry point. You paste text, and it reports characters, words, and token counts for several models at once — the page lists Claude 3.5 Sonnet (200K context), Claude 3 Haiku (200K context), GPT-4o (128K context), and Gemini 1.5 Flash (1,000K context) — with a per-call cost estimate next to each.

The practical workflow:

1. Paste the exact prompt you intend to send, including system instructions and any few-shot examples.
2. Read the token count against the context window shown for your target model. If you're near the limit, trim examples or split the task.
3. Compare the per-call cost across models. A prompt that's cheap on Haiku may be several times the price on Sonnet — the side-by-side view makes that visible before you commit.
4. Multiply by expected call volume to sanity-check the monthly figure, or use the separate AI Cost Calculator, which projects monthly LLM API costs across Claude, GPT, and Gemini.

The reason to do this client-side rather than by calling the API is speed and cost: you get an answer without spending tokens or waiting on a round trip. Treat the numbers as estimates — tokenization details and current per-token pricing should be confirmed against Anthropic's own documentation before you rely on them for a budget.

Converting JSON Schema into an Anthropic tool-use definition

Tool use (function calling) requires you to describe each tool's inputs in a specific shape that Claude expects. If you already have a JSON Schema — from an OpenAPI spec, a validation library, or an internal service — rewriting it by hand into an Anthropic tool definition is mechanical and easy to get subtly wrong.

The JSON Schema → Claude Tool converter is designed for exactly this: paste a JSON Schema, get a ready-to-use Anthropic tool-use definition. As of the site's listing it is marked for Q3 2026 and not yet live; the page offers an email notification and points you to the token counter in the meantime. Until it ships, the manual path is to map your schema's properties, required, and type fields into the tool's input schema and keep descriptions short and specific, since Claude uses them to decide when to call the tool.

Prompt analysis and the tools still coming

The Claude System Prompt Analyzer (listed for Q1 2027) is aimed at the clarity, length, and structure of a system prompt — useful when a prompt is long enough that token cost and instruction-following both suffer. Two other upcoming tools round out the set: a Prompt Diff Tool (Q4 2026) for comparing two prompt versions structurally, and Markdown → Anthropic Messages API (Q4 2026) for turning a pasted conversation into the exact request JSON Claude expects.

If your immediate need is a number — tokens, cost, context headroom — the live token counter and cost calculator cover it today. If your need is a correctly formatted payload for tool use or the Messages API, check whether the converter has shipped; otherwise plan to hand-write the definition and validate it with a test call.

Choosing the right tool for the task

• Checking whether a prompt fits: token counter, compared against the model's context window.
• Deciding between Claude models: token counter's per-call estimates, then the cost calculator for monthly projection.
• Setting up function calling: the JSON Schema converter once available; manual mapping until then.
• Diagnosing a weak or bloated system prompt: the system prompt analyzer once available; otherwise count tokens first and cut length.

All of the live tools described here run in-browser and require no sign-up, which makes them safe for pasting prompt text you'd rather not send to a third-party server — but confirm that client-side claim yourself for anything sensitive, and verify current model names, context limits, and pricing against Anthropic's documentation, since those change independently of any third-party tool.

LLM tools are small, single-purpose utilities that help you build and debug applications on top of large language models. The ones developers reach for most often fall into four groups: token counters, cost calculators, prompt analyzers, and schema converters. HandyAI, for example, lists 10 such tools — token counters, prompt analyzers, schema converters, and cost calculators — described as single-purpose, free, and entirely in-browser, with no sign-up. That combination matters because it tells you what these tools are good for (quick, private, disposable checks) and what they are not (full observability platforms).

The four categories that cover most day-to-day work

Token counting

Token counts decide whether a prompt fits a model's context window and how much a call will cost. HandyAI's Live LLM Token Counter counts tokens for Claude, GPT-4, and Gemini side-by-side with live cost estimates, and shows context sizes such as Claude 3.5 Sonnet at 200K, GPT-4o at 128K, Claude 3 Haiku at 200K, and Gemini 1.5 Flash at 1,000K. Use it before you ship a long system prompt or paste in a large document, so you find the overflow before the API does.

Cost estimation

A token count is only half the answer; the other half is what those tokens cost per call and per month. The AI Cost Calculator projects monthly LLM API costs across Claude, GPT, and Gemini. This is the tool to open when you are choosing between models for a workload, or when you want to know whether a prompt change that adds 2,000 tokens per request is affordable at your call volume.

Prompt analysis and comparison

Prompt quality is hard to see by eye once a prompt grows past a few paragraphs. Two tools in this space are listed as upcoming: the Claude System Prompt Analyzer (Q1 2027), which takes a pasted system prompt and returns clarity, length, and structure feedback, and the Prompt Diff Tool (Q4 2026), which compares two prompt versions structurally so you can see exactly what changed. Until those ship, the practical substitute is disciplined manual versioning plus token counts on each revision.

Schema and format conversion

Wiring a model into tool use means writing a tool definition in exactly the shape the API expects. The JSON Schema → Claude Tool converter (listed for Q3 2026) is meant to turn any JSON Schema into a ready-to-use Anthropic tool-use definition, and Markdown → Anthropic Messages API (Q4 2026) is meant to turn a pasted conversation into the exact request JSON Claude expects. Both are conversion chores that are easy to get subtly wrong by hand.

How to choose, and what to watch for

Three caveats apply across the board. First, coverage is limited: a tool built around Claude, GPT, and Gemini may not know your fine-tuned or self-hosted model. Second, announced tools are not shipped tools — the JSON Schema converter, Cron Expression Explainer, Prompt Diff Tool, Markdown → Anthropic Messages API, Claude System Prompt Analyzer, and Regex Builder from Natural Language all carry future quarters (Q3 2026 through Q1 2027) and a notify-me form, so plan around what exists today. Third, browser-side tools are convenient and keep your prompts local, but they are point checks, not logging or monitoring; for production you still need your own request logging and spend tracking.

A practical workflow

A workable routine for a prompt-heavy project: draft the prompt, run it through the token counter to confirm it fits and to see the per-call cost, adjust length or model choice based on the cost calculator, and keep each version labeled so you can compare them once the diff tool is available. For tool-use work, write the schema first, convert it rather than hand-assembling the definition, and validate the result against a real API call. Combine tools by task rather than expecting one to do everything — the value of single-purpose utilities is that each answers one question quickly, and the cost is that you assemble the workflow yourself.

AI developer tools are single-purpose utilities that handle the unglamorous parts of building with LLMs: counting tokens, estimating API costs, debugging prompts, converting schemas into tool-use definitions, and assembling API request payloads. Developers actually use them at three moments — before a call (cost and token budgeting), during prompt work (analysis and diffing), and at integration time (format conversion). The most practical ones run entirely in the browser, require no sign-up, and let you compare Claude, GPT, and Gemini side by side. HandyAI is one example of a site organized around exactly this set of tasks.

The four categories that matter

Most AI developer tooling clusters into four jobs. Knowing which job you're doing tells you which tool to reach for.

Token counters and cost calculators

These are the entry point for most developers because token counts drive both context-window limits and billing. A live token counter lets you paste text and see counts for multiple models at once — for example, Claude 3.5 Sonnet (200K context), GPT-4o (128K context), Claude 3 Haiku (200K context), and Gemini 1.5 Flash (1,000K context) — with per-call cost estimates updating as you type.

How to use one for a real estimate:

1. Paste the exact text you plan to send — system prompt plus user message, not a summary.
2. Read the token count per model and compare against that model's context window.
3. Multiply the per-call cost by your expected call volume to get a monthly figure.
4. Re-run after trimming the prompt to see whether the savings justify the edit.

A companion cost calculator projects monthly API spend across Claude, GPT, and Gemini, which is useful when you're choosing a model for a workload rather than debugging a single call. The practical rule: count tokens on the real payload, and treat any estimate made from character counts as a rough upper bound.

Prompt analysis, diffing, and system-prompt review

Prompt debugging is where developers lose the most time, and the tools here split into three distinct jobs:

• Prompt diff compares two versions of a prompt structurally, so you can see exactly what changed between the version that worked and the one that didn't. This matters when prompts grow past a few paragraphs and manual comparison stops being reliable.
• System prompt analysis takes a system prompt and returns feedback on clarity, length, and structure. It's the closest thing to a lint pass for prompts.
• Prompt engineering guidance in general — the discipline behind writing clearer instructions — is the underlying skill these tools support. If you're new to it, the tools are most useful after you understand the basic moves: state the role, specify the output format, and give examples.

One caveat worth planning around: on HandyAI, the prompt diff tool and the Claude system prompt analyzer are listed as upcoming, not live. The token counter and cost calculator are the currently available tools. Check availability before you build a workflow around a specific one.

Format conversion: schemas and API payloads

Integration work is full of small, error-prone translations. Two conversions come up repeatedly:

• JSON Schema → Claude tool-use definition. If you already maintain JSON Schemas for your own validation, converting them into the tool-use format Anthropic expects saves hand-transcription errors. This is listed as shipping in Q3 2026 on HandyAI, so it's a "plan for it" item rather than a "use it today" item.
• Markdown → Anthropic Messages API request. Paste a conversation written in markdown and get the exact request JSON Claude expects. Also listed for Q4 2026.

Until those ship, the honest approach is to do these conversions by hand against the official API docs, or write a small script — the conversion logic is deterministic and doesn't need a hosted tool.

How to choose a tool

Use the same criteria across candidates rather than comparing feature lists:

1. Does it run client-side? Browser-only tools mean your prompts and schemas never leave your machine. HandyAI labels its live tools as client-side, which is the property to look for if you're pasting proprietary prompts.
2. Does it require an account? No sign-up means no friction for a one-off task. HandyAI states no sign-up is required; verify this on whichever site you use, since it's a per-site policy.
3. Does it support multiple models? A counter that only knows one model is useless the moment you compare providers. Side-by-side counts across Claude, GPT, and Gemini are the useful shape.
4. Is the tool actually live? Sites list roadmaps alongside shipped tools. Separate the two before committing.

If your need is a quick token count or a monthly cost projection, a live in-browser counter and calculator cover it today. If your need is schema conversion or prompt diffing, check whether the specific tool has shipped — and if not, a short script against the official docs is a reasonable stopgap.

Prompt engineering is the practice of designing and refining the text you send to a large language model (LLM) so that its output is accurate, relevant, and usable. You write better prompts by being explicit about the role, task, context, output format, and constraints, then testing and revising based on the results. This guide covers the core concept, the main techniques and when to use them, a reusable prompt structure, common failure modes, and how to evaluate your prompts. It is for anyone who wants more reliable AI output, whether you are new to prompting or already using LLMs regularly.

What prompt engineering actually is

An LLM does not read your mind. It predicts a continuation based on the text you give it. Prompt engineering works because the input shapes that prediction: the same model can produce a vague answer or a precise one depending on how the request is framed.

This is why two prompts asking for the "same thing" can produce very different results. "Summarize this" leaves the length, audience, and focus open. "Summarize this customer feedback in three bullet points for a product manager, focusing on recurring complaints" narrows the space of acceptable outputs.

Prompt engineering is not a single trick. It is a set of techniques you choose from depending on the task, plus a habit of iterating.

Common prompting techniques and when to use them

A few practical notes:

• Zero-shot first. Try the simplest version before adding complexity. Many tasks do not need examples.
• Few-shot when format matters. If you need a particular structure, showing two or three examples is usually more effective than describing the structure in words.
• Chain-of-thought when the answer requires reasoning. Forcing an answer without intermediate steps tends to produce confident but wrong results on multi-step problems. Asking for the reasoning first, then the conclusion, improves reliability.
• Combine techniques. A role plus a format plus one example is often stronger than any single technique alone.

A reusable prompt structure

You can build most prompts from five components. Not every prompt needs all five, but when output is disappointing, checking which component is missing usually reveals the fix.

1. Role — Who should the model act as? "You are a technical writer explaining this to a non-technical audience."
2. Task — What exactly should it do? Use a specific verb: summarize, classify, rewrite, compare, extract.
3. Context — What background does it need? Paste the source text, describe the audience, or state the goal.
4. Output format — What should the result look like? Specify length, structure, and format (bullets, table, JSON).
5. Constraints — What should it avoid or respect? Word limits, tone, things to exclude, assumptions not to make.

A filled-in example:

You are a customer support lead. (role)
Rewrite the following refund policy so a first-time buyer can understand it. (task)
The audience is non-native English speakers shopping on mobile. (context)
Return it as a short intro paragraph plus five bullet points, each under 20 words. (format)
Do not use legal jargon or promise anything the original policy does not state. (constraints)

If you only remember one thing: state the task and the output format explicitly. Most weak prompts fail on one of those two.

Common failure modes and how to fix them

Vague instructions. "Make this better" gives the model no target. Fix: name the dimension — clearer, shorter, more formal, more persuasive.

Missing examples. The model guesses at your format and guesses wrong. Fix: add two or three input–output examples.

Context overload. Pasting ten pages when only one paragraph matters dilutes the signal and can push the model to miss the relevant part. Fix: include only the context the task requires, and point to it directly ("Using only the section titled Billing…").

Conflicting constraints. "Be concise but cover every detail" forces the model to choose. Fix: prioritize — "Cover the three most important points in under 100 words."

Assuming shared knowledge. The model does not know your internal project names, acronyms, or history. Fix: define terms or provide the background inline.

No format specification. You get a wall of text when you needed a list. Fix: state the structure you want.

How to test and improve a prompt

Treat prompting as a loop, not a one-shot attempt:

1. Write a first version using the five-component structure.
2. Run it on more than one input if the task is repeatable. A prompt that works once may fail on a different case.
3. Compare outputs against a clear criterion. Decide in advance what "good" means — correct facts, right format, appropriate tone.
4. Change one thing at a time. If you rewrite everything at once, you will not know what helped.
5. Keep the version that performs best across your test cases, not just the one that produced a good answer once.

For tasks you will repeat, save your working prompt as a template with placeholders for the parts that change. This turns a one-off success into a reusable tool.

Where to learn more

Learn Prompting describes itself as a large and comprehensive prompt engineering course, with over 60 content modules translated into 9 languages and a community of more than 3 million learners. Its materials cover prompting fundamentals as well as adjacent areas such as AI red-teaming and LLM security, including a free 7-day "Learn Prompt Hacking" course and an AI/ML Red-Teaming & AI Security Masterclass. The site lists a pricing page, so check there for current access and cost details rather than assuming all content is free.

If you are starting out, the practical path is: learn the five-component structure, practice zero-shot and few-shot prompting on real tasks, add chain-of-thought when reasoning is involved, and build the habit of testing prompts against more than one input before relying on them.