Relace: Relace Search

Relace Search is a text model from Relace, listed on api14 under the model id relace/relace-search. It sits in the text category and is built around codebase exploration rather than general chat. According to the provider, the model uses 4 to 12 view_file and grep tools in parallel to explore a codebase and return the files relevant to a user request. That places it in the retrieval space, but with an agentic approach rather than the embedding and vector search pattern used by RAG.

The model takes text as input and returns text as output. It has a context window of 256,000 tokens and a maximum output of 128,000 tokens, which is generous enough to hold a large amount of source material alongside the request and still leave room for a substantial answer. Supported request parameters are max_tokens, response_format, seed, stop, temperature, tool_choice, tools, and top_p. The presence of tools and tool_choice is consistent with its tool-driven design: the model is expected to call view_file and grep as part of producing its answer.

Practical uses follow from that design. If you are building a coding assistant, an agent that answers questions about a repository, or a pipeline that needs to locate the files relevant to a change request, Relace Search is aimed at that job. Instead of embedding a codebase and hoping similarity search surfaces the right chunks, you let the model decide which files to open and which patterns to grep for, then return the relevant files. It also fits workflows where a downstream step needs a shortlist of files rather than a finished patch, such as triage, onboarding into an unfamiliar repository, or scoping before an edit.

You call it through api14's OpenAI-compatible API using the model id relace/relace-search. Because the interface follows the OpenAI chat completions shape, you send a request with the model field set to that id and your messages, and you can pass any of the supported parameters: max_tokens, response_format, seed, stop, temperature, tool_choice, tools, and top_p. If your existing code already targets an OpenAI-compatible endpoint, switching to this model is largely a matter of changing the model string and, where relevant, supplying tool definitions.

One thing to weigh is scope. The provider description frames the model around codebase exploration with view_file and grep, so tasks that have nothing to do with locating files in a repository may be better served by a general purpose text model. If you need image or audio input, this model does not accept it, since both input and output are text only.