K3Nova
These notes explain how the k3nova.com workspace handles access, deployment, context, source boundaries and comparison evidence.
Plan access is managed through k3nova.com. Server API keys can be created from the Open API panel after a paid plan is active, and each key can have its own daily Agent credits cap.
The chat endpoint is POST /api/v1/chat/completions. Calls use the same plan allowance as the workspace and stop before model access when the key, plan, quota or runtime configuration check fails. See the Open API guide for curl and JavaScript examples.
Buzz users can connect their own channel agent to K3Nova with a server API key and a local bridge process. The customer creates or chooses that Buzz agent in their own community, adds it to the target channel, and runs the bridge beside their relay or trusted machine.
The bridge watches a selected Buzz channel, sends mentioned thread context to /api/v1/chat/completions, and replies back in the same Buzz thread.
K3Nova does not store Buzz private keys. Customers keep their Buzz relay URL, agent private key and channel ID in their own server or local environment. The integration manifest is available at /api/integrations/buzz/manifest.
See the Open API Buzz section for the required environment variables and bridge command.
Google sign-in is available for the k3nova.com workspace. It creates a k3nova.com account session only and does not grant an official Kimi or Moonshot account.
For development, run the Node server locally and connect it to a compatible server-side model backend with environment variables or a local secure credential store. Production keeps private credentials on the server side.
The workspace is designed for long-context tasks such as briefs, notes, code, website plans and research outlines. Attachments are summarized into the request payload, and the current conversation is kept local so users can continue the same working thread.
k3nova.com is an independent implementation with an original interface. It does not copy official private source code, account systems, protected artwork or billing flows. Public docs describe that boundary so users can evaluate the workspace honestly.
Comparisons should use reproducible journeys: first visit, mode switch, file attachment, prompt response, refresh restore, export, protected runtime gate and mobile layout. Benchmarks are useful only when the prompt, environment, model setting and pass criteria are recorded.