Learn by using GetRuthless
Keep this guide beside your Ruthless chat. Copy one prompt, add the example it asks for and paste it into “Message Ruthless”. Nothing is sent until you choose to send it.
The short answer
GetRuthless offers standard and modified models in one workspace and API. Compare them against the same representative task before deciding which belongs in your workflow. Reduced refusal behaviour is a characteristic to investigate, not evidence of better accuracy.
Choose a useful comparison
Start with a job you actually repeat: explaining a service, proposing a small patch, reviewing an API contract or drafting product copy. A deliberately sensational prompt may reveal refusal differences while telling you little about everyday development value. Choose a task whose result you can inspect independently.
For example, ask each candidate to review a fictional order endpoint that trusts an account ID from its request body. Supply the same route, authentication helper and expected account boundary. A useful answer identifies the ownership mistake, suggests deriving the account from the authenticated session and proposes a test that attempts access from another account. Fluent prose alone earns no credit.
Select candidates without assuming a winner
The public model catalogue lists current IDs. Standard examples include gpt-sol, claude-sonnet and gemini-argon; modified examples include kimi-pro-abliterated, ruthless-ai and ruthless-forge. These are possible comparison candidates, not a measured ranking. Confirm availability and current prices before using an ID. Website labels and API IDs serve different purposes. [1][3]
Compare a standard model and a modified model with the same context and settings where supported. Then add another candidate only if the first comparison leaves a meaningful question. Abliteration aims to reduce refusals; it does not establish truthfulness, security, neutrality or a guaranteed improvement over a standard model. A standard option may be your preferred everyday choice.
Measure the whole useful result
Write the acceptance checks before reading responses. In the order example, score whether the model spots the account boundary, preserves valid requests, proposes executable checks and marks missing information. Count unsupported claims and unnecessary changes as costs. If you apply a patch, run its checks in an isolated branch and inspect the final diff.
Record elapsed time to a usable answer, confirmed usage and the time you spend correcting it. Compare current input, output and any extra tool or research charges; a lower advertised token price does not guarantee a cheaper completed task. Keep prompt length, effort and output allowance comparable. Treat a single slow response as an observation, not a universal latency benchmark. [1][2]
Repeat once, then choose for this workflow
Use a second task with different demands: a UI state bug rather than an account boundary, for instance. Keep one previously unseen case out of prompt tuning. If a model succeeds only after you teach it the answer, you have measured coaching rather than independent problem solving. Record uncertainty when outcomes are close.
In GetRuthless chat, select each model explicitly and paste the same redacted context into a fresh comparison conversation. In an API harness, preserve model IDs and request identities alongside results. This guide supplies a method, not test results: no paid model comparison was run to establish a winner. Choose the option that meets your checks at an acceptable total cost, and keep alternatives for different tasks.
Review this redacted order endpoint and its authentication helper. Identify account-isolation mistakes, propose the smallest repair and list tests with expected outcomes. Separate facts visible in the supplied code from assumptions. Do not claim to have run tests. Context: [paste route, helper and contract].Common questions
Should every task use an abliterated model?
No. Choose according to observed results on the task. Refusal behaviour is one dimension; accuracy, useful output, latency and total cost also matter.
Can a model compare itself fairly?
It can help organise a rubric, but its self-description is not performance evidence. Use your own fixtures, actual outputs and confirmed receipts to make the choice.
Sources & further reading
The example prompts and workflows are GetRuthless guidance. Source references support the concepts explained; they are not an endorsement of GetRuthless.
Put the guide into practice.
Open Ruthless and choose an available standard or abliterated model suited to your task. Copy a prompt above, add the context it asks for and check the result. You can compare models in the same workspace; see current pricing before sending requests.