Short answer: the setup in five steps
This SillyTavern world info guide starts with the part most people want first. To use World Info with this API, you connect SillyTavern to the endpoint, raise the context size, then build entries that fit a token budget.
- Create an API key on the key page.
- In SillyTavern, open the API connections panel, choose Chat Completion, and pick the Custom (OpenAI-compatible) source.
- Set the endpoint URL to
https://api.uncensoredvideo.top/v1, paste the key, and enteruncensoredas the model ID. - Set the context size to match the 100,000-token window, leaving room for the reply.
- Open World Info, create a book, attach it to your character or chat, and tune the budget settings covered below.
Menu labels shift between SillyTavern versions, so treat the names here as a map rather than exact wording. The site name mentions video, but the service is a text API: one open-weight model, tuned to answer without content refusals for lawful adult use, with no image, audio or video generation. Sexual content involving minors is not allowed.
Test the endpoint before touching SillyTavern
When a connection fails, the cause is nearly always a typo in the URL or key. A one-line test saves guessing. This lists the available model:
curl https://api.uncensoredvideo.top/v1/models -H "Authorization: Bearer YOUR_KEY"Then send a short chat completion to confirm generation works:
curl https://api.uncensoredvideo.top/v1/chat/completions -H "Authorization: Bearer YOUR_KEY" -H "Content-Type: application/json" -d '{"model":"uncensored","messages":[{"role":"user","content":"Reply with the word ready."}],"max_tokens":10}'If both return JSON, SillyTavern will connect with the same values. The base URL ends in /v1 and does not include /chat/completions; SillyTavern adds the path itself. A 401 means a bad key. The full request reference is in the API docs.
Why World Info needs a large window
World Info, also called a lorebook, injects entries into the prompt when their keywords appear in recent chat. The point is to keep a big world out of the prompt until it is relevant. But entries still sit in the prompt when they fire, next to the character card, the chat history and your system prompt. On a small window, all of that competes for space, and the lorebook loses.
A 100,000-token window, which covers prompt plus completion, changes the balance. You can afford a long character card, 50 or more chat messages of history and several lore entries at once. The window does not mean you should fill it. A longer prompt is slower to process, costs more per message, and gives the model more to ignore. The goal is relevant context, not maximum context.
A practical split for a 100,000-token window:
- Character card and persona: 1,500 to 3,000 tokens
- World Info budget: 4,000 to 10,000 tokens
- Chat history: whatever remains, up to your chosen limit
- Reply space: 500 to 1,500 tokens
These figures are suggestions for a typical roleplay, not API requirements. Most sessions never need the upper bounds.
Building entries that work
Keywords and content
Each entry has primary keywords that trigger it and a content field that gets injected. Write keywords the way players actually say things. For a city, add the name, a nickname and the district names. Entries match on the recent messages, so a keyword that only appears in the lore text itself will never fire.
Keep content short and factual
Write entries as compact statements, not prose. Compare these two:
Harrow Quay: port district, controlled by the Salt Guild. Smuggling tolerated, murder not. Curfew at midnight, enforced by hired watchmen.
A paragraph of atmosphere for the same place may run four times as long and add little the model cannot invent. Reserve long entries for facts the model must get right: names, rules of magic, who owes whom.
Constant, selective and recursive entries
- Constant entries are always injected. Use them for rules that apply to every scene, such as the setting's tone or how magic works, and keep the total small.
- Selective entries use secondary keywords as a filter, so "dragon" only fires when "cave" is also mentioned.
- Recursive scanning lets one entry's text trigger others. It is powerful for linked lore, and it can pull in far more than you expect. Set a limit on recursion steps.
Position and order
Entries can be inserted before or after the character definitions, or at a set depth in the chat. A depth near the bottom of the history puts the fact close to the latest message, where models tend to weigh it more. Order values decide which entries survive when the budget is tight, so give essential lore a higher priority.
Settings that control token spend
The World Info panel has a handful of global controls. Names vary by version, but these exist in recent releases.
| Setting | What it does | Starting value |
|---|---|---|
| Scan depth | How many recent messages are searched for keywords | 4 to 8 |
| Budget (percent of context) | Share of the context that World Info may use | 10 to 15 percent |
| Budget cap | A hard token ceiling for World Info | 6,000 to 10,000 |
| Min activations | Keeps scanning deeper until enough entries fire | 0 unless you need it |
| Recursion steps | Maximum chain length for recursive triggers | 2 to 3 |
A larger scan depth catches lore that was mentioned a few turns ago, at the price of more false triggers. With 100,000 tokens available, a budget cap is more about cost control than fitting the window. If you see the model suddenly writing about something irrelevant, a keyword is firing too broadly; switch it to a selective entry.
Also check that the chat history setting in SillyTavern is not trimming messages earlier than you intend. The context size field is a limit on what SillyTavern sends, so if it stays at a small default, the large window goes unused.
What a roleplay session costs
Pricing is $0.15 per 1M input tokens and $0.50 per 1M output tokens. Roleplay is input-heavy, because SillyTavern resends the character card, lore and history on every message.
Take a prompt of 12,000 tokens (character card, a few lore entries, history) and a reply of 400 tokens.
- Input: 12,000 / 1,000,000 x $0.15 = $0.0018
- Output: 400 / 1,000,000 x $0.50 = $0.0002
- Total: $0.002 per message
A hundred messages cost $0.20. The $0.50 trial credit covers about 250 messages at this size. Push the prompt to 40,000 tokens and the same reply costs 40,000 / 1,000,000 x $0.15 = $0.006 for input plus $0.0002 for output, so $0.0062 per message, and the trial lasts about 80 messages (0.50 / 0.0062 is about 80.6). That is the cost of a very large lorebook budget and long history, and it is the argument for tight entries.
The trial is claimed with one click on the API key page after sign-up, needs no payment method, lasts 7 days and is one per person. Top-ups go from $20 to $500 in any whole amount, with +5% from $50, +10% from $100 and +15% from $200. This site accepts crypto only: USDT on TRC20 or USDC on Base. Credit never expires, and failed or refused requests are not charged. Full details are on the pricing page.
Troubleshooting and limits
A full key allows 8 concurrent requests and 300 requests per minute. The trial key allows 2 and 60. SillyTavern can exceed two concurrent requests with group chats, swipes fired quickly, or a second tab, and a streamed reply holds its slot until it ends. The API then answers HTTP 429 with the code concurrency. A request-rate overrun returns rate_limited, and temporary overload comes with a Retry-After: 5 header. Waiting a few seconds and retrying is enough.
- Replies cut off. Check the max response length in SillyTavern. It sets
max_tokens, which is optional on this API. - Lore never fires. Raise scan depth, and check the keyword spelling against how it appears in chat.
- Replies ignore lore that did fire. Move the entry to a depth closer to the bottom of the history, or shorten it so it stands out.
- Prompt feels slow. Reduce the budget cap and the chat history length before blaming the endpoint.
For characters who speak in a fixed style, set temperature around 0.8 to 1.0 and add a mild frequency penalty if the model repeats phrases. Prompts are not used for training. The model is a single open-weight model run by an independent provider, not a router across vendors, so quality depends on that one model rather than a pool.
