Languages

How do you build Japanese AI apps with Plugsky?

Japanese mixes kanji, hiragana and katakana with no word spaces, so token and indexing behaviour differs sharply from English. Plugsky serves it on the standard OpenAI-compatible endpoint — set base_url to https://api.plugsky.com/v1 and send UTF-8 text to /v1/chat/completions. Normalise character width, segment text before indexing, fix one keigo level per surface, and use plugsky-embed-multilingual for cross-language retrieval.

Key facts

Japanese scriptKanji, hiragana and katakana with no word spaces; width variants matter
TokenisationCharacter-based encoding and katakana loanwords can raise token counts — measure with the token calculator
RegisterKeigo, plain and casual forms are distinct — fix one per surface
SegmentationSpaces are not delimiters, so indexing and chunking need a segmenter
API compatibilityOpenAI-compatible POST https://api.plugsky.com/v1/chat/completions — chat, streaming, JSON mode and function calling
Models30+ models behind one endpoint, from free tiers to frontier reasoning
Free tierFree plan with plugsky-micro and plugsky-lite, no card required
Product statusChat, streaming, JSON mode, function calling, embeddings, RAG and agents live; audio, images, moderation, files, batch, fine-tuning, assistants and responses coming soon

TL;DR

  • Japanese runs on the standard endpoint with one base_url change.
  • Normalise full-width and half-width characters before counting or indexing.
  • Segment before indexing — spaces do not delimit words.
  • Fix one keigo level per surface and state it in the prompt.
  • plugsky-embed-multilingual covers Japanese and English retrieval.

How it works, step by step

  1. Create a free Plugsky key and set base_url to https://api.plugsky.com/v1.
  2. Send real Japanese text to /v1/chat/completions and compare two or three models.
  3. Normalise width variants and normalise Unicode before measuring tokens or embedding.
  4. Add a glossary for product terms so katakana renderings stay consistent.
  5. Segment text with a Japanese tokenizer before keyword indexing or chunking.
  6. For RAG, embed with plugsky-embed-multilingual and test Japanese and English queries, then review outputs with native speakers.
1Create a freePlugsky key and setbase_url to2Send real Japanesetext to/v1/chat/completions3Normalise widthvariants andnormalise Unicode4Add a glossary forproduct terms sokatakana renderings5Segment text with aJapanese tokenizerbefore keyword6For RAG, embed withplugsky-embed-multilingualand test Japanese

Try it yourself

Open the token calculator →

How Plugsky handles Japanese text

Japanese needs no special endpoint: UTF-8 text goes in and comes back. The language-specific work starts with writing system. Text mixes kanji, hiragana, katakana and Latin words in one sentence, and the same character can appear in full-width or half-width form — ABC versus ABC, 123 versus 123. Normalising width early stops near-duplicate strings from fragmenting your token counts and search indexes.

Register is the second decision. Keigo, plain and casual forms are not interchangeable, and business content expects a consistent politeness level across greetings, apologies and requests. Put the level in the system prompt and test it on realistic templates.

Tokenisation and cost in Japanese

Tokenisers split Japanese by characters, subwords or a mix, so counts per sentence depend heavily on the model and script mix. Katakana loanwords — product names, technical terms — often fragment into many pieces, and full-width Latin or digits add further variation.

  • Measure on real product text, not on dictionary sentences.
  • Normalise full-width and half-width characters first.
  • Keep a glossary so loanword renderings stay stable.
  • Re-measure whenever you change models.

Japanese retrieval and RAG

Keyword search needs a Japanese segmenter because spaces are not delimiters; embeddings help, and one multilingual collection built with plugsky-embed-multilingual serves Japanese documents with Japanese or English queries. Common failures come from width variants, loanword spelling and mixed scripts.

  • Segment before indexing and chunking.
  • Normalise width and Unicode form before embedding.
  • Test English queries against Japanese documents explicitly.
  • Keep one embedding model per collection.

Code example: a Japanese request

Point your OpenAI client at https://api.plugsky.com/v1; only the content and system prompt change.

client = OpenAI(base_url="https://api.plugsky.com/v1", api_key=os.environ["PLUGSKY_API_KEY"])

client.chat.completions.create(model="plugsky-pro", messages=[{"role": "system", "content": "ビジネス向けの丁寧な日本語で回答してください"}, {"role": "user", "content": "この契約書を三つのポイントに要約してください"}])

Start on the free plan with plugsky-micro and plugsky-lite, then compare paid models on a Japanese gold set. See the docs for the API reference.

Honest comparison

CapabilityPlugskyJapanese apps todayBuilding in-house
API compatibilityOpenAI-compatible — change base_url and model nameVaries by provider and SDKFull rewrite
Japanese text handlingUTF-8 with width guidance, glossaries and keigo prompt controlDepends on provider tokeniser and prompt hygieneYou build normalisation, segmentation and evals
Token budgetFixed tokeniser per model; measure script mix and chunk to fitVaries by provider and modelYou host and tune each tokeniser
Multilingual retrievalplugsky-embed-multilingual for Japanese and English RAGOften needs a separate embedding vendorYou serve and maintain embeddings
SovereigntyCloud, VPC, on-prem and air-gapped with residency optionsUsually US/EU public endpointsYou own the full stack

Frequently asked questions

Can Plugsky handle Japanese text?

Yes. The API accepts UTF-8 Japanese input across kanji, hiragana and katakana on the OpenAI-compatible chat endpoint. Compare models on your own prompts.

How do full-width and half-width characters matter?

The same visible text can be encoded differently, which changes token counts and search matching. Normalise width early and keep the display form separate.

Why does Japanese need segmentation?

Japanese is written without spaces, so keyword indexing and chunking need a segmenter rather than whitespace splitting. Embeddings complement, but do not replace, segmentation.

How do I control politeness level?

State the expected register — keigo, plain or casual — in the system prompt and test it on greetings, apologies and requests, where inconsistency shows first.

Is there a multilingual embedding model?

Yes — plugsky-embed-multilingual is part of the 30+ model catalogue and supports Japanese and English retrieval from one collection.

Can I deploy in my own environment?

Yes. Plugsky supports cloud, VPC, on-prem and air-gapped deployment with residency options for regulated teams.

Is there a free plan?

Yes — plugsky-micro and plugsky-lite are free with no card, and a 14-day full-access trial covers the paid catalogue.