Karivox
Overview
Payments
AI key check
Prop firm rules
Market data
Plans & prices
Changing a price asks for your password again. Nothing here lives in the code — a new owner runs this business without opening a single source file.
Bot prices
Three ladders: by the share of start dates that pass where the evaluation has a deadline, by days to pass where it has none, and by the average month in swing trading. Discounted grants us resale and trading rights; private does not. A negative price means the step is not offered at all.
What the models charge US is a cost, not a price, and it stays in AI spend — beside the report that shows when one of those numbers has gone stale. Everything on this page is money that comes in.
Keys & payments
AI
Each job below uses one model, never two at once. The key belongs to the provider, not to the job: choose the same provider for both and you enter its key once. Choose different ones and each asks for its own.
Outbound proxy
Two things go out through this and nothing else does: captions from YouTube, and the prop firm rules we re-read from the firms' own pages. Both are refused to addresses that belong to data centres — YouTube asks the server to prove it is not a bot, Apex answers 403 outright — and from a home connection both work without complaint. No setting of ours fixes that: the request has to arrive from a residential address. Buy a residential proxy, put its endpoint here, and test it below. The proxy is the fallback, not the first road: both jobs try going out directly first and only then through it. The models, Stripe and the mail service always go out directly, and their traffic is never billed to the proxy.
Connecting Stripe
- Stripe dashboard → Developers → API keys. Copy the secret key (sk_live_…) and the publishable key (pk_live_…).
- Paste both above.
-
Developers → Webhooks → Add endpoint. URL:
https://your-domain/api/stripeTick exactly these events. Anything not ticked never reaches us — and a refund we never hear about leaves the customer holding everything they bought: - Copy the signing secret (whsec_…) into the Stripe webhook signing secret field above.
- Set Take real payments to yes.
Until all four are in place the site runs in training mode: plans activate without payment so you can test the whole flow. Nobody is charged and no card is asked for.
Limits & method
Numbers here are measured, not chosen, and each is explained under the field it belongs to. Loosening one does not make the method sharper — it makes the reports dishonest.
Site
Users
Users
| Name | Plan | Checks | Checks used | Extractions used | Status | Source | Created |
|---|
All users' checks
| # | When | Strategy | Best score | State |
|---|
Traffic
Give every place you post the link its own label, and this table shows which of them brought people who paid. A label nobody created here is still counted, on a row of its own.
New link
Labels
| Label | Visits | Signups | Runs | Payers | Revenue |
|---|
Finds
Strategies that passed all three conditions. They are written here by themselves, the moment the run ends, and they stay: deleting the person who sent one does not delete the find. Each row keeps its own copy of everything — the sender, the rules, the numbers and the thresholds that were in force that day.
Finds
| # | When | Source | Market | Account | Passes in | Bot price | Trades | State |
|---|
Activity
Who did what, and when. Every run and every extraction the service has ever done, whoever asked for it. Traffic says where people came from and Finds says which strategies passed; this is the work itself.
Strategy runs
| # | When | Strategy | Market | State | Re-runs |
|---|
Extracted, never run
The rules came back and the extraction was paid for, but the person never started the run. We paid a model for each of these.
| # | When | Strategy | Source |
|---|
Extractions
Every rule extraction we ran for somebody, with the model that did it and what it cost us. Our own model comparisons are not here: those are re-runs to pick a model, not work a customer asked for.
| When | Job | Model | Seconds | Spent | Check |
|---|
Work per person
Counted in the database, not from the lists above: those come back capped, and counting them would say how much of a person fitted in the slice. Pick a row to see everything that person did.
| Name | Plan | Checks | Extractions | Never run | Cost to us | Last run |
|---|
AI spend
Every call to a model, with its raw token split kept alongside the money. Raw tokens are the point: prices here are typed in by hand, so one of them will eventually be wrong — and with the tokens stored, everything recounts. A model with no price in the table is reported as such and never priced off a neighbour.
What to top up
Only DeepSeek reports a real balance to an ordinary API key. For Claude, OpenAI and Grok that needs a separate organisation admin key, so the “left” column is our own arithmetic and nobody else’s: what you recorded as put in, minus what has been spent since the day of the first. Where both numbers stand side by side and disagree, that is worth knowing: it means either a top-up nobody recorded here, or a model missing from the price table.
| Provider | Spent this month | Put in, our record | Spent since then | Left, our count | Balance from the provider |
|---|
Money put in
Recorded by hand, because there is nowhere else to get it from. Everything above the “left” column stands on these rows. A wrong row is corrected, not deleted: voided rows stay visible, so that a jump in the remainder always has an explanation next month.
| Date | Provider | Amount | Note | Recorded by |
|---|
Spent this calendar month
The same month as the tile above, counted the same way, in UTC. Add the provider rows up and you get that tile. Models nobody called this month are not listed — but a model whose price we do not have is listed anyway, because that is not zero, it is unknown.
| Provider | Model | Job | Spent | Calls | Input | Output |
|---|
Spent since the very first call
Everything ever recorded, not this month. Same tokens cost different money depending on who answered — that is the whole reason this table exists.
| Provider | Model | Job | Spent | Calls | Input | Output |
|---|
Model prices
None of the three providers gives prices through an API — this table is typed in by hand, per million tokens, and its only job is to be honest about going stale. DeepSeek charges by the hour of day, so it gets two rows per model and the window itself lives here, not in the code. Editing these does not ask for your password: they are what we pay, not what anyone pays us.
| Provider | Model | Window | Input | Cache read | Cache write | Output | Hours, UTC | Checked | Confirmed |
|---|
Latest calls
| When | Job | Model | Input | From cache | Output | Seconds | Spent |
|---|
Same extraction, another model
Re-runs the rule extraction only — the historical run is not repeated, it takes minutes and has nothing to do with the model. The earlier extraction is kept, never overwritten, and both are shown side by side with what each cost and how long it took. Which set of rules is better is a judgement for a person: nothing here scores them. This spends real money, which is why the button lives in the admin panel and nowhere else.
The list of checks lives in Activity now — it is a log of what people did, not a part of the model comparison. Open a check there and this same side-by-side window comes up.
Bot requests
Strategies that passed and whose owner asked for the bot. Nothing was charged: agree the scope, then send the invoice. The price shown is the one the ladder offered at the moment of the request.
Bot requests
| # | When | Market | Passes in | Kind | Price | State |
|---|
Refund requests
Only what the customer has not used is refundable, and an untouched one-off purchase is refunded by the customer themselves without landing here at all. What arrives here is everything the rule does not cover: disputes, our own failures, odd cases. Approving sends the money back through Stripe from this page and takes the credited checks or extractions off the balance — do not do it by hand in the Stripe dashboard, or the two halves come apart. Declining needs a reason: the customer reads it, and a refusal without one reads as a swindle and ends in a chargeback. The policy promises an answer within two business days.
Refund requests
| # | When | Purchase | Paid | Unused | Reason | State |
|---|
Consents
Every acceptance of the Terms of Service, the Privacy Policy, the Risk Disclosure and the Refund Policy — at signup and at every purchase. This is what a refund argument, a chargeback or a complaint about the terms is answered with, and it is the only place the answer exists: an unrecorded tick box proves nothing. Records here outlive the account they belong to, because the dispute arrives after the account has gone.
Consents
| # | When | Bought | Wording | From |
|---|
Audit log
Every settings change, every account edit, every failed sign-in. This exists so a change can always be traced to a person.
Audit log
| When | Who | Action | Detail |
|---|