Every decision in an API design is a statement about what you think your users are trying to do. Here are the principles that guide ours.
Predictability Over Flexibility
A flexible API with many configuration options is powerful in theory and frustrating in practice. Most users do not want to tune 12 parameters. They want a sensible default that works, with a small number of clear levers for the cases where they need to adjust behavior.
Crucible has three reasoning modes, a temperature setting, and a max tokens parameter. That covers 95% of what people actually need. We resist adding parameters that require users to understand internal model behavior to use correctly.
Structured Outputs as a First-Class Primitive
Most API design treats structured output as a prompt engineering problem. You ask the model to return JSON and then deal with the cases where it does not. We treat it as an infrastructure problem. When you provide a schema, we guarantee the output matches it. That guarantee changes what you can build on top of us.
Transparency in Reasoning
We return the reasoning trace because we believe users should be able to audit how the model arrived at its output. This is not a feature for everyone. Most users never look at the trace. But for the teams building products where the reasoning matters as much as the conclusion, it is essential. We will always err on the side of giving users more visibility into model behavior, not less.
Stability
We version our models and our API independently. A model update does not change your API integration. An API change does not change model behavior. We announce breaking changes 30 days in advance and maintain previous versions for at least 12 months.
Every decision in an API design is a statement about what you think your users are trying to do. Here are the principles that guide ours.
Predictability Over Flexibility
A flexible API with many configuration options is powerful in theory and frustrating in practice. Most users do not want to tune 12 parameters. They want a sensible default that works, with a small number of clear levers for the cases where they need to adjust behavior.
Crucible has three reasoning modes, a temperature setting, and a max tokens parameter. That covers 95% of what people actually need. We resist adding parameters that require users to understand internal model behavior to use correctly.
Structured Outputs as a First-Class Primitive
Most API design treats structured output as a prompt engineering problem. You ask the model to return JSON and then deal with the cases where it does not. We treat it as an infrastructure problem. When you provide a schema, we guarantee the output matches it. That guarantee changes what you can build on top of us.
Transparency in Reasoning
We return the reasoning trace because we believe users should be able to audit how the model arrived at its output. This is not a feature for everyone. Most users never look at the trace. But for the teams building products where the reasoning matters as much as the conclusion, it is essential. We will always err on the side of giving users more visibility into model behavior, not less.
Stability
We version our models and our API independently. A model update does not change your API integration. An API change does not change model behavior. We announce breaking changes 30 days in advance and maintain previous versions for at least 12 months.
Every decision in an API design is a statement about what you think your users are trying to do. Here are the principles that guide ours.
Predictability Over Flexibility
A flexible API with many configuration options is powerful in theory and frustrating in practice. Most users do not want to tune 12 parameters. They want a sensible default that works, with a small number of clear levers for the cases where they need to adjust behavior.
Crucible has three reasoning modes, a temperature setting, and a max tokens parameter. That covers 95% of what people actually need. We resist adding parameters that require users to understand internal model behavior to use correctly.
Structured Outputs as a First-Class Primitive
Most API design treats structured output as a prompt engineering problem. You ask the model to return JSON and then deal with the cases where it does not. We treat it as an infrastructure problem. When you provide a schema, we guarantee the output matches it. That guarantee changes what you can build on top of us.
Transparency in Reasoning
We return the reasoning trace because we believe users should be able to audit how the model arrived at its output. This is not a feature for everyone. Most users never look at the trace. But for the teams building products where the reasoning matters as much as the conclusion, it is essential. We will always err on the side of giving users more visibility into model behavior, not less.
Stability
We version our models and our API independently. A model update does not change your API integration. An API change does not change model behavior. We announce breaking changes 30 days in advance and maintain previous versions for at least 12 months.