o1 is a conversational reasoning model in OpenAI's o series, suited for tasks that require breaking down conditions, comparing solutions, and checking logic. Its primary value lies in mathematical analysis, complex code debugging, and scientific problem exploration, rather than turning every question into a long answer. It can be integrated into applications using the public request formats in this page's API section.
Point the Base URL to api.acedata.cloud, configure your platform API key and the model ID below, and use your compatible SDK or client.
api.acedata.cloudo1import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["ACEDATACLOUD_API_KEY"],
base_url="https://api.acedata.cloud/v1",
)
response = client.responses.create(
model="o1",
input="Hello!",
)
print(response.output_text)Choose an available protocol for this model. OpenAI SDK uses a Base URL ending in /v1; Anthropic SDK uses the root URL. See each guide for protocol-specific parameters, tools and response formats.
Clarify capacity, input and output, and invocation methods before choosing a model.
The o1 series is designed to invest more reasoning before answering. Platform input is organized as messages or input; for ongoing tasks, the application provides relevant history rather than treating ordinary response identifiers as long-term memory.
Learn what o1 can bring to your work.
o1 is suited to problems that cannot be answered simply through direct retrieval or template application. After submitting objectives, known conditions, and constraints, you can ask it to provide a solution path, key assumptions, and verification methods. For mathematical derivations and logical analysis, the focus should be on whether the conclusion satisfies the conditions, not merely whether the answer is detailed.
For code tasks, you can provide relevant functions, error information, expected behavior, and failing examples together, allowing o1 to analyze deviations between the implementation and requirements. It is better suited to debugging discussions that require understanding multiple conditions, and can deliver repair suggestions and testing approaches; after generating code, it still needs to be run and verified in a real environment.
When using Chat Completions, include relevant history in messages; when using Responses, organize input and related conversation content according to the documentation. Provide the latest materials, revision goals, and key constraints in each round; for longer tasks, retain phased summaries and a final version that can be checked independently.
Start with specific tasks to identify where the model can be effective.
Provide the problem, symbol definitions, and existing derivation, and ask o1 to check for missing conditions, discuss special cases, and provide an explanation of a verifiable solution. Deliverables may include a derivation draft, error identification, or alternative methods. This is suitable for discussing complex problems in research and learning; generated text should not be treated directly as a verified proof.
Provide minimal reproducible code, error logs, and expected results, and let o1 compare possible causes, explain where to make changes, and suggest tests covering boundary conditions. This is suitable for defects caused jointly by multiple branches or constraints; narrowing down to the key code first makes it easier to determine whether suggestions are effective than submitting a large number of unrelated files at once.
Organize research questions, known relationships, data summaries, and hypotheses into text, and ask o1 to distinguish facts from speculation and reason through the conditions required for a solution to hold. It can be used to create formula drafts, analysis outlines, and lists of questions to verify, especially at stages where logic must first be clarified before moving on to experimental or computational validation.
Choose based on task complexity, input materials, and expected results.
When a problem involves multi-step derivation, complex debugging, or mutually constraining conditions, you can choose o1. If the main task is everyday Q&A, copy rewriting, or image-text interaction, you should also consider general-purpose models such as GPT-4o. The basis for selection is the capability required by the task, rather than assuming that a reasoning model is more suitable for all work by default.
o1, o1-preview, o1-mini, and o1-pro are different names and should not be understood interchangeably. The public positioning of o1-mini leans toward more streamlined programming reasoning; the o1 on this page is suitable for integrated discussions of mathematics, code, and scientific questions. When migrating existing applications, use your own typical problems to compare results rather than carrying over evaluations or parameter assumptions from other versions.
Based on o1's characteristics, first validate small tasks whose results can be checked.
You can ask directly: Analyze the root cause from this set of code, input examples, and erroneous results; compare two repair options, identify the conditions under which each applies, and then provide reproducible validation steps.
Provide sufficient textual context; focus on checking logical premises and whether new edge-case errors arise after the fix.
Use the full model ID o1, first confirm the public request format and available parameters on the API page, then connect your application. Retain result parsing, exception handling, and supporting evidence, and evaluate with the same set of real samples whether it is suitable for continued use.
Before formal use, understand the quality of outputs and the scope of capabilities.
Answers to common questions about using o1.
They are not interchangeable names. This page calls model: "o1"; o1-preview is the name of an early preview version in the series. The feature limitations, usage limits, and evaluation results from the preview period should not be used directly to assess o1; actual model selection should be based on your own math, code, or analysis tasks.
Problems requiring multi-step analysis, interacting conditions, or solution verification are more suitable, such as mathematical derivations, complex code debugging, and scientific hypothesis discussions. When submitting, clearly state the goal, known conditions, and acceptance criteria, and ask it to explain key assumptions; this is usually more useful than simply asking it to “think deeply.”
Use Chat Completions or Responses and provide the full model ID. Chat Completions uses messages and choices, while Responses uses input and its corresponding response structure; handle history management, streaming events, and tool parameters separately according to the selected API, and do not mix the two formats.
Do not treat code text as an execution result. o1 can be used to generate code and debugging suggestions, but actual execution requires an environment provided by the application. It is recommended to first check dependencies, inputs, and permissions, then run tests, provide exceptions and test results to the model, and continue locating issues and verifying changes.
Clearly specify variable ranges, units, boundary conditions, and existing derivations; ask it to distinguish assumptions from conclusions and provide key equations, counterexample checks, or numerical verification methods. Carefully review whether each key step is valid, and do not assume a proof is correct merely because the response is lengthy or sounds certain.
Choose a development approach or application suited to this model and follow its setup guide.
↗OpenAI Chat Completions API
SDK installation, authentication and examples↗OpenAI Responses API
SDK installation, authentication and examples
↗Using Ace Data Cloud with Cherry Studio
Chat client setup · Base URL, API key and model
↗Using Ace Data Cloud with ChatBox
Chat client setup · Base URL, API key and modelThis is only a basic call example. See the full docs for more parameters and advanced usage.
View Docs