I have two CCR1009-8G-1S-1S+ running 6.35.4 lets call them R1 and R2

the configuration is this:

one upstream BGP peer on both routers(I am unable to alter configuration on this router)
The Upstream BGP peer, connects to both my routers inside a /29 network.

I want R1 to be the primary path for outgoing and incoming traffic with R2 the backup.

R1 has the lower IP in the /29 and the lower router ID so it should be preferred path, however it is not always and seems to be random.
Upstream ISP are saying this is because I am sending local preference as 85 on all my routes.

How do I fix this? I have looked at SET BGP LOCAL Preference in my outbound BGP filters but it doesn't seem to work.

When I examine my advertised prefixes the local pref is blank.

You should set the local pref in your INBOUND filter.  Then it will work.

But here's the thing, the routes I am sending to the upstream peer are learned from OSPF, so I am originating them...
I am receiving only default route from upstream router

I already asked the ISP if they can set the local pref on their inbound route map but they told me it's something I need to do.

Okay - let's see if I can re-state the problem to make sure I understand it.

There are three routers ISP, R1, and R2, and they are all connected into a /29 network.
You want ISP to prefer R1 for all traffic they send to you.

When they say this is something you need to do on your end, I'd say they're wrong (but they may be referring you to one of the following "automatic" methods). At the end of the day, you're trying to influence your INGRESS traffic, and as such, this can only be done by influencing the EGRESS policy of the ISP. Hopefully they're not expecting you to use AS_PREPEND to do this, because while that would work, it will have unwanted side effects.

MEDs:
Your situation is exactly what MED is for - "multi-exit discriminators" but local_pref is the defacto standard for this behavior in today's world.... BGP communities can be much more flexible than MEDs. To do this with MEDs - you would need to make sure that the OSPF cost to reach destinations from R2 should be at least one point higher than as seen from R1. (basically, the MED is based on whatever the IGP's metric is - so if RIP, then the number of hops gets imported, or if OSPF, then the cost gets imported, if static, then the distance gets imported)
eBGP must be configured to accept MED from the neighbor, so your ISP may or may not allow this.....

LocalPREF:
(TL;DR for LocalPref: You need to be able to send a community which means "don't prefer this so much" on everything that R2 sends to ISP, so that ISP will always prefer R1 over R2. The ISP must be configured to support this.)

LocalPREF is a value that has global meaning within a single ASN. It doesn't transit over eBGP to other ASNs. Local_pref affects OUTBOUND traffic, though - so it's the ISP who needs to set LocalPREF in THEIR router based on which of your routers a path was learned from. (basically, set local_pref to 99 for everything from R2 would be sufficient)

Note that this decreased local_pref shouldn't be so reduced that it falls below the preference of the ISPs other peers/transit providers. In this case, the ISP would consider R2 to be worse than going all the way around the Internet to reach you....

The common way that BGP providers allow their customers to have self-service LocalPREF is through the use of communities.
If your ISP accepts communities, then they can tell you what communities they accept, and how the communities affect their policy. Commonly-available community actions include such behaviors as "do not advertise to other peers", "prepend X times to other peers", "raise local_pref", "lower local_pref" and "blackhole"

Each carrier makes their own "menu" of services, though - in my case, AT&T only offers very basic ones as above, but Level3's list is pages and pages long, and you can get very detailed in what you want to do....

Alternative:
If they're using Cisco or Mikrotik, you might be able to ask them nicely to set the weight higher on all routes learned from R1.....

AS-PREPEND:
The problem with AS-PREPEND is that this affects the global view of your advertisements. If you have some other ISP2 out there, then any AS-PREPEND you send to ISP1 may affect the global balance of traffic being sent to you via ISP1/ISP2.... In other words, if R1 goes down, suddenly the prepended route via R2 will be the only one available to ISP1, who will now show a "longer" path to reach you... so the world may simply choose to avoid ISP1 entirely, when all you wanted was to tweak the balance between two specific links. If they want you to use AS-Prepend, tell them they're being silly and that they should use one of the above methods I mentioned.

One more note on MED, instead of relying on your IGP metrics, you can just specify a MED when sending routes to an eBGP neighbor.

In routing filters, there is a BGP action "set BGP MED" - put MED of 50 on R1, and MED 100 on R2.
This will be the simplest (and in my opinion, the most appropriate) way to get your intended behavior.

Just insert a new rule at the beginning of your out-filter for the neighbor:
action=passthrough
bgp-action set BGP MED = X
(no criteria such as prefixes are required - leave your existing filter as-is below this new rule - this new rule simply means "set the MED and keep processing")

Ask your ISP if they will accept MEDs from your routers.

Thank you once again ZeroByte for being my hero and explaining things so clearly.

I didn't know that communities = local pref, I thought they were something completely different and not related.

I think it will make more sense now if I tell you that I am using communities already on both R1 & R2 and that they are sending the same community value.

Perhaps this is why the ISP reports the routes are having the local pref 85 on both.

The reason I had the same community value on both R1 and R2 advertisements is because these prefixes are also advertised at another POP with another ISP so I wanted my routers at this location R1 & R2 to be identical but redundant. 

You have given me enough information for me to start experimenting with changing the community values or maybe try the MED idea.

One more note on MED, instead of relying on your IGP metrics, you can just specify a MED when sending routes to an eBGP neighbor.

In routing filters, there is a BGP action "set BGP MED" - put MED of 50 on R1, and MED 100 on R2.
This will be the simplest (and in my opinion, the most appropriate) way to get your intended behavior.

Just insert a new rule at the beginning of your out-filter for the neighbor:
action=passthrough
bgp-action set BGP MED = X
(no criteria such as prefixes are required - leave your existing filter as-is below this new rule - this new rule simply means "set the MED and keep processing")

Ask your ISP if they will accept MEDs from your routers.

I had not heard if they support MED(was previously told to use communities for my multi-home setup) but looks like they do because I tried what you said and it works
I have R2 distributing default route into my OSPF network with a slightly higher cost than R1 and now I have R1 the primary router for inbound routes as well thanks to MED values.
This is what I wanted to achieve so thank you. I can't seem to rate your posts because it tells me no points left or something but I wan't to give you kudos.

Glad I could help. Yours is exactly the kind of situation MED was designed for - locally-significant difference between multiple links between neighboring ASNs, but not affecting global policy.

Another nice thing with MED is that it works even if the links are between different routers on both sides.

Some carriers don't like them because they can cause the carrier to transport your traffic longer on their network before handing it off to you.