An API for your workflow, not a finished application
Send your own instructions, history and task data for writing, coding or analysis. Your application still owns its interface, user data, validation and actions. “Without censorship” describes positioning, not universal compliance, unlimited throughput or absent logs. A model describing a tool action has not executed it.
Connect URL, key and exact model ID
Use https://dikaya.cc/v1 and a personal Dikaya key stored server-side in DIKAYA_API_KEY. Do not embed it in public HTML, browser JavaScript or a shipped client bundle. Start with text Chat Completions and seller-pro-2, a modified version based on GLM-5.3. The authenticated /v1/models catalogue is authoritative for your key’s available models and rates. Responses and Messages are also supported formats; individual third-party client features still need verification.
Bound context, output and tools separately
Context window, JSON size and output are different limits. Paid output defaults to 16384, unless your key/client sets another value; explicit maximum 65536 remains subject to the model. The eligible one-time demo has up to 3 text Pro 2 requests, output 8192 including reasoning, 6000 context bytes, 10 requests/minute and one concurrent request. Client tools require top-up and execute in the application. Add streaming and tools only after a small text request works.
API request bodies are limited to 16 MiB. This is the JSON byte bound, not the model context window or output-token budget.
Account for cost and uncertain completion
Input, cached input and output determine token cost; reasoning is part of output. Chat/API share prepaid USD credit, minimum top-up $5, no subscription or expiry. An estimate is reserved before inference; known usage settles actual cost and releases the remainder. Explicit HTTP rejection releases unused work, but a completed image stage may still be billed. Lost connection or unknown usage can retain a reservation: do not silently start a fresh billed operation. Keep partial output, request IDs and terminal state; check usage and finish reason, not merely status 200.
Build a small, inspectable integration
Use the bounded curl sample without automatic retry. Define the response shape, test formatting and local validation, then add concurrency limits and intentional recovery. Image support varies; Pro image handling may involve a separate paid Flash description stage rather than native vision. Prompts, answers and usage logs are stored and external processing is involved. Publish your own users’ data flow honestly; account support handles integration and payment questions manually.
Illustrative task, not a captured model answer
Suggest three structures for a notes application and compare their trade-offs.
curl https://dikaya.cc/v1/chat/completions \
-H "Authorization: Bearer $DIKAYA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"seller-pro-2","max_tokens":512,"messages":[{"role":"user","content":"Suggest three structures for a notes application and compare their trade-offs."}]}'This opens the visible task as an editable chat draft after sign-in. Only your explicit send starts processing; this page generates nothing.
Questions and answers
What do I put in the model field?
Use the exact catalogue ID, for example seller-pro-2, not a display label or another service’s identifier. The base URL is https://dikaya.cc/v1, not the model name.
Does compatible mean every IDE feature works?
No. Verify custom base URL support, streaming, tool format and the specific client mode independently. See Documentation for actual setup instructions.
Should I retry after a timeout?
A timeout does not prove the previous operation failed or was free. Preserve state and investigate the request outcome; any new generation can create another charge.