AI & LLM developer tools
Working with LLM APIs means debugging formats that sit between your code and the model: a structured output schema that OpenAI or Gemini rejects for an unsupported constraint, a streamed response you need to parse as server-sent events, a JSONL training or eval file with one malformed line breaking the whole read, or a token count you need before hitting a context limit. These tools work directly on those formats rather than requiring a live API call.
The Structured output schema checker validates a schema against OpenAI and Gemini's specific constraints before you send it, and the SSE parser identifies which blocks in a stream actually dispatch versus ones that don't. The JSONL viewer finds the exact line causing a parse failure instead of failing the whole file. For RAG pipelines, the RAG text chunker splits text by character count, token estimate or headings, the Token counter counts using o200k_base or cl100k_base, and the Vector similarity calculator compares embeddings by cosine, dot product and Euclidean distance.
7 tools
All AI / LLM Dev Tools tools
-
Structured output schema checker
Validate structured output schemas against OpenAI and Gemini constraints
-
JSONL viewer
Find line errors in JSONL files and inspect records without parsing failures
-
JSON-RPC message viewer
Pair JSON-RPC requests and responses by ID across message batches
-
SSE parser
Parse server-sent events and identify which blocks actually dispatch
-
RAG text chunker
Split text into chunks by character count, token estimate or Markdown headings
-
Token counter
Count tokens using o200k_base or cl100k_base with ID inspection and context
-
Vector similarity calculator
Compare vector similarity using cosine, dot product and Euclidean distance
AI / LLM Dev Tools tools FAQ
Both providers support a subset of JSON Schema with constraints that vary between them, so a schema valid in one can be rejected by the other for an unsupported keyword or nesting depth. The Structured output schema checker validates a schema against both providers' constraints before you send a request.
Token count depends on the tokenizer, and o200k_base and cl100k_base split text differently, so the same prompt can cost a different number of tokens depending on the model family. The Token counter counts using either tokenizer with ID-level inspection so you can see exactly where tokens split.
There's no single right size; it depends on your embedding model's context window and how much surrounding context each retrieved chunk needs to stay useful. The RAG text chunker splits text by character count, token estimate or Markdown headings so you can compare strategies directly.