/v1/models
Returns an OpenAI-shaped model list. Use model IDs from this response rather than a provider’s model name.
BitGenius developer API
Use familiar Responses and Chat Completions request shapes to build corpus-grounded BSV experiences. Keep your application’s tools and conversation history under your control.
https://api.bitgenius.net/v1bitgeniusChoose a request surface and a language. Every example uses the same API base URL.
BITGENIUS_API_KEY.GET /v1/models before choosing a model alias. This preview defines bitgenius.# BitGenius developer API preview.
curl https://api.bitgenius.net/v1/responses \
-H "Authorization: Bearer $BITGENIUS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "bitgenius",
"input": "Explain BRC-100 wallet permissions with sources.",
"store": false
}'JavaScript and Python examples use the OpenAI client’s custom base URL. Contract compatibility is bounded by the matrix below; these are integration recipes, and live SDK interoperability remains a release check.
Corpus retrieval supplies grounding and provenance. Built-in web search is unavailable in this preview; current facts require separate verification. The model is instructed to disclose when current confirmation is unavailable. Check cited sources before relying on an answer.
One model alias. Two generation surfaces. Explicit validation.
/v1/modelsReturns an OpenAI-shaped model list. Use model IDs from this response rather than a provider’s model name.
/v1/responsesAccepts a string or text message / function-call history. Returns output items and token usage; store: false is supported.
model · input · tools · stream/v1/chat/completionsAccepts text messages with system, developer, user, assistant, or tool roles. Returns choices with text or function tool calls.
model · messages · tools · streamBoth surfaces accept model, tools, tool_choice, parallel_tool_calls, stream, and store: false. Responses also accepts instructions and uses max_output_tokens. Chat uses either max_tokens or max_completion_tokens, plus optional stream_options.include_usage. Sampling controls (temperature and top_p) are unsupported by the current provider adapter. Unknown fields produce a 400 error that names the parameter. The HTTP JSON body limit is 64 KiB; history is limited to 256 messages including instructions, and at most 64 functions may be declared. The parser ceiling is 32,768 output tokens; the runtime’s configured budget may be lower.
The model can request a function call. Your application decides whether and how to execute it.
Responses uses flat function definitions and function_call_output items. Chat Completions nests definitions under function and returns tool outputs as role: "tool" messages. Return each call’s exact ID and retain the previous messages and output items.
const tools = [{
type: "function",
name: "lookup_protocol",
description: "Read a protocol description from my approved local index.",
parameters: {
type: "object",
properties: { number: { type: "integer" } },
required: ["number"],
additionalProperties: false,
},
}];
const first = await client.responses.create({
model: "bitgenius",
input: "Find BRC-100 in my protocol index.",
tools,
tool_choice: "auto",
store: false,
});
// Keep the original input and every output item in client-owned history.
// Validate the tool name and arguments before running your own function.
const calls = first.output.filter(item => item.type === "function_call");
const outputs = [];
for (const call of calls) {
if (call.name !== "lookup_protocol") throw new Error("Unexpected tool");
const args = JSON.parse(call.arguments);
if (!Number.isInteger(args.number)) throw new Error("Invalid arguments");
const output = await lookupApprovedProtocol(args.number);
outputs.push({ type: "function_call_output", call_id: call.call_id,
output: JSON.stringify(output) });
}
if (calls.length) {
const next = await client.responses.create({
model: "bitgenius",
input: [
{ role: "user", content: "Find BRC-100 in my protocol index." },
...first.output,
...outputs,
],
tools,
store: false,
});
console.log(next.output_text);
}This example assumes your application supplies lookupApprovedProtocol. In production, constrain allowed arguments and output size, and obtain user approval for consequential actions. A tool declaration does not grant permission.
Streaming, cancellation, and retries each have a distinct outcome.
Chat emits chat.completion.chunk data and ends with [DONE]; request the optional usage chunk explicitly. Responses emits named lifecycle, output-item, text, function-argument, and terminal events.
Abort the HTTP request to signal cancellation. A disconnected stream is incomplete; do not invent a successful terminal event or treat a partial function argument as executable.
Use a unique Idempotency-Key for each generation. Reusing it suppresses a second execution with 409; it does not replay the result. After a timeout, preserve the key. A new key starts new work and can incur another charge.
Send relevant previous messages and tool outputs on each request. Stored Responses, previous_response_id, and background continuation are unsupported.
const controller = new AbortController();
const stream = await client.responses.create({
model: "bitgenius",
input: "Summarize BRC-100 permission boundaries.",
stream: true,
store: false,
}, { signal: controller.signal });
for await (const event of stream) {
if (event.type === "response.output_text.delta") {
process.stdout.write(event.delta);
}
// Handle completed, incomplete, and error outcomes separately.
}
// From your Stop control: controller.abort();Validation failures use an OpenAI-shaped error object with message, type, code, and parameter. Handle authentication, insufficient credits, throttling, and provider failures separately. After SSE starts, inspect terminal error events even when the original HTTP status was 200. Keep bounded request diagnostics; never log bearer keys or private prompts by default.
OpenAI-shaped request and response contracts for the listed features. Compatibility does not imply every OpenAI API feature.
| Capability | Status | Scope |
|---|---|---|
| Models | Preview contract | GET /v1/models; discover the bitgenius alias. |
| Responses | Preview contract | Text input, client-managed history, function calls, SSE, store: false. |
| Chat Completions | Preview contract | Text messages, function calls, SSE, optional usage chunk. |
| Function tools | Client executed | auto, none, required, or a named function; validate before execution. |
| Corpus grounding | Preview contract | Retrieved source provenance; freshness must be verified separately. |
| Built-in web search | Unavailable | Pending a verified credit-reservation bound for search-result tokens. |
| Account API keys & credits | Available | Account-owned inference keys with expiry, revocation, and metered account credits. |
| Hosted tools & agents | Unsupported | No hosted MCP execution, browser, shell, computer use, or agent runtime. |
| Stored Responses & multimodal | Unsupported | No previous_response_id, background jobs, images, audio, files, or JSON output modes. |
| BRC-105 API payment | Planned | Optional payment adapter; no live wallet or payment flow in this preview. |
Unsupported input is rejected explicitly. The preview does not silently discard unknown options or substitute a hosted tool for your function.
The developer API uses the BitGenius account boundary and metered credit lifecycle.
Account-owned, expiring API keys use Authorization: Bearer. The recommended expiry is 90 days. Keep keys in server environment configuration, rotate them deliberately, and revoke access when a consumer no longer needs it.
The release integrates the existing reserve, finalize, and release credit flow. A key does not create a new balance or bypass account checks. Stopping a request can still incur usage; if provider usage is unavailable after work starts, a conservative bound is settled. Token usage and customer credits are different units.
Key management, credit enforcement, rate limits, and production privacy behavior must pass the release gate before live use. store: false controls this API’s response persistence contract; it is not a guarantee about all provider processing. Do not send secrets in prompts or expose a key in a generated frontend.
Local MCP tools and a developer skill make the documented boundary available while you code.
Download developer toolkit ↓ · Download developer skill ↓
Extract the toolkit locally, review its included tooling guide, and follow the install instructions. These packages contain only public developer guidance and local tooling; downloading them does not install a skill or grant API access.
tar -xzf bitgenius-developer-toolkit.tar.gz
node bitgenius-developer-toolkit/tools/developer-mcp/server.mjsThe stdio server exposes get_compatibility, get_example, and validate_request, plus fixed documentation resources. It performs local contract work; it does not send generation requests. The download includes its request validator. In a repository checkout, build the backend first to enable canonical validation; discovery and examples work offline without that build.
{
"mcpServers": {
"bitgenius-developer": {
"command": "node",
"args": ["/absolute/path/bitgenius-developer-toolkit/tools/developer-mcp/server.mjs"]
}
}
}Requires Node.js 24+. Configuration format varies by MCP client. A hosted remote MCP endpoint is not part of this preview.
The downloaded skill’s bitgenius-developer folder guides endpoint selection, client tool round trips, request validation, and safe secret handling.
SKILL.md.For Codex, the personal destination is ~/.codex/skills/bitgenius-developer. This page does not install a skill or grant account access.
The preview becomes a live integration when the following checks are complete.
Request conventions follow the official Responses migration guide, function-calling guide, and streaming guide. The compatibility table above defines BitGenius’s narrower contract.